Guia de Integração de Consentimento de Cookie para Experiência Digital e Repetição de Sessão do FullStory: Manual 2026
O FullStory é a plataforma dominante na categoria de análise de experiência digital por um motivo: captura tudo por padrão. Onde as ferramentas de análise tradicionais registram eventos discretos que o desenvolvedor instrumentou, e onde as plataformas de análise de produto registram interações mais um suplemento capturado automaticamente, o FullStory captura o DOM completamente renderizado, o rastro do cursor, o tempo das teclas pressionadas, o comportamento de rolagem, os cliques de raiva, os cliques mortos, as solicitações de rede e os erros de JavaScript — e os une em gravações de sessão que o analista pode examinar quadro a quadro. Essa cobertura é o produto. É também por isso que o FullStory está na interseção das regras de consentimento mais rigorosas em todos os regimes de privacidade modernos. A orientação de repetição de sessão do EDPB de 2023 e as prioridades do grupo de trabalho de 2026 tratam a repetição de sessão como uma categoria de consentimento distinta e mais rígida. A CNIL foi o regulador mais público sobre o assunto, mas não está sozinha — o Garante, o ICO, a AEPD espanhola e o AP holandês expressaram posições alinhadas. Uma implantação do FullStory configurada para captura com consentimento em primeiro lugar, com o mascaramento correto, a configuração de portais correta e o rastro de auditoria correto, é uma das ferramentas mais poderosas que um editor pode usar; uma que não esteja assim configurada é um dos alvos mais fáceis que um regulador encontrará.
Por que o FullStory está na categoria de consentimento mais rígida
Uma inicialização padrão do FullStory faz o que toda ferramenta de repetição de sessão faz, mais. Ele define cookies de primeira parte sob o namespace fs_uid e fs_lua contendo o identificador de visitante persistente e o carimbo de data e hora da última atividade, gera um identificador de sessão sob fs_session e começa a transmitir o DOM renderizado para rs.fullstory.com em milissegundos após o carregamento da página. O stream inclui cada evento de entrada, cada movimento do mouse, cada posição de rolagem, cada transição de página e — quando o módulo de captura de rede está habilitado — cada resposta XHR e fetch que a página emite, com corpos de resposta incluídos a menos que o operador tenha configurado supressão.
Cada uma dessas capturas ativa um portal de consentimento separado. Persistir o identificador do visitante é uma operação de armazenamento e acesso nos termos do Artigo 5(3) da Diretiva ePrivacy que requer consentimento prévio, livre, específico, informado e inequívoco em todo o EEE, no Reino Unido e em qualquer jurisdição que tenha importado o mesmo padrão. Gravar o DOM renderizado é processamento de dados pessoais nos termos do GDPR porque o registro visual é suficiente para identificar e revelar conteúdo substantivo sobre o usuário. Capturar o fluxo de teclas pressionadas é uma sensibilidade particular: tudo o que o usuário digita em um campo de formulário é capturado quadro a quadro, e se o campo não estiver mascarado a gravação inclui o conteúdo digitado. O EDPB foi explícito ao afirmar que a captura de repetição de sessão é uma categoria que requer consentimento explícito e granular distinto do consentimento genérico de análise.
O que o FullStory escreve antes do consentimento — e o que deve ser suprimido
O início rápido padrão do FullStory instala o snippet de rastreamento diretamente no <head> da página. Isso funciona como documentado e é a fonte das falhas de conformidade mais comuns: o snippet é executado antes que o banner de cookies seja renderizado, os cookies fs_uid e fs_session são escritos em milissegundos e o stream de repetição de sessão começa a fluir para rs.fullstory.com independentemente do que o usuário decidir depois. Todo regulador europeu que se pronunciou sobre esse padrão decidiu da mesma forma: cookies definidos antes do consentimento são ilegais, a gravação capturada antes do consentimento é processamento ilegal e o editor arca com a responsabilidade.
Uma integração em conformidade deve, portanto, impedir que o snippet do FullStory seja inicializado até que a categoria de consentimento relevante tenha sido concedida. O padrão que funciona em produção é a API FS.consent() combinada com gravação adiada: o snippet é carregado com FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) e FS.shutdown() chamado imediatamente, depois FS.restart() e FS.consent(true) são chamados apenas depois que o CMP sinaliza que a categoria de repetição de sessão foi concedida.
Os cookies e o armazenamento que o FullStory escreve
O snippet do FullStory escreve os seguintes identificadores na inicialização, todos não essenciais e que requerem consentimento: fs_uid com expiração de vários anos contendo o identificador de visitante persistente; fs_lua com o carimbo de data e hora da última atividade do usuário; fs_session com o identificador de sessão; e os marcadores de estado de gravação que o FullStory usa internamente. Revogar o consentimento deve tanto expirar esses cookies quanto chamar FS.consent(false) seguido de FS.shutdown() para parar captura adicional, e o editor deve enviar uma solicitação de exclusão pelo endpoint de privacidade do FullStory para as gravações anteriores do usuário.
Mapeando o FullStory para frameworks de consentimento
O FullStory não implementa nativamente o IAB TCF ou a IAB Global Privacy Platform — é uma plataforma de experiência digital de primeira parte, não um fornecedor de tecnologia publicitária. Ele expõe uma API de consentimento nativa e suporta um modelo de mascaramento privado por padrão que opera independentemente do estado de consentimento. O padrão que sobrevive à revisão de um regulador trata cada módulo do FullStory como um portal separado vinculado a um sinal CMP específico.
- A repetição de sessão e o stream completo do DOM estão vinculados a uma categoria dedicada de repetição de sessão ou pesquisa distinta da análise genérica. A orientação do EDPB é explícita neste ponto — o consentimento de repetição deve ser separado e granular, não agrupado com análise ou marketing.
- A captura de rede fica por trás de um sub-portal mais rígido na mesma categoria porque captura corpos de resposta HTTP que podem conter dados pessoais não relacionados à interface visível.
- A costura de identidade via FS.identify() pode ser executada com um identificador de sessão efêmero com base em interesse legítimo quando o usuário é anônimo, mas costurar a identificação a um identificador persistente de primeira parte entre sessões requer o mesmo consentimento que a repetição de sessão.
- Mapas de calor e análise de conversão derivados do stream de repetição de sessão herdam o portal do stream upstream — não são superfícies de consentimento separadas, são produtos downstream dos mesmos dados capturados.
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 adiado que inicializa o FullStory com captura suprimida via FS.shutdown(), um ouvinte de consentimento que chama FS.consent(true) e FS.restart() quando o portal de repetição de sessão abre, e uma configuração de mascaramento privado por padrão que suprime rigidamente cada campo de entrada a menos que explicitamente optado.
Mascaramento privado por padrão
A camada de mascaramento do FullStory opera independentemente do consentimento e deve ser configurada agressivamente mesmo quando o consentimento foi concedido. A classe CSS fs-mask em qualquer elemento suprime o conteúdo desse elemento da gravação; a classe CSS fs-exclude exclui o elemento completamente do stream do DOM; a classe fs-block bloqueia tanto o conteúdo quanto a estrutura. Sob as regras de categoria especial do GDPR e a definição de informações pessoais sensíveis do 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 atributos de mascaramento independentemente do estado de consentimento do usuário. A postura recomendada é aplicar fs-mask no nível do formulário em vez do nível do campo.
Seleção de região e residência de dados
O FullStory opera endpoints de ingestão separados para os EUA e a UE. Para o tráfego do EEE e do Reino Unido, o endpoint da UE é o padrão correto — mantém ingestão, processamento e armazenamento dentro do EEE e reduz a exposição ao Schrems II que qualquer implantação de repetição de sessão na região dos EUA carregaria. O endpoint é configurado por organização do FullStory e não pode ser alterado retroativamente, portanto a escolha da região deve ser feita antes do dimensionamento e documentada no aviso de privacidade para que a cadeia de base legal de coleta ao armazenamento esteja limpa.
Validando a integração e o rastro de auditoria
A etapa de validação é o que os reguladores verificam e o que os editores mais frequentemente ignoram nas ferramentas de repetição de sessão. Uma implantação do FullStory corretamente integrada deve passar por quatro testes em sequência. Primeiro, uma sessão limpa do navegador com o banner exibido mas sem escolha feita deve produzir zero solicitações para rs.fullstory.com além da busca do arquivo SDK e zero cookies fs_ em document.cookie. Segundo, recusar o consentimento de repetição de sessão deve manter esse estado — sem captura, sem identificador, sem gravação. Terceiro, aceitar o consentimento de repetição de sessão deve produzir o cookie esperado fs_uid, um único evento FS.consent(true) e o stream do DOM fluindo para o endpoint da região configurada, com campos mascarados confirmados para capturar apenas o marcador de posição da máscara. Quarto, revogar o consentimento deve interromper imediatamente qualquer captura adicional, expirar os cookies fs_ e acionar uma solicitação de exclusão pelo endpoint de privacidade do FullStory para as gravações anteriores do usuário.
A expectativa do rastro de auditoria é onde as ferramentas de repetição de sessão enfrentam o escrutínio mais rígido. As diretrizes de banner de cookies do EDPB de 2023 e as prioridades renovadas do grupo de trabalho de 2026 são explícitas ao afirmar que o editor deve ser capaz de provar, para qualquer gravação de sessão específica no projeto do FullStory, que o usuário que a gerou havia dado consentimento válido de repetição de sessão no momento da captura. O padrão é definir a versão do consentimento e o carimbo de data e hora como variáveis do usuário no identificador do FullStory via FS.setUserVars({ consent_version: 'v3', consent_ts: ts }) para que qualquer gravação individual seja rastreável de volta a uma entrada específica do log de consentimento. Uma implantação corretamente configurada com portais, combinada com atributos de mascaramento que por padrão são privados e um caminho de exclusão que se ativa na revogação, é o que transforma a cobertura do FullStory de um risco de concentração regulatória em uma parte defensável da pilha de experiência digital de um editor.