Warum PostHog Einwilligung erfordert — und warum die Antwort für jedes Modul verschieden ist

Das Web-SDK von PostHog ist kein passiver Seiten-Tag. Bei einer Standard-Initialisierung setzt das SDK einen oder mehrere Persistenz-Einträge — standardmäßig ein kombiniertes Cookie-plus-localStorage-Schema mit Schlüssel unter ph_{projectKey}_posthog — generiert einen stabilen eindeutigen Bezeichner, erfasst den ersten Seitenaufruf mit Referrer, UTM-Parametern und Klick-IDs und öffnet einen langlebigen Ereigniskanal zum konfigurierten Ingest-Host. Wenn Session-Replay auf Projektebene aktiviert ist, streamt das SDK zusätzlich eine kontinuierliche Aufzeichnung des gerenderten DOM, der Mauskoordinaten und der Eingabeereignisse. Wenn Feature-Flags konfiguriert sind, wertet das SDK sie gegen den eindeutigen Bezeichner aus, hält die Entscheidungen für die Sitzung fest und gibt für jede Auswertung ein $feature_flag_called-Ereignis aus.

Jede dieser Aktivitäten entspricht einer anderen Einwilligungsschranke. Das Speichern eines eindeutigen Bezeichners ist eine Speicher-und-Zugriffs-Operation nach Article 5(3) der ePrivacy-Richtlinie und erfordert vorherige, freiwillige, spezifische, informierte und eindeutige Einwilligung im EWR, im Vereinigten Königreich und in jeder Rechtsordnung, die denselben Standard übernommen hat. Das Erfassen von Verhaltensereignissen ist eine Verarbeitung personenbezogener Daten nach der DSGVO, da die Kombination aus Bezeichner, IP-Adresse und Verhaltensspur ausreicht, um eine Person zu identifizieren. Session-Replay fällt nach der EDPB-Leitlinie zum Session-Replay in eine eigene, strengere Kategorie — Replay erfasst das gerenderte DOM und alle nicht maskierten Eingabefelder und erfordert eine ausdrückliche, granulare Einwilligung, die sich von der allgemeinen Analyse-Einwilligung unterscheidet. Die Auswertung von Feature-Flags ist die subtile Frage: Eine Flag-Prüfung, die einen booleschen Wert zurückgibt, erfordert an sich keine Einwilligung, aber das Speichern der Flag-Zuweisung des Nutzers an einen stabilen Bezeichner über Sitzungen hinweg schon, denn so entstehen durch Flag-basierte Experimente nachverfolgbare Daten auf Nutzerebene.

Was PostHog vor der Einwilligung schreibt — und was unterdrückt werden muss

Das Standard-PostHog Browser SDK schreibt bei der Initialisierung Folgendes: einen kombinierten Cookie-und-localStorage-Eintrag unter ph_{projectKey}_posthog, der den eindeutigen Bezeichner, den Sitzungsbezeichner und die Feature-Flag-Entscheidungen enthält, plus bei aktiviertem Session-Replay einen zusätzlichen In-Memory-Aufzeichnungspuffer, der alle paar Sekunden an den Ingest-Endpoint geleert wird. Das SDK sendet außerdem unmittelbar ein $pageview-Ereignis und bei aktivierter Autoerfassung jeden nachfolgenden Klick, jede Formularinteraktion und jeden Rage-Click auf der Seite.

Das empfohlene Muster ist, PostHog mit opt_out_capturing_by_default: true und disable_session_recording: true zu initialisieren und beide Flags umzuschalten, sobald das Consent-Banner ein positives Signal zurückgibt. Dies ist die Integrationsposition, die die PostHog-Dokumentation jetzt empfiehlt, und es ist die Position, die eine behördliche Prüfung übersteht, weil sie den Standard umkehrt: Es wird nichts erfasst, bis die Einwilligung erfasst ist, und das SDK bietet einen sauberen Übergang statt eines zustandsbehafteten Retrofits.

Die Cookies, localStorage-Einträge und Bezeichner, die PostHog speichert

Browser SDK 1.x schreibt einen Persistenz-Eintrag pro Projekt mit Schlüssel unter ph_{projectKey}_posthog mit einer standardmäßigen Ablaufzeit von 365 Tagen. Die Init-Option persistence steuert den zugrunde liegenden Mechanismus: nur cookie, nur localStorage, localStorage+cookie (Standard), sessionStorage oder memory. Für ein Consent-First-Deployment ist die memory-Persistenz der richtige Standard, wenn noch keine Einwilligung erteilt wurde — sie stellt sicher, dass kein Bezeichner die Seitensitzung überlebt — mit einem Übergang zu localStorage+cookie, sobald die Einwilligung umgeschaltet wird. Das SDK schreibt außerdem unter __ph_opt_in_out_{projectKey} einen Opt-in- oder Opt-out-Marker, um die Auswahl des Nutzers über Besuche hinweg zu speichern; dieser Marker ist selbst ein unbedingt notwendiges Cookie, da er eine Einwilligungsentscheidung speichert.

PostHog-Module auf Einwilligungsrahmen abbilden

PostHog implementiert weder das IAB TCF noch die IAB Global Privacy Platform nativ und ist nicht als AdTech-Anbieter konzipiert. Es integriert sich jedoch über ein publisherseitiges Bridging mit Google Consent Mode v2, stellt eine native Opt-in- und Opt-out-API bereit und respektiert den Do-Not-Track-Header über die Init-Option respect_dnt. Das Muster, das in der Produktion funktioniert, behandelt jedes PostHog-Modul als eine separate Schranke, die an ein spezifisches CMP-Signal gebunden ist.

• Produktanalyse-Ereignisse sind an den Analyse-Zweck gebunden. In TCF-Begriffen ist das am häufigsten Zweck 8 (Messung der Inhalteleistung) kombiniert mit Zweck 1 (Speichern von und/oder Zugriff auf Informationen). Für Consent Mode entspricht dies analytics_storage.
• Session-Replay liegt hinter einer strengeren Schranke. Der Session-Replay von PostHog erfasst das gerenderte DOM und alle nicht maskierten Eingabefelder; daher ist ein Opt-in auf Präferenz- oder Forschungsebene, das sich von Analyse unterscheidet, die vertretbare Position nach EDPB-Leitlinien.
• Feature-Flags und Experimente können unter einem Legitimate-Interest-Basis mit flüchtiger, In-Memory-Auswertung laufen, wenn das Ziel nur darin besteht, die gerenderte Seite zu variieren. Eine persistente Flag-Zuweisung, die über Sitzungen hinweg an einen stabilen Bezeichner gebunden ist, erfordert dieselbe Einwilligung wie Analyse, denn dann wird das Flag zum nachverfolgbaren Datenpunkt auf Nutzerebene.
• Umfragen und Feedback sind an dieselbe Schranke wie Session-Replay gebunden, wenn sie Freitexteingaben sammeln, oder an die Analyse-Schranke, wenn sie nur Bewertungen oder Einzelauswahlantw­orten sammeln.

Das Integrationsmuster, das funktioniert

Das Referenz-Deployment hat vier Teile: eine CMP, die ein Echtzeit-Consent-Change-Ereignis bereitstellt, ein verzögertes Bootstrap, das PostHog mit deaktivierter Erfassung und deaktiviertem Replay initialisiert, einen Consent-Listener, der opt_in_capturing und den Aufzeichnungsschalter umschaltet, wenn die relevanten Schranken geöffnet werden, und einen Widerrufspfad, der opt_out_capturing aufruft, den Replay-Puffer stoppt und persistente Bezeichner über die Reset-API des SDK löscht.

Web-Implementierung

Das sauberste Muster ist, das PostHog SDK auf jeder Seite zu laden, aber als initiales Bootstrap posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) aufzurufen. Abonnieren Sie das Consent-Change-Ereignis des CMP. Wenn die Analyse-Kategorie auf true wechselt, rufen Sie posthog.set_config({ persistence: 'localStorage+cookie' }) gefolgt von posthog.opt_in_capturing() auf; dadurch wird die Ereigniserfassung wieder aktiviert und der Persistenzübergang beginnt, den eindeutigen Bezeichner zu schreiben. Wenn die Session-Replay-Kategorie auf true wechselt, rufen Sie posthog.startSessionRecording() auf. Wenn eine Schranke zurückgezogen wird, rufen Sie posthog.opt_out_capturing() für die Analyse-Schranke oder posthog.stopSessionRecording() für die Replay-Schranke auf, lassen Sie die entsprechenden Persistenz-Einträge über posthog.reset() ablaufen und senden Sie über die GDPR API von PostHog eine Löschanfrage, wenn der Nutzer sein Recht auf Löschung geltend gemacht hat.

Regionauswahl: PostHog Cloud US vs. EU vs. selbst gehostet

PostHog betreibt zwei Cloud-Regionen — US (us.posthog.com) und EU (eu.posthog.com) — und unterstützt selbst gehostete Installationen auf der eigenen Infrastruktur des Kunden. Für EWR- und UK-Traffic ist die EU-Cloud der richtige Standard; sie hält Ingest, Verarbeitung und Speicherung innerhalb des EWR und reduziert das Schrems-II-Risiko, das jedes US-Region-Analyse-Deployment mit sich bringt. Die Init-Option api_host legt die Region fest. Selbst gehostetes PostHog verlagert den gesamten Stack auf die eigene Infrastruktur des Publishers, was die stärkste Datenresidenz-Position darstellt, aber keine Einwilligungspflichten beseitigt — die Rechtsgrundlage folgt den Daten, nicht dem Betreiber. Welche Option auch gewählt wird, sie muss in der Datenschutzerklärung und im Verzeichnis der Verarbeitungstätigkeiten des Verantwortlichen wiedergegeben werden.

Serverseitige Erfassung

PostHog unterstützt serverseitigen Ereignis-Ingest über die Python-, Node-, Go-, Ruby- und PHP-SDKs. Serverseitige Ereignisse sind nicht von der Einwilligung ausgenommen — die Rechtsgrundlage folgt den Daten —, aber serverseitiger Ingest gibt dem Publisher volle Kontrolle darüber, welche Felder wann ausgegeben werden. Ein verbreitetes Muster ist es, serverseitig einen minimalen, nur notwendigen Ereignissatz auf Basis berechtigter Interessen zu erfassen und diese Ereignisse dann erst nach erteilter Analyse-Einwilligung mit Verhaltensdetails aus dem Client anzureichern. Serverseitige und clientseitige Ereignisse joinen auf demselben eindeutigen Bezeichner, wenn die Einwilligung umgeschaltet wurde; vor der Einwilligung werden serverseitige Ereignisse mit einem anonymen, kurzlebigen Bezeichner ausgegeben, der bei jeder Sitzung zurückgesetzt wird.

Validierung der Integration und Prüfpfad

Der Validierungsschritt ist das, was Regulatoren prüfen und was Publisher am häufigsten überspringen. Ein korrekt integriertes PostHog-Deployment muss vier Tests nacheinander bestehen. Erstens muss eine saubere Browser-Sitzung mit angezeigtem Banner, aber ohne getroffene Auswahl, null Anfragen an den konfigurierten api_host außer dem SDK-Dateiabruf, null ph_-Cookies in document.cookie und null ph_-Einträge in localStorage erzeugen. Zweitens muss die Ablehnung von Analyse diesen Zustand aufrechterhalten — keine Erfassung, keine Aufzeichnung, kein persistenter Bezeichner. Drittens muss die Annahme von Analyse unmittelbar ein $opt_in-Ereignis, den erwarteten ph_{projectKey}_posthog-Persistenz-Eintrag mit korrekten SameSite-Attributen und Ereignisverkehr zum konfigurierten Host erzeugen. Viertens muss der nachträgliche Widerruf der Einwilligung sofort weitere Erfassung und Replay stoppen, persistente Bezeichner ablaufen lassen und über die GDPR API von PostHog eine Löschanfrage auslösen, wenn der Nutzer die Löschung geltend gemacht hat.

Die Prüfpfad-Erwartung nach den EDPB-Cookie-Banner-Leitlinien von 2023 und den erneuerten Task-Force-Prioritäten für 2026 lautet, dass der Publisher für jedes Ereignis im PostHog-Projekt nachweisen kann, dass der Nutzer, der es erzeugt hat, zum Zeitpunkt der Erfassung eine gültige Einwilligung erteilt hatte. Das Standardmuster ist es, die Einwilligungsversion und den Zeitstempel als Personeneigenschaften auf der eindeutigen ID über posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) zu setzen, damit jedes einzelne Ereignis auf einen bestimmten Einwilligungslog-Eintrag zurückverfolgt werden kann. Ein korrekt geschranktes Deployment in Kombination mit einer zur Zielgruppe passenden Regionauswahl, einer standardmäßig auf Memory eingestellten Persistenz und einem Löschpfad, der beim Widerruf ausgelöst wird, ist das, was PostHog von einem regulatorischen Konzentrationsrisiko in ein vertretbares Zentrum des Produktanalyse-Stacks verwandelt.