Ein Replay ist eine Rekonstruktion, kein Video
Das häufigste Missverständnis über Session Replay ist, dass es den Bildschirm aufzeichnet. Das tut es nicht. Ein Replay erfasst das DOM – die Struktur der Seite – plus jede Änderung daran, zusammen mit Klicks, Scrollbewegungen, Eingabe-Events, Netzwerk-Timings und Konsolenfehlern. Bei der Wiedergabe wird die Seite in deinem Browser aus diesen Daten neu aufgebaut.
Genau dieser Unterschied ist der springende Punkt. Weil ein Replay aus strukturierten Daten statt aus Pixeln besteht, kannst du es durchsuchen, genau zu dem Moment springen, in dem ein Fehler ausgelöst wurde, und den Zustand des DOM in diesem Augenblick lesen. Eine Bildschirmaufnahme bietet dir nichts davon und kostet bei der Erfassung weit mehr Bandbreite.
Was es dir bietet, was ein Stack-Trace nicht kann
Ein Fehler-Tracking sagt dir, dass in Zeile 214 ein TypeError geworfen wurde. Es sagt dir nicht, dass der Nutzer das Formular bereits zweimal abgeschickt hatte, dass der zweite Versuch über eine langsame Verbindung lief oder dass der Button danach deaktiviert blieb. Replay liefert die Abfolge von Ereignissen, die den Zustand erzeugt hat, an dem dein Code gescheitert ist.
In der Praxis schrumpft dadurch der langsamste Teil des Debuggens: die Reproduktion. Statt Schritte aus einem einzeiligen Bug-Report zu erraten, siehst du dir den Weg an, den der Nutzer tatsächlich genommen hat.
So nutzt du es, wenn ein Bug reinkommt
Arbeite dich vom Fehler aus rückwärts vor, statt vom Session-Start aus vorwärts. Finde den Fehler in deinem Monitoring, öffne das verknüpfte Replay und spring zum Zeitstempel. Spul dann dreißig Sekunden zurück – die Ursache liegt fast immer in der halben Minute vor dem Symptom, nicht am Anfang der Session.
Prüfe drei Dinge in dieser Reihenfolge: was der Nutzer unmittelbar davor angeklickt hat, ob eine Anfrage fehlgeschlagen ist oder hing, und ob das, was er auf dem Bildschirm sah, dem entsprach, was du rendern wolltest. Die meisten Bugs lösen sich bei einem dieser drei Punkte.
Was es nicht löst
Replay zeigt dir, was passiert ist, nie warum die Person es getan hat. Wenn ein Nutzer ein Formular abbricht, sagt dir die Aufzeichnung, bei welchem Feld er aufgehört hat – sie kann dir nicht sagen, ob die Frage verwirrend, aufdringlich oder einfach zu lang war. Diese Antwort bekommst du, indem du fragst.
Außerdem taugt es wenig für aggregierte Fragen. Eine Aufzeichnung ist eine Anekdote. Wenn du wissen musst, wie oft etwas passiert, ist das ein Funnel oder eine Event-Abfrage; nutze Replay, um den Abbruch zu erklären, nicht, um ihn zu messen.
Ein Tool speziell fürs Debuggen wählen
Wenn Debuggen die Aufgabe ist, gewichte drei Dinge höher als alles andere. Erfassung von Konsole und Netzwerk – ohne sie schaust du einen Stummfilm. Verknüpfung von Fehlern mit Replays, damit dich eine Exception direkt zur Session bringt, die sie ausgelöst hat, statt zu einer Liste, die du durchsuchen musst. Und Datenschutzkontrollen, die fein genug sind, um das Tool nützlich zu halten: Jede Eingabe zu maskieren schützt Nutzer, kann aber genau den Wert verbergen, der den Bug ausgelöst hat – achte also auf Regeln auf Feldebene statt auf einen Alles-oder-nichts-Schalter.