Hvorfor PostHog krever samtykke — og hvorfor svaret ikke er det samme for alle moduler

PostHog-nett-SDK er ikke en passiv sidetagg. Ved standard initialisering setter SDK inn én eller flere persistensoppføringer for første part — som standard et kombinert cookie og localStorage-opplegg nøklet under ph_{projectKey}_posthog — genererer en stabil distinkt identifikator, registrerer den innledende sidevisningen med referanseside, UTM-parametere og klikk-identifikatorer, og åpner en langvarig hendelseskanal til den konfigurerte inntaksvertstjeneren. Hvis sesjonsavspilling er aktivert på prosjektnivå, begynner SDK-en dessuten å streame en kontinuerlig oversikt over det renderte DOM, musepekeren og inndatahendelser. Hvis funksjonsflagg er konfigurert, evaluerer SDK-en dem mot den distinkte identifikatoren, lagrer avgjørelsene for sesjonen og sender ut en $feature_flag_called-hendelse for hver evaluering.

Hver av disse aktivitetene tilsvarer en annen samtykkeporten. Å lagre en distinkt identifikator er en lagrings- og tilgangsoperasjon under Article 5(3) i ePrivacy-direktivet og krever forhåndsgitt, fritt gitt, spesifikt, informert og entydig samtykke i hele EØS, Storbritannia og enhver jurisdiksjon som har importert den samme standarden. Å registrere atferdshendelser er behandling av personopplysninger under GDPR fordi kombinasjonen av identifikator, IP-adresse og atferdsspor er tilstrekkelig til å identifisere en person. Sesjonsavspilling er i en separat, strengere kategori under EDPB-veiledningen for sesjonsavspilling — avspilling registrerer det renderte DOM og eventuelle umaskerte inndatafelter og krever eksplisitt, granulert samtykke som er distinkt fra generisk analysesamtykke. Evaluering av funksjonsflagg er den subtile: en flaggsjekk som returnerer en boolsk verdi, krever ikke i seg selv samtykke, men å lagre brukerens flaggtilordning til en stabil identifikator på tvers av sesjoner krever det, fordi det er slik flaggbasert eksperimentering skaper sporbare data på brukernivå.

Hva PostHog skriver før samtykke — og hva som må undertrykkes

Standard PostHog Browser SDK skriver følgende ved initialisering: én kombinert cookie og localStorage-oppføring under ph_{projectKey}_posthog som inneholder den distinkte identifikatoren, sesjonsidentifikatoren og funksjonsflagg-avgjørelsene, pluss, når sesjonsavspilling er aktivert, en ekstra opptaksbuffer i minnet som tømmes til innholdsendepunktet hvert par sekunder. SDK-en sender også en umiddelbar $pageview-hendelse og, hvis autofangst er på, alle påfølgende klikk, skjemainteraksjoner og raserihendelser på siden.

Det anbefalte mønsteret er å initialisere PostHog med opt_out_capturing_by_default: true og disable_session_recording: true, og deretter snu begge flaggene når samtykkebannerden returnerer et positivt signal. Dette er integrasjonsposisjonen som PostHog-dokumentasjonen nå anbefaler, og det er posisjonen som overlever en regulators gjennomgang fordi den inverterer standarden: ingenting registreres før samtykke er registrert, og SDK-en gir en ren overgang fremfor en tilstandsbasert modernisering.

Informasjonskapsler, localStorage-oppføringer og identifikatorer PostHog lagrer

Browser SDK 1.x skriver én persistensoppføring per prosjekt, nøklet under ph_{projectKey}_posthog, med standard utløp på 365 dager. Init-alternativet persistence kontrollerer den underliggende mekanismen: bare cookie, bare localStorage, localStorage+cookie (standarden), sessionStorage eller memory. For en samtykke-først-distribusjon er memory-persistens den riktige standarden når samtykke ennå ikke er gitt — det sikrer at ingen identifikator overlever sidesesjonen — med en overgang til localStorage+cookie når samtykke snus. SDK-en skriver også en opt-in- eller opt-out-markering under __ph_opt_in_out_{projectKey} for å huske brukerens valg mellom besøk; den markeringen er i seg selv en nødvendig informasjonskapsel fordi den lagrer en samtykkebestemmelse.

Kartlegging av PostHog-moduler til samtykkerammer

PostHog implementerer ikke IAB TCF eller IAB Global Privacy Platform, og det er ikke bygget som en ad-tech-leverandør. Det integrerer imidlertid med Google Consent Mode v2 gjennom bridging på utgivernes side, eksponerer en nativ opt-in og opt-out API, og respekterer Do Not Track-hodet via init-alternativet respect_dnt. Mønsteret som fungerer i produksjon, behandler hver PostHog-modul som en separat port bundet til et spesifikt CMP-signal.

• Produktanalysehendelser er knyttet til analyseformålet. I TCF-termer er dette oftest formål 8 (måle innholdsytelse) kombinert med formål 1 (lagre og/eller få tilgang til informasjon). For Consent Mode tilsvarer dette analytics_storage.
• Sesjonsavspilling er bak en strengere port. PostHog-sesjonsavspillingen registrerer det renderte DOM og eventuelle umaskerte inndatafelter, så en opt-in på preferanse- eller forskningsnivå distinkt fra analyse er den forsvarlige posisjonen under EDPB-veiledningen.
• Funksjonsflagg og eksperimentering kan kjøre med flyktig, minnebasert evaluering under et grunnlag for berettiget interesse når målet bare er å variere den rendrede siden. Vedvarende flaggtilordning knyttet til en stabil identifikator på tvers av sesjoner krever det samme samtykket som analyse, fordi det er da flagget blir et sporbart datapunkt på brukernivå.
• Undersøkelser og tilbakemeldinger er knyttet til den samme porten som sesjonsavspilling når de samler inn fritekstinndata, eller til analyseportalen når de bare samler inn vurderinger eller enkeltvalgsvar.

Integrasjonsmønsteret som fungerer

Referansedistribusjonen har fire deler: en CMP som eksponerer en sanntids samtykkeendringshendelse, en utsatt bootstrap som initialiserer PostHog med registrering og avspilling deaktivert, en samtykkehendelseslytter som snur opt_in_capturing og opptaksbryteren når de relevante portene åpnes, og en tilbakekallingsbane som kaller opt_out_capturing, stopper avspillingsbufferen og sletter vedvarende identifikatorer via SDK-ens tilbakestillings-API.

Nettimplementering

Det reneste mønsteret er å laste inn PostHog SDK på hver side, men kalle 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 den innledende bootstrap. Abonner på CMP-ens samtykkeendringshendelse. Når analysekategorien overgår til true, kaller du posthog.set_config({ persistence: 'localStorage+cookie' }) etterfulgt av posthog.opt_in_capturing(); dette aktiverer hendelsesregistrering på nytt og persistensovergangen begynner å skrive den distinkte identifikatoren. Når sesjonsavspillingskategorien overgår til true, kaller du posthog.startSessionRecording(). Når en av portene trekkes tilbake, kaller du posthog.opt_out_capturing() for analyseportalen eller posthog.stopSessionRecording() for avspillingsporten, utløper de relevante persistensoppføringene via posthog.reset(), og sender inn en slettingsforespørsel via PostHog GDPR-API-en hvis brukeren har påberopt seg sletteretten.

Regionsvalg: PostHog Cloud US vs EU vs selvhostet

PostHog driver to skyregioner — US (us.posthog.com) og EU (eu.posthog.com) — og støtter selvhoste installasjoner på kundens egen infrastruktur. For EØS- og Storbritannia-trafikk er EU-skyen den riktige standarden; den holder inntak, behandling og lagring innenfor EØS og reduserer Schrems II-eksponeringen som alle US-region-analytikkdistribusjoner bærer. Init-alternativet api_host fester regionen. Selvhostet PostHog flytter hele stakken til utgiverens egen infrastruktur, som er den sterkeste posisjonen for dataresidency, men fjerner ikke samtykkeforpliktelsene — det rettslige grunnlaget følger dataene, ikke operatøren. Uansett hvilken alternativ som velges, må det gjenspeiles i personvernerklæringen og kontrollerens behandlingsregister.

Serversideopptaking

PostHog støtter serversidehendelsesopptak via Python-, Node-, Go-, Ruby- og PHP-SDK-ene. Serversidehendelser er ikke unntatt fra samtykke — det rettslige grunnlaget følger dataene — men serversidefangst gir utgiveren full kontroll over hvilke felter som sendes ut og når. Et vanlig mønster er å fange opp et minimalt, kun-essensielle hendelsessett på serversiden under berettiget interesse, og deretter berike disse hendelsene med atferdsdetaljer fra klienten bare etter at brukeren har gitt analysesamtykke. Serversiden og klientsidehendelsene kobles til den samme distinkte identifikatoren når samtykke er snudd; før samtykke sendes serversidehendelsene med en anonym, flyktig identifikator som tilbakestilles på hver sesjon.

Validering av integrasjonen og revisjonssporet

Valideringstrinnet er det regulatorer sjekker og det utgivere oftest hopper over. En korrekt integrert PostHog-distribusjon må bestå fire tester i rekkefølge. For det første må en ren nettlesersesjon med banneret vist men ingen valg foretatt produsere null forespørsler til den konfigurerte api_host utover SDK-filhentingen, null ph_-informasjonskapsler i document.cookie og null ph_-oppføringer i localStorage. For det andre må avvisning av analyse opprettholde den tilstanden — ingen registrering, ingen opptak, ingen vedvarende identifikator. For det tredje må aksept av analyse produsere en umiddelbar $opt_in-hendelse, den forventede persistensoppføringen ph_{projectKey}_posthog med korrekte SameSite-attributter og hendelsesttrafikk som strømmer til den konfigurerte verten. For det fjerde må tilbakekalling av samtykke etter faktum umiddelbart stoppe videre registrering og avspilling, utløpe vedvarende identifikatorer og utløse en slettingsforespørsel via PostHog GDPR-API-en hvis brukeren har påberopt seg sletting.

Revisjonssporforventningen under EDPB-ens 2023-retningslinjer for informasjonskapselbannere og de fornyede 2026-arbeidsgruppeprioritene er at utgiveren kan bevise, for enhver gitt hendelse i PostHog-prosjektet, at brukeren som genererte den hadde gitt gyldig samtykke på tidspunktet for registrering. Standardmønsteret er å angi samtykkeversjon og tidsstempel som personegenskaper på den distinkte ID-en via posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) slik at enhver individuell hendelse er sporbar tilbake til en spesifikk samtykkeloggoppføring. En korrekt sikret distribusjon, kombinert med regionsvalg som samsvarer med publikum, persistens som standard er minne og en slettingsbane som aktiveres ved tilbakekalling, er det som gjør PostHog fra en regulatorisk konsentrasjonsrisiko til et forsvarlig senter i produktanalysestabelen.