FullStory Digital Experience und Session Replay Cookie-Einwilligungs-Integrationsleitfaden: Playbook 2026
FullStory ist die dominante Plattform in der Kategorie Digital Experience Analytics aus einem Grund: Es erfasst standardmäßig alles. Während herkömmliche Analysetools diskrete Ereignisse aufzeichnen, die der Entwickler instrumentiert hat, und Produktanalyseplattformen Interaktionen plus ein automatisch erfasstes Supplement aufzeichnen, erfasst FullStory das vollständig gerenderte DOM, den Cursor-Trail, das Timing der Tastenanschläge, das Scroll-Verhalten, Rage-Klicks, Dead-Klicks, Netzwerkanfragen und JavaScript-Fehler — und fügt sie zu Session-Aufzeichnungen zusammen, durch die der Analyst Frame für Frame scrollen kann. Diese Abdeckung ist das Produkt. Es ist auch der Grund, warum FullStory an der Schnittstelle der strengsten Einwilligungsregeln in jedem modernen Datenschutzregime sitzt. Die EDPB-Leitlinien zur Session-Replay von 2023 und die Prioritäten der Taskforce 2026 behandeln Session-Replay als eine eigene, strengere Einwilligungskategorie. Die CNIL war der öffentlichste Regulierer zu diesem Thema, ist aber nicht allein — das Garante, die ICO, die spanische AEPD und die niederländische AP haben alle abgestimmte Positionen vertreten. Ein FullStory-Deployment, das für consent-first Erfassung konfiguriert wurde, mit korrekter Maskierung, korrektem Gating und korrektem Audit-Trail, ist eines der leistungsfähigsten Tools, das ein Publisher betreiben kann; eines, das nicht entsprechend konfiguriert wurde, ist eines der leichtesten Ziele, das ein Regulierer finden wird.
Warum FullStory in der strengsten Einwilligungskategorie sitzt
Eine Standard-FullStory-Initialisierung tut, was jedes Session-Replay-Tool tut, und mehr. Sie setzt First-Party-Cookies unter dem fs_uid- und fs_lua-Namespace, die den persistenten Besucher-Identifier und den Zeitstempel der letzten Aktivität enthalten, generiert einen Session-Identifier unter fs_session und beginnt innerhalb von Millisekunden nach dem Seitenladen das gerenderte DOM an rs.fullstory.com zu streamen. Der Stream enthält jedes Eingabeereignis, jede Mausbewegung, jede Scroll-Position, jeden Seitenübergang und — wenn das Netzwerkerfassungsmodul aktiviert ist — jede XHR- und Fetch-Antwort, die die Seite ausgibt, mit enthaltenen Antwort-Bodies, es sei denn, der Operator hat Unterdrückung konfiguriert.
Jede dieser Erfassungen aktiviert ein separates Einwilligungsgate. Das Persistieren des Besucher-Identifiers ist eine Speicher-und-Zugriffs-Operation gemäß Artikel 5(3) der ePrivacy-Richtlinie, die eine vorherige, freiwillig erteilte, spezifische, informierte und eindeutige Einwilligung im gesamten EWR, im Vereinigten Königreich und in jeder Rechtsordnung erfordert, die denselben Standard übernommen hat. Das Aufzeichnen des gerenderten DOM ist die Verarbeitung personenbezogener Daten gemäß der DSGVO, da der visuelle Datensatz ausreichend ist, um den Nutzer zu identifizieren und substantiellen Inhalt über ihn zu enthüllen. Das Erfassen des Tastenanschlag-Streams ist eine besondere Sensibilität: Alles, was der Nutzer in ein Formularfeld eingibt, wird Frame für Frame erfasst, und wenn das Feld unmaskiert ist, enthält die Aufzeichnung den eingegebenen Inhalt. Die EDPB hat explizit betont, dass die Session-Replay-Erfassung eine Kategorie ist, die eine ausdrückliche, granulare Einwilligung erfordert, die von der generischen Analyseeinwilligung zu unterscheiden ist — und dass die Maskierung eine Ergänzung zur Einwilligung ist, kein Ersatz dafür.
Was FullStory vor der Einwilligung schreibt — und was unterdrückt werden muss
Das Standard-FullStory-Quickstart installiert das Tracking-Snippet direkt in den <head> der Seite. Das funktioniert wie dokumentiert und ist die Quelle des häufigsten Compliance-Fehlers: Das Snippet läuft, bevor das Cookie-Banner gerendert wurde, die fs_uid- und fs_session-Cookies werden innerhalb von Millisekunden gesetzt, und der Session-Replay-Stream beginnt unabhängig davon, was der Nutzer später entscheidet, zu rs.fullstory.com zu fließen. Jeder europäische Regulierer, der sich zu diesem Muster geäußert hat, hat gleich entschieden: Vor der Einwilligung gesetzte Cookies sind rechtswidrig, die vor der Einwilligung erfasste Aufzeichnung ist eine rechtswidrige Verarbeitung, und der Publisher trägt die Haftung.
Eine konforme Integration muss daher verhindern, dass das FullStory-Snippet initialisiert wird, bis die relevante Einwilligungskategorie erteilt wurde. Das Muster, das in der Produktion funktioniert, ist die FS.consent()-API in Kombination mit verzögerter Aufzeichnung: Das Snippet wird mit FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) geladen und FS.shutdown() wird sofort aufgerufen, dann werden FS.restart() und FS.consent(true) erst aufgerufen, nachdem das CMP signalisiert hat, dass die Session-Replay-Kategorie erteilt wurde. Das alternative Muster ist die bedingte Script-Injektion — das FullStory-Snippet wird erst nach Erteilung der Einwilligung zum DOM hinzugefügt — was sauberer ist, aber erfordert, dass der Operator jedes vor-Einwilligungs-Identitäts-Stitching verliert, das FullStory andernfalls bereitstellen würde.
Die Cookies und der Speicher, den FullStory schreibt
Das FullStory-Snippet schreibt bei der Initialisierung die folgenden Identifier, die alle nicht wesentlich sind und eine Einwilligung erfordern: fs_uid mit einem mehrjährigen Ablauf, der den persistenten Besucher-Identifier enthält, fs_lua mit dem Zeitstempel der letzten Benutzeraktivität, fs_session mit dem Session-Identifier und die Aufzeichnungsstatus-Marker, die FullStory intern verwendet. Das Widerrufen der Einwilligung muss daher sowohl diese Cookies ablaufen lassen als auch FS.consent(false) gefolgt von FS.shutdown() aufrufen, um weitere Erfassung zu stoppen, und der Publisher muss über den Datenschutz-Endpunkt von FullStory eine Löschanfrage für die früheren Aufzeichnungen des Nutzers senden.
FullStory auf Einwilligungsrahmen abbilden
FullStory implementiert IAB TCF oder die IAB Global Privacy Platform nicht nativ — es ist eine First-Party-Digital-Experience-Plattform, kein Ad-Tech-Anbieter. Es stellt eine native Einwilligungs-API bereit und unterstützt ein privates Maskierungsmodell als Standard, das unabhängig vom Einwilligungsstatus funktioniert. Das Muster, das die Prüfung eines Regulierers besteht, behandelt jedes FullStory-Modul als separates Gate, das an ein spezifisches CMP-Signal gebunden ist.
- Session Replay und der vollständige DOM-Stream sind an eine dedizierte Session-Replay- oder Forschungskategorie gebunden, die von der generischen Analyse getrennt ist. Die EDPB-Leitlinien sind in diesem Punkt explizit — die Replay-Einwilligung muss separat und granular sein, nicht mit Analytics oder Marketing gebündelt.
- Die Netzwerkerfassung sitzt hinter einem strengeren Sub-Gate innerhalb derselben Kategorie, da sie HTTP-Antwort-Bodies erfasst, die personenbezogene Daten enthalten können, die nicht mit der sichtbaren Oberfläche zusammenhängen. Die Netzwerkerfassung sollte standardmäßig deaktiviert sein und nur für spezifische Anwendungspfade aktiviert werden, bei denen der Operator bestätigt hat, dass die Antwort-Bodies keine sensiblen Daten enthalten.
- Identity-Stitching über FS.identify() kann mit einem ephemeren Session-Identifier auf der Grundlage eines berechtigten Interesses laufen, wenn der Nutzer anonym ist, aber das Verknüpfen der Identifikation mit einem persistenten First-Party-Identifier über Sessions hinweg erfordert dieselbe Einwilligung wie Session Replay.
- Heatmaps und Konversionsanalysen, die aus dem Session-Replay-Stream abgeleitet werden, erben das Gate vom vorgelagerten Stream — sie sind keine separaten Einwilligungsoberflächen, sie sind nachgelagerte Produkte derselben erfassten Daten.
Das Integrationsmuster, das funktioniert
Das Referenz-Deployment hat vier Teile: ein CMP, das ein Echtzeit-Einwilligungsänderungsereignis bereitstellt, ein verzögertes Bootstrap, das FullStory mit unterdrückter Erfassung über FS.shutdown() initialisiert, ein Einwilligungs-Listener, der FS.consent(true) und FS.restart() aufruft, wenn das Session-Replay-Gate sich öffnet, und eine privat-als-Standard-Maskierungskonfiguration, die jedes Eingabefeld hart unterdrückt, es sei denn, es wird ausdrücklich eingeschaltet.
Privat-als-Standard-Maskierung
Die Maskierungsschicht von FullStory funktioniert unabhängig von der Einwilligung und sollte aggressiv konfiguriert werden, selbst wenn eine Einwilligung erteilt wurde. Die CSS-Klasse fs-mask auf einem beliebigen Element unterdrückt den Inhalt dieses Elements aus der Aufzeichnung; die CSS-Klasse fs-exclude schließt das Element vollständig aus dem DOM-Stream aus; die Klasse fs-block blockiert sowohl Inhalt als auch Struktur. Gemäß den Sonderkategorien-Regeln der DSGVO und der Definition sensibler personenbezogener Informationen der CCPA muss jedes Feld, das Gesundheitsinformationen, Finanzdaten, Behördenkennzeichen, biometrische Daten, genaue Geolokalisierung oder Inhalte privater Kommunikation erfassen könnte, die Maskierungsattribute unabhängig vom Einwilligungsstatus des Nutzers verwenden. Die empfohlene Vorgehensweise ist, fs-mask auf Formularebene statt auf Feldebene anzuwenden — ein Entwickler, der einem bestehenden Formular ein neues Feld hinzufügt, wird sich viel seltener daran erinnern, es einzeln zu maskieren, als wenn er innerhalb eines Formularbereichs-Maskierungs-Wrappers arbeitet, der es automatisch erfasst.
Regionsauswahl und Datenspeicherung
FullStory betreibt separate US- und EU-Aufnahme-Endpunkte. Für EWR- und UK-Traffic ist der EU-Endpunkt der richtige Standard — er hält Aufnahme, Verarbeitung und Speicherung innerhalb des EWR und reduziert die Schrems-II-Exposition, die jedes US-Regions-Session-Replay-Deployment tragen würde. Der Endpunkt wird pro FullStory-Organisation konfiguriert und kann nicht rückwirkend geändert werden, daher muss die Regionsentscheidung vor der Skalierung getroffen und in der Datenschutzerklärung dokumentiert werden, damit die Rechtsgrundlagenkette von der Erfassung bis zur Speicherung sauber ist.
Validierung der Integration und des Audit-Trails
Der Validierungsschritt ist das, was Regulierer prüfen und was Publisher bei Session-Replay-Tools am häufigsten überspringen. Ein korrekt integriertes FullStory-Deployment muss vier Tests der Reihe nach bestehen. Erstens muss eine saubere Browser-Session mit angezeigtem Banner, aber ohne getroffene Entscheidung, null Anfragen an rs.fullstory.com über den SDK-Dateidownload hinaus und null fs_-Cookies in document.cookie erzeugen. Zweitens muss die Ablehnung der Session-Replay-Einwilligung diesen Zustand aufrechterhalten — keine Erfassung, kein Identifier, keine Aufzeichnung. Drittens muss die Akzeptanz der Session-Replay-Einwilligung das erwartete fs_uid-Cookie, ein einzelnes FS.consent(true)-Ereignis und den DOM-Stream, der zum konfigurierten Regions-Endpunkt fließt, erzeugen, wobei maskierte Felder bestätigt werden, nur den Masken-Platzhalter zu erfassen. Viertens muss der Widerruf der Einwilligung sofort weitere Erfassung stoppen, die fs_-Cookies ablaufen lassen und eine Löschanfrage über den Datenschutz-Endpunkt von FullStory für die früheren Aufzeichnungen des Nutzers auslösen.
Die Erwartung an den Audit-Trail ist der Punkt, an dem Session-Replay-Tools der strengsten Prüfung ausgesetzt sind. Die EDPB-Cookie-Banner-Richtlinien von 2023 und die erneuerten Prioritäten der Taskforce 2026 sind explizit, dass der Publisher für jede spezifische Session-Aufzeichnung im FullStory-Projekt nachweisen können muss, dass der Nutzer, der sie generiert hat, zum Zeitpunkt der Erfassung eine gültige Session-Replay-Einwilligung erteilt hatte. Das Standardmuster ist, die Einwilligungsversion und den Zeitstempel als Benutzervariablen am FullStory-Identifier über FS.setUserVars({ consent_version: 'v3', consent_ts: ts }) zu setzen, sodass jede einzelne Aufzeichnung auf einen spezifischen Einwilligungs-Log-Eintrag zurückverfolgt werden kann. Ein korrekt gegatetes Deployment, kombiniert mit Maskierungsattributen, die standardmäßig auf privat gesetzt sind, und einem Löschpfad, der beim Widerruf aktiviert wird, ist das, was die Abdeckung von FullStory von einem regulatorischen Konzentrationsrisiko in einen vertretbaren Teil des Digital Experience Stacks eines Publishers verwandelt.