Por que um cookie de rastreamento volta depois da recusa?

Todos os artigos

Quase sempre porque o script que o criou continua rodando. Apagar um cookie não para o código que o gravou: se esse código não foi avisado de que o consentimento foi negado, ele grava o cookie de novo no próximo envio. As outras causas são uma exclusão feita no domínio ou caminho errado e um cookie definido pelo seu servidor.

Por que um cookie apagado reaparece depois de uma recusa?

Um cookie é um arquivo que o navegador guarda. A tag que o criou é código que roda na página, e continua rodando depois que o banner fecha. Você apaga o arquivo e o código continua lá, pronto para gravá-lo de novo no próximo envio.

Reproduzimos isso com o gtag.js real do Google em um domínio de teste em novembro de 2026. Com a análise ainda permitida, apagamos _ga e _ga_<id> corretamente. Os dois sumiram. O evento seguinte enviado pela tag gravou o cookie de sessão, _ga_<id>, de volta na hora. No site de um cliente com quem trabalhamos no mesmo mês, um cookie de análise voltou quando a página ficou oculta, e não em um evento. As equipes costumam ler isso como falha da ferramenta de consentimento. O que falha é a ordem das operações.

A solução é avisar a tag primeiro. No mesmo teste, enviar gtag('consent', 'update', { analytics_storage: 'denied' }) e só então apagar os cookies os manteve fora mesmo com outro evento e uma página oculta simulada. Uma tag que sabe que o consentimento foi negado para de gravar; uma que não sabe desfaz a sua exclusão.

Por que apagar o cookie parece não adiantar nada?

Porque a exclusão precisa corresponder ao cookie que ela mira. Um navegador só remove um cookie quando o nome, o domínio e o caminho da exclusão batem com os usados na criação, como descreve a referência do MDN sobre o cabeçalho Set-Cookie. As tags do Google gravam os seus no nível de domínio mais alto possível, então em shop.example.com o cookie _ga fica em .example.com.

No nosso teste, uma exclusão escrita como document.cookie = '_ga=; Max-Age=0; path=/', sem domínio, não removeu nada. O script rodou sem erro e o cookie ficou. Adicione domain=.example.com e ele sai. O mesmo vale para o caminho: uma exclusão em / não alcança um cookie criado em um caminho diferente de /.

E os cookies definidos pelo servidor?

Nenhum script da página consegue ler ou apagar um cookie marcado como HttpOnly. Configurações de tagueamento do lado do servidor costumam usar um, por exemplo o cookie FPID que um contêiner de servidor pode emitir. Só o servidor pode fazê-lo expirar, então o servidor precisa saber da recusa e agir na próxima requisição. Se você usa um contêiner de servidor, confira se o cliente dele lê o estado do consentimento e para de emitir o cookie quando ele é negado. Como passar o sinal de consentimento para um contêiner de servidor cobre essa parte.

O cookie voltou mesmo ou nunca saiu?

Confira antes de corrigir. Alguns cookies devem ficar: o seu registro de consentimento e os estritamente necessários, como um cookie de sessão ou de carrinho. Cookies no domínio de outra empresa não podem ser removidos pelo seu site de jeito nenhum. Depois abra o painel de armazenamento do navegador e olhe a coluna de domínio. Um cookie no domínio principal pode pertencer a outro site seu no mesmo domínio, e quem decide é o banner desse site. Um cookie com valor novo foi gravado de novo. Um com o valor antigo nunca foi apagado. E se ele apareceu antes de o visitante escolher qualquer coisa, a tag rodou antes de o padrão negado ser definido: é um problema de ordem de carregamento, não de exclusão. O nosso post sobre como verificar se uma tag realmente grava cookies mostra como ler esses painéis.

Como impedir que um cookie volte depois da recusa?

1. Envie primeiro o sinal de negação

   Avise cada ferramenta no formato que ela escuta antes de mexer no armazenamento: uma atualização de consentimento para as tags do Google e a chamada equivalente para cada outro fornecedor. Uma tag que sabe que o consentimento foi negado para de gravar.

2. Apague em todos os níveis de domínio

   Apague cada cookie no host atual e em cada domínio acima dele até o registrável, com path=/. Uma exclusão sem domínio deixa passar, sem aviso, os cookies do domínio principal.

3. Segure as tags que ainda não rodaram

   Garanta que nada esperando para carregar possa começar depois da recusa e gravar o cookie de novo. Esse é o papel do bloqueio de tags, não da exclusão.

4. Faça os cookies do servidor expirarem no servidor

   Para qualquer cookie HttpOnly, faça o servidor ler o estado do consentimento e expirar o cookie na próxima requisição. Nenhum script da página consegue fazer isso.

5. Teste com uma página oculta e um recarregamento

   Aceite, depois recuse, envie um evento, troque de aba e recarregue. Leia o painel de cookies depois de cada passo. Uma recusa que só dura até o próximo envio não está funcionando.

Para a ordem completa que uma retirada deve seguir, incluindo a redefinição de identidade de que a maioria das bibliotecas precisa, veja o que acontece quando alguém retira o consentimento de cookies.

Como o Velo lida com isso

Quando um visitante recusa uma categoria que tinha permitido, o Velo envia o sinal de negação a cada fornecedor que está configurado para avisar e depois apaga os cookies próprios conhecidos e as chaves de armazenamento dessa categoria no host atual e em cada domínio acima dele até o registrável, com path=/. Ele não alcança cookies HttpOnly nem cookies de outro caminho, e não mexe no próprio registro de consentimento, porque esse registro é o que prova que a recusa aconteceu.