Session-Replay ohne Überwachung

DatenschutzDenis Povarov20. August 2026

Session-Replay hat ein Imageproblem, und es ist weitgehend verdient.

Geprägt haben die Kategorie Analytics-Tools, die jede Session aller Leute ununterbrochen und für immer aufzeichnen, damit ein Growth-Team im nächsten Quartal durch den Checkout von irgendwem spulen kann. Das ist Überwachung mit angehängter Debugging-Funktion, und es ist nachvollziehbar, dass Leuten dabei unwohl ist.

Ich nutze Replay trotzdem, weil bei einer bestimmten Art von Bug nichts anderes hilft. Aber ich nutze es anders.

Wo Replay das einzige Werkzeug ist

Die meisten Bugs lösen Console und Netzwerk-Log. Ein Fehler, ein 500, fertig.

Dann gibt es die andere Sorte. Console sauber. Netzwerk sauber. Jeder Request hat 200 zurückgegeben. Und die Person ist sich vollkommen sicher, dass etwas kaputtgegangen ist.

Sie hat fast immer recht. Kaputt war die Interaktion: ein Klick, der auf dem falschen Element gelandet ist, ein Formular, das sich stillschweigend zurückgesetzt hat, ein Modal, das hinter einem Overlay aufging, ein Zustandswechsel, der die UI in einem Zustand hinterließ, mit dem du nie gerechnet hast. Nichts davon erzeugt einen Fehler, denn aus Sicht des Codes ist nichts schiefgelaufen.

In solchen Fällen ist das Replay die ganze Untersuchung. Du schaust dir die zwölf Sekunden vor dem Bericht an und siehst, was die Person tatsächlich getan hat, und das ist regelmäßig nicht das, was sie beschrieben hat.

An einen Bericht gebunden, nicht an eine Person

Der Kernunterschied: Das Replay in BugDump hängt an einem Fehlerbericht, nicht an einem Profil.

Die Aufzeichnung existiert, um einen bestimmten eingereichten Bericht zu erklären. Sie legt keine Langzeitakte über das Verhalten von irgendwem an. Es gibt keinen Session-Browser, kein „schau einer zufälligen Person zu“, keine Funnel-Analyse. Wenn niemand einen Bug gemeldet hat, schaut sich niemand irgendetwas an.

Das ist ein kleineres Feature als Replay in Analytics-Tools. Genau darum geht es. Die schmale Version löst das Debugging-Problem ohne den Teil, bei dem Leuten unwohl wird.

Weichzeichnen liegt in der Hand der meldenden Person

Der Screenshot-Editor hat ein Werkzeug zum Weichzeichnen, und es funktioniert so, wie es sollte: Weichgezeichnet wird im Browser, vor dem Upload. Ein weichgezeichneter Bereich wird nicht erst auf meinen Servern unkenntlich gemacht, er kommt dort nie an.

Das kehrt die übliche Aufteilung um. Normalerweise ist Datenschutz ein Versprechen des Herstellers: „Wir gehen verantwortungsvoll mit deinen Daten um“, und du entscheidest, ob du das glaubst. Weichzeichnen im Browser ist kein Versprechen. Die Pixel verlassen den Rechner nicht.

Praktisch heißt das: Wer eine Seite voller Kundennamen vor sich hat, kann dir trotzdem den Screenshot schicken, den du brauchst. Ohne das Werkzeug schicken die Vorsichtigen gar nichts.

Standardmäßig aus, wo es zählt

captureNetworkBodies ist false, solange du es nicht einschaltest.

Bodys sind nützlich, manchmal ist der Response-Payload der ganze Bug. Dort stecken aber auch Tokens, personenbezogene Daten und Zahlungsdaten. Der sichere Standard ist der, bei dem das Einschalten eine bewusste Entscheidung von jemandem ist.

Replay selbst lässt sich mit einer Zeile abschalten, global oder auf den Routen, die nicht aufgezeichnet werden sollen:

Bugdump.init({
  apiKey: 'your-api-key',
  features: {
    sessionReplay: false,
  },
});

So funktioniert jede Capture-Funktion: Screenshots, Bildschirmaufnahme, Replay und Anhänge lassen sich einzeln ein- und ausschalten. Du kannst BugDump mit nichts als einer Beschreibung und einem Console-Log betreiben, wenn deine Compliance-Vorgaben das verlangen.

Die Berechtigungsabfrage, die ich behalten habe

Screenshots und Aufnahmen nutzen standardmäßig getDisplayMedia, das den eigenen Berechtigungsdialog des Browsers zeigt. Ich könnte ihn ganz vermeiden, indem ich standardmäßig per DOM rendere.

Ich habe ihn aus zwei Gründen behalten.

Die Aufnahme ist wirklich originalgetreu: Canvas, Video, Cross-Origin-iframes und native Steuerelemente werden genau so erfasst, wie sie gerendert sind, statt nachgebaut. Und die Abfrage ist ehrlich. Die Person erfährt vom Browser und nicht von mir, dass ihr Bildschirm gleich aufgenommen wird. Sie kann ablehnen, und dann greift die DOM-Aufnahme, statt dass der Bericht verloren geht.

Ein Berechtigungsdialog ist eine Hürde. Er ist auch eine Einwilligung, eingeholt von einer Instanz, die keiner von uns beiden kontrolliert.

Wo ich am Ende stehe

Replay ist ein starkes Werkzeug, und die Analytics-Branche hat den Leuten beigebracht, ihm zu misstrauen. Das Misstrauen ist berechtigt, und das Werkzeug lohnt sich trotzdem.

Meine Antwort: Replay an Berichte statt an Sessions binden, das Werkzeug zum Weichzeichnen der meldenden Person in die Hand geben und vor dem Upload anwenden, die riskanteste Erfassung standardmäßig ausschalten und jede Funktion mit einer Zeile abschaltbar machen.

Du bekommst die zwölf Sekunden, die den Bug erklären. Ein Überwachungssystem bekommst du nicht, und ich auch nicht.