Per què PostHog requereix consentiment — i per què la resposta no és la mateixa per a cada mòdul

El SDK web de PostHog no és una etiqueta de pàgina passiva. En una inicialització predeterminada, el SDK estableix una o més entrades de persistència — per defecte, un esquema combinat de galeta i localStorage amb clau sota ph_{projectKey}_posthog — genera un identificador distint estable, captura la visualització de pàgina inicial amb referidor, paràmetres UTM i identificadors de clic, i obre un canal d'esdeveniments de llarga durada cap a l'amfitrió d'ingesta configurat. Si la reproducció de sessions està habilitada a nivell de projecte, el SDK comença a transmetre contínuament un registre del DOM renderitzat, les coordenades del ratolí i els esdeveniments d'entrada. Si hi ha indicadors de funcionalitat configurats, el SDK els avalua contra l'identificador distint, conserva les decisions per a la sessió i emet un esdeveniment $feature_flag_called per a cada avaluació.

Cadascuna d'aquestes activitats correspon a una porta de consentiment diferent. Conservar un identificador distint és una operació d'emmagatzematge i accés en virtut de l'Article 5(3) de la Directiva ePrivacy i requereix un consentiment previ, lliure, específic, informat i inequívoc a l'EEE, al Regne Unit i a qualsevol jurisdicció que hagi adoptat el mateix estàndard. Capturar esdeveniments de comportament és un tractament de dades personals en virtut del GDPR perquè la combinació d'identificador, adreça IP i rastre de comportament és suficient per identificar un individu. La reproducció de sessions se situa en una categoria separada i més estricta en virtut de la guia de reproducció de sessions de l'EDPB: la reproducció captura el DOM renderitzat i qualsevol camp d'entrada no emmascarada, i requereix un consentiment explícit i granular diferent del consentiment genèric d'anàlisi. L'avaluació d'indicadors de funcionalitat és el subtil: una comprovació d'indicador que retorna un booleà no requereix en si mateixa consentiment, però conservar l'assignació d'indicadors de l'usuari a un identificador estable entre sessions sí ho requereix, perquè és així com l'experimentació basada en indicadors crea dades traçables a nivell d'usuari.

Què escriu PostHog abans del consentiment — i què s'ha de suprimir

El PostHog Browser SDK predeterminat escriu el següent en la inicialització: una entrada combinada de galeta i localStorage sota ph_{projectKey}_posthog que conté l'identificador distint, l'identificador de sessió i les decisions d'indicadors de funcionalitat, més, quan la reproducció de sessions està habilitada, un buffer de gravació addicional en memòria que es buida a l'endpoint d'ingesta cada pocs segons. El SDK també envia un esdeveniment $pageview immediat i, si la captura automàtica està activada, cada clic, interacció de formulari i clic de ràbia posteriors a la pàgina.

El patró recomanat és inicialitzar PostHog amb opt_out_capturing_by_default: true i disable_session_recording: true, i després canviar tots dos indicadors un cop el bàner de consentiment retorni un senyal positiu. Aquesta és la posició d'integració que la documentació de PostHog recomana ara, i és la postura que supera la revisió d'un regulador perquè inverteix el valor predeterminat: no es captura res fins que es registra el consentiment, i el SDK proporciona una transició neta en lloc d'una adaptació amb estat.

Les galetes, entrades de localStorage i identificadors que PostHog conserva

El Browser SDK 1.x escriu una entrada de persistència per projecte, amb clau sota ph_{projectKey}_posthog, amb una caducitat predeterminada de 365 dies. L'opció d'inicialització persistence controla el mecanisme subjacent: només cookie, només localStorage, localStorage+cookie (el predeterminat), sessionStorage o memory. Per a un desplegament que dóna prioritat al consentiment, la persistència de memory és el valor predeterminat correcte quan el consentiment encara no s'ha atorgat — garanteix que cap identificador sobrevisqui la sessió de la pàgina — amb una transició a localStorage+cookie un cop el consentiment canvia. El SDK també escriu un marcador d'inclusió o exclusió voluntària sota __ph_opt_in_out_{projectKey} per recordar l'elecció de l'usuari entre visites; aquest marcador en si és una galeta estrictament necessària perquè conserva una decisió de consentiment.

Assignació de mòduls de PostHog a marcs de consentiment

PostHog no implementa de forma nativa el IAB TCF ni la Plataforma de Privadesa Global IAB, i no està construït com a proveïdor de tecnologia publicitària. Tanmateix, s'integra amb Google Consent Mode v2 mitjançant ponts del costat del publicador, exposa una API nativa d'inclusió i exclusió voluntàries, i respecta la capçalera Do Not Track mitjançant l'opció d'inicialització respect_dnt. El patró que funciona en producció tracta cada mòdul de PostHog com una porta separada lligada a un senyal de CMP específic.

• Els esdeveniments d'anàlisi de producte s'associen al propòsit analític. En termes de TCF, normalment és el propòsit 8 (mesurar el rendiment del contingut) combinat amb el propòsit 1 (emmagatzemar i/o accedir a informació). Per a Consent Mode, això correspon a analytics_storage.
• La reproducció de sessions se situa darrere d'una porta més estricta. La reproducció de sessions de PostHog captura el DOM renderitzat i qualsevol camp d'entrada no emmascarada, per la qual cosa una inclusió voluntària de nivell de preferències o de recerca diferent de l'anàlisi és la postura defensable en virtut de la guia de l'EDPB.
• Els indicadors de funcionalitat i l'experimentació poden funcionar amb una avaluació efímera i en memòria sota una base d'interès legítim quan l'objectiu és únicament variar la pàgina renderitzada. L'assignació persistent d'indicadors vinculada a un identificador estable entre sessions requereix el mateix consentiment que l'anàlisi, perquè és llavors quan l'indicador es converteix en un punt de dades traçable a nivell d'usuari.
• Les enquestes i els comentaris s'associen a la mateixa porta que la reproducció de sessions quan recopilen text lliure, o a la porta d'anàlisi quan només recopilen valoracions o respostes d'opció única.

El patró d'integració que funciona

El desplegament de referència té quatre parts: un CMP que exposa un esdeveniment de canvi de consentiment en temps real, un bootstrap diferit que inicialitza PostHog amb la captura i la reproducció desactivades, un listener de consentiment que canvia opt_in_capturing i el commutador de gravació quan s'obren les portes pertinents, i un camí de retirada que crida a opt_out_capturing, atura el buffer de reproducció i neteja els identificadors persistents mitjançant l'API de restabliment del SDK.

Implementació web

El patró més net és carregar el SDK de PostHog a cada pàgina però cridar a posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) com a bootstrap inicial. Subscriviu-vos a l'esdeveniment de canvi de consentiment del CMP. Quan la categoria d'anàlisi fa la transició a true, crideu a posthog.set_config({ persistence: 'localStorage+cookie' }) seguit de posthog.opt_in_capturing(); això reactiva la captura d'esdeveniments i la transició de persistència comença a escriure l'identificador distint. Quan la categoria de reproducció de sessions fa la transició a true, crideu a posthog.startSessionRecording(). Quan qualsevol porta es retira, crideu a posthog.opt_out_capturing() per a la porta d'anàlisi o a posthog.stopSessionRecording() per a la porta de reproducció, feu caducar les entrades de persistència rellevants mitjançant posthog.reset(), i envieu una sol·licitud d'eliminació a través de l'API GDPR de PostHog si l'usuari ha invocat el dret de supressió.

Selecció de la regió: PostHog Cloud US vs EU vs allotjament propi

PostHog opera dues regions de núvol — US (us.posthog.com) i EU (eu.posthog.com) — i admet instal·lacions allotjades a la pròpia infraestructura del client. Per al trànsit de l'EEE i del Regne Unit, el núvol de la UE és el valor predeterminat correcte; manté la ingesta, el processament i l'emmagatzematge dins de l'EEE i redueix l'exposició de Schrems II que comporta qualsevol desplegament analític a la regió dels EUA. L'opció d'inicialització api_host fixa la regió. PostHog allotjat de forma pròpia trasllada tota la pila a la infraestructura pròpia del publicador, que és la postura de residència de dades més sòlida, però no elimina les obligacions de consentiment: la base jurídica segueix les dades, no l'operador. Qualsevol opció que s'esculli ha de reflectir-se a l'avís de privadesa i al registre de tractaments del responsable.

Captura del costat del servidor

PostHog admet la ingesta d'esdeveniments del costat del servidor mitjançant els SDK de Python, Node, Go, Ruby i PHP. Els esdeveniments del costat del servidor no estan exempts de consentiment — la base jurídica segueix les dades — però la ingesta del costat del servidor dóna al publicador un control total sobre quins camps s'emeten i quan. Un patró habitual és capturar un conjunt mínim d'esdeveniments estrictament necessaris del costat del servidor sota un interès legítim, i després enriquir aquests esdeveniments amb detalls de comportament del client únicament després que l'usuari hagi atorgat el consentiment d'anàlisi. Els esdeveniments del costat del servidor i del costat del client s'uneixen al mateix identificador distint quan el consentiment ha canviat; abans del consentiment, els esdeveniments del costat del servidor s'emeten amb un identificador anònim i efímer que es restableix a cada sessió.

Validació de la integració i registre de l'auditoria

El pas de validació és el que verifiquen els reguladors i el que els editors s'ometen amb més freqüència. Un desplegament de PostHog correctament integrat ha de superar quatre proves en seqüència. En primer lloc, una sessió de navegador neta amb el bàner mostrat però sense cap elecció feta ha de produir zero sol·licituds a l'api_host configurat més enllà de la recuperació del fitxer SDK, zero galetes ph_ a document.cookie i zero entrades ph_ a localStorage. En segon lloc, el rebuig de l'anàlisi ha de mantenir aquest estat: sense captura, sense gravació, sense identificador persistent. En tercer lloc, l'acceptació de l'anàlisi ha de produir un esdeveniment $opt_in immediat, l'entrada de persistència esperada ph_{projectKey}_posthog amb atributs SameSite correctes i trànsit d'esdeveniments que flueix cap a l'amfitrió configurat. En quart lloc, retirar el consentiment a posteriori ha d'aturar immediatament la captura i la reproducció ulteriors, fer caducar els identificadors persistents i activar una sol·licitud d'eliminació a través de l'API GDPR de PostHog si l'usuari ha invocat la supressió.

L'expectativa de registre d'auditoria en virtut de les directrius sobre bàners de galetes de l'EDPB del 2023 i de les prioritats renovades del grup de treball del 2026 és que el publicador pugui demostrar, per a qualsevol esdeveniment del projecte PostHog, que l'usuari que el va generar havia atorgat un consentiment vàlid en el moment de la captura. El patró estàndard és establir la versió del consentiment i la marca de temps com a propietats de persona a l'ID distint mitjançant posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) perquè qualsevol esdeveniment individual sigui traçable fins a una entrada específica del registre de consentiment. Un desplegament correctament controlat, combinat amb una selecció de regió que coincideixi amb l'audiència, una persistència predeterminada a memòria i un camí d'eliminació que s'activa en retirar-se, és el que transforma PostHog d'un risc de concentració regulatòria en un centre defensable de la pila d'anàlisi de producte.