Por qué PostHog requiere consentimiento — y por qué la respuesta no es la misma para cada módulo

El SDK web de PostHog no es una etiqueta de página pasiva. En una inicialización predeterminada, el SDK establece una o más entradas de persistencia — por defecto, un esquema combinado de cookie y localStorage con clave bajo ph_{projectKey}_posthog — genera un identificador distintivo estable, captura la vista de página inicial con referrer, parámetros UTM e identificadores de clic, y abre un canal de eventos de larga duración hacia el host de ingesta configurado. Si la reproducción de sesiones está habilitada a nivel de proyecto, el SDK comienza además a transmitir un registro continuo del DOM renderizado, las coordenadas del ratón y los eventos de entrada. Si hay indicadores de funcionalidades configurados, el SDK los evalúa contra el identificador distintivo, conserva las decisiones para la sesión y emite un evento $feature_flag_called para cada evaluación.

Cada una de estas actividades corresponde a una puerta de consentimiento diferente. Conservar un identificador distintivo es una operación de almacenamiento y acceso conforme al Article 5(3) de la Directiva ePrivacy y requiere un consentimiento previo, libre, específico, informado e inequívoco en el EEE, el Reino Unido y cualquier jurisdicción que haya adoptado el mismo estándar. Capturar eventos de comportamiento es un tratamiento de datos personales conforme al GDPR porque la combinación de identificador, dirección IP y rastro de comportamiento es suficiente para singularizar a un individuo. La reproducción de sesiones se encuentra en una categoría separada y más estricta conforme a la orientación del EDPB sobre reproducción de sesiones — la reproducción captura el DOM renderizado y cualquier campo de entrada no enmascarado y requiere un consentimiento explícito y granular distinto del consentimiento genérico de análisis. La evaluación de indicadores de funcionalidades es lo sutil: una comprobación de indicador que devuelve un valor booleano no requiere en sí misma consentimiento, pero conservar la asignación del indicador del usuario a un identificador estable entre sesiones sí lo requiere, porque así es como la experimentación basada en indicadores crea datos rastreables a nivel de usuario.

Qué escribe PostHog antes del consentimiento — y qué debe suprimirse

El PostHog Browser SDK predeterminado escribe lo siguiente en la inicialización: una entrada combinada de cookie y localStorage bajo ph_{projectKey}_posthog que contiene el identificador distintivo, el identificador de sesión y las decisiones de indicadores de funcionalidades, más, cuando la reproducción de sesiones está habilitada, un búfer de grabación adicional en memoria que se vacía al endpoint de ingesta cada pocos segundos. El SDK también envía un evento $pageview inmediato y, si la captura automática está activada, cada clic posterior, interacción con formulario y clic de rabia en la página.

El patrón recomendado es inicializar PostHog con opt_out_capturing_by_default: true y disable_session_recording: true, y luego cambiar ambos indicadores en cuanto el banner de consentimiento devuelva una señal positiva. Esta es la postura de integración que la documentación de PostHog recomienda ahora, y es la postura que supera la revisión de un regulador porque invierte el valor predeterminado: no se captura nada hasta que se registra el consentimiento, y el SDK proporciona una transición limpia en lugar de una adaptación con estado.

Las cookies, entradas de localStorage e identificadores que PostHog conserva

El Browser SDK 1.x escribe una entrada de persistencia por proyecto, con clave bajo ph_{projectKey}_posthog, con una caducidad predeterminada de 365 días. La opción de inicialización persistence controla el mecanismo subyacente: solo cookie, solo localStorage, localStorage+cookie (el predeterminado), sessionStorage o memory. Para un despliegue que prioriza el consentimiento, la persistencia de memory es el valor predeterminado correcto cuando el consentimiento aún no se ha otorgado — garantiza que ningún identificador sobreviva la sesión de la página — con una transición a localStorage+cookie en cuanto el consentimiento cambia. El SDK también escribe un marcador de inclusión o exclusión bajo __ph_opt_in_out_{projectKey} para recordar la elección del usuario entre visitas; ese marcador es en sí mismo una cookie estrictamente necesaria porque conserva una decisión de consentimiento.

Asignación de módulos de PostHog a marcos de consentimiento

PostHog no implementa de forma nativa el IAB TCF ni la Plataforma de Privacidad Global de IAB, y no está construido como proveedor de tecnología publicitaria. Sin embargo, se integra con Google Consent Mode v2 mediante puentes del lado del editor, expone una API nativa de inclusión y exclusión, y respeta la cabecera Do Not Track mediante la opción de inicialización respect_dnt. El patrón que funciona en producción trata cada módulo de PostHog como una puerta separada vinculada a una señal de CMP específica.

• Los eventos de análisis de producto se vinculan al propósito analítico. En términos TCF, esto es con mayor frecuencia el propósito 8 (medir el rendimiento del contenido) combinado con el propósito 1 (almacenar y/o acceder a información). Para Consent Mode, esto se corresponde con analytics_storage.
• La reproducción de sesiones se encuentra detrás de una puerta más estricta. La reproducción de sesiones de PostHog captura el DOM renderizado y cualquier campo de entrada no enmascarado, por lo que una inclusión voluntaria de nivel de preferencias o investigación distinta del análisis es la postura defendible conforme a la orientación del EDPB.
• Los indicadores de funcionalidades y la experimentación pueden funcionar con una evaluación efímera en memoria bajo una base de interés legítimo cuando el objetivo es únicamente variar la página renderizada. La asignación persistente de indicadores vinculada a un identificador estable entre sesiones requiere el mismo consentimiento que el análisis, porque entonces el indicador se convierte en un punto de datos rastreable a nivel de usuario.
• Las encuestas y los comentarios se vinculan a la misma puerta que la reproducción de sesiones cuando recopilan texto libre, o a la puerta de análisis cuando solo recopilan valoraciones o respuestas de opción única.

El patrón de integración que funciona

El despliegue de referencia tiene cuatro partes: un CMP que expone un evento de cambio de consentimiento en tiempo real, un bootstrap diferido que inicializa PostHog con la captura y la reproducción desactivadas, un listener de consentimiento que activa opt_in_capturing y el interruptor de grabación cuando se abren las puertas pertinentes, y una ruta de retirada que llama a opt_out_capturing, detiene el búfer de reproducción y limpia los identificadores persistentes mediante la API de restablecimiento del SDK.

Implementación web

El patrón más limpio es cargar el SDK de PostHog en cada página pero llamar 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 }) como bootstrap inicial. Suscríbase al evento de cambio de consentimiento del CMP. Cuando la categoría de análisis pase a true, llame a posthog.set_config({ persistence: 'localStorage+cookie' }) seguido de posthog.opt_in_capturing(); esto reactiva la captura de eventos y la transición de persistencia empieza a escribir el identificador distintivo. Cuando la categoría de reproducción de sesiones pase a true, llame a posthog.startSessionRecording(). Cuando se retire cualquier puerta, llame a posthog.opt_out_capturing() para la puerta de análisis o a posthog.stopSessionRecording() para la puerta de reproducción, haga caducar las entradas de persistencia pertinentes mediante posthog.reset() y envíe una solicitud de eliminación a través de la API GDPR de PostHog si el usuario ha invocado su derecho de supresión.

Selección de región: PostHog Cloud US vs EU vs autoalojado

PostHog opera en dos regiones de nube — US (us.posthog.com) y EU (eu.posthog.com) — y admite instalaciones autoalojadas en la propia infraestructura del cliente. Para el tráfico del EEE y del Reino Unido, la nube europea es el valor predeterminado correcto; mantiene la ingesta, el procesamiento y el almacenamiento dentro del EEE y reduce la exposición al Schrems II que conlleva cualquier despliegue analítico en la región de EE. UU. La opción de inicialización api_host fija la región. PostHog autoalojado traslada toda la pila a la propia infraestructura del editor, que es la postura más sólida de residencia de datos, pero no elimina las obligaciones de consentimiento — la base jurídica sigue a los datos, no al operador. La opción que se elija debe reflejarse en el aviso de privacidad y en el registro de actividades de tratamiento del responsable.

Captura del lado del servidor

PostHog admite la ingesta de eventos del lado del servidor a través de los SDK de Python, Node, Go, Ruby y PHP. Los eventos del lado del servidor no están exentos del consentimiento — la base jurídica sigue a los datos —, pero la ingesta del lado del servidor otorga al editor un control total sobre qué campos se emiten y cuándo. Un patrón habitual es capturar del lado del servidor un conjunto mínimo de eventos estrictamente necesarios bajo un interés legítimo y, a continuación, enriquecer esos eventos con detalles de comportamiento del cliente únicamente después de que el usuario haya otorgado el consentimiento de análisis. Los eventos del lado del servidor y del lado del cliente se unen al mismo identificador distintivo cuando el consentimiento ha cambiado; antes del consentimiento, los eventos del lado del servidor se emiten con un identificador anónimo y efímero que se restablece en cada sesión.

Validación de la integración y rastro de auditoría

El paso de validación es lo que comprueban los reguladores y lo que los editores más frecuentemente omiten. Un despliegue de PostHog correctamente integrado debe superar cuatro pruebas en secuencia. En primer lugar, una sesión de navegador limpia con el banner mostrado pero sin elección realizada debe producir cero solicitudes al api_host configurado más allá de la recuperación del archivo SDK, cero cookies ph_ en document.cookie y cero entradas ph_ en localStorage. En segundo lugar, rechazar el análisis debe mantener ese estado: sin captura, sin grabación, sin identificador persistente. En tercer lugar, aceptar el análisis debe producir un evento $opt_in inmediato, la entrada de persistencia esperada ph_{projectKey}_posthog con atributos SameSite correctos y tráfico de eventos fluyendo hacia el host configurado. En cuarto lugar, retirar el consentimiento posteriormente debe detener inmediatamente la captura y la reproducción adicionales, hacer caducar los identificadores persistentes y activar una solicitud de eliminación a través de la API GDPR de PostHog si el usuario ha invocado la supresión.

La expectativa del rastro de auditoría conforme a las directrices del EDPB sobre banners de cookies de 2023 y las renovadas prioridades del grupo de trabajo para 2026 es que el editor pueda demostrar, para cualquier evento del proyecto PostHog, que el usuario que lo generó había dado un consentimiento válido en el momento de la captura. El patrón estándar es establecer la versión del consentimiento y la marca de tiempo como propiedades de persona en el ID distintivo mediante posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) para que cualquier evento individual sea rastreable hasta una entrada específica del registro de consentimiento. Un despliegue correctamente controlado, combinado con una selección de región que coincida con la audiencia, una persistencia que usa memoria por defecto y una ruta de eliminación que se activa al retirar el consentimiento, es lo que convierte a PostHog de un riesgo de concentración regulatoria en un centro defendible de la pila de análisis de producto.