Por que PostHog require consentimento — e por que a resposta non é a mesma para cada módulo

O SDK web de PostHog non é un tag de páxina pasivo. Nunha inicialización por defecto, o SDK establece unha ou máis entradas de persistencia de terceiros propios — por defecto un esquema combinado de cookie máis localStorage indexado baixo ph_{projectKey}_posthog — xera un identificador distinto estable, captura a páxina vista inicial co referente, parámetros UTM e identificadores de clic, e abre un canal de eventos de longa duración cara ao host de inxestión configurado. Se a gravación de sesión está activada a nivel de proxecto, o SDK comeza ademais a transmitir un rexistro continuo do DOM renderizado, coordenadas do rato e eventos de entrada. Se as marcas de funcionalidade están configuradas, o SDK avalíaas fronte ao identificador distinto, persiste as decisións para a sesión e emite un evento $feature_flag_called por cada avaliación.

Cada unha destas actividades responde a unha porta de consentimento diferente. Persistir un identificador distinto é unha operación de almacenamento e acceso en virtude do artigo 5(3) da Directiva ePrivacy e require consentimento previo, libremente dado, específico, informado e sen ambigüidades en todo o EEE, no Reino Unido e en calquera xurisdición que implantase o mesmo estándar. A captura de eventos de comportamento é tratamento de datos persoais en virtude do GDPR, porque a combinación de identificador, enderezo IP e rastro de comportamento é suficiente para singularizar un individuo. A gravación de sesión sitúase nunha categoría separada e máis estrita en virtude das directrices de gravación de sesión do EDPB — o replay captura o DOM renderizado e calquera campo de entrada non enmascarado e require un consentimento explícito e granular distinto do consentimento xenérico de análise. A avaliación de marcas de funcionalidade é a máis sutil: unha verificación de marca que devolve un booleano non require en si consentimento, pero persistir a asignación de marca do usuario nun identificador estable entre sesións sí o require, porque así é como a experimentación baseada en marcas crea datos rastrexables ao nivel do usuario.

O que PostHog escribe antes do consentimento — e o que debe suprimirse

O SDK Browser de PostHog por defecto escribe o seguinte na inicialización: unha entrada de cookie combinada e de localStorage baixo ph_{projectKey}_posthog que contén o identificador distinto, o identificador de sesión e as decisións de marca de funcionalidade, máis, cando a gravación de sesión está activada, un búfer de gravación adicional en memoria que baleira cara ao punto final de inxestión cada poucos segundos. O SDK tamén envía un evento $pageview inmediato e, se a captura automática está activa, cada clic, interacción con formulario e rage-click posteriores na páxina.

O patrón recomendado é inicializar PostHog con opt_out_capturing_by_default: true e disable_session_recording: true, e logo cambiar ambas marcas en canto o banner de consentimento devolva un sinal positivo. Esta é a postura de integración que a documentación de PostHog recomenda agora, e é a postura que supera a revisión dun regulador porque inverte o comportamento por defecto: non se captura nada ata que se rexistra o consentimento, e o SDK ofrece unha transición limpa en lugar dunha adaptación con estado.

As cookies, entradas de localStorage e identificadores que PostHog persiste

O SDK Browser 1.x escribe unha entrada de persistencia por proxecto, indexada baixo ph_{projectKey}_posthog, cunha caducidade de 365 días por defecto. A opción de inicialización persistence controla o mecanismo subxacente: só cookie, só localStorage, localStorage+cookie (por defecto), sessionStorage ou memory. Para unha implantación de consentimento primeiro, a persistencia memory é o valor por defecto correcto cando aínda non se concedeu o consentimento — garante que ningún identificador sobreviva á sesión da páxina — cunha transición a localStorage+cookie unha vez que cambia o consentimento. O SDK tamén escribe un marcador de opt-in ou opt-out baixo __ph_opt_in_out_{projectKey} para recordar a elección do usuario entre visitas; ese marcador é el mesmo unha cookie estritamente necesaria porque persiste unha decisión de consentimento.

Mapeamento dos módulos de PostHog nos marcos de consentimento

PostHog non implementa de forma nativa o IAB TCF nin a Plataforma Global de Privacidade IAB, e non foi construído como un provedor de tecnoloxía publicitaria. Non obstante, intégrase con Google Consent Mode v2 mediante ponte do lado do editor, expón unha API nativa de opt-in e opt-out, e respecta a cabeceira Do Not Track mediante a opción de inicialización respect_dnt. O patrón que funciona en produción trata cada módulo de PostHog como unha porta separada ligada a un sinal CMP específico.

• Os eventos de análise de produtos están vinculados á finalidade de análise. En termos TCF, trátase con máis frecuencia da finalidade 8 (medir o rendemento do contido) combinada coa finalidade 1 (almacenar e/ou acceder á información). Para Consent Mode, isto corresponde a analytics_storage.
• A gravación de sesión sitúase detrás dunha porta máis estrita. A gravación de sesión de PostHog captura o DOM renderizado e calquera campo de entrada non enmascarado, polo que un opt-in de nivel de preferencias ou investigación distinto da análise é a postura defendible en virtude das directrices do EDPB.
• As marcas de funcionalidade e a experimentación poden executarse con avaliación efémera en memoria baixo a base de interese lexítimo cando o obxectivo é só variar a páxina renderizada. A asignación persistente de marca vinculada a un identificador estable entre sesións require o mesmo consentimento que a análise, porque é entón cando a marca se converte nun punto de datos rastrexable ao nivel do usuario.
• As enquisas e o feedback están vinculados á mesma porta que a gravación de sesión cando recollen texto libre, ou á porta de análise cando só recollen valoracións ou respostas de selección única.

O patrón de integración que funciona

A implantación de referencia ten catro partes: unha CMP que expón un evento de cambio de consentimento en tempo real, un bootstrap diferido que inicializa PostHog coa captura e a reprodución desactivadas, un escoitador de consentimento que cambia opt_in_capturing e o interruptor de gravación cando se abren as portas pertinentes, e un camiño de retirada que chama a opt_out_capturing, detén o búfer de reprodución e borra os identificadores persistentes mediante a API de reinicio do SDK.

Implementación web

O patrón máis limpo é cargar o SDK de PostHog en cada páxina pero chamar posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) como bootstrap inicial. Subscríbete ao evento de cambio de consentimento da CMP. Cando a categoría de análise pase a true, chama a posthog.set_config({ persistence: 'localStorage+cookie' }) seguido de posthog.opt_in_capturing(); isto reactiva a captura de eventos e a transición de persistencia comeza a escribir o identificador distinto. Cando a categoría de gravación de sesión pase a true, chama a posthog.startSessionRecording(). Cando calquera porta se retire, chama a posthog.opt_out_capturing() para a porta de análise ou posthog.stopSessionRecording() para a porta de reprodución, fai caducar as entradas de persistencia pertinentes mediante posthog.reset(), e envía unha solicitude de eliminación mediante a API GDPR de PostHog se o usuario invocou o seu dereito ao borrado.

Selección de rexión: PostHog Cloud EUA vs UE vs auto-aloxado

PostHog opera dúas rexións de nube — EUA (us.posthog.com) e UE (eu.posthog.com) — e admite instalacións auto-aloxadas na infraestrutura propia do cliente. Para o tráfico do EEE e do Reino Unido, a nube da UE é o valor por defecto correcto; mantén a inxestión, o procesamento e o almacenamento dentro do EEE e reduce a exposición a Schrems II que calquera implantación de análise na rexión dos EUA leva consigo. A opción de inicialización api_host fixa a rexión. PostHog auto-aloxado move toda a pila á infraestrutura propia do editor, que é a postura de residencia de datos máis sólida pero non elimina as obrigas de consentimento — a base xurídica segue aos datos, non ao operador. Calquera opción elixida debe quedar reflectida no aviso de privacidade e no rexistro de tratamentos do responsable do tratamento.

Captura no lado do servidor

PostHog admite a inxestión de eventos no lado do servidor mediante os SDK de Python, Node, Go, Ruby e PHP. Os eventos no lado do servidor non están exentos do consentimento — a base xurídica segue aos datos — pero a inxestión no lado do servidor dá ao editor un control total sobre os campos que se emiten e cando. Un patrón común é capturar un conxunto mínimo de eventos esenciais no lado do servidor baixo interese lexítimo e enriquecer despois eses eventos con detalles de comportamento do cliente só despois de que o usuario conceda o consentimento de análise. Os eventos no lado do servidor e do cliente únense no mesmo identificador distinto cando o consentimento cambiou; antes do consentimento, os eventos do lado do servidor emítense cun identificador anónimo e efémero que se restablece en cada sesión.

Validación da integración e a pista de auditoría

O paso de validación é o que os reguladores comprueban e o que os editores omiten con maior frecuencia. Unha implantación PostHog correctamente integrada debe superar catro probas en secuencia. Primeiro, unha sesión de navegador limpa co banner mostrado pero sen elección realizada debe producir cero solicitudes ao api_host configurado máis aló da obtención do ficheiro SDK, cero cookies ph_ en document.cookie e cero entradas ph_ en localStorage. Segundo, rexeitar a análise debe manter ese estado — ningunha captura, ningunha gravación, ningún identificador persistente. Terceiro, aceptar a análise debe producir un evento $opt_in inmediato, a entrada de persistencia ph_{projectKey}_posthog esperada con atributos SameSite correctos, e tráfico de eventos cara ao host configurado. Cuarto, retirar o consentimento despois dos feitos debe deter de inmediato calquera captura e reprodución ulterior, facer caducar os identificadores persistentes e desencadear unha solicitude de eliminación mediante a API GDPR de PostHog se o usuario invocou o borrado.

A expectativa de pista de auditoría en virtude das directrices de banners de cookies do EDPB de 2023 e das prioridades renovadas do grupo de traballo de 2026 é que o editor poida demostrar, para calquera evento dado no proxecto PostHog, que o usuario que o xerou dera un consentimento válido no momento da captura. O patrón estándar é establecer a versión do consentimento e o selo de tempo como propiedades de persoa no ID distinto mediante posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) para que calquera evento individual sexa rastrexable ata unha entrada específica do rexistro de consentimento. Unha implantación correctamente pechada, combinada cunha selección de rexión que coincida coa audiencia, cunha persistencia que por defecto sexa memoria e cun camiño de eliminación que se active na retirada, transforma PostHog dun risco de concentración regulatoria nun centro defendible da pila de análise de produtos.