Wie Session Replay funktioniert und was es nicht sieht

Was ist Session Replay?

In der Web-Analyse ist Session Replay eine Technik, die den Besuch eines Nutzers als abspielbare Wiedergabe rekonstruiert, indem sie DOM-Änderungen und Eingabeereignisse aufzeichnet, statt den Bildschirm zu filmen. Der Recorder serialisiert das DOM der Seite einmal beim Laden und streamt danach jede Mutation, jeden Klick, jedes Scrollen, jeden Tastendruck und jede Viewport-Änderung als zeitgestempeltes Ereignis. Ein Player wendet diesen Ereignisstrom später auf eine neu aufgebaute Kopie der Seite in einem sandboxed iframe an, weshalb die Wiedergabe wie ein Video aussieht, aber nur einen Bruchteil davon wiegt.

Dieser Unterschied bestimmt alles Weitere, von dem, was ein Replay belegt, bis zu dem, was seine Speicherung kostet.

Wie zeichnet Session Replay eine Seite ohne Video auf?

Ein Session-Replay-Recorder erfasst Zustand, keine Pixel. Beim Laden der Seite durchläuft er den DOM-Baum und serialisiert jeden Knoten in eine JSON-Struktur, wobei er jedem Knoten eine stabile numerische id zuweist. Diese erste Nutzlast ist der vollständige DOM-Snapshot, und alles danach ist ein Diff.

Ab diesem Punkt hängt der Recorder einen MutationObserver und eine Reihe von Event-Listenern an. Jede Änderung wird zu einem kleinen Datensatz: Knoten 412 hat ein Kind bekommen, bei Knoten 205 wurde der Text ersetzt, das Fenster scrollte auf y=1,200 bei Millisekunde 8,431. Die Open-Source-Bibliothek rrweb hat das Format etabliert, dem die meisten Anbieter folgen, samt dem Modell einer id pro Knoten und der Aufteilung in Snapshot plus Inkremente.

Die Wiedergabe kehrt den Vorgang um. Der Player baut aus dem Snapshot ein Dokument, hängt es in ein iframe mit deaktivierten Skripten ein und wendet die Mutationen dann in aufgezeichneter Reihenfolge gegen eine virtuelle Uhr an. Auf der abgespielten Seite wird nichts ausgeführt, und der Cursor, den Sie sehen, ist ein gezeichnetes Overlay, kein aufgezeichneter Zeiger.

Was kann ein Session Replay erfassen, und was entgeht ihm?

Ein Session Replay erfasst alles, was im DOM der aufgezeichneten Seite steht, und nichts, was außerhalb davon liegt. Weil der Recorder dasselbe DOM liest, das der Browser rendert, erscheinen von einer Browser-Erweiterung eingefügte Inhalte im Replay genau so, wie der Besucher sie gesehen hat, was Fehlerberichte erklärt, die niemand im Team reproduzieren kann.

Die Lücken sind konkret:

• Canvas- und WebGL-Flächen werden als leere Kästen gerendert, sofern der Recorder nicht für ihre Erfassung konfiguriert ist, denn ihre Inhalte sind keine DOM-Knoten.
• <video>- und <iframe>-Inhalte von einer anderen Origin lassen sich nicht auslesen, das Replay zeigt also den Elementrahmen ohne Inhalt.
• Native Browser-UI erscheint nie: Autofill-Dropdowns, alert()-Dialoge, das Druckfenster, die Downloadleiste, die Devtools.
• Alles in einem anderen Tab, einem anderen Fenster oder im Betriebssystem liegt außerhalb des Erfassungsbereichs.
• Serverzustand bleibt unsichtbar. Das Replay zeigt, dass ein Formular einen Fehler zurückgegeben hat, nicht welche Datenbankbedingung ihn ausgelöst hat.

Ein Fehlermodus überrascht Teams Monate später. Bilder, Schriften und Stylesheets werden als URLs gespeichert, nicht als Bytes, deshalb rendern ältere Replays nach einem Deploy, das ein Stylesheet ändert, mit den neuen Styles. Ein Replay von vor sechs Monaten belegt Struktur und Verhalten, nicht das exakte Aussehen.

Wie schützt Maskierung personenbezogene Daten in einem Session Replay?

Maskierung ersetzt sensible Werte im Browser, bevor ein Ereignis gesendet wird, der Server erhält den ursprünglichen Text also nie. Ein Recorder wendet die Regeln beim Serialisieren jedes Knotens an: Passwortfelder werden standardmäßig verworfen, bei Elementen mit einer Klasse wie .mask wird der Text durch Sternchen ersetzt, und blockierte Elemente werden zu einem leeren Platzhalterkasten, der das Layout erhält.

Zwei Richtlinien verhalten sich unter Druck unterschiedlich. Eine Blocklist maskiert die Felder, an deren Markierung Sie gedacht haben, und gibt das Feld preis, das ein Entwickler im nächsten Sprint hinzufügt. Eine Allowlist maskiert standardmäßig alles und gibt nur die Elemente frei, die Sie benennen, was hässlichere Replays und keine Überraschungen ergibt. Wählen Sie die Allowlist für jede Oberfläche, die Zahlungs-, Gesundheits-, Konto- oder Supportdaten berührt.

Flowsery ist cookiefrei, in der EU gehostet und GDPR by design und liefert ein einziges Skript unter 10 KB.

Blockliste vs. Freigabeliste beim Maskieren

Blockliste

• Maskiert nur die heute markierten Felder
• Lässt das Feld durch, das ein Entwickler im nächsten Sprint hinzufügt

Freigabeliste

• Maskiert standardmäßig alles
• Gibt nur die genannten Elemente frei
• Hässlichere Replays, aber keine Überraschungen

Wie viel Speicher braucht ein Session Replay?

Der Speicherbedarf skaliert mit dem Ereignisvolumen, nicht mit der Sitzungsdauer in Echtzeit. Ein Besucher, der zehn Minuten lang einen Artikel liest, erzeugt fast keine Mutationen; ein Besucher, der neunzig Sekunden lang Elemente in einer Canvas-App herumzieht, erzeugt Zehntausende. Die Schätzung lautet:

monthly bytes = sessions recorded x events per session x compressed bytes per event

Ein Rechenbeispiel. Nehmen Sie 50,000 aufgezeichnete Sitzungen pro Monat an, 4,000 Ereignisse pro Sitzung und 200 komprimierte Bytes pro Ereignis:

4,000 x 200 = 800,000 Bytes, also rund 800 KB pro Sitzung. 800 KB x 50,000 = 40,000,000 KB, also rund 40 GB pro Monat.

Dieselben 50,000 Sitzungen als 720p-Video aufgezeichnet gingen in die Terabyte. Dieses Verhältnis ist der Grund, warum Replay-Tools nach Sitzungszahlen und Aufbewahrungsfenstern statt nach Gigabyte abrechnen, und Flowsery legt Tariflimits als Kontingente fest, die Analytics-Sitzungen, Session Recordings, KI-analysierte Sitzungen und die Replay-Aufbewahrung in Monaten abdecken.

Sollten Sie Sitzungen samplen oder alle aufzeichnen?

Sampling tauscht diagnostische Abdeckung gegen Kosten und versagt genau bei den Sitzungen, die Sie brauchen. Wenn ein Checkout-Bug einen von 400 Besuchern trifft und Sie 10 Prozent des Traffics aufzeichnen, erfassen Sie den Bug einmal alle 4,000 Sitzungen und können einen Fix nicht bestätigen, ohne Wochen zu warten. Seltene Ereignisse sind der Grund, warum es Replay gibt, und seltene Ereignisse sind das, was Sampling löscht.

Flowsery zeichnet jede Nutzersitzung ohne Daten-Sampling auf und verbindet sich ohne erneute Instrumentierung mit Replays, die bereits in PostHog oder Amplitude aufgezeichnet wurden. Wenn ein Budget doch eine Sampling-Entscheidung erzwingt, behalten Sie 100 Prozent der Sitzungen, die Checkout, Anmeldung und jeden Flow berühren, der einen JavaScript-Fehler ausgelöst hat.

Wie unterscheidet sich Session Replay von Screen Recording und einer Heatmap?

Session Replay, Screen Recording und Heatmaps beantworten drei Fragen aus drei Datenquellen. Screen Recording erfasst kodierte Pixel von allem, was eine Capture-API sieht. Eine Heatmap fasst Koordinaten vieler Besucher zu einem Bild zusammen und behält keinen einzelnen Pfad.

Frage	Session Replay	Screen Recording	Heatmap
Was gespeichert wird	DOM-Mutationen und Eingabeereignisse als JSON	Kodierte Videobilder	Aggregierte Koordinaten und Zählwerte
Größe pro Sitzung	Kilobyte	Megabyte	Kein Artefakt pro Sitzung
Text nach der Erfassung	Echter, markierbarer DOM-Text	Nur Pixel	Nicht aufbewahrt
Wer es startet	Das Seitenskript, automatisch	Ein Mensch, absichtlich	Das Seitenskript, automatisch
Umfang	Nur die aufgezeichnete Seite	Der ganze Bildschirm oder das Fenster	Nur die aufgezeichnete Seite
Zeigt den Pfad einer Person	Ja	Ja	Nein, es führt alle zusammen
Beantwortet	Warum ist dieser Besuch gescheitert	Was hat diese Person dabei gesagt	Wo klicken alle

Nutzen Sie eine Heatmap, um zu entscheiden, wo Sie hinsehen, und ein Replay, um herauszufinden, was dort passiert ist. Eine Heatmap zeigt einen kalten CTA; erst ein Session Recording eines Besuchers, der daran vorbeigescrollt ist, verrät Ihnen, dass der Button bei diesem Breakpoint hinter einem Sticky-Header lag.

Wo setzen Teams Session Replay in der Praxis ein?

Teams nutzen Replay, um die Lücke zwischen einem Fehlerbericht und einer Reproduktion zu schließen. Ein Stacktrace nennt die Zeile, die den Fehler geworfen hat; das Replay davor zeigt die elf Klicks, die die App in diesen Zustand gebracht haben. Dasselbe gilt für stille Fehler, bei denen nichts geworfen wird und der einzige Beleg ein Besucher ist, der sechsmal auf einen deaktivierten Button klickt.

Replays einzeln anzusehen funktioniert ab ein paar hundert Sitzungen pro Tag nicht mehr, deshalb zählt Erkennung mehr als Wiedergabe. Flowserys AI Session Replay erkennt Rage Clicks, Dead Clicks, JavaScript-Fehler, Abbrüche und kaputte Flows automatisch, gruppiert passende Sitzungen zu einem Issue und sortiert Issues danach, wie viele Nutzer betroffen sind. Jedes Issue landet in Slack, Linear oder Jira mit angehängtem Replay und Reproduktionsschritten, und ein @flowsery-Tag in Slack öffnet einen Draft-Pull-Request in Ihrem GitHub-Repo. Diese Frustrationssignale verwandeln Aufzeichnungen in eine priorisierte Warteschlange.

Häufig gestellte Fragen

Ist Session Replay dasselbe wie Screen Recording?

Nein. Screen Recording speichert kodierte Videobilder eines Bildschirms oder Fensters, während Session Replay DOM-Mutationen und Eingabeereignisse speichert und die Seite daraus neu aufbaut. Die Folgen sind die Größe, Kilobyte gegen Megabyte, und der Umfang, denn Replay sieht nur die aufgezeichnete Seite.

Zeichnet Session Replay Passwörter auf?

Recorder verwerfen die Werte von Passwortfeldern standardmäßig, das Feld erscheint also maskiert und der echte Wert verlässt den Browser nie. Andere sensible Felder bleiben ungeschützt, solange Sie sie nicht markieren, weshalb eine Allowlist, die alles maskiert und benannte Elemente wieder freigibt, das Markieren einzelner Felder schlägt.

Warum sehen alte Replays kaputt aus?

Replays referenzieren Stylesheets, Schriften und Bilder per URL, statt ihre Bytes zu speichern. Ein CSS-Deploy oder ein gelöschtes CDN-Asset lässt ältere Replays mit den neuen Styles oder mit fehlenden Bildern rendern. Die DOM-Struktur und die Interaktions-Timeline bleiben korrekt.

Kann Session Replay in ein iframe hineinsehen?

Ein Recorder kann Same-Origin-iframes erfassen, indem er sie zusammen mit dem Hauptdokument instrumentiert. Cross-Origin-iframes blockiert das Sicherheitsmodell des Browsers, deshalb erscheint ein eingebettetes Zahlungsformular oder ein Widget von einer anderen Domain in der Wiedergabe als leerer Rahmen.

Wie lange sollten Replays aufbewahrt werden?

Die Aufbewahrung sollte dem kürzesten Zeitraum entsprechen, in dem Sie auf die Daten reagieren, denn jeder zusätzliche Monat kostet mehr und erhöht das Datenschutzrisiko. Flowsery gibt die Replay-Aufbewahrung in Monaten als Teil des Tarifkontingents an.

Verlangsamt Session Replay eine Seite?

Die Kosten des Recorders entstehen beim Serialisieren des initialen DOM und beim anschließenden Beobachten von Mutationen, deshalb zahlen schwere Single-Page-Anwendungen mit großen Bäumen mehr als statische Seiten. Das Skriptgewicht ist der Teil, den Sie bei der Installation steuern: Flowsery liefert ein einziges Skript unter 10 KB.

Verwendet Flowsery Cookies zur Aufzeichnung?

Flowsery zeichnet Sitzungen ohne Cookies auf, läuft auf EU-gehosteter Infrastruktur und ist GDPR by design gebaut. Das Skript, das den DOM-Snapshot und den Mutationsstream erfasst, ist unter 10 KB groß, sodass die Aufzeichnungspipeline selbst keine Cookie-Abhängigkeit hat.

Kann eine Browser-Erweiterung in einem Session Replay auftauchen?

Ja, denn der Recorder liest dasselbe DOM, das der Browser rendert, und der von einer Erweiterung eingefügte Inhalt wird Teil dieses DOM. Das erklärt Bug-Reports, die im Team niemand nachstellen kann, weil die Erweiterung nur im Browser dieser einen Besucherin existiert.

Lässt sich Session Replay mit Tools wie PostHog oder Amplitude verbinden?

Flowsery lässt sich mit Replays verbinden, die bereits in PostHog oder Amplitude aufgezeichnet wurden, sodass ein Team eine Website, die bereits Events an eine dieser Plattformen sendet, nicht neu instrumentieren muss. Es zeichnet jede Sitzung ohne Sampling auf, wodurch die seltenen Checkout- oder Signup-Fehler erhalten bleiben, die eine Teilerfassung übersehen würde.

Kann Session Replay Probleme automatisch erkennen, ohne dass man jede Aufnahme ansieht?

Flowserys KI-Session-Replay erkennt Rage Clicks, Dead Clicks, JavaScript-Fehler, Abbrüche und defekte Abläufe, gruppiert passende Sitzungen zu einem Issue und ordnet die Issues danach, wie viele Nutzer betroffen sind. Jedes Issue landet mit Replay und Reproduktionsschritten in Slack, Linear oder Jira, und wer @flowsery in Slack markiert, öffnet einen Entwurf-Pull-Request im verbundenen GitHub-Repo.