O Consent Mode V2 é o mecanismo do Google que faz as tags dele respeitarem a escolha do visitante no banner de cookies. O comportamento depende do modo implementado. No modo básico, quando o visitante recusa, as tags do Google não disparam. No modo avançado, elas chegam a carregar e a enviar medições sem cookies, os chamados pings sem cookie, que podem alimentar a modelagem do Google se a propriedade se qualificar. A segunda versão, anunciada no final de 2023, adicionou dois sinais novos de consentimento. Sem eles a V2 fica incompleta, e é justamente essa incompletude que o Tag Assistant deixa à mostra em sites que já têm banner.

O sintoma de uma implementação pela metade raramente aparece no banner. Ele aparece no modo de visualização do Tag Assistant: sinais que nem constam na página, um estado negado declarado depois das tags carregarem, ou sinais em desacordo com a escolha que o visitante fez no banner. A confusão que leva até aqui é misturar duas coisas que não são a mesma: o consentimento, que é a decisão jurídica do titular, e o Consent Mode, que é o mecanismo técnico que executa essa decisão no navegador.

Este guia mostra o que mudou na V2, como o lado jurídico se conecta ao sinal técnico e como confirmar, passo a passo, que tudo funciona. Para montar o banner do zero, com o código de integração do GA4 e do pixel da Meta e a diferença entre modo básico e avançado, vale ler o guia sobre como integrar o banner de cookies ao GA4 e à Meta. Aqui o foco é a validação da V2.

O Consent Mode existe para que o banner não fique só na tela. Ele é a ponte entre a caixa de Aceitar e Recusar e o que as tags do Google fazem. Em vez de o site bloquear o script às cegas, o banner avisa o estado do consentimento e as tags decidem como agir conforme o modo, básico ou avançado.

A primeira versão trabalhava com dois sinais de armazenamento. ad_storage controlava o uso de cookies para publicidade e analytics_storage o uso para estatística. A V2 acrescentou dois sinais que falam de dado do usuário, não só de cookie. ad_user_data controla o consentimento para enviar dados do usuário, como e-mail ou telefone de conversões avançadas, ao Google para fins de publicidade. ad_personalization controla o uso desses dados para personalizar anúncios, como em remarketing.

São quatro sinais de consentimento, portanto, e todos precisam estar declarados para a V2 estar completa. Os dois novos não são detalhe. Eles passaram a ser exigidos pelo Google para tráfego europeu (Espaço Econômico Europeu, Reino Unido e Suíça) que usa recursos de personalização de anúncios. Para tráfego brasileiro a exigência não vale da mesma forma, mas o sinal continua valendo: ele diz ao Google o que pode fazer com o dado daquele visitante.

Existem ainda dois campos que parecem sinais mas não são. ads_data_redaction e url_passthrough são configurações de comportamento. No gtag.js eles vão numa chamada separada, gtag('set', {...}), e não dentro do objeto gtag('consent', 'default', ...); no GTM, em templates de CMP, entram pelo gtagSet. Misturá-los com os quatro sinais de consentimento é um erro frequente e quebra o entendimento do que cada um faz.

O consentimento, na LGPD, é a manifestação de vontade pela qual o titular autoriza uma empresa a tratar os dados dele para uma finalidade específica. A lei diz que ela pode ser dada por escrito ou por outro meio, e exige que seja livre, informada e inequívoca, conforme o artigo 5º, inciso XII. O termo de consentimento é uma das formas de registrar essa manifestação, não a única, e o registro em si não é a base legal: a base é o consentimento válido. O artigo 8º detalha que ele precisa ser específico e que a revogação tem que ser facilitada e gratuita.

O consentimento, por sua vez, é só uma das bases legais do artigo 7º. Há tratamento que pode se apoiar em outra base, como execução de contrato ou legítimo interesse, e nesse caso não depende do aceite do titular. É por isso que afirmar que todo site precisa de banner por causa da LGPD é uma meia verdade: depende do dado, da finalidade e da base escolhida.

O Consent Mode é a camada técnica. Ele é o que faz a escolha registrada no banner, que costuma espelhar o aceite do consentimento, chegar às tags e ser respeitada. As duas camadas precisam estar alinhadas. Mas o alinhamento não se confirma sozinho: o time jurídico prepara o termo, o time de marketing instala o banner, e a verificação de que o sinal técnico sai do navegador com o valor certo é o passo que costuma sobrar.

A consequência de desalinhamento é jurídica e técnica ao mesmo tempo. Para o tratamento que depende de consentimento, coletar dado de visitante que o recusou descumpre a base legal escolhida, e o artigo 42 da LGPD prevê reparação de danos a quem sofrer tratamento de dados em violação à lei. Do lado técnico, o dado coletado antes do consentimento estraga a qualidade da medição e ainda deixa o site exposto. Validar o Consent Mode é, portanto, também verificar que a base legal documentada está de fato sendo honrada no navegador. Isso é uma verificação de engenharia, não uma opinião jurídica, e não substitui a revisão da base legal por quem entende do assunto.

Por que o consentimento negado precisa ser declarado antes das tags

O defeito que mais invalida uma implementação de Consent Mode não é um sinal errado. É a ordem em que o estado negado é declarado.

A Google tag só respeita o estado de consentimento que conhece no instante em que dispara. Se o default negado for declarado depois dela carregar, o primeiro evento da página sai como se tudo estivesse concedido. O visitante ainda nem viu o banner e a Google tag já enviou o primeiro hit, podendo ler ou gravar cookies antes de o estado negado passar a valer. O estado negado chega atrasado e só vale para os eventos seguintes, o que é o oposto do objetivo.

Diagrama: quando o consentimento padrão negado é declarado antes das tags, o estado negado vale desde o início; quando é declarado depois, o primeiro evento vaza como se fosse concedido.
O default negado precisa chegar antes da Google tag. Declarar depois não dá erro visível no painel, por isso passa batido.

No GTM a forma oficial de resolver isso é o gatilho nativo de Consent Initialization, que roda antes de todas as outras tags. É nele que se declara o estado padrão, geralmente por um Template de CMP da galeria ou por um Custom Template que chame setDefaultConsentState. No gtag.js puro, a chamada gtag('consent','default',...) tem que aparecer antes da Google tag. Em ambos os casos, o estado precisa também restaurar a escolha que o visitante já fez em visitas anteriores, em geral lida de localStorage, para que um visitante que voltou e já aceitou não fique preso no negado.

A validação acontece no modo de visualização do GTM, que é o Tag Assistant. Ele é a mesma interface aberta pelo botão Visualizar, e mostra o que cada tag fez em cada evento, inclusive o estado de consentimento resolvido naquele instante. O lugar certo de olhar o consentimento é a aba Consent, não o DebugView.

Abra uma sessão anônima, recuse o banner e reproduza uma ação que deveria gerar um evento. No painel esquerdo, selecione o primeiro evento de consentimento para ler o On-page Default, o estado declarado no carregamento da página, e o último evento de consentimento para ler o On-page Update, o estado depois do visitante responder o banner. Na aba Tags do mesmo evento, confirme que as tags fizeram o esperado: no modo básico, bloqueadas enquanto negadas; no avançado, disparadas em pings sem cookie.

Os valores esperados dependem da política do site. Quatro sinais negados é o exemplo conservador para um visitante novo cujo tratamento depende de consentimento, e o campo region permite conceder de saída nas regiões em que o banner não se aplica. Compare sempre o resultado com o que sua política define. Teste três cenários, em sessões separadas. Recusar tudo: os quatro sinais, ad_storage, analytics_storage, ad_user_data e ad_personalization, precisam aparecer como denied no On-page Default e seguir denied no On-page Update. Aceitar tudo: o On-page Default segue denied e o On-page Update passa todos para granted. Escolha granular, como só a categoria de estatística: analytics_storage aparece como granted e os três sinais publicitários seguem denied, refletindo o que o visitante escolheu. Se os quatro sempre viram granted juntos, mesmo num banner que oferece escolha por categoria, a implementação não está repassando a decisão granular.

Ilustração da aba Consent do modo de visualização do GTM, mostrando um sinal de consentimento e o estado resolvido nas colunas On-page Default e On-page Update.
Ilustração da aba Consent no modo de visualização, não é uma captura. O que importa é o estado resolvido de cada sinal nas colunas Default e Update.

Três resultados merecem atenção. Se um sinal segue denied no On-page Update depois do aceite, o update não foi disparado, foi disparado com valor errado, ou a CMP não está falando com o GTM. Se um sinal que você esperava ver não aparece de jeito nenhum, a V2 está incompleta: faltou declarar os dois sinais novos no default e no update. Se todos aparecem como granted desde o primeiro evento, mesmo recusando tudo, o default negado não está sendo aplicado antes das tags, o caso da seção anterior.

Conclua com um teste de retorno. Recarregue a página ou volte a ela depois do aceite e confirme que o estado restaurado continua granted, sem voltar ao negado, o que mostraria que a escolha anterior não está sendo persistida. Para confirmar além do estado, cruze com a aba de rede do navegador: com ad_storage negado os cookies de publicidade não são lidos nem gravados, mas a requisição ainda pode levar a URL completa, com o identificador de clique (GCLID), que só é removido se ads_data_redaction estiver ligado. O DebugView do GA4 mostra o evento chegando quando o analytics_storage permite, mas não é ele que diz se o consentimento está certo, e com o armazenamento negado eventos podem nem aparecer lá. Para o diagnóstico do caso oposto, em que a tag simplesmente não dispara, o passo a passo por sintomas está no guia sobre por que a tag não dispara no Tag Assistant.

O que o ads_data_redaction e o url_passthrough fazem

Esses dois campos mudam o comportamento do Google quando o consentimento de publicidade está negado. Não pedem consentimento, definem o que o Google faz com o dado enquanto espera, e por isso vivem numa chamada de configuração separada, não junto com os quatro sinais.

ads_data_redaction é uma configuração opcional. Com ad_storage negado, o Google já passa a usar um domínio sem cookies de publicidade de terceiros; ligar o redaction dá um passo a mais e remove o identificador de clique, o GCLID, e qualquer URL que o contenha das requisições para o Google Ads e o Floodlight. O bloqueio de novos cookies é consequência do ad_storage negado, não do redaction. Por isso, sem cookie não é o mesmo que sem identificador.

url_passthrough, quando ligado, faz parâmetros como o identificador de clique e o linker de medição seguirem de página em página no mesmo domínio quando os cookies não podem ser gravados. Isso ajuda a manter a atribuição e a continuidade de sessão numa navegação sem cookie. Ele vem desligado por padrão. Ligá-lo é uma troca entre preservar atribuição e deixar parâmetros rodando pela URL antes do consentimento, e convém testar redirecionamentos e páginas que já usam query string, que podem interagir com esses parâmetros.

Checklist rápido de validação

Cada item aponta para uma verificação concreta dentro do modo de visualização do GTM ou do navegador.

  1. Os quatro sinais estão declarados no default e no update, incluindo ad_user_data e ad_personalization?
  2. O default negado roda no gatilho de Consent Initialization, antes das outras tags?
  3. A escolha anterior do visitante é restaurada ao carregar a página, para não prender quem já aceitou?
  4. Na aba Consent, recusar tudo deixa os quatro sinais como denied no Default e no Update?
  5. Aceitar tudo passa os quatro para granted no Update, e uma escolha granular reflete só a categoria escolhida?
  6. A aba Tags confirma o comportamento por modo: bloqueadas no básico, em ping sem cookie no avançado?
  7. Na aba de rede, com ad_storage negado não há leitura nem gravação de cookies de publicidade, e o GCLID só some se ads_data_redaction estiver ligado?

O Consent Mode faz a parte dele, que é passar o consentimento do banner para as tags do Google. Ele não resolve as outras restrições que cercaram o rastreamento, como bloqueadores de anúncio, limite de duração de cookies no navegador e extensões de privacidade. Para esse terreno existe o rastreamento server-side, que manda o evento a um endpoint no seu próprio domínio antes de conversar com as plataformas.

O container servidor não substitui o consentimento. Ele continua precisando respeitar o estado que veio do navegador, redigindo ou segurando o evento quando for o caso, e não recupera o dado que o consentimento negado tirou. Pode dar mais durabilidade ao cookie em certas configurações, mas isso depende da implementação, não é garantia. Se você ainda não tem um container server-side de pé, o guia sobre o que é a hospedagem de container server-side cobre o que ela resolve e quando não vale a pena, e o de quanto custa o GTM server side faz a conta da hospedagem por cenário.

Validar o Consent Mode V2 é fechar o ciclo entre o que o consentimento promete e o que o navegador executa. O registro sem o sinal técnico é papel. O sinal técnico sem a base legal é mecanismo sem fundamento. Quando os dois estão alinhados e validados, a escolha do visitante passa a ser respeitada de verdade, e é isso que a medição precisa refletir. Se prefere que alguém monte e valide o seu setup, dê uma olhada no que cobrimos em serviços de rastreamento.