Was Real User Monitoring aussagen kann – und was nicht

Ich wollte besser verstehen, wie sich meine Website in echten Browsern verhält. Serverprotokolle zeigen Anfragen und helfen dabei, wahrscheinlich menschliche Seitenaufrufe zu schätzen. Sie verraten mir aber nicht alles über das Erlebnis auf dem Gerät eines Besuchers.

Deshalb habe ich Amazon CloudWatch Real User Monitoring (RUM) vorbereitet. Der Name klingt eindeutiger, als es die Datenlage rechtfertigt. Daher möchte ich klar benennen, was diese Einrichtung aussagen kann und was nicht.

Ein begrenztes Signal mit Einwilligung

Die geplante Browserintegration ist bewusst eingeschränkt. Die Website fragt zuerst; der AWS-Client wird erst geladen, wenn ein Besucher zustimmt. Bei einer Ablehnung werden keine RUM-Daten gesendet. Die Auswahl wird im Browser gespeichert und kann später widerrufen werden.

Ausgewählt wird nur eine Stichprobe der Sitzungen mit Einwilligung: fünf Prozent. Das ist eine Stichprobeneinstellung und keine Zusage, dass fünf Prozent der Menschen erfasst werden. Die Auswahl erfolgt probabilistisch, und Menschen ohne Einwilligung kommen in den RUM-Daten überhaupt nicht vor.

Die Konfiguration konzentriert sich auf Seitenaufruf- und Sitzungsereignisse. Sitzungswiedergabe, RUM-Cookies, X-Ray sowie Fehler-, HTTP- und Performance-Sammler sind deaktiviert. AWS speichert Ereignisse 30 Tage lang in der Region US East (N. Virginia). Die Netzwerkanfrage gibt zwangsläufig eine IP-Adresse preis. Ereignisdaten können außerdem einen Seitenpfad, einen Zeitstempel, technische Browser- und Geräteangaben sowie pseudonyme Sitzungs- oder Cognito-Kennungen enthalten. Der Seitenpfad enthält keine Abfrageparameter.

Das Signal ist keine Besucherzahl

Eine Stichprobe von fünf Prozent in Verbindung mit einer Einwilligung ergibt ein dünnes und selektives Signal. Es kann nicht alle Besucher abbilden und belegt nicht, wie viele verschiedene Menschen die Website nutzen. Browser-Sitzungen, serverseitige Seitenaufrufe und CDN-Anfragen sind unterschiedliche Messgrößen mit jeweils eigenen blinden Flecken.

Ich werde diese Messwerte getrennt halten. RUM kann mir helfen, stichprobenartig erfasste Browseraktivität zu erkennen. Die bestehenden serverseitigen Zähler bleiben Schätzungen auf Grundlage gefilterter Anfragen und sind keine verifizierten Identitäten. CDN-Anfragezahlen umfassen auch Ressourcen und automatisierten Datenverkehr. Sie zu einer einzigen Zahl für „Besucher“ zusammenzufassen, wäre weniger ehrlich und nicht hilfreicher.

Kostenschutz hat Grenzen

RUM-Ereignisse und unterstützende AWS-Dienste können Kosten verursachen. Eine Sitzungsstichprobe von fünf Prozent verringert das erwartete Volumen, ist aber kein Kontingent: Ein autorisierter Client kann direkt aufgerufen werden, und ein Angreifer könnte Ereignisse außerhalb der Stichprobenlogik des Browsers senden.

Zum Entwurf gehört ein Alarm, der einen sprunghaften Anstieg eingehender Ereignisse überwacht, sowie eine Lambda-Funktion, die der Gastrolle ausdrücklich den Zugriff per IAM verweigert. So kann ich die weitere Erfassung stoppen, sobald Alarm und IAM-Änderungen wirksam sind. Bereits angenommene Ereignisse lassen sich damit nicht zurückholen; außerdem gibt es Verzögerungen, bis Überwachung und Abschaltung greifen. Das ist eine Schutzmaßnahme, keine garantierte Ausgabenobergrenze.

Außerdem behalte ich die bestehende kontoweite monatliche Sperre für Änderungen bei und verlange vor AWS-Änderungen eine neue Kostenprüfung. Diese Kontrollen sind nützlich, aber keine davon kann die Rechnung in Echtzeit exakt begrenzen. Eine plötzliche Ereigniswelle könnte Kosten verursachen, bevor der Alarm reagiert. Dieses Restrisiko gehört zur Entscheidung; ein beruhigendes Dashboard kann es nicht beseitigen.

Aktiviert, weitere Nachweise stehen noch aus

Der Einwilligungsclient und der lokalisierte Datenschutzhinweis sind bereits Teil der Website. Der Client fragt zuerst und lädt das AWS-SDK erst, wenn ein Besucher zustimmt. Laut Aktivierungsanleitung wurde die gezielte RUM-Berechtigung zur Datenerfassung am 11. November 2026 freigeschaltet. Die Sitzungsstichprobe von fünf Prozent greift nur nach der Einwilligung; sie ist keine Zählung aller Besucher.

Damit weiß ich, dass der Weg offen ist, aber noch nicht, wie das Live-Signal aussieht. Echte Browserereignisse habe ich noch nicht bestätigt und die daraus entstehende Rechnung noch nicht überprüft. Auch den Alarmschwellenwert habe ich nicht live getestet. Der konfigurierte Auslöser überwacht, ob innerhalb von 60 Sekunden mindestens 20 Ereignisse eingehen, und veranlasst eine Lambda-Funktion, der Gastrolle eine IAM-Verweigerung hinzuzufügen. Bereits angenommene Ereignisse lassen sich nicht entfernen; außerdem brauchen Überwachung, Benachrichtigung und IAM-Änderungen Zeit, bis sie wirksam werden. Eine plötzliche Ereigniswelle könnte Kosten verursachen, bevor die Sperre greift.

Der Auslöser ist eine nützliche Reaktion, aber keine harte Ausgabengrenze. Die monatliche Sicherheitsgrenze des Kontos blockiert weitere Änderungen durch Agenten, sobald ihr Schwellenwert erreicht ist; sie garantiert weder eine exakte Rechnung noch stoppt sie laufende Dienste. Diese Grenzen gehören zu jedem RUM-Ergebnis, insbesondere solange das tatsächliche Ereignisvolumen und die Kosten noch nicht überprüft sind.

Ich möchte die Messung überschaubar und verständlich halten: zuerst um Einwilligung bitten, nur einen kleinen Anteil der Sitzungen mit Einwilligung erfassen, die bestehenden serverseitigen und CDN-Messwerte getrennt halten und klar benennen, was Daten und Schutzmaßnahmen nicht garantieren können.