Waarom PostHog toestemming vereist — en waarom het antwoord niet hetzelfde is voor elke module

De web-SDK van PostHog is geen passieve paginatag. Bij een standaardinitalisatie stelt de SDK een of meer persistente vermeldingen van de eerste partij in — standaard een gecombineerd cookie- en localStorage-schema met de sleutel ph_{projectKey}_posthog — genereert een stabiele unieke identifier, legt de initiële paginaweergave vast met verwijzer, UTM-parameters en klikidentificatoren, en opent een langdurig gebeurteniskanaal naar de geconfigureerde opnameconfiguratie. Als sessieherhaling op projectniveau is ingeschakeld, begint de SDK bovendien een doorlopende opname van de weergegeven DOM, muiscoördinaten en invoergebeurtenissen te streamen. Als functiemarkering is geconfigureerd, evalueert de SDK deze ten opzichte van de unieke identifier, bewaart de beslissingen voor de sessie en zendt een $feature_flag_called-gebeurtenis uit voor elke evaluatie.

Elk van deze activiteiten correspondeert met een ander toestemmingspoort. Het opslaan van een unieke identifier is een opslag- en toegangsoperatie krachtens Article 5(3) van de ePrivacy-richtlijn en vereist voorafgaande, vrijelijk gegeven, specifieke, geïnformeerde en ondubbelzinnige toestemming in de EER, het VK en elke jurisdictie die dezelfde norm heeft overgenomen. Het vastleggen van gedragsgebeurtenissen is de verwerking van persoonsgegevens krachtens de GDPR, omdat de combinatie van identifier, IP-adres en gedragsspoor voldoende is om een individu te identificeren. Sessieherhaling valt in een afzonderlijke, strengere categorie onder de sessieherhalingsrichtlijnen van de EDPB — herhaling legt de weergegeven DOM en eventuele niet-gemaskeerde invoervelden vast en vereist expliciete, gedetailleerde toestemming die losstaat van generieke analysetoestemming. Functiemarkeeringsevaluatie is de subtiele: een markeeringscontrole die een boolean retourneert, vereist op zichzelf geen toestemming, maar het opslaan van de markeeringstoewijzing van de gebruiker aan een stabiele identifier over sessies heen vereist dit wel, omdat dat de manier is waarop op markering gebaseerde experimenten traceerbare gebruikersniveaugegevens creëren.

Wat PostHog schrijft vóór toestemming — en wat onderdrukt moet worden

De standaard PostHog Browser SDK schrijft het volgende bij initialisatie: één gecombineerde cookie- en localStorage-vermelding onder ph_{projectKey}_posthog met de unieke identifier, sessie-identifier en beslissingen over functiemarkering, plus, wanneer sessieherhaling is ingeschakeld, een extra opnamebuffer in het geheugen die elke paar seconden naar het opname-eindpunt wordt gestuurd. De SDK stuurt ook onmiddellijk een $pageview-gebeurtenis en, als automatisch vastleggen is ingeschakeld, elke volgende klik, formulierinteractie en woedeklik op de pagina.

Het aanbevolen patroon is om PostHog te initialiseren met opt_out_capturing_by_default: true en disable_session_recording: true, en vervolgens beide markeringen om te keren zodra de toestemmingsbanner een positief signaal retourneert. Dit is de integratiepositie die de PostHog-documentatie nu aanbeveelt, en het is de positie die een toetsing door een toezichthouder doorstaat, omdat het de standaard omkeert: er wordt niets vastgelegd totdat de toestemming is geregistreerd, en de SDK biedt een schone overgang in plaats van een stateful retrofit.

De cookies, localStorage-vermeldingen en identifiers die PostHog opslaat

De Browser SDK 1.x schrijft één persistentievermelding per project, met de sleutel ph_{projectKey}_posthog, met een standaard verlooptermijn van 365 dagen. De init-optie persistence bepaalt het onderliggende mechanisme: alleen cookie, alleen localStorage, localStorage+cookie (de standaard), sessionStorage of memory. Voor een toestemming-eerst implementatie is memory-persistentie de juiste standaard wanneer er nog geen toestemming is verleend — het zorgt ervoor dat geen enkele identifier de paginasessie overleeft — met een overgang naar localStorage+cookie zodra de toestemming wordt omgezet. De SDK schrijft ook een opt-in of opt-out markering onder __ph_opt_in_out_{projectKey} om de keuze van de gebruiker bij bezoeken te onthouden; die markering zelf is een strikt noodzakelijk cookie omdat het een toestemmingsbeslissing bewaart.

PostHog-modules koppelen aan toestemmingskaders

PostHog implementeert IAB TCF of het IAB Global Privacy Platform niet van nature, en het is niet gebouwd als een ad-tech-leverancier. Het integreert echter met Google Consent Mode v2 via bridging aan de uitgeverskant, biedt een native opt-in en opt-out API, en respecteert de Do Not Track-header via de respect_dnt-init-optie. Het patroon dat in productie werkt, behandelt elke PostHog-module als een afzonderlijke poort die gebonden is aan een specifiek CMP-signaal.

• Productanalysegebeurtenissen zijn gebonden aan het analysedoel. In TCF-termen is dit het meest voorkomend doel 8 (het meten van inhoudsprestaties) gecombineerd met doel 1 (informatie opslaan en/of openen). Voor Consent Mode komt dit overeen met analytics_storage.
• Sessieherhaling bevindt zich achter een strengere poort. De sessieherhaling van PostHog legt de weergegeven DOM en eventuele niet-gemaskeerde invoervelden vast, dus een opt-in op voorkeurs- of onderzoeksniveau die losstaat van analyse is de verdedigbare positie krachtens de EDPB-richtlijnen.
• Functiemarkering en experimenten kunnen werken met vluchtige evaluatie in het geheugen op basis van een gerechtvaardigd belang wanneer het doel slechts is de weergegeven pagina te variëren. Permanente markeringstoewijzing die aan een stabiele identifier over sessies heen is gekoppeld, vereist dezelfde toestemming als analyse, omdat dat het moment is waarop de markering een traceerbaar gebruikersniveau gegevenspunt wordt.
• Enquêtes en feedback zijn gebonden aan dezelfde poort als sessieherhaling wanneer ze vrije-tekstinvoer verzamelen, of aan de analysepoort wanneer ze alleen beoordelingen of enkelvoudige-keuze-antwoorden verzamelen.

Het integratiepatroon dat werkt

De referentie-implementatie heeft vier onderdelen: een CMP die een realtime toestemmingswijzigingsgebeurtenis blootstelt, een uitgestelde bootstrap die PostHog initialiseert met uitgeschakeld vastleggen en herhaling, een toestemmingslistener die opt_in_capturing en de opnameschakelaar omkeert wanneer de relevante poorten opengaan, en een intrekkingspad dat opt_out_capturing aanroept, de herhalingsbuffer stopt en persistente identifiers verwijdert via de reset-API van de SDK.

Web-implementatie

Het schoonste patroon is om de PostHog SDK op elke pagina te laden maar posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) aan te roepen als de initiële bootstrap. Abonneer u op de toestemmingswijzigingsgebeurtenis van de CMP. Wanneer de analysecategorie overschakelt naar true, roept u posthog.set_config({ persistence: 'localStorage+cookie' }) aan gevolgd door posthog.opt_in_capturing(); dit schakelt het vastleggen van gebeurtenissen opnieuw in en de persistentieovergang begint de unieke identifier te schrijven. Wanneer de categorie sessieherhaling overschakelt naar true, roept u posthog.startSessionRecording() aan. Wanneer een van beide poorten wordt ingetrokken, roept u posthog.opt_out_capturing() aan voor de analysepoort of posthog.stopSessionRecording() voor de herhalingspoort, laat de relevante persistentievermeldingen verlopen via posthog.reset(), en dient u een verwijderingsverzoek in via de GDPR-API van PostHog als de gebruiker zijn recht op verwijdering heeft ingeroepen.

Regiokeuze: PostHog Cloud VS vs EU vs zelfgehost

PostHog exploiteert twee cloudregio's — VS (us.posthog.com) en EU (eu.posthog.com) — en ondersteunt zelfgehoste installaties op de eigen infrastructuur van de klant. Voor EER- en VK-verkeer is de EU-cloud de juiste standaard; het houdt opname, verwerking en opslag binnen de EER en vermindert de Schrems II-blootstelling die elke VS-regio-analytische implementatie met zich meebrengt. De api_host-init-optie fixeert de regio. Zelfgehoste PostHog verplaatst de volledige stack naar de eigen infrastructuur van de uitgever, wat de sterkste positie voor gegevensresidentie is, maar de toestemmingsverplichtingen niet opheft — de rechtsgrondslag volgt de gegevens, niet de operator. Welke optie ook wordt gekozen, moet worden weergegeven in de privacyverklaring en het verwerkingsregister van de verwerkingsverantwoordelijke.

Server-side vastleggen

PostHog ondersteunt server-side gebeurtenisopname via de Python-, Node-, Go-, Ruby- en PHP-SDK's. Server-side gebeurtenissen zijn niet vrijgesteld van toestemming — de rechtsgrondslag volgt de gegevens — maar server-side opname geeft de uitgever volledige controle over welke velden worden uitgestoten en wanneer. Een veelgebruikt patroon is om een minimale set van alleen essentiële gebeurtenissen server-side vast te leggen op basis van gerechtvaardigd belang, en die vervolgens pas te verrijken met gedragsdetails van de client nadat de gebruiker analysetoestemming heeft gegeven. De server-side en client-side gebeurtenissen worden samengevoegd op dezelfde unieke identifier wanneer de toestemming is omgezet; vóór de toestemming worden de server-side gebeurtenissen uitgestoten met een anonieme, vluchtige identifier die bij elke sessie wordt gereset.

De integratie en het auditspoor valideren

De validatiestap is wat toezichthouders controleren en wat uitgevers het vaakst overslaan. Een correct geïntegreerde PostHog-implementatie moet vier tests in volgorde doorstaan. Ten eerste moet een schone browsersessie met de banner getoond maar geen keuze gemaakt nul verzoeken aan de geconfigureerde api_host produceren buiten de SDK-bestandsophaling, nul ph_-cookies in document.cookie en nul ph_-vermeldingen in localStorage. Ten tweede moet het weigeren van analyse die toestand handhaven — geen vastlegging, geen opname, geen persistente identifier. Ten derde moet het accepteren van analyse onmiddellijk een $opt_in-gebeurtenis produceren, de verwachte persistentievermelding ph_{projectKey}_posthog met correcte SameSite-attributen en gebeurtenisverkeer dat naar de geconfigureerde host stroomt. Ten vierde moet het intrekken van toestemming na het feit onmiddellijk verdere vastlegging en herhaling stoppen, persistente identifiers laten verlopen en een verwijderingsverzoek activeren via de GDPR-API van PostHog als de gebruiker verwijdering heeft ingeroepen.

De verwachting voor het auditspoor onder de EDPB-richtlijnen voor cookiebanners van 2023 en de vernieuwde prioriteiten van de taskforce van 2026 is dat de uitgever voor elke gegeven gebeurtenis in het PostHog-project kan aantonen dat de gebruiker die hem genereerde op het moment van vastleggen geldige toestemming had gegeven. Het standaardpatroon is om de toestemmingsversie en tijdstempel in te stellen als persoonseigenschappen op de unieke ID via posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) zodat elke afzonderlijke gebeurtenis traceerbaar is naar een specifiek toestemmingslogboekitem. Een correct beveiligde implementatie, gecombineerd met regiokeuze die overeenkomt met het publiek, persistentie die standaard op geheugen staat en een verwijderingspad dat bij intrekking wordt geactiveerd, is wat PostHog transformeert van een regelgevend concentratierisico naar een verdedigbaar centrum van de productanalysestack.