Consent Mode v2 do Google: como funciona e por que ele decide se sua conversão é medida

Existe um ponto de falha silencioso entre o banner de cookies e a plataforma de anúncios que derruba conversão sem gerar erro nenhum: a forma como as tags reagem à escolha do usuário. Quando essa reação está mal configurada, uma parcela dos eventos simplesmente não é enviada, outra é enviada sem a permissão que a tornaria utilizável, e o relatório passa a mostrar menos conversões do que realmente aconteceram. O Consent Mode do Google é o mecanismo que padroniza essa reação — e a versão 2 tornou alguns dos seus sinais obrigatórios para quem faz remarketing e mede conversão no ecossistema Google.

Entender o Consent Mode não é uma tarefa jurídica, é uma tarefa de engenharia de mensuração. Ele decide, evento a evento, se a tag coleta com plenitude, se coleta de forma limitada, ou se apenas envia um sinal sem cookies para que o Google faça uma estimativa depois. Quem trata isso como "só ligar o banner" descobre, meses adiante, que estava perdendo dados o tempo todo.

O problema que o Consent Mode resolve#

O conflito é simples de enunciar e difícil de resolver na prática: você precisa medir conversão para otimizar campanha, mas só pode processar dados do usuário dentro do que ele autorizou. A abordagem ingênua tem dois extremos ruins. Ou você bloqueia todas as tags até o consentimento (e perde todo o sinal de quem não interage com o banner ou nega parcialmente), ou você dispara tudo sempre (e trata dado sem base legal, o que é risco).

O Consent Mode oferece um caminho intermediário estruturado. Em vez de "ligado ou desligado", as tags do Google passam a ler o estado de consentimento e ajustar o próprio comportamento: coletar por completo quando há permissão, operar de forma restrita (sem cookies persistentes, com pings anônimos) quando não há, e alimentar a modelagem de conversão do Google para estimar o que não pôde ser observado diretamente.

O ponto que costuma passar despercebido: o Consent Mode não é o banner. Ele é a camada que traduz a decisão do banner (a CMP) para as tags. O banner coleta a escolha; o Consent Mode a comunica; a tag obedece.

Os quatro sinais de consentimento#

O Consent Mode v2 trabalha com quatro parâmetros de consentimento, cada um governando um tipo de tratamento. Entender o que cada um controla é o que evita configurar errado.

• analytics_storage — governa o armazenamento ligado à análise, tipicamente os cookies de mensuração do Google Analytics. Negado, o GA4 opera sem cookies e envia pings sem identificadores para modelagem.
• ad_storage — governa o armazenamento ligado à publicidade, como os cookies usados para conversão e remarketing. Negado, o Google Ads não grava nem lê esses cookies.
• ad_user_data — é um sinal novo da versão 2. Autoriza (ou não) o envio de dados do usuário ao Google para fins de publicidade. Diz respeito ao consentimento para que dados pessoais viagem, não só ao armazenamento local.
• ad_personalization — também novo na versão 2. Autoriza (ou não) o uso dos dados para publicidade personalizada, como remarketing e públicos semelhantes.

A distinção entre ad_storage e os dois sinais novos é o coração da versão 2. A versão anterior tratava sobretudo do armazenamento (cookies) no dispositivo. A versão 2 separou explicitamente o envio de dados (ad_user_data) e a personalização (ad_personalization), porque são finalidades distintas do ponto de vista de privacidade: é possível consentir com a medição de conversão e negar a personalização, por exemplo. Sem os dois sinais novos preenchidos, recursos de público e remarketing do Google param de receber dados, o que impacta diretamente campanhas.

Basic vs. advanced: o trade-off central#

Há dois modos de implementar o Consent Mode, e a escolha entre eles é o trade-off que mais afeta a cobertura de dados.

Modo básico (basic)#

No modo básico, as tags do Google não carregam antes do consentimento. Se o usuário nega ou não interage, a tag simplesmente não dispara — nenhum ping é enviado. Só depois de um consentimento afirmativo é que a tag é carregada e passa a coletar. A vantagem é a simplicidade e a garantia de que nada sai sem permissão. A desvantagem é que você perde completamente o sinal de todo mundo que não consentiu, e a modelagem do Google tem menos dados de base para estimar.

Modo avançado (advanced)#

No modo avançado, as tags carregam desde o início, mas respeitam o estado de consentimento. Quando não há permissão, elas enviam pings sem cookies — sinais anônimos, sem identificadores, que informam ao Google que houve um evento sem revelar quem foi. Esses pings alimentam a modelagem de conversão, permitindo que o Google estime as conversões perdidas com base em padrões agregados. A vantagem é uma cobertura muito maior e uma modelagem mais precisa. O custo é uma configuração mais cuidadosa e a necessidade de estar confortável com o envio desses pings anônimos.

Na prática, o modo avançado costuma recuperar uma fatia relevante de conversões que o modo básico deixaria invisíveis — mas exige que o default esteja corretamente declarado como negado antes de qualquer interação.

O estado default e o update#

O Consent Mode funciona em duas etapas temporais que precisam acontecer na ordem certa.

Primeiro, antes de qualquer tag do Google carregar, você declara o estado padrão — tipicamente tudo negado, porque o usuário ainda não decidiu:

``js gtag('consent', 'default', { ad_storage: 'denied', analytics_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied', wait_for_update: 500 }); ``

O wait_for_update diz às tags para esperarem alguns milissegundos por uma atualização antes de agir, evitando disparar no estado negado se o usuário já tiver uma escolha salva.

Depois que o usuário interage com o banner, a CMP dispara o update com a decisão real:

``js gtag('consent', 'update', { ad_storage: 'granted', analytics_storage: 'granted', ad_user_data: 'granted', ad_personalization: 'granted' }); ``

A ordem é inegociável: o default precisa ser executado antes do carregamento das tags, e o update só depois da decisão. Inverter isso — declarar o default tarde demais, ou nunca declará-lo — é o erro que mais quebra o Consent Mode, porque as tags acabam agindo sem saber que deveriam se conter.

Modelagem de conversão#

Quando o consentimento é negado no modo avançado, o Google recebe pings sem cookies e não observa a conversão de forma identificável. Ele então usa modelagem de conversão: uma estimativa estatística que atribui, ao volume de eventos anônimos, a proporção de conversões esperada com base no comportamento observável dos usuários que consentiram.

É importante ter clareza sobre a natureza desse número. Ele não é uma contagem, é uma inferência. Serve para preencher a lacuna deixada pela falta de consentimento e recuperar uma leitura mais fiel da performance real da campanha. Tratá-lo como se fosse uma contagem exata — ou, no outro extremo, ignorá-lo como se fosse inventado — leva a decisões erradas. A modelagem é uma aproximação útil da tendência, e é justamente o que o modo avançado habilita que o básico não habilita.

Integração com a CMP e com o server-side#

O Consent Mode não existe sozinho. Ele depende de três peças conversando: o banner/CMP que coleta a escolha, o gtag ou o GTM que carrega as tags, e o destino (Google Ads, GA4). Em implementações via Google Tag Manager, cada tag pode ter configurações de consentimento adicionais que a impedem de disparar sem os sinais requeridos — uma camada de segurança além do próprio Consent Mode.

O ponto crítico para quem faz mensuração server-side: o sinal de consentimento precisa acompanhar o evento até o servidor. Enviar um evento server-side de um usuário que negou a coleta não torna a coleta legítima só porque saiu da sua infraestrutura em vez do navegador. A decisão de consentimento capturada no cliente deve viajar junto com o evento, e o servidor deve respeitá-la antes de encaminhar às plataformas. Uma camada de conversão bem desenhada carrega o estado de consentimento como parte do contrato de cada evento e o aplica no ponto de distribuição.

Erros comuns e como validar#

Alguns problemas se repetem em quase toda implementação malfeita:

• Default ausente ou tardio. Se o consent default não roda antes das tags, elas assumem o comportamento padrão e coletam quando não deveriam — ou, dependendo da configuração, deixam de coletar quando poderiam.
• Pings sem consentimento no modo básico. Misturar as premissas dos dois modos: achar que está no básico (nada dispara) mas ter tags que disparam mesmo assim.
• Sinais novos esquecidos. Configurar ad_storage e analytics_storage mas deixar ad_user_data e ad_personalization de fora, o que degrada silenciosamente os públicos e o remarketing.
• Ordem de carregamento errada. A CMP carregando depois das tags, invertendo a sequência default → tags → update.

A validação passa por inspecionar, no próprio navegador, as requisições que saem para o Google e conferir os parâmetros de consentimento que elas carregam (o Google anexa indicadores do estado de consentimento às chamadas). Ferramentas de depuração de tags mostram, evento a evento, qual foi o estado lido. O teste decisivo é percorrer os três caminhos — usuário que aceita tudo, usuário que nega tudo, usuário que não interage — e confirmar que o comportamento de cada tag corresponde ao esperado em cada caso.

Síntese#

O Consent Mode v2 é a peça que decide, na prática, se sua conversão é medida — e como. Ele traduz a escolha do banner em comportamento de tag por meio de quatro sinais: ad_storage e analytics_storage para armazenamento, e os dois sinais da versão 2, ad_user_data e ad_personalization, para envio de dados e personalização. A regra operacional é curta: declare o default negado antes de qualquer tag carregar, aplique o update com a decisão real da CMP, prefira o modo avançado se você aceita os pings sem cookies e quer que a modelagem recupere as conversões perdidas, e leve o sinal de consentimento até o servidor na sua arquitetura server-side. Quando o número de conversões parecer baixo demais sem explicação, o Consent Mode é o primeiro lugar a investigar — porque é ali que os eventos somem sem deixar rastro de erro.