Guia de Integração do Consentimento de Cookies para Análise de Produtos Heap Auto-Capture: Manual 2026 para Editores
O Heap é incomum no ecossistema de análise de produtos por causa do que faz por predefinição. Enquanto o Mixpanel, o Amplitude e o PostHog pedem ao editor para instrumentar os eventos relevantes, o Heap captura tudo automaticamente e permite que o analista defina eventos retroativamente a partir do fluxo capturado. Esse modelo de captura automática é a característica definidora do produto e a razão pela qual as equipas o escolhem; é também a razão pela qual uma implementação padrão do Heap tem uma das superfícies de dados comportamentais mais amplas de qualquer ferramenta que um editor provavelmente instale. Cada clique, toque, rolagem, interação com formulário, transição de página e clique de frustração é capturado contra um identificador persistente em milissegundos após o carregamento da página — o que significa que cada uma dessas operações gera uma obrigação de consentimento. A boa notícia é que o Heap, desde a sua aquisição pela Contentsquare, é fornecido com uma das APIs de consentimento mais granulares no espaço de análise de produtos; o trabalho está em ligá-la corretamente à superfície de captura automática, à camada de identidade e ao módulo de repetição de sessão que a integração Contentsquare adiciona.
Por que o Heap requer consentimento — e por que a resposta é mais ampla do que a análise típica
Uma inicialização padrão do Heap faz várias coisas no primeiro carregamento da página. Define um cookie de primeira parte sob _hp2_id.{envId} contendo o identificador persistente do utilizador, um cookie de sessão sob _hp2_ses_id.{envId} com o identificador de sessão, um cookie de taxa de amostragem sob _hp2_props.{envId}, e um marcador _hp2_loaded indicando que o SDK foi inicializado. Gera o identificador único se ainda não existir, captura a visualização de página inicial com referenciador, parâmetros UTM e identificadores de clique, e começa imediatamente a registar cada interação subsequente contra esse identificador — cliques, toques, alterações de formulário, alterações de rota, eventos personalizados e, quando a integração Contentsquare está ativada, a diferença completa do DOM renderizado para repetição de sessão.
Cada uma dessas atividades aciona uma porta de consentimento separada. A persistência do identificador do utilizador é uma operação de armazenamento e acesso ao abrigo do Artigo 5(3) da Diretiva ePrivacy e requer consentimento prévio, livremente prestado, específico, informado e inequívoco em todo o EEE, no Reino Unido e em qualquer jurisdição que tenha adotado o mesmo padrão. A captura do fluxo de eventos de captura automática é um tratamento de dados pessoais ao abrigo do RGPD porque a combinação de identificador, endereço IP e rasto comportamental é suficiente para individualizar uma pessoa. A repetição de sessão enquadra-se numa categoria separada e mais rigorosa ao abrigo das orientações do EDPB sobre repetição de sessão — a repetiçã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 CCPA e a CPRA tratam o mesmo tratamento como venda ou partilha, a menos que o editor tenha o contrato relevante de prestador de serviços com o Heap — que o Heap oferece, mas o contrato só entra em vigor quando a integração é configurada para o modo de prestador de serviços.
O que o Heap escreve antes do consentimento — e o que deve ser suprimido
O início rápido padrão fornecido com o painel do Heap instala o fragmento de rastreamento diretamente no <head> da página. Isso funciona conforme documentado e é a fonte da falha de conformidade mais comum nas implementações do Heap: o fragmento é executado antes de o banner de cookies ter sido renderizado, os cookies _hp2_ são escritos em milissegundos e o fluxo de captura automática começa a fluir para heapanalytics.com independentemente do que o utilizador decidir mais tarde. Cada regulador europeu que se pronunciou sobre este padrão decidiu da mesma forma: os cookies definidos antes do consentimento são ilegais, e o editor suporta a responsabilidade.
Uma integração conforme deve, portanto, impedir que o fragmento do Heap seja carregado até que a categoria de consentimento relevante tenha sido concedida. Os dois padrões que funcionam em produção são a injeção condicional de scripts — o fragmento é adicionado ao DOM apenas depois de o CMP sinalizar o consentimento — e o pré-carregamento do fragmento com heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) como um bootstrap diferido e depois chamar heap.startAutoCapture() assim que o consentimento for registado. O padrão de injeção condicional é mais limpo e é o que a documentação do Heap agora recomenda. O padrão de bootstrap diferido é a escolha certa quando o editor precisa de uma referência global estável para a junção de identidades, mas não pode permitir que a captura automática seja ativada antes do consentimento.
Os cookies e armazenamento que o Heap escreve
O fragmento do Heap escreve os seguintes identificadores na inicialização, todos os quais são não essenciais e requerem consentimento: _hp2_id.{envId} com uma validade de 14 meses contendo o identificador do utilizador, _hp2_ses_id.{envId} com uma validade de sessão de 30 minutos, _hp2_props.{envId} para taxa de amostragem e propagação de propriedades, e _hp2_loaded como o marcador de carregamento. O módulo de repetição de sessão integrado com Contentsquare adiciona um buffer de gravação na memória que descarrega para o endpoint do Heap a cada poucos segundos e pode preservar separadamente um pequeno identificador de sessão de repetição. A retirada do consentimento deve, portanto, tanto expirar os cookies _hp2_ como sinalizar um pedido de eliminação através da API RGPD do Heap para as gravações anteriores do utilizador e o fluxo de eventos.
Mapeamento do Heap para estruturas de consentimento
O Heap não implementa nativamente o IAB TCF ou a Plataforma Global de Privacidade IAB — é uma plataforma de análise de produtos de primeira parte, não um fornecedor de tecnologia publicitária — mas integra-se com o Google Consent Mode v2 através de uma ponte do lado do editor, expõe uma API nativa de opt-in e opt-out, e suporta uma camada de redação de propriedades sensíveis que opera independentemente do estado de consentimento. O padrão que resiste à revisão de um regulador trata cada módulo do Heap como uma porta separada vinculada a um sinal CMP específico.
- Captura automática e fluxo de eventos principal estão vinculados ao objetivo de análise. Em termos de TCF, este é mais frequentemente o objetivo 8 (medir o desempenho do conteúdo) combinado com o objetivo 1 (armazenar e/ou aceder a informações). Para o Consent Mode, este mapeia para analytics_storage.
- Repetição de sessão através da integração Contentsquare fica atrás de uma porta mais rigorosa e separada porque a repetição captura o DOM renderizado e quaisquer campos de entrada não mascarados, e as orientações do EDPB sobre repetição de sessão tratam-na como uma categoria que requer consentimento explícito e granular distinto da análise genérica.
- Identificação do utilizador através de heap.identify() pode ser executada com um identificador de sessão efémero com base em interesses legítimos quando o utilizador é anónimo, mas a junção da identificação a um identificador persistente de primeira parte entre sessões requer o mesmo consentimento que a análise porque é então que o identificador se torna um ponto de dados rastreável ao nível do utilizador.
- Propagação de identidade entre sites ou entre produtos através da API de identidade requer a porta de marketing porque cruza a linha da análise de produtos para a atribuição de marketing ao nível do utilizador.
O padrão de integração que funciona
A implementaçã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 carrega o Heap com captura automática desativada, um ouvinte de consentimento que ativa a captura automática e inicia o buffer de repetição de sessão quando as portas relevantes abrem, e um caminho de retirada que chama heap.resetIdentity(), para a captura automática, expira os cookies _hp2_ e envia um pedido de eliminação através do endpoint RGPD do Heap.
Implementação web
Na web, o padrão mais limpo é carregar o fragmento do Heap condicionalmente — a etiqueta <script> é injetada apenas depois de a categoria de análise ter sido concedida. Subscreva o evento de mudança de consentimento do CMP. Quando a categoria de análise transitar para true, injete o fragmento do Heap com secureCookie: true, disableTextCapture: false para captura automática completa e qualquer configuração específica do ambiente. Quando o consentimento de repetição de sessão transitar para true e a integração Contentsquare estiver ativada, o buffer de repetição ativa-se automaticamente. Quando qualquer porta for retirada, chame heap.resetIdentity() seguido da remoção do elemento de script do Heap, expire os cookies _hp2_ via document.cookie e invoque a API de eliminação RGPD para o identificador do utilizador.
Redação de propriedades sensíveis
O Heap é fornecido com uma camada de redação que opera independentemente do estado de consentimento e que os editores devem usar mesmo quando o consentimento foi concedido. O atributo data-heap-redact-text num campo de formulário suprime o conteúdo de texto capturado; o atributo data-heap-redact-attributes suprime os atributos do elemento. Ao abrigo das regras de categorias especiais do RGPD e da definição de informações pessoais sensíveis da CCPA, qualquer campo que possa capturar informações de saúde, detalhes financeiros, identificadores governamentais, dados biométricos, geolocalização precisa ou conteúdo de comunicações privadas deve usar os atributos de redação independentemente do estado de consentimento do utilizador. Definir os atributos ao nível do formulário é o padrão mais seguro — suprime todo o formulário mesmo quando um programador adiciona um novo campo que se esquece de marcar individualmente.
Seleção de região: residência de dados na UE versus EUA
O Heap opera endpoints de ingestão separados para a UE e EUA. Para o tráfego do EEE e do Reino Unido, o endpoint da UE é o predefinido correto; mantém a ingestão, o processamento e o armazenamento dentro do EEE e reduz a exposição ao Schrems II que qualquer implementação de análise na região dos EUA acarreta. O endpoint é definido através da configuração do fragmento e não pode ser alterado retroativamente — os dados existentes permanecem onde foram inicialmente ingeridos. Para os editores que planeiam um lançamento do Heap, vale, portanto, a pena confirmar a região antes da escalonamento e documentar a escolha na notificação de privacidade para que a cadeia de fundamento jurídico seja clara desde a recolha até ao armazenamento.
Validação da integração e a trilha de auditoria
A etapa de validação é o que os reguladores verificam e o que os editores mais frequentemente ignoram. Uma implementação do Heap corretamente integrada deve passar em quatro testes em sequência. Primeiro, uma sessão de browser limpa com o banner exibido mas sem escolha feita deve produzir zero pedidos a heapanalytics.com além da obtenção do ficheiro SDK e zero cookies _hp2_ em document.cookie. Segundo, recusar a análise deve manter esse estado — sem captura automática, sem identificador, sem gravação. Terceiro, aceitar a análise deve produzir o cookie _hp2_id esperado com atributos SameSite corretos e tráfego de eventos a fluir para o endpoint da região configurada. Quarto, retirar o consentimento deve imediatamente parar a captura automática e repetição adicionais, expirar os cookies _hp2_ e acionar um pedido de eliminação através da API RGPD do Heap.
A expectativa de trilha de auditoria ao abrigo das orientações do EDPB de 2023 sobre banners de cookies e das prioridades renovadas do grupo de trabalho de 2026 é que o editor possa provar, para qualquer evento dado no projeto Heap, que o utilizador que o gerou tinha dado consentimento válido no momento da captura. O padrão standard é definir a versão do consentimento e o carimbo de data/hora como propriedades do utilizador no ID único através de heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }) para que qualquer evento individual seja rastreável de volta a uma entrada específica do registo de consentimento. Uma implementação corretamente bloqueada, conjugada com atributos de redação que suprimem campos sensíveis por predefinição e um caminho de eliminação que se ativa na retirada, é o que transforma o modelo de captura automática do Heap de um risco de concentração regulatória numa das partes mais poderosas e defensáveis da pilha de análise de produtos de um editor.