O que acontece quando alguém retira o consentimento de cookies

Todos os artigos

A coleta para nas categorias que a pessoa revogou, e os cookies que já estão no dispositivo dela, em geral, ficam onde estão. Três coisas devem vir em seguida. O registro ganha um evento de retirada em vez de perder a concessão original. Um sinal de negação vai para toda ferramenta que aceita um. E cada ferramenta redefine a identidade antes de a captura ser desligada.

A resposta que todo mundo dá é sobre arquivos de cookie

Pesquise essa pergunta e você recebe a resposta para uma mais estreita: a retirada apaga os cookies que já estão no dispositivo? A resposta é não, e o raciocínio é sólido. Um script só consegue mexer em cookies do próprio domínio, então nada no seu site alcança um cookie que outra empresa gravou no domínio dela. Isso é uma regra de segurança do navegador, não uma falha da sua ferramenta de consentimento. Cookies próprios (first party) como _ga são a exceção: eles ficam no seu próprio domínio, então o seu site pode apagá-los. O que uma plataforma de consentimento faz é bloquear os scripts que leem e gravam esses cookies.

Essa resposta está correta, e é a menor parte da transição. Apagar um arquivo depois protege muito pouco: o momento que importa é quando os dados circulam, ou seja, quando um cookie é definido e quando é lido. O bloqueio impede as duas coisas. Limpar arquivos, não.

Existe uma exceção real. Com ads_data_redaction ativado e ad_storage negado, o Google remove os identificadores de clique dos pings que ainda envia, como documenta o guia do 'consent mode' do Google. Essa é a única alavanca da stack que tira alguma coisa do que é enviado, e é uma configuração do Google, não algo que o seu banner executa.

O que quase ninguém documenta é o que a sua stack de medição deve fazer nesse momento. É aí que a retirada dá errado, e dá errado em silêncio: o banner fecha e tudo parece bem.

O que deve acontecer, em ordem

A retirada é uma sequência, e a ordem importa mais do que qualquer chamada isolada.

1. Registre a retirada como um novo evento, não como uma edição

   Uma retirada não é uma correção da concessão original. É um segundo fato: este visitante consentiu em um momento e revogou em outro, e as duas coisas são verdade. Armazene-a como uma nova linha que aponta para a concessão que ela substitui, em uma tabela que não pode ser atualizada nem apagada. O artigo 7(3) do GDPR diz que a retirada não afeta a licitude do tratamento feito antes dela, e a concessão original é a sua prova disso. Sobrescreva-a e você terá destruído a única prova de que a coleta anterior era lícita. O Velo grava uma retirada como um novo evento que referencia o anterior, mantido indefinidamente mesmo quando os registros comuns de concessão expiram.

2. Envie um sinal de negação, não fique em silêncio

   O instinto é fazer tudo parar de disparar. Com o Consent Mode, isso está errado. A tag deve continuar no lugar e receber uma atualização que define analytics_storage e os três sinais de publicidade como denied. Ela então envia um ping sem cookies e sem nenhum identificador, e esse ping mantém vivos a modelagem e os relatórios básicos. Remover a tag por completo não envia nada, e nada não é o mesmo que uma recusa registrada. Um é um visitante que disse não; o outro é um visitante que não existe.

3. Fale com cada ferramenta no dialeto que ela entende

   Não existe uma API de consentimento única. As tags do Google leem uma chamada gtag('consent', 'update', …), as da Microsoft um push para uetq, as da Meta uma chamada fbq. E os gatilhos do Google Tag Manager não enxergam um CustomEvent do navegador, então uma retirada que só dispara um deixa todos os gatilhos de evento personalizado sem disparar. Envie também um evento nomeado para a camada de dados. O nosso próprio SDK faz todo caminho que muda o consentimento passar por uma única função que emite os quatro: um clique no banner, uma decisão guardada sendo reaplicada, um sinal de Global Privacy Control forçando categorias a desligar. Assim, uma retirada não tem como sair por um caminho diferente do de uma concessão.

4. Redefina a identidade antes de parar a captura, nunca depois

   A maioria das bibliotecas de análise expõe duas chamadas: uma apaga quem o visitante é, a outra desliga a captura. Quase todo mundo as escreve nessa ordem na cabeça, primeiro parar de capturar e depois esquecer a pessoa, e quase todo mundo está escrevendo um bug. Em muitas bibliotecas, a flag de consentimento e a identidade compartilham o mesmo armazenamento, então o reset apaga o opt-out que você acabou de definir. Reset primeiro, desligar a captura por último.

5. Aplique a trava de novo e depois recarregue a página

   O bloqueio governa o que ainda não rodou. Um script que já carregou continua na memória, com os próprios timers, e pode gravar o cookie de novo na próxima interação, não importa o que o seu banner diga agora. Aplicar a trava de novo impede a próxima coisa; recarregar a página é a única garantia limpa de que nada do estado de consentimento anterior continua rodando. O recarregamento também reaplica a decisão guardada desde o início, o caminho que um visitante que volta percorre, então esse caso é testado de graça.

Qual etapa dá errado com mais frequência?

Encontramos o quarto passo na nossa própria stack, não na de um cliente. O nosso banner nega a análise; o ramo de negação chamava o opt-out primeiro e o reset de identidade depois. Parece certo à primeira leitura: parar de capturar, depois esquecer a pessoa.

Nos dados, isso gerou duas pessoas: uma identificada e uma anônima, compartilhando um único identificador de dispositivo com minutos de diferença. A causa estava na biblioteca, não no banner. No posthog-js 1.424.1, a chamada de reset também redefine o estado de consentimento armazenado, então rodá-la depois do opt-out apagava o opt-out, e a captura voltava sob um identificador anônimo novo e em uma nova sessão. Todo visitante que retirava o consentimento era contado duas vezes, sem nenhum aviso.

Inverter as duas chamadas resolveu, e a verificação foi feita em um navegador limpo, não em code review. Aceite, e um identificador aparece. Recuse, e a flag de opt-out fica true, com zero requisições saindo para um evento forçado. Aceite de novo mais tarde, e volta o mesmo identificador, não um terceiro.

O que o visitante deve conseguir ver?

O GDPR diz que retirar o consentimento tem que ser tão fácil quanto dá-lo. Na prática, isso significa um controle que reabre o painel de preferências a partir de qualquer página, não um link enterrado em um documento de política. A decisão deve valer na própria página em que a pessoa está.

Também significa um recibo que a pessoa possa mostrar depois, o mesmo mecanismo que responde como provar que um visitante deu consentimento. Uma retirada é um registro de consentimento como qualquer outro.

A última coisa a resolver é quando perguntar de novo. Uma retirada não é permissão para mostrar o banner na próxima visualização de página; tratá-la assim é o que transforma um banner em incômodo. O momento certo tem a sua própria resposta: quanto tempo dura o consentimento de cookies e quando o banner deve perguntar de novo.

Como testar uma retirada?

Quase todo banner foi testado na chegada. Quase nenhum foi testado na saída, e é por isso que bugs de retirada sobrevivem por meses enquanto o caminho do aceite continua perfeito. Aceite, navegue por duas páginas, depois retire o consentimento e observe três coisas: o que sai do navegador, se o opt-out continua definido um minuto depois, e quantas pessoas a sua ferramenta de análise acha que aquele navegador era.

O Velo faz toda mudança de consentimento, seja concessão ou retirada, passar por um único caminho que registra o evento, atualiza o Consent Mode, envia para a camada de dados o evento que aciona os gatilhos do seu contêiner e chama a API de consentimento de cada fornecedor. Isso elimina a divergência entre as duas direções. Não elimina o teste: acertar a ordem em que as suas próprias ferramentas esperam as chamadas continua sendo tarefa sua.