Varför PostHog kräver samtycke — och varför svaret inte är detsamma för varje modul

PostHog:s webb-SDK är inte en passiv sidtagg. Vid en standardinitiering sätter SDK:n en eller flera beständiga poster på första part — som standard ett kombinerat cookie plus localStorage-schema med nyckel under ph_{projectKey}_posthog — genererar en stabil unik identifierare, fångar den första sidvisningen med hänvisare, UTM-parametrar och klickidentifierare, och öppnar en långlivad händelsekanal till den konfigurerade intagsvärden. Om sessionsuppspelning är aktiverat på projektnivå börjar SDK:n dessutom strömma en kontinuerlig post av den renderade DOM:en, muskoordinater och indatahändelser. Om funktionsflaggor är konfigurerade utvärderar SDK:n dem mot den unika identifieraren, bevarar besluten för sessionen och sänder ut ett $feature_flag_called-händelse för varje utvärdering.

Var och en av dessa aktiviteter mappas till en annan samtyckesport. Att bevara en unik identifierare är en lagrings-och-åtkomst-operation enligt Artikel 5(3) i ePrivacy-direktivet och kräver ett föregående, fritt givet, specifikt, informerat och otvetydigt samtycke i hela EEA, UK och alla jurisdiktioner som har importerat samma standard. Att fånga beteendehändelser är behandling av personuppgifter enligt GDPR eftersom kombinationen av identifierare, IP-adress och beteendespår räcker för att peka ut en individ. Sessionsuppspelning tillhör en separat, striktare kategori enligt EDPB:s vägledning om sessionsuppspelning — uppspelning fångar den renderade DOM:en och alla omaskerade inmatningsfält och kräver uttryckligt, granulerat samtycke som är skilt från generellt analytiksamtycke. Utvärdering av funktionsflaggor är den subtila aspekten: en flaggkontroll som returnerar ett booleskt värde kräver inte i sig samtycke, men att bevara användarens flaggtilldelning till en stabil identifierare över sessioner kräver det, eftersom det är så flaggbaserad experimentering skapar spårbara användarspecifika data.

Vad PostHog skriver innan samtycke — och vad som måste undertryckas

Standardversionen av PostHog Browser SDK skriver följande vid initiering: en kombinerad cookie- och localStorage-post under ph_{projectKey}_posthog som innehåller den unika identifieraren, sessionsidentifieraren och beslut om funktionsflaggor, plus, när sessionsuppspelning är aktiverat, en extra inspelningsbuffert i minnet som töms till intagsändpunkten var några sekunder. SDK:n skickar också omedelbart en $pageview-händelse och, om automatisk insamling är på, varje efterföljande klick, formulärinteraktion och raseriklick på sidan.

Det rekommenderade mönstret är att initialisera PostHog med opt_out_capturing_by_default: true och disable_session_recording: true, och sedan vända båda flaggorna när samtyckesbaneren returnerar en positiv signal. Det är den integreringspostur som PostHog-dokumentationen nu rekommenderar, och det är den postur som överlever en regulators granskning eftersom den inverterar standarden: inget fångas tills samtycke registreras, och SDK:n ger en ren övergång snarare än en tillståndsbaserad efterhandskonfiguration.

Cookies, localStorage-poster och identifierare som PostHog bevarar

Browser SDK 1.x skriver en beständig post per projekt, med nyckel under ph_{projectKey}_posthog, med en standard utgångstid på 365 dagar. Initieringsalternativet persistence styr den underliggande mekanismen: endast cookie, endast localStorage, localStorage+cookie (standard), sessionStorage eller memory. För en samtyckesfirst-driftsättning är memory-beständighet rätt standard när samtycke ännu inte har beviljats — det säkerställer att ingen identifierare överlever sidsessionen — med en övergång till localStorage+cookie när samtycket vänder. SDK:n skriver också en opt-in eller opt-out-markör under __ph_opt_in_out_{projectKey} för att komma ihåg användarens val över besök; den markören är i sig en strikt nödvändig cookie eftersom den bevarar ett samtycksbeslut.

Mappning av PostHog-moduler till samtycksramverk

PostHog implementerar inte nativt IAB TCF eller IAB Global Privacy Platform, och är inte byggt som en annonsteknikleverantör. Det integrerar dock med Google Consent Mode v2 genom bryggor på utgivarsidan, exponerar ett native opt-in och opt-out API, och respekterar Do Not Track-rubriken via initieringsalternativet respect_dnt. Mönstret som fungerar i produktion behandlar varje PostHog-modul som en separat port bunden till en specifik CMP-signal.

• Produktanalyshändelser är bundna till analyseringssyftet. I TCF-termer är detta oftast syfte 8 (mäta innehållsprestanda) kombinerat med syfte 1 (lagra och/eller åtkomst till information). För Consent Mode mappar detta till analytics_storage.
• Sessionsuppspelning ligger bakom en striktare port. PostHog:s sessionsuppspelning fångar den renderade DOM:en och alla omaskerade inmatningsfält, så ett preferens- eller forskningsnivå opt-in skild från analys är den försvarsbara hållningen enligt EDPB:s vägledning.
• Funktionsflaggor och experimentering kan köras med efemär, minnesbaserad utvärdering under en legitim intressebas när målet enbart är att variera den renderade sidan. Beständig flaggtilldelning knuten till en stabil identifierare över sessioner kräver samma samtycke som analys, eftersom det är då flaggan blir en spårbar datapoint på användarnivå.
• Enkäter och feedback är bundna till samma port som sessionsuppspelning när de samlar in fritext, eller till analysports när de bara samlar in betyg eller enkelsvarssvar.

Integreringsmönstret som fungerar

Referensimplementationen har fyra delar: en CMP som exponerar en händelse för samtyckesändring i realtid, en uppskjuten bootstrap som initialiserar PostHog med insamling och uppspelning inaktiverade, en samtyckeslyssnare som vänder opt_in_capturing och inspelningsbrytaren när de relevanta portarna öppnas, och en återkallningsväg som anropar opt_out_capturing, stoppar uppspelningsbufferten och rensar beständiga identifierare via SDK:ns reset API.

Webbimplementering

Det renaste mönstret är att ladda PostHog SDK på varje sida men anropa 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 initiala bootstrapen. Prenumerera på CMP:ns samtycksändringshändelse. När analyskategorin övergår till true anropar du posthog.set_config({ persistence: 'localStorage+cookie' }) följt av posthog.opt_in_capturing(); detta återaktiverar händelseinsamling och beständighetstransitionen börjar skriva den unika identifieraren. När sessionsuppspelningskategorin övergår till true anropar du posthog.startSessionRecording(). När någon port återkallas anropar du posthog.opt_out_capturing() för analysporten eller posthog.stopSessionRecording() för uppspelningsporten, låter de relevanta beständighetposterna gå ut via posthog.reset(), och skickar en raderingsbegäran via PostHog:s GDPR API om användaren har åberopat sin raderingsrätt.

Regionval: PostHog Cloud US kontra EU kontra självhostad

PostHog driver två molnregioner — US (us.posthog.com) och EU (eu.posthog.com) — och stöder självhostad installation på kundens egna infrastruktur. För EEA- och UK-trafik är EU-molnet rätt standard; det håller intag, bearbetning och lagring inom EEA och minskar Schrems II-exponeringen som varje US-regions analytikdriftsättning medför. Initieringsalternativet api_host fastställer regionen. Självhostad PostHog flyttar hela stacken till utgivarens egna infrastruktur, vilket är den starkaste dataresidenspositionen, men tar inte bort samtyckesskyldigheter — den rättsliga grunden följer datan, inte operatören. Vilket alternativ som än väljs måste återspeglas i integritetsmeddelandet och registeransvarigs register över behandling.

Serverhändelseinsamling

PostHog stöder serverhändelseintagning via Python, Node, Go, Ruby och PHP SDK:er. Serverhändelser är inte undantagna från samtycke — den rättsliga grunden följer datan — men serverintag ger utgivaren fullständig kontroll över vilka fält som sänds ut och när. Ett vanligt mönster är att fånga en minimal uppsättning väsentliga händelser på serversidan under legitimt intresse, och sedan berika dessa händelser med beteendedetaljer från klienten först efter att användaren har beviljat analytiksamtycke. Serverhändelserna och klienthändelserna slås samman på samma unika identifierare när samtycket har vänts; innan samtycket sänds ut serverhändelserna med en anonym, efemär identifierare som återställs vid varje session.

Validering av integrationen och revisionsspåret

Valideringssteget är vad regulatorer kontrollerar och vad utgivare oftast hoppar över. En korrekt integrerad PostHog-driftsättning måste klara fyra tester i följd. Först måste en ren webbläsarsession med baneren visad men inget val gjort producera noll begäranden till den konfigurerade api_host utöver SDK-filhämtningen, noll ph_-cookies i document.cookie, och noll ph_-poster i localStorage. Andra, att avvisa analys måste hålla det tillståndet — ingen insamling, ingen inspelning, ingen beständig identifierare. Tredje, att acceptera analys måste omedelbart producera en $opt_in-händelse, den förväntade beständighetsposten ph_{projectKey}_posthog med korrekta SameSite-attribut, och händelsetrafik som flödar till den konfigurerade värden. Fjärde, att återkalla samtycke efter det faktum måste omedelbart stoppa ytterligare insamling och uppspelning, låta beständiga identifierare gå ut och utlösa en raderingsbegäran via PostHog:s GDPR API om användaren har åberopat radering.

Förväntningen på revisionsspåret enligt EDPB:s 2023 cookie-bannerriktlinjer och de förnyade 2026 prioriteringarna för arbetsgruppen är att utgivaren kan bevisa, för varje given händelse i PostHog-projektet, att användaren som genererade den hade gett giltigt samtycke vid insamlingstillfället. Standardmönstret är att ange samtyckesversion och tidstämpel som personegenskaper på det unika ID:t via posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) så att varje enskild händelse är spårbar tillbaka till en specifik samtyckesloggpost. En korrekt grindad driftsättning, kombinerad med regionval som matchar publiken, beständighet som standard är minne, och en raderingsväg som aktiveras vid återkallelse, är vad som förvandlar PostHog från en regulatorisk koncentrationsrisk till ett försvarbart centrum i produktanalysstacken.