Banner de cookies: como integrar GA4 e Meta ao consentimento

Um banner de cookies é a caixa que pede o aceite do visitante para coletar dados. Quando ele entra no ar, costuma mudar os números do GA4 e da Meta. Às vezes isso é erro de configuração. Outras vezes é exatamente o esperado, porque com consentimento de verdade quem recusa deixa de ser contado. O problema aparece quando você não consegue distinguir uma coisa da outra.

Este guia mostra como ligar o banner ao Consent Mode do GA4 e ao controle de consentimento do pixel da Meta. O objetivo é medir o tráfego consentido da forma correta e respeitar a recusa. Não promete recuperar o dado que o consentimento tirou, porque isso nem sempre é possível.

O que um banner de cookies faz

Por fora, o banner é uma caixa com Aceitar e Recusar. Por dentro, é uma chave que decide quais scripts de marketing rodam no navegador do visitante.

Existem dois comportamentos comuns. No bloqueio por padrão, nenhum script de marketing dispara antes do visitante responder. Na aceitação por padrão, as tags rodam desde o primeiro segundo e o banner funciona mais como aviso.

Esses dois modos são uma escolha de desenho do banner e de postura jurídica. Eles não definem, sozinhos, como o consentimento chega ao GA4 e à Meta. Para isso existe o Consent Mode.

Por que o número muda, e quando é esperado

Quando o banner entra, o número de sessões e conversões costuma cair. Isso não é, por si só, prova de erro.

Sair de uma coleta sem consentimento para uma com consentimento real remove do relatório quem recusou. No modo básico do Consent Mode essas pessoas somem de vez. No avançado parte delas é modelada, mas só se a operação se qualificar para modelagem.

O jeito correto de ler a queda é decompor o que aconteceu. Qual a taxa de aceite do banner, qual modo foi implementado, e se a operação atinge o volume que o Google exige para modelar. O sucesso aqui é medir corretamente o tráfego consentido e respeitar a recusa, não fazer o número voltar ao que era antes do consentimento existir.

Consent Mode e a modelagem do GA4

O Consent Mode é o mecanismo do Google que faz o banner falar com as tags. Em vez de o banner bloquear o script às cegas, ele avisa o estado do consentimento e o GA4 decide o que fazer.

A base do funcionamento é o estado padrão negado, declarado antes de qualquer tag, atualizado para concedido quando o visitante aceita. No gtag.js a sequência completa é esta:

// 1. prepara o dataLayer e a funcao gtag ANTES do consentimento
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}

// 2. declara o PADRAO NEGADO antes de carregar a Google tag
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});

// 3. so agora carrega a Google tag
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');

E no clique do banner, a atualização:

// no aceite do visitante
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

No GTM o caminho oficial é diferente. Em vez de um Custom HTML solto chamando gtag('consent', 'default'), que não garante terminar antes do próximo trigger, usa-se um Template de CMP da galeria do GTM, ou um Custom Template que chame setDefaultConsentState no trigger nativo de Consent Initialization e updateConsentState no clique do banner. O trigger de Consent Initialization roda antes das outras tags, que é o ponto que importa.

Um detalhe que decide entre os dois modos do Consent Mode. No básico, a tag do Google simplesmente não dispara enquanto o estado estiver negado, nada é enviado. No avançado, a tag carrega mesmo negada e envia medições sem cookies, os chamados pings sem cookie. É esse segundo modo que habilita a modelagem.

A modelagem não é automática. O Google exige um volume mínimo, na faixa de mil eventos por dia com consentimento negado durante sete dias seguidos, além de um número mínimo de usuários consentidos e da implementação avançada em todas as páginas. Sites pequenos podem não se qualificar. O efeito real do Consent Mode é reduzir a lacuna, não apagar o consentimento negado.

Os defaults também podem variar por região. Com o campo region na mesma chamada de default, é possível deixar negado na União Europeia e concedido no Brasil, e o Google resolve a região sozinho. O que define o comportamento é o sinal que você manda, não uma regra fixa.

Antes das tags em qualquer página, leia a escolha que o visitante já fez, em geral em localStorage, e atualize o estado para concedido se foi um aceite anterior. Assim um visitante que voltou não fica travado no negado.

A Meta tem consentimento próprio

O pixel da Meta não lê o Consent Mode do Google, e essa é a origem do erro mais comum nesse tipo de implementação. Os sinais ad_storage, ad_user_data e ad_personalization são dos produtos do Google. A Meta tem o seu próprio controle de consentimento, e ele precisa ser chamado à parte.

No código do pixel, o revoke precisa vir depois do stub do fbq existir, mas antes do fbq('init') e do primeiro PageView. Executado depois, o primeiro envio já escapou:

// o snippet base do Meta cria o stub fbq; depois disso:
fbq('consent', 'revoke');        // ANTES do init e do PageView
fbq('init', PIXEL_ID);
fbq('track', 'PageView');
// no aceite do banner:
fbq('consent', 'grant');

No GTM existe uma alternativa que dispensa esse revoke: o hard gate. A tag do pixel da Meta simplesmente não dispara enquanto o trigger de consentimento publicitário não estiver satisfeito, e dispara no evento de atualização de consentimento. Assim o pixel nem inicializa antes do aceite. Os dois caminhos são válidos. O erro é não fazer nenhum dos dois.

Do lado do servidor, a API de Conversões da Meta não herda o estado do navegador. É o backend que decide, e a decisão certa para rastreamento publicitário sem consentimento é bloquear o evento da CAPI por inteiro. Retirar apenas e-mail e telefone não vira um gate: o evento ainda carrega IP, user agent, fbp, fbc e outros identificadores, e aplicar hash não anonimiza dado pessoal, só pseudonimiza. Sem consentimento e sem outra base legal documentada, o evento não sai.

Por isso a consistência entre navegador e servidor importa. O estado sinalizado no browser tem que chegar ao backend. Escrevi um guia sobre como a deduplicação entre pixel e CAPI funciona, e é nessa fronteira entre os dois lados que a consistência costuma quebrar.

A ordem de configuração correta

A montagem certa segue uma ordem fixa. Pular um passo é o que produz leitura errada de número.

1. Antes das tags em qualquer página, restaure a escolha que o visitante já fez (em localStorage) e atualize o estado de consentimento.
2. Declare o consentimento padrão negado antes de carregar qualquer tag. No gtag.js na sequência acima; no GTM via Consent Initialization.
3. Carregue as tags só depois do estado padrão estar declarado.
4. No clique do banner, dispare dois sinais de uma vez: a atualização do Consent Mode do Google e o fbq('consent', ...) do pixel da Meta.
5. Repasse a decisão ao backend, para que a CAPI só saia com consentimento ou com outra base legal documentada.
6. Valide antes de confiar no número.

Erros comuns

Quatro equívocos produzem queda de número ou leitura errada, e são fáceis de confundir com comportamento esperado.

Declarar o consentimento padrão depois das tags. O estado negado chega atrasado, o primeiro evento conta como concedido, e quem recusou aparece como se tivesse aceito.

Ligar o Consent Mode só para o Google e esquecer o pixel da Meta. O GA4 respeita o consentimento e o pixel segue disparando para todo mundo.

Ler a queda de número como prova de erro sem olhar a taxa de aceite, o modo implementado e a elegibilidade para modelagem.

Bloquear a CAPI só parcialmente, achando que tirar e-mail e telefone resolve. O evento ainda leva identificadores suficientes para descartar essa saída como gate de consentimento.

Como validar que o banner está aplicando o consentimento

Não confie só no Gerenciador de Eventos. Ele confirma que eventos chegaram, mas não prova que nenhum identificador foi transmitido nem que o consentimento foi aplicado nos dois lados. E pode misturar eventos de navegador e servidor, escondendo um lado bloqueado e o outro ainda enviando.

No navegador, abra uma sessão anônima, recuse o banner, e inspecione as requisições e os cookies na aba de rede. No modo básico, um evento de conversão que aparece aí com tudo negado indica que a tag não está sendo bloqueada. No avançado, o evento pode aparecer, e o correto é que viaje sem cookies nem identificadores, só o ping sem cookie. Para o caso oposto, de uma tag que não dispara de jeito nenhum, o passo a passo de diagnóstico por sintomas está no guia sobre por que a tag não dispara no Tag Assistant.

No GA4, nas configurações de consentimento dentro de Admin, você vê quais sinais chegam e a parcela do tráfego coberta. Dados modelados aparecem como indicadores de qualidade nos relatórios, não numa tela de proporção. O eventual uplift de modelagem para o Google Ads aparece no diagnóstico de conversões, e só para contas que se qualificam. Para validar especificamente os quatro sinais da V2 na aba Consent do Tag Assistant, há um guia dedicado sobre como validar o Consent Mode V2.

Na Meta, use Test Events no Gerenciador de Eventos e olhe separadamente Browser e Server. Com o pixel bloqueado, nada sai. Com o pixel revogado, o stub existe mas nenhum dado identificável é enviado. Na CAPI, nenhum evento chega enquanto o consentimento não existir. Se um evento de conversão aparecer por qualquer canal durante a recusa, o gate não está fechado.

O server-side reduz a perda, não a apaga

O Consent Mode resolve o consentimento. Ele não resolve o resto da pilha de restrições que cresceu em volta dele: bloqueadores de anúncio, limite de duração de cookies no navegador, extensões de privacidade.

O rastreamento server-side ajuda nesse terreno, dentro de um limite honesto. Em vez de o navegador falar direto com a Meta e o Google, ele manda o evento para um endpoint no seu próprio domínio, e é esse servidor que conversa com as plataformas. Isso reduz a quantidade de requisições que o bloqueador corta e dá mais controle sobre o cookie.

Não é imunidade. A requisição ainda nasce no navegador e pode ser bloqueada antes de chegar ao servidor. O Safari, em especial, já detecta endpoints de primeira parte disfarçados via CNAME e limita os cookies deles. E o container servidor continua precisando respeitar o consentimento, redigindo ou segurando eventos quando for o caso. Server-side aumenta a durabilidade do dado que você tem direito de coletar. Não restaura o dado que o consentimento tirou.

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, quanto custa na prática e quando não vale a pena. Se prefere que alguém levante o seu setup, dê uma olhada no que cobrimos em serviços de rastreamento.