Por que o PostHog requer consentimento — e por que a resposta não é a mesma para cada módulo

O SDK web do PostHog não é uma tag de página passiva. Em uma inicialização padrão, o SDK define uma ou mais entradas de persistência de primeira parte — por padrão, um esquema combinado de cookie e localStorage com chave ph_{projectKey}_posthog — gera um identificador distinto estável, captura o pageview inicial com referenciador, parâmetros UTM e identificadores de cliques, e abre um canal de eventos de longa duração para o host de ingestão configurado. Se a reprodução de sessão estiver habilitada no nível do projeto, o SDK também começa a transmitir um registro contínuo do DOM renderizado, coordenadas do mouse e eventos de entrada. Se os flags de funcionalidades estiverem configurados, o SDK os avalia em relação ao identificador distinto, persiste as decisões para a sessão e emite um evento $feature_flag_called para cada avaliação.

Cada uma dessas atividades corresponde a um portão de consentimento diferente. Persistir um identificador distinto é uma operação de armazenamento e acesso sob o Article 5(3) da Diretiva ePrivacy e requer consentimento prévio, livremente dado, específico, informado e inequívoco em todo o EEE, Reino Unido e qualquer jurisdição que tenha adotado o mesmo padrão. Capturar eventos comportamentais é o processamento de dados pessoais sob o GDPR porque a combinação de identificador, endereço IP e rastro comportamental é suficiente para identificar um indivíduo. A reprodução de sessão está em uma categoria separada e mais estrita sob as diretrizes de reprodução de sessão do EDPB — a reprodução captura o DOM renderizado e quaisquer campos de entrada não mascarados e requer consentimento explícito e granular que seja distinto do consentimento genérico de análise. A avaliação de flags de funcionalidades é a sutil: uma verificação de flag que retorna um booleano não requer consentimento por si só, mas persistir a atribuição de flag do usuário a um identificador estável entre sessões sim, porque é assim que a experimentação baseada em flags cria dados rastreáveis no nível do usuário.

O que o PostHog registra antes do consentimento — e o que deve ser suprimido

O Browser SDK padrão do PostHog registra o seguinte na inicialização: uma entrada combinada de cookie e localStorage sob ph_{projectKey}_posthog contendo o identificador distinto, o identificador de sessão e as decisões de flags de funcionalidades, além de — quando a reprodução de sessão está habilitada — um buffer de gravação adicional na memória que é descarregado para o endpoint de ingestão a cada poucos segundos. O SDK também envia um evento $pageview imediato e, se a captura automática estiver ativada, cada clique subsequente, interação com formulário e clique de raiva na página.

O padrão recomendado é inicializar o PostHog com opt_out_capturing_by_default: true e disable_session_recording: true, depois inverter ambos os flags assim que o banner de consentimento retornar um sinal positivo. Esta é a postura de integração que a documentação do PostHog agora recomenda, e é a postura que sobrevive a uma revisão regulatória porque inverte o padrão: nada é capturado até que o consentimento seja registrado, e o SDK fornece uma transição limpa em vez de uma modernização baseada em estado.

Os cookies, entradas de localStorage e identificadores que o PostHog persiste

O Browser SDK 1.x registra uma entrada de persistência por projeto, com chave ph_{projectKey}_posthog, com validade padrão de 365 dias. A opção de inicialização persistence controla o mecanismo subjacente: apenas cookie, apenas localStorage, localStorage+cookie (o padrão), sessionStorage ou memory. Para uma implantação com consentimento em primeiro lugar, a persistência memory é o padrão correto quando o consentimento ainda não foi concedido — garante que nenhum identificador sobreviva à sessão da página — com transição para localStorage+cookie assim que o consentimento for concedido. O SDK também registra um marcador de opt-in ou opt-out sob __ph_opt_in_out_{projectKey} para lembrar a escolha do usuário entre visitas; esse marcador em si é um cookie estritamente necessário porque persiste uma decisão de consentimento.

Mapeando os módulos do PostHog para frameworks de consentimento

O PostHog não implementa nativamente o IAB TCF ou o IAB Global Privacy Platform, e não foi construído como um fornecedor de ad-tech. No entanto, integra-se com o Google Consent Mode v2 por meio de bridging no lado do editor, expõe uma API nativa de opt-in e opt-out, e respeita o cabeçalho Do Not Track por meio da opção de inicialização respect_dnt. O padrão que funciona em produção trata cada módulo do PostHog como um portão separado vinculado a um sinal de CMP específico.

• Eventos de análise de produto estão vinculados ao propósito de análise. Em termos de TCF, isso é mais comumente o propósito 8 (medir o desempenho do conteúdo) combinado com o propósito 1 (armazenar e/ou acessar informações). Para o Consent Mode, isso corresponde a analytics_storage.
• Reprodução de sessão fica atrás de um portão mais estrito. A reprodução de sessão do PostHog captura o DOM renderizado e quaisquer campos de entrada não mascarados, portanto, um opt-in de nível de preferências ou pesquisa distinto da análise é a postura defensável sob as diretrizes do EDPB.
• Flags de funcionalidades e experimentação podem ser executados com avaliação efêmera na memória sob uma base de interesse legítimo quando o objetivo é apenas variar a página renderizada. A atribuição de flag persistente vinculada a um identificador estável entre sessões requer o mesmo consentimento que a análise, porque é quando o flag se torna um ponto de dados rastreável no nível do usuário.
• Pesquisas e feedback estão vinculados ao mesmo portão que a reprodução de sessão quando coletam entrada de texto livre, ou ao portão de análise quando coletam apenas avaliações ou respostas de escolha única.

O padrão de integração que funciona

A implantação de referência tem quatro partes: um CMP que expõe um evento de mudança de consentimento em tempo real, um bootstrap diferido que inicializa o PostHog com captura e reprodução desabilitadas, um listener de consentimento que inverte opt_in_capturing e o switch de gravação quando os portões relevantes abrem, e um caminho de retirada que chama opt_out_capturing, para o buffer de reprodução e limpa identificadores persistentes por meio da API de reset do SDK.

Implementação web

O padrão mais limpo é carregar o SDK do PostHog em cada página, mas 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. Assine o evento de mudança de consentimento do CMP. Quando a categoria de análise transitar para true, chame posthog.set_config({ persistence: 'localStorage+cookie' }) seguido de posthog.opt_in_capturing(); isso reativa a captura de eventos e a transição de persistência começa a registrar o identificador distinto. Quando a categoria de reprodução de sessão transitar para true, chame posthog.startSessionRecording(). Quando qualquer portão for retirado, chame posthog.opt_out_capturing() para o portão de análise ou posthog.stopSessionRecording() para o portão de reprodução, expire as entradas de persistência relevantes via posthog.reset(), e envie uma solicitação de exclusão por meio da API GDPR do PostHog se o usuário tiver invocado seu direito de exclusão.

Seleção de região: PostHog Cloud EUA vs UE vs auto-hospedado

O PostHog opera duas regiões de nuvem — EUA (us.posthog.com) e UE (eu.posthog.com) — e suporta instalações auto-hospedadas na própria infraestrutura do cliente. Para o tráfego do EEE e do Reino Unido, a nuvem da UE é o padrão correto; mantém a ingestão, o processamento e o armazenamento dentro do EEE e reduz a exposição ao Schrems II que qualquer implantação de análise na região dos EUA carrega. A opção de inicialização api_host fixa a região. O PostHog auto-hospedado move toda a stack para a própria infraestrutura do editor, que é a postura de residência de dados mais forte, mas não remove as obrigações de consentimento — a base legal segue os dados, não o operador. Qualquer opção escolhida deve ser refletida no aviso de privacidade e no registro de atividades de processamento do controlador.

Captura no lado do servidor

O PostHog suporta ingestão de eventos no lado do servidor por meio dos SDKs Python, Node, Go, Ruby e PHP. Eventos no lado do servidor não estão isentos de consentimento — a base legal segue os dados — mas a ingestão no lado do servidor dá ao editor controle total sobre quais campos são emitidos e quando. Um padrão comum é capturar um conjunto mínimo de eventos essenciais apenas no lado do servidor sob interesse legítimo, e depois enriquecer esses eventos com detalhes comportamentais do cliente somente após o usuário ter concedido consentimento de análise. Os eventos no lado do servidor e no lado do cliente se juntam no mesmo identificador distinto quando o consentimento foi concedido; antes do consentimento, os eventos no lado do servidor são emitidos com um identificador anônimo e efêmero que é redefinido em cada sessão.

Validando a integração e a trilha de auditoria

O passo de validação é o que os reguladores verificam e o que os editores mais frequentemente ignoram. Uma implantação do PostHog corretamente integrada deve passar por quatro testes em sequência. Primeiro, uma sessão limpa do navegador com o banner exibido, mas sem nenhuma escolha feita, deve produzir zero requisições ao api_host configurado além do download do arquivo SDK, zero cookies ph_ em document.cookie e zero entradas ph_ em localStorage. Segundo, recusar a análise deve manter esse estado — sem captura, sem gravação, sem identificador persistente. Terceiro, aceitar a análise deve produzir um evento $opt_in imediato, a entrada de persistência esperada ph_{projectKey}_posthog com os atributos SameSite corretos, e o tráfego de eventos fluindo para o host configurado. Quarto, retirar o consentimento após o fato deve interromper imediatamente a captura e reprodução adicionais, expirar identificadores persistentes e acionar uma solicitação de exclusão por meio da API GDPR do PostHog se o usuário tiver invocado a exclusão.

A expectativa de trilha de auditoria sob as diretrizes de banner de cookies do EDPB de 2023 e as prioridades renovadas do grupo de trabalho de 2026 é que o editor possa provar, para qualquer evento em particular no projeto PostHog, que o usuário que o gerou havia dado consentimento válido no momento da captura. O padrão é definir a versão do consentimento e o timestamp como propriedades da pessoa no ID distinto via posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) para que qualquer evento individual seja rastreável de volta a uma entrada específica do log de consentimento. Uma implantação corretamente protegida, combinada com seleção de região compatível com o público, persistência que padroniza para memória e um caminho de exclusão que se ativa na retirada, é o que transforma o PostHog de um risco regulatório concentrado em um centro defensável da stack de análise de produtos.