„Was hast du gemacht, kurz bevor es kaputtging?“ ist die Frage, die jedes Entwicklungsteam stellt und auf die kaum jemand, der einen Bug meldet, genau antworten kann. Leute wissen nicht mehr, welchen Button sie als zweiten geklickt haben, ob die Seite fertig geladen war oder dass sie mitten im Formular auf Zurück gedrückt haben. Session-Replay beantwortet die Frage, ohne sie zu stellen: eine durchspulbare Aufzeichnung dessen, was im Browser tatsächlich passiert ist, angehängt an den Fehlerbericht.
Wie Session-Replay tatsächlich funktioniert
Modernes Session-Replay ist kein Video. Pixel aufzuzeichnen würde riesige Datenmengen erzeugen, wäre langsam und blind für die Struktur der Seite. Stattdessen machen Tools wie rrweb – die Open-Source-Engine, auf der das Replay von BugDump aufbaut – einen Snapshot des DOM und zeichnen dann Mutationen auf: hinzugefügte und entfernte Knoten, geänderte Attribute, Eingabewerte, Scrollen, Mausbewegungen, Klicks.
Die Wiedergabe baut die Seite aus diesen Daten wieder auf, so wie man eine Schachpartie aus der Notation nachspielt, statt das Brett zu filmen. Das Ergebnis ist kompakt, und weil es strukturell statt visuell ist, kannst du durchspulen und genau sehen, mit welchem Element die Person interagiert hat, nicht nur, wo ihr Cursor auf dem Bildschirm war.
Die praktische Folge: Replay ist günstig genug, um ständig im Hintergrund zu laufen. Die Momente vor der Entscheidung, einen Bug zu melden, sind also schon aufgezeichnet, wenn jemand auf den Melde-Button klickt. Genau das können Abläufe im Stil von „Jetzt Bildschirm aufnehmen“ nie liefern: Der Bug ist schon passiert, wenn irgendwer die Aufnahme startet.
Was Replay dir sagt und Logs nicht
Console- und Netzwerk-Logs sagen dir, was der Code gemacht hat. Replay sagt dir, was die Person gemacht hat. Bugs leben in der Lücke zwischen beidem, und manche Arten lassen sich ohne die Sicht der Person kaum diagnostizieren:
Reihenfolge-Bugs: Das Modal geht nur kaputt, wenn es geöffnet, geschlossen und wieder geöffnet wird. Keine einzelne Logzeile sagt das; das Replay zeigt es in zehn Sekunden.
Race Conditions: Jemand hat geklickt, bevor eine Anfrage fertig war. Das Replay hat den Zeitstempel des Klicks, das Netzwerk-Log den der Antwort, und zusammen ergeben sie die Diagnose.
„Falsche“ Eingaben, die gar nicht falsch sind: Jemand hat einen Wert mit Leerzeichen am Ende eingefügt, oder Autofill hat ein Feld befüllt, mit dem du nicht gerechnet hast. Das Replay zeigt den tatsächlichen Zustand des Formulars.
Verwirrung über den UI-Zustand: Die Person war in einer gefilterten Ansicht, in einem veralteten Tab oder mitten in einer ungespeicherten Bearbeitung. Der Zustand des DOM ist für jeden Moment da.
Umgekehrt gilt dasselbe: Replay ohne Logs zeigt dir, dass die Seite kaputtging, aber nicht, warum. Die nicht abgefangene Exception steht in der Console, der 500er im Netzwerk-Tab. Deshalb ist Replay als ein Panel eines vollständigen Berichts am nützlichsten, nicht als eigenständiges Tool.
Replay im Workflow für Fehlerberichte
Das traditionelle Zuhause von Session-Replay ist Analytics: alle aufzeichnen und dann Sessions stichprobenartig ansehen, um die UX zu untersuchen. Dieses Modell kann viel, ist aber schwerfällig: Du speicherst Tausende Sessions, um dir gelegentlich eine anzusehen.
Bei Fehlerberichten ist es umgekehrt. BugDump sammelt das Replay im Hintergrund und hängt es an, wenn jemand einen Bericht abschickt, zusammen mit dem Console-Puffer (bis zu 300 Einträge, 2.000 während einer Aufnahme), dem Netzwerk-Puffer (150 Anfragen, 1.000 während einer Aufnahme, Fehlschläge markiert), Details zur Umgebung und Performance-Metriken. Du bekommst Replays genau für die Sessions, in denen etwas schiefging und ein Mensch das gesagt hat. Aussagekräftigere Sessions gibt es nicht.
Der Bericht kommt als vollständige Fallakte: Lies den einen Satz, mit dem die Person den Bug beschreibt, spul durch das Replay, um die Aktion zu sehen, such in der Console die Exception, die sie ausgelöst hat, und finde die fehlgeschlagene Anfrage im Netzwerk-Log. Bei vielen Bugs ersetzt diese Abfolge das komplette Gespräch über „Schritte zur Reproduktion“.
Datenschutz
Eine DOM-Aufzeichnung kann alles enthalten, was eine Seite anzeigt, auch das, was Leute eintippen. Nimm das ernst:
Entscheide, was aufgezeichnet wird. Replay sollte pro Projekt bewusst eingeschaltet werden und keine unsichtbare Voreinstellung sein, die du vergessen hast. BugDump bietet es als Feature-Flag (
features.sessionReplay), das du steuerst.Filter sensiblen Traffic. Wenn du Netzwerkdaten erfasst, halte Endpunkte von Drittanbietern oder sensible Endpunkte mit Filtern ganz aus den Puffern heraus: verworfen, bevor sie gespeichert werden, nicht nachträglich geschwärzt.
Lass die meldende Person Bildinhalte schwärzen. Mit einem Weichzeichner beim Annotieren des Screenshots kann jemand die eigene Kontonummer vor dem Absenden verbergen. Schwärzen durch die Person, die weiß, was sensibel ist, schlägt Schwärzen per Regex.
Leg es offen. Deine Datenschutzerklärung sollte sagen, dass Fehlerberichte eine Aufzeichnung der Session der meldenden Person enthalten können. Wer einen Bug meldet, ist meist froh, dass die Daten mitgehen, sollte es aber wissen.
Wann Replay zu viel ist
Nicht jedes Projekt braucht Replay vom ersten Tag an. Eine Content-Website ohne interaktiven Zustand holt den meisten Nutzen aus Screenshots und Console-Logs. Replay verdient seinen Platz, wenn deine App Abläufe hat – mehrstufige Formulare, Editoren, Checkouts, Dashboards –, bei denen der Weg so wichtig ist wie das Ziel. Wenn in deinen letzten fünf Gesprächen über Bugs der Satz „Okay, aber was hast du davor geklickt?“ vorkam, macht sich Replay sofort bezahlt.
Unterscheide auch, welche Art „Aufzeichnung“ du bekommst. Das Widget von BugDump bietet beides: eine bewusst gestartete Bildschirmaufnahme (die Person erklärt ein Problem, während sie ihren Bildschirm aufnimmt) und Session-Replay im Hintergrund (automatisch, an Berichte angehängt). Das eine ist ein Werkzeug zur Verständigung, das andere eines für die Spurensicherung. Sie ergänzen sich, statt sich zu ersetzen.
Die älteste Lücke in Fehlerberichten
Session-Replay schließt die älteste Lücke in Fehlerberichten: den Unterschied zwischen dem, was Leute erzählen, und dem, was passiert ist. Zusammen mit Console-Logs, Netzwerkdaten und Details zur Umgebung, automatisch erfasst in dem Moment, in dem eine echte Person auf ein echtes Problem stößt, macht es „nicht reproduzierbar“ vom üblichen Abschlussgrund zur Ausnahme.
Session-Replay ohne Überwachung – wie BugDump Replay einsetzt: auf einen Bericht beschränkt, von der meldenden Person schwärzbar und mit einer Zeile abschaltbar.
So erfasst du Console-Logs und Netzwerk-Requests aus fremden Browsern – wie du Console, Fehler, fetch und XHR instrumentierst, ohne die Seite kaputtzumachen, die du beobachtest.
Bei mir läuft’s: ein Leitfaden für nicht reproduzierbare Bugs – die rund acht Unterschiede zwischen zwei Rechnern, hinter denen sich „nicht reproduzierbar“ fast immer verbirgt.