Hvorfor PostHog kræver samtykke — og hvorfor svaret ikke er det samme for hvert modul

PostHogs web-SDK er ikke en passiv side-tag. Ved en standard initialisering sætter SDK en eller flere persistensindgange — som standard et kombineret cookie- og localStorage-skema med nøgle under ph_{projectKey}_posthog — genererer et stabilt distinkt identifikator, fanger den indledende sidevisning med referrer, UTM-parametre og klikidentifikatorer og åbner en langvarig hændelseskanal til den konfigurerede ingest-host. Hvis sessionsafspilning er aktiveret på projektniveau, begynder SDK'en desuden at streame et løbende optag af det renderede DOM, musekoordinater og inputhændelser. Hvis funktionsflag er konfigureret, evaluerer SDK'en dem mod det distinkte identifikator, fastholder beslutningerne for sessionen og udsender en $feature_flag_called-hændelse for hver evaluering.

Hver af disse aktiviteter svarer til en anden samtykkeport. At fastholde et distinkt identifikator er en lagrings-og-adgangsoperation under Article 5(3) i ePrivacy-direktivet og kræver forudgående, frit givet, specifikt, informeret og utvetydigt samtykke på tværs af EØS, UK og enhver jurisdiktion, der har importeret den samme standard. At fange adfærdshændelser er behandling af personoplysninger under GDPR, fordi kombinationen af identifikator, IP-adresse og adfærdsspor er tilstrækkelig til at identificere en person. Sessionsafspilning befinder sig i en separat, strengere kategori under EDPB's vejledning om sessionsafspilning — afspilning fanger det renderede DOM og ethvert umaskeret inputfelt og kræver eksplicit, granulært samtykke, der er adskilt fra generisk analysesamtykke. Evaluering af funktionsflag er det subtile: en flagkontrol, der returnerer en boolean, kræver ikke samtykke i sig selv, men at fastholde brugerens flagtildeling til et stabilt identifikator på tværs af sessioner gør, fordi det er sådan flagbaseret eksperimentering skaber sporbare data på brugerniveau.

Hvad PostHog skriver, inden samtykke — og hvad der skal undertrykkes

Standard PostHog Browser SDK skriver følgende ved initialisering: én kombineret cookie- og localStorage-indgang under ph_{projectKey}_posthog indeholdende det distinkte identifikator, sessionsidentifikatoren og funktionsflag-beslutninger, plus, når sessionsafspilning er aktiveret, en yderligere in-memory optagelsesbuffer, der tømmes til ingest-endpoint hvert par sekunder. SDK'en sender også en øjeblikkelig $pageview-hændelse og, hvis autofangst er slået til, ethvert efterfølgende klik, formularinteraktion og rageclick på siden.

Det anbefalede mønster er at initialisere PostHog med opt_out_capturing_by_default: true og disable_session_recording: true og derefter slå begge flag til, når samtykkebanneret returnerer et positivt signal. Dette er den integrationsstilling, som PostHog-dokumentationen nu anbefaler, og det er den stilling, der overlever en regulators gennemgang, fordi den inverterer standarden: intet fanges, indtil samtykke er registreret, og SDK'en giver en ren overgang i stedet for en stateful retrofit.

De cookies, localStorage-indgange og identifikatorer, som PostHog fastholder

Browser SDK 1.x skriver én persistensindgang pr. projekt, med nøgle under ph_{projectKey}_posthog, med en standard udløbstid på 365 dage. persistence-initialiserings-optionen styrer den underliggende mekanisme: kun cookie, kun localStorage, localStorage+cookie (standard), sessionStorage eller memory. Til et samtykke-first deployment er memory-persistens den rigtige standard, når samtykke endnu ikke er givet — den sikrer, at intet identifikator overlever siden-sessionen — med en overgang til localStorage+cookie, når samtykke skifter. SDK'en skriver også en opt-in- eller opt-out-markør under __ph_opt_in_out_{projectKey} for at huske brugerens valg på tværs af besøg; den markør er i sig selv en strengt nødvendig cookie, fordi den fastholder en samtykkebeslutning.

Kortlægning af PostHog-moduler til samtykkerammer

PostHog implementerer ikke IAB TCF eller IAB Global Privacy Platform native, og det er ikke bygget som en adtech-leverandør. Det integrerer dog med Google Consent Mode v2 gennem brokobling på udgiversiden, eksponerer en native opt-in og opt-out API og respekterer Do Not Track-headeren via respect_dnt-initialiserings-optionen. Det mønster, der fungerer i produktion, behandler hvert PostHog-modul som en separat port bundet til et specifikt CMP-signal.

• Produktanalyse-hændelser er bundet til analysformålet. I TCF-termer er dette oftest formål 8 (måle indholdsydelse) kombineret med formål 1 (lagre og/eller få adgang til information). For Consent Mode svarer dette til analytics_storage.
• Sessionsafspilning befinder sig bag en strengere port. PostHogs sessionsafspilning fanger det renderede DOM og ethvert umaskeret inputfelt, så et præference- eller forskningsniveau opt-in, der er adskilt fra analyse, er den forsvarlige stilling under EDPB's vejledning.
• Funktionsflag og eksperimentering kan køre med flygtig, in-memory evaluering under et legitimitetsgrundlag, når målet kun er at variere den renderede side. Vedvarende flagtildeling knyttet til et stabilt identifikator på tværs af sessioner kræver det samme samtykke som analyse, fordi det er da, flaget bliver et sporbart datapunkt på brugerniveau.
• Undersøgelser og feedback er bundet til den samme port som sessionsafspilning, når de indsamler fritekstinput, eller til analyseporten, når de kun indsamler vurderinger eller enkeltvalg-svar.

Det integrationsmønster, der fungerer

Referencedeploy'et har fire dele: en CMP, der eksponerer en realtids samtykkeskiftehændelse, et udskudt bootstrap, der initialiserer PostHog med deaktiveret fangst og afspilning, en samtykkely­tter, der slår opt_in_capturing og optagelseskontakten til, når de relevante porte åbner, og en tilbagetrækningssti, der kalder opt_out_capturing, stopper afspilningsbufferen og rydder persistente identifikatorer via SDK'ens nulstillings-API.

Webimplementering

Det reneste mønster er at indlæse PostHog SDK på hver side, men at kalde posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) som det første bootstrap. Abonner på CMP'ens samtykkeskiftehændelse. Når analysekategorien overgår til true, kald posthog.set_config({ persistence: 'localStorage+cookie' }) efterfulgt af posthog.opt_in_capturing(); dette genaktiverer hændelsesfangst, og persistensovergangen begynder at skrive det distinkte identifikator. Når sessionsafspilningskategorien overgår til true, kald posthog.startSessionRecording(). Når en port trækkes tilbage, kald posthog.opt_out_capturing() for analyseporten eller posthog.stopSessionRecording() for afspilningsporten, lad de relevante persistensindgange udløbe via posthog.reset() og afsend en sletningsanmodning via PostHogs GDPR API, hvis brugeren har gjort brug af sin ret til sletning.

Regionvalg: PostHog Cloud US vs EU vs selvhostet

PostHog opererer to cloudregioner — US (us.posthog.com) og EU (eu.posthog.com) — og understøtter selvhostede installationer på kundens egen infrastruktur. For EØS- og UK-trafik er EU-skyen den rigtige standard; den holder ingest, behandling og lagring inden for EØS og reducerer Schrems II-eksponeringen, som enhver US-region analytikdeployment bærer. api_host-initialiserings-optionen fastlåser regionen. Selvhostet PostHog flytter hele stakken over på udgiverens egen infrastruktur, hvilket er den stærkeste dataresidenspoition, men fjerner ikke samtykkeforpligtelserne — det juridiske grundlag følger dataene, ikke operatøren. Uanset hvilken mulighed der vælges, skal den afspejles i privatlivspolitikken og den dataansvarliges behandlingsregistre.

Server-side fangst

PostHog understøtter server-side hændelsesingest via Python-, Node-, Go-, Ruby- og PHP-SDK'erne. Server-side hændelser er ikke fritaget for samtykke — det juridiske grundlag følger dataene — men server-side ingest giver udgiveren fuld kontrol over, hvilke felter der udsendes og hvornår. Et almindeligt mønster er at fange et minimalt sæt af rent nødvendige hændelser server-side under legitim interesse og derefter berige disse hændelser med adfærdsdetaljer fra klienten kun, efter at brugeren har givet analysesamtykke. Server-side og klient-side hændelser joiner på det samme distinkte identifikator, når samtykke er skiftet; før samtykke udsendes server-side hændelser med et anonymt, kortvarigt identifikator, der nulstilles ved hver session.

Validering af integrationen og revisionssporet

Valideringstrinnet er, hvad regulatorer kontrollerer, og hvad udgivere oftest springer over. Et korrekt integreret PostHog-deployment skal bestå fire tests i rækkefølge. For det første skal en ren browsersession med banneret vist, men uden foretaget valg, producere nul anmodninger til den konfigurerede api_host ud over SDK-filhentningen, nul ph_-cookies i document.cookie og nul ph_-indgange i localStorage. For det andet skal afvisning af analyse holde denne tilstand — ingen fangst, ingen optagelse, intet persistente identifikator. For det tredje skal accept af analyse producere en øjeblikkelig $opt_in-hændelse, den forventede ph_{projectKey}_posthog-persistensindgang med korrekte SameSite-attributter og hændelsestraffik, der flyder til den konfigurerede host. For det fjerde skal tilbagetrækning af samtykke efterfølgende øjeblikkeligt stoppe yderligere fangst og afspilning, lade persistente identifikatorer udløbe og udløse en sletningsanmodning via PostHogs GDPR API, hvis brugeren har påberåbt sig sletning.

Revisionssti-forventningen under EDPB's cookie-banner-retningslinjer fra 2023 og de fornyede prioriteter for taskforcen i 2026 er, at udgiveren kan bevise for enhver given hændelse i PostHog-projektet, at den bruger, der genererede den, havde givet gyldigt samtykke på fangst-tidspunktet. Standardmønsteret er at indstille samtykkeversionen og tidsstemplet som personegenskaber på det distinkte ID via posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }), så enhver individuel hændelse kan spores tilbage til en specifik samtykkelogpost. Et korrekt gatekepet deployment, kombineret med regionvalg, der matcher målgruppen, persistens, der som standard er memory, og en sletningssti, der aktiveres ved tilbagetrækning, er det, der forvandler PostHog fra en regulatorisk koncentrationsrisiko til et forsvarligt center i produktanalysestakken.