Real User Monitoring (RUM)

Real User Monitoring (RUM) ist ein Verfahren, um zu messen, wie sich eine Website oder Anwendung für die Menschen verhält, die sie tatsächlich nutzen. Ein kleiner Codeabschnitt in der Seite oder ein SDK in der mobilen App zeichnet bei jedem echten Besuch Zeiten und Fehler auf und sendet sie zur Auswertung an einen Erfassungsdienst.

Das Wort „Real“ ist der Kern. Ein Labortest zeigt, wie eine Seite auf einem schnellen Rechner in einem einzigen Rechenzentrum lädt. RUM zeigt, wie sie auf einem drei Jahre alten Smartphone im Zug lädt, bei schwachem Netz und mit einer Browser-Erweiterung, die eigene Skripte einschleust. Diese Bedingungen sind zu vielfältig, um sie nachzustellen, daher lassen sie sich nur dort erfassen, wo sie auftreten.

RUM ist passiv: Es erzeugt keinen Testverkehr, sondern beobachtet nur. Es ist eine Hälfte der Messung der digitalen Erfahrung, die andere ist das synthetische Monitoring, und es ist eine Lesart des weiter gefassten Begriffs End User Monitoring, der auch die Aktivitätserfassung umfasst. Es gehört zur allgemeinen Praxis des Monitorings. Trotz des Namens ist der „Nutzer“ hier eine Besuchersitzung und kein Beschäftigter, der bewertet wird.

Unabhängig vom Anbieter folgt jedes RUM-Setup demselben Weg vom Gerät des Besuchers bis zum Dashboard.

1. 1

   Instrumentieren

   Fügen Sie der Seite ein Skript oder der App ein SDK hinzu. Es registriert Beobachter für die Leistungsdaten, die der Browser ohnehin bereitstellt.

2. 2

   Erfassen

   Während des Besuchs liest das Skript Zeiten für Navigation, Ressourcen, Darstellung und Interaktionen aus und vermerkt JavaScript-Fehler und fehlgeschlagene Anfragen.

3. 3

   Anreichern

   Jeder Datensatz erhält Kontext: Seite oder Bildschirm, Browser, Gerätekategorie, Verbindungstyp, ungefährer Standort und eine Sitzungskennung.

4. 4

   Senden

   Das Skript sendet die Daten in kleinen Paketen als Beacon, idealerweise wenn die Seite ausgeblendet oder geschlossen wird, damit der Besuch selbst nicht gebremst wird.

5. 5

   Aggregieren

   Das Backend gruppiert die Datensätze nach Seite, Release, Land oder Gerät und zeigt Verteilungen, Trends und Alarme.

RUM erfasst viele Signale, doch drei sind in der Webarbeit Standard. Sie heißen Core Web Vitals, und Google veröffentlicht Zielwerte, die als gut gelten, wenn sie bei mindestens 75 Prozent der Besuche erreicht werden. Darüber hinaus verfolgt RUM meist die Antwortzeit des Servers (TTFB), JavaScript-Fehler, die Dauer der API-Aufrufe der Seite und in mobilen Apps Abstürze und Startzeiten.

RUM-Daten sind eine Verteilung, keine Einzelzahl. Ein Durchschnitt verdeckt die Besucher, die am meisten leiden, deshalb lesen Teams Perzentile: Der Median zeigt den typischen Besuch, das 75. oder 95. Perzentil den langsamen Rand. Vergleichen Sie über Releases hinweg dasselbe Perzentil, sonst wirkt eine veränderte Besucherzusammensetzung wie eine Änderung der Website.

Den eigentlichen Nutzen bringt die Aufteilung. Gliedern Sie die Daten nach Gerätekategorie, Browser, Verbindungstyp, Seitenvorlage und Geolokalisierung, und das Problem benennt sich meist selbst: ein schweres Skript, das nur einfache Smartphones ausbremst, eine Region weit entfernt vom nächsten Server, ein Release, das die Fehlerrate in einer Browserversion erhöht hat. Die Methode hat auch blinde Flecken. Sie sieht nur Besuche, bei denen das Skript geladen wurde, und Blocker sowie Einwilligungsentscheidungen nehmen einen Teil davon weg.

RUM wird selten allein eingesetzt. Synthetisches Monitoring führt per Skript gesteuerte Prüfungen von festen Standorten nach Zeitplan aus, und Application Performance Monitoring (APM) verfolgt, was in den Servern geschieht. Jedes beantwortet eine andere Frage:

Die meisten enttäuschenden RUM-Projekte scheitern auf vertraute Weise:

• Durchschnitte statt Perzentile lesen, sodass die langsamsten Besucher unsichtbar bleiben
• Zeiträume mit anderer Mischung aus Geräten, Ländern oder Verkehrsquellen vergleichen und das Ergebnis dem letzten Release zuschreiben
• Vollständige URLs mit Query-Parametern, Formularwerten oder Nutzerkennungen erfassen, die die Fragestellung nie brauchte, ein Problem, das Anonymisierung an der Quelle beseitigen würde
• So aggressiv samplen, dass seltene Seiten und seltene Fehler verschwinden
• Nur die Geschwindigkeit beobachten und sie nie mit Ergebnissen wie Absprungrate, Conversion oder Support-Anfragen verknüpfen

RUM-Daten dienen mehreren Teams, und jedes braucht einen anderen Ausschnitt. Ebenso wichtig ist, wofür RUM nicht gedacht ist: Es ist kein Werkzeug, um einzelne Beschäftigte zu beobachten, das ist Aufgabe der Überwachung der Nutzeraktivität.

RUM erfasst Leistungsdaten, doch auch diese können personenbezogen sein. IP-Adressen, Geräteeigenschaften, Sitzungskennungen und URLs können auf eine Person verweisen, daher kann das Datenschutzrecht (in der EU die DSGVO) greifen, und die ePrivacy-Regeln zum Speichern oder Auslesen von Informationen auf dem Gerät können eine Einwilligung verlangen. Eine datenschutzfreundliche Konfiguration verzichtet auf dauerhafte Kennungen, kürzt IP-Adressen, entfernt Query-Parameter und respektiert die Entscheidung im Einwilligungsbanner. Klären Sie die Einzelheiten für Ihre Märkte mit Rechtsberatung.

Ein sinnvoller Anfang ist klein. Wählen Sie die drei oder vier Seiten mit dem größten Ertrag, messen Sie darauf die Core Web Vitals, richten Sie einen Alarm auf das 75. Perzentil ein und prüfen Sie ihn nach jedem Release. Geht es Ihnen darum, was Beschäftigte tun, und nicht darum, wie eine Website performt, ist die passende Kategorie das Monitoring der Mitarbeiteraktivität, das andere Daten und andere Schutzmaßnahmen verwendet.