Session-Recording DSGVO-konform mit First-Party-Infrastruktur

Warum klassische Session-Recording-Tools ein DSGVO-Problem sind

Session-Recordings erfassen zwangsläufig personenbezogene Daten: Mausbewegungen in Kombination mit Seiteninhalt, ausgefüllte Formularfelder, geklickte Elemente. Das macht sie nach der DSGVO zu einer Verarbeitung personenbezogener Daten, die einer Rechtsgrundlage bedarf. Die meisten Anbieter arbeiten mit einer Einwilligung (Art. 6 Abs. 1 lit. a DSGVO), was ein Cookie-Banner mit aktivem Opt-in voraussetzt.

Doch selbst mit Einwilligung bleiben bei klassischen Tools erhebliche Risiken. Wenn die Recording-Library von einem externen CDN geladen wird, findet ein Datentransfer in Drittländer statt, der nach der Schrems-II-Rechtsprechung zusätzliche Maßnahmen erfordert. Wenn die Aufzeichnungsdaten auf US-Servern gespeichert werden, reicht ein Data Processing Agreement (DPA) allein in der Regel nicht aus. Deutsche Datenschutzbehörden haben mehrfach klargestellt, dass die Übermittlung personenbezogener Daten in die USA ohne ergänzende Maßnahmen einen DSGVO-Verstoß darstellt (DSK, 2024).

• Externes JavaScript: Die Recording-Library wird von einem CDN eines Drittanbieters geladen. Bereits der Request überträgt die IP-Adresse des Besuchers an den Drittanbieter.
• US-Datenspeicherung: Aufzeichnungsdaten werden auf Servern außerhalb der EU verarbeitet und gespeichert. Ein Standard-DPA reicht nach Schrems II erfahrungsgemäß nicht aus.
• Erkennbare Dateinamen: Dateien wie rrweb.min.js oder session-replay.js stehen auf den Filterlisten von uBlock Origin und EasyPrivacy und werden geblockt, selbst wenn sie von der eigenen Domain geladen werden.
• Fehlendes PII-Masking: Ohne aktive Konfiguration werden Passwörter, Kreditkartennummern und persönliche Daten im Klartext aufgezeichnet.
• Consent-Verlust: Zwischen 30 und 50 % der Besucher lehnen Tracking typischerweise ab (Usercentrics). Diese Besucher werden nicht aufgezeichnet, was die Daten systematisch verzerrt.

Der First-Party-Ansatz: Session-Recording ohne Drittanbieter

First-Party-Session-Recording eliminiert alle oben genannten Risiken, indem jede Komponente der Aufzeichnungskette über die eigene Infrastruktur läuft. Kein externer CDN-Request, keine Datenübertragung an US-Server, keine erkennbaren Tracking-Dateinamen. Die technische Architektur besteht aus drei Schichten:

Technische Architektur im Detail

rrweb als Open-Source-Basis

rrweb (Record and Replay the Web) ist eine Open-Source-Library (MIT-Lizenz), die DOM-Mutationen, Mausbewegungen und Interaktionen als kompakte JSON-Events aufzeichnet. Im Gegensatz zu Video-basierten Ansätzen werden keine Pixel aufgezeichnet, sondern strukturierte Daten, die deutlich weniger Speicher benötigen und nachträglich filterbar sind. XICTRAQ nutzt rrweb als Basis und erweitert es um automatisches PII-Masking, Chunk-basiertes Streaming und Kompression.

Obfuskierte Dateinamen gegen Adblocker

Ein häufig übersehenes Problem: Selbst wenn Sie rrweb von Ihrer eigenen Domain ausliefern, erkennen Adblocker wie uBlock Origin die Datei am Namen. rrweb.min.js steht auf der EasyPrivacy-Filterliste und wird geblockt, unabhängig von der Herkunft. XICTRAQ löst dieses Problem, indem die Library unter obfuskierten Dateinamen ausgeliefert wird: rx.js für die Recording-Library, rxp.js und rxp.css für den Player. Diese Namen stehen auf keiner bekannten Filterliste (Stand 2026).

First-Party-Proxy per Nginx

Der First-Party-Proxy stellt sicher, dass alle Datenflüsse zwischen Besucher und Recording-Server über Ihre eigene Domain laufen. Ein einfacher Nginx-location-Block leitet den Pfad /a/ an den XICTRAQ-API-Server weiter. Für den Besucher und seinen Browser sieht jeder Request so aus, als ginge er an Ihre Domain. Das hat drei Vorteile: kein Third-Party-Request in der Browser-DevTools-Console, kein Cross-Origin-Problem mit CSP-Headern und kein Eintrag in Adblocker-Filterlisten. Die Proxy-Einrichtung dauert typischerweise wenige Minuten.

NDJSON-Streaming und Kompression

XICTRAQ verwendet NDJSON (Newline-Delimited JSON) für das Streaming der Aufzeichnungsdaten. Jede Interaktion wird als einzelne JSON-Zeile gesendet, was robustes Chunk-basiertes Streaming ermöglicht. Bei einem Verbindungsabbruch gehen nur die Daten seit dem letzten Chunk verloren, nicht die gesamte Aufzeichnung. Nach Abschluss der Aufzeichnung werden die Daten automatisch per gzip komprimiert, was typischerweise eine Speicherersparnis von etwa 70 % ergibt.

Automatisches PII-Masking: Pflicht, nicht Option

Personenbezogene Daten in Session-Recordings sind das größte DSGVO-Risiko. Wenn ein Passwort, eine IBAN oder eine Kreditkartennummer im Klartext aufgezeichnet wird, liegt ein meldepflichtiger Data Breach vor. Manuelle Konfiguration des PII-Maskings ist fehleranfällig, weil jedes neue Formularfeld einzeln markiert werden muss.

XICTRAQ setzt auf mehrstufiges automatisches PII-Masking, das ohne manuelle Konfiguration arbeitet:

• Input-Typ-Erkennung: Alle input[type=password], input[type=email], input[type=tel] und textarea-Felder werden automatisch maskiert. Der Inhalt wird durch Platzhalterzeichen ersetzt.
• Attribut-basierte Erkennung: Felder mit name- oder id-Attributen wie iban, kreditkarte, geburtsdatum, sozialversicherung werden unabhängig vom Input-Typ maskiert.
• CSS-Klassen-Whitelist: Über die CSS-Klasse data-private können zusätzliche Elemente manuell als sensibel markiert werden. Umgekehrt bleiben Elemente ohne diese Markierung sichtbar.
• Regex-basierte Nachfilterung: Muster wie IBAN (DE + 20 Ziffern), Kreditkartennummern (16 Ziffern) und E-Mail-Adressen werden serverseitig vor der Speicherung erkannt und maskiert.

Opt-in-Modell: data-record als Consent-Gate

Session-Recording ist bei XICTRAQ standardmäßig deaktiviert. Die Aktivierung erfolgt über das HTML-Attribut data-record="1" im Tracker-Snippet. Dieses Attribut kann dynamisch gesetzt werden, etwa nachdem der Besucher in einem Cookie-Banner aktiv zugestimmt hat. Ohne data-record="1" wird keine Recording-Library geladen, kein DOM-Observer gestartet und kein einziges Aufzeichnungs-Event gesendet.

<script defer src="https://www.ihre-seite.de/t.js"
        data-site="IHRE_SITE_ID"
        data-record="1"></script>

Die Aufzeichnung startet ausschließlich nach einem xictraq.consent('granted')-Aufruf, unabhängig davon, welcher Consent-Modus im Dashboard hinterlegt ist: der gespeicherte Modus kann den Riegel nur öffnen, und eine Aufzeichnung ohne Einwilligung ist nach § 25 TDDDG nicht gedeckt. Die cookielose Aggregat-Messung läuft daneben in beiden Modi weiter, weil sie nach § 25 Abs. 2 Nr. 2 TDDDG einwilligungsfrei ist. Die Kombination aus Opt-in-Recording und Consent-Gate entspricht den Empfehlungen der Datenschutzkonferenz (DSK) für DSGVO-konformes Website-Tracking.

Einrichtung in der Praxis: Drei Schritte

Die Einrichtung von First-Party-Session-Recording mit XICTRAQ erfordert drei Schritte, die in der Regel in unter 15 Minuten abgeschlossen sind:

1. Tracker-Snippet einbinden: Fügen Sie das XICTRAQ-Snippet mit data-record="1" in den <head> Ihrer Website ein. Der Tracker erkennt automatisch die Basis-URL und leitet die Recording-Library (rx.js) von Ihrer Domain nach. Eine separate Script-Einbindung ist nicht erforderlich.
2. First-Party-Proxy konfigurieren: Richten Sie in Ihrer Nginx- oder Apache-Konfiguration einen Reverse-Proxy für den Pfad /a/ ein, der Requests an api.xictraq.com weiterleitet. Eine detaillierte Anleitung finden Sie in der Proxy-Dokumentation. Alternativ funktioniert das Recording auch ohne Proxy — die Daten werden dann direkt an die XICTRAQ-API gesendet.
3. Consent-Integration: Verbinden Sie Ihr Cookie-Banner mit dem XICTRAQ-Consent-API-Aufruf xictraq.consent('granted'). Erst nach diesem Aufruf beginnt die Aufzeichnung. Bei cookielosem Basis-Tracking ohne Banner wird das Recording separat über das data-record-Attribut gesteuert.

Aufzeichnungen im Dashboard auswerten

Das XICTRAQ-Dashboard zeigt alle aufgezeichneten Sessions in einer filterbaren Liste. Jede Session enthält Metadaten wie Startzeit, Dauer, Seitenanzahl, Gerät und Betriebssystem. Der integrierte Player gibt die Aufzeichnung als DOM-Replay wieder — keine Video-Dateien, sondern eine exakte Rekonstruktion der Besucher-Interaktion.

Automatische Tags klassifizieren Sessions nach Verhaltensmustern: rage_click (mehrfaches schnelles Klicken auf dasselbe Element), error (JavaScript-Fehler während der Session) und conversion (abgeschlossener Kauf oder Formular-Submit). Diese Tags werden per Cron-Job alle 30 Minuten aktualisiert und ermöglichen gezieltes Filtern nach problematischen Sessions. In Kombination mit Heatmaps ergibt sich ein vollständiges Bild der Nutzerinteraktion.

Datenschutzrechtliche Bewertung

Session-Recording mit First-Party-Infrastruktur und Opt-in-Consent lässt sich auf zwei DSGVO-Rechtsgrundlagen stützen:

• Einwilligung (Art. 6 Abs. 1 lit. a DSGVO): Der sicherste Weg. Der Besucher stimmt der Aufzeichnung aktiv zu, bevor die Recording-Library geladen wird. Der Aufruf xictraq.consent('granted') erzwingt diesen Ablauf technisch: ohne ihn startet keine Aufzeichnung.
• Berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO): Theoretisch denkbar, wenn die Aufzeichnung auf das technisch Notwendige beschränkt ist (nur eigene Domain, kein Third-Party-Transfer, vollständiges PII-Masking). In der Praxis empfehlen Datenschutzbehörden in der Regel dennoch eine Einwilligung.

Entscheidend ist, dass alle drei Voraussetzungen erfüllt sind: Erstens keine Datenübertragung in Drittländer (EU-Hosting und First-Party-Proxy). Zweitens automatisches PII-Masking, das sensitive Felder vor der Speicherung unkenntlich macht. Drittens ein technisch durchgesetztes Opt-in, das die Aufzeichnung erst nach aktiver Zustimmung startet. XICTRAQ erfüllt alle drei Voraussetzungen architektonisch, nicht durch nachträgliche Konfiguration.

Vergleich: Third-Party vs. First-Party Session-Recording

Speichereffizienz und Datenretention

Session-Recordings erzeugen erhebliche Datenmengen. Eine einzelne 5-Minuten-Session kann unkomprimiert zwischen 2 und 10 MB NDJSON-Daten erzeugen, je nach Komplexität der Seite und Interaktionshäufigkeit. XICTRAQ komprimiert abgeschlossene Aufzeichnungen per stündlichem Cron-Job auf .ndjson.gz, was typischerweise eine Reduktion um etwa 70 % ergibt.

Die Datenretention ist planabhängig und beträgt zwischen 7 Tagen (Starter) und 2 Jahren (Enterprise). Ältere Aufzeichnungen werden automatisch gelöscht, was sowohl der Speichereffizienz als auch dem Datenschutzgrundsatz der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO) entspricht. Die aktuelle Preisübersicht zeigt die Retention-Zeiträume pro Plan.

UX-Optimierung mit Session-Recordings: Praxisbeispiele

Die wertvollsten Erkenntnisse aus Session-Recordings liegen oft in den Details, die quantitative Analysen nicht erfassen. Hier einige typische Anwendungsfälle:

• Rage-Clicks identifizieren: Ein Besucher klickt mehrfach schnell auf ein Element, das nicht reagiert. Das deutet auf ein UX-Problem hin — ein vermeintlicher Button, der keiner ist, oder ein Ladevorgang ohne Feedback.
• Formular-Abbrüche verstehen: Warum brechen Besucher ein Checkout-Formular bei Feld 4 von 6 ab? Das Formular-Feld verlangt möglicherweise ein Format, das nicht kommuniziert wird, oder die Fehlermeldung ist nicht sichtbar.
• Mobile-Navigation testen: Wie interagieren Besucher mit dem Hamburger-Menü? Finden sie die Unterseiten? In Kombination mit Click-Heatmaps werden die Schwachstellen der mobilen Navigation sichtbar.
• JavaScript-Fehler kontextualisieren: Ein Error-Log zeigt TypeError: undefined is not a function. Die Session-Aufzeichnung zeigt, welche Aktion den Fehler ausgelöst hat und ob der Besucher danach die Seite verlassen hat.

Session-Recording als Teil einer Privacy-First-Analyse-Strategie

Session-Recording ist kein isoliertes Tool, sondern Teil einer umfassenden Analytics-Strategie. In Kombination mit cookielosem Basis-Tracking, Click-Heatmaps, Form-Analytics und A/B-Testing entsteht ein vollständiges Bild des Nutzerverhaltens — ohne einen einzigen Datenpunkt an Drittanbieter zu senden.

Der Unified-Tracker-Ansatz von XICTRAQ bedeutet, dass alle Analytics-Features über ein einziges Script-Snippet (t.js) gesteuert werden. Session-Recording wird bei Bedarf per data-record-Attribut zugeschaltet, ohne eine zusätzliche Library einbinden zu müssen. Das reduziert die Komplexität und stellt sicher, dass alle Datenflüsse über denselben First-Party-Proxy laufen. Detaillierte Informationen zu allen Analytics-Features finden Sie auf der Feature-Seite, eine kostenlose Demo ist ohne Registrierung verfügbar.

Häufige Fragen zu DSGVO-konformem Session-Recording