Duas tarefas diferentes

Quando um visitante faz uma escolha de consentimento, duas coisas distintas precisam acontecer. Primeiro, o navegador precisa lembrar a escolha para que o banner não reapareça a cada página e as tags saibam o que podem fazer. Segundo, você pode precisar comprovar depois que a escolha foi feita, o que foi mostrado ao visitante e quando. Essas tarefas costumam ser resolvidas por mecanismos de armazenamento diferentes, e confundi-las causa problemas reais: banners que continuam reaparecendo, escolhas que somem em alguns navegadores ou nenhum registro para apresentar quando alguém pede.

Esta comparação examina as três opções comuns — cookies first-party, armazenamento do navegador como o localStorage e registros de consentimento do lado do servidor — e onde cada uma se encaixa.

Opção 1: cookies first-party

Os cookies são o lar tradicional do estado de consentimento. Os CMPs TCF normalmente armazenam a string de consentimento em um cookie first-party, e muitos CMPs armazenam nele também seus próprios dados de preferências.

Pontos fortes

• Legível pelo servidor. O cookie é enviado com cada requisição, então o código do servidor, a lógica de borda e o tagging do lado do servidor podem ler a escolha sem esperar pelo JavaScript.
• Compartilhável entre subdomínios. Um cookie definido no seu domínio registrável pode cobrir os subdomínios www, blog e shop.
• Amplamente esperado. Muitas integrações de ad tech procuram o consentimento em cookies.

Pontos fracos

• Limites de tamanho. Os navegadores limitam o tamanho do cookie a cerca de 4 KB, e uma string TCF com muitos vendors mais outros valores pode se aproximar desse limite.
• Sobrecarga nas requisições. Toda requisição ao seu domínio carrega o cookie, inclusive as de imagens e scripts.
• Limites de duração em alguns navegadores. A Intelligent Tracking Prevention do Safari limita a um máximo de sete dias a duração dos cookies criados por JavaScript. Cookies definidos pelo seu próprio servidor em uma resposta HTTP geralmente recebem um tratamento mais generoso, embora haja exceções.

Opção 2: localStorage e outros armazenamentos do navegador

Alguns CMPs armazenam preferências detalhadas no localStorage, às vezes junto com um cookie menor.

Pontos fortes

• Mais espaço. Vários megabytes por origem, suficientes para escolhas detalhadas no nível de vendor.
• Sem sobrecarga nas requisições. Nada é enviado automaticamente ao servidor.

Pontos fracos

• Invisível para o servidor. O código do servidor e a lógica de borda não conseguem lê-lo, então qualquer decisão do lado do servidor precisa esperar o navegador.
• Preso a uma única origem. O armazenamento em www.example.com não está disponível em shop.example.com, então o visitante pode ver o banner de novo em cada subdomínio.
• Sujeito a exclusão. O Safari pode remover o armazenamento gravável por scripts, inclusive o localStorage, de sites com os quais o usuário não interagiu por sete dias de uso do navegador, e os modos de navegação privada costumam apagá-lo quando a sessão termina.

Opção 3: registros de consentimento do lado do servidor

Um registro do lado do servidor é uma entrada armazenada por você ou pelo seu provedor de CMP cada vez que uma escolha é feita. Geralmente contém um identificador pseudônimo, o carimbo de data e hora, as escolhas, a versão do banner ou da política exibida e um contexto como a região.

Pontos fortes

• Evidência durável. Sobrevive à limpeza de cookies e às restrições dos navegadores, o que o torna a ferramenta certa para demonstrar que o consentimento foi obtido.
• Auditável. Você pode gerar relatórios sobre as escolhas ao longo do tempo e responder a perguntas sobre eventos específicos.
• Potencial entre dispositivos. Para leitores logados, um registro no servidor pode sincronizar as escolhas entre dispositivos, se você explicar isso a eles.

Pontos fracos

• Não substitui o estado local. As tags no navegador ainda precisam de um sinal local rápido; consultar um servidor a cada visualização de página para buscar o consentimento adiciona latência.
• É, em si, um dado pessoal. Os registros exigem um período de retenção, controles de acesso e um lugar no seu aviso de privacidade.
• Dependência de um identificador. Visitantes anônimos só podem ser associados a um registro por meio de um identificador armazenado no dispositivo deles, o que leva você de volta ao armazenamento local.

Resumo lado a lado

• Melhor para lembrar a escolha na web: cookies first-party, de preferência definidos pelo seu servidor com uma duração estável.
• Melhor para dados de preferências detalhados no navegador: localStorage, combinado com um cookie que o servidor consiga ler.
• Melhor para comprovar a escolha: registros do lado do servidor.
• Pior escolha isolada: depender apenas do localStorage, o que deixa o servidor às cegas e a escolha frágil em alguns navegadores.

Uma abordagem combinada prática

1. Armazene o sinal local de referência — por exemplo a string TCF e um registro compacto de preferências — em um cookie first-party limitado ao seu domínio registrável.
2. Use o localStorage apenas para dados complementares que não precisem chegar ao servidor.
3. Grave um registro do lado do servidor para cada escolha, incluindo a versão do banner e da política exibidas.
4. Se uma escolha armazenada desaparecer, mostre o banner novamente em vez de presumir uma resposta anterior.
5. Defina um período de nova solicitação para as escolhas armazenadas e registre-o na sua política.

Armazenar a própria escolha de consentimento do visitante geralmente é considerado necessário para prestar o serviço que o visitante pediu — lembrar a decisão dele — mas confira as orientações aplicáveis nos seus principais mercados.

Principais conclusões

• Lembrar uma escolha e comprovar uma escolha são tarefas diferentes, que exigem armazenamentos diferentes.
• Os cookies são legíveis pelo servidor e compartilháveis entre subdomínios, mas limitados em tamanho e, no Safari, em duração quando definidos por script.
• O localStorage oferece espaço, mas é invisível para o servidor e pode ser apagado pelos navegadores.
• Os registros do lado do servidor são a camada de evidência, não um substituto para o sinal local.
• Combine um cookie first-party definido pelo servidor, armazenamento opcional do navegador e registros no servidor.