CookiePass e o Google Consent Mode: o que um banner de consentimento faz ao seu tráfego

O Consent Mode não é um interruptor para as suas etiquetas. Com ele, a etiqueta Google continua a disparar em cada página; o que muda é uma marca em cada hit e o que a Google faz com ele por causa dela. Quando analytics_storage está negado, a etiqueta não define cookies, não guarda um client id entre páginas e envia o que a Google chama um ping sem cookies — um hit que o GA4 usa para modelação, não para os relatórios que lê.

A marca é um parâmetro de consulta chamado gcs: duas letras e dois dígitos. O primeiro dígito é ad_storage, o segundo analytics_storage; 1 concedido, 0 negado.

gcs=G100   ad_storage denied,  analytics_storage denied
gcs=G101   ad_storage denied,  analytics_storage granted
gcs=G110   ad_storage granted, analytics_storage denied
gcs=G111   both granted
(no gcs)   no Consent Mode on the page — treated as granted

A última linha é a que escapa. Uma página sem Consent Mode não envia gcs, e a Google trata cada hit dela como consentido. Adicionar um banner que implemente o Consent Mode não reduz o que é enviado — começa a dizer a verdade sobre isso.

O Consent Mode v2 exige uma sequência, não uma definição. O estado predefinido tem de ser declarado antes de a etiqueta Google carregar — negado para quem ainda não escolheu —, uma atualização tem de seguir no momento em que o visitante decide, e esse estado tem de ser reposto em cada visita seguinte. Com a ordem errada, a primeira visualização de página de cada sessão sai como consentida antes de o banner sequer aparecer.

Esta é a sequência que o CookiePass produz a partir do seu próprio script, pelo que nada disto vai parar ao seu contentor do Tag Manager:

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

// …the visitor accepts…
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

É esta a integração toda. As etiquetas da própria Google respeitam o estado de consentimento automaticamente, incluindo as que o SignalHost publica no seu contentor web. Nada no seu contentor de servidor precisa de uma condição de consentimento; adicioná-la à mão é como uma etiqueta Google bloqueada acaba ao lado de etiquetas de evento desbloqueadas a enviar dados diretamente para a Google.

Cada hit continua a fazer o mesmo caminho: o navegador envia-o para o seu próprio hostname, o edge reencaminha-o para o seu contentor de servidor e o contentor passa-o ao GA4. A diferença está toda no payload.

• Antes da escolha: gcs=G100 em cada hit, sem cookie _ga e com um client id novo em cada página. O GA4 recebe um ping sem cookies; o seu contentor conta um pedido.
• Depois de aceitar: gcs=G111, os cookies são definidos e a sessão junta-se. A partir daqui são os hits de que os seus relatórios são feitos.
• Depois de recusar: gcs=G100 em cada página, enquanto a escolha se mantiver. Os eventos da medição avançada — scroll, file_download e os restantes — seguem a mesma regra que o page_view.

É por isso que a página do contentor mostra dois números por evento quando há um banner: os hits enviados com consentimento de analytics — o que o Analytics vai mostrar como utilizadores e sessões — e, após a barra, tudo o que o contentor reencaminhou. session_start e first_visit nunca aparecem em nenhuma das colunas: o Analytics deriva-os de sinais no primeiro page_view em vez de os receber como eventos.

Conte com as duas colunas a divergir, e conte com a diferença ser o número mais útil da página.

• O Analytics reporta menos utilizadores e sessões do que os pedidos que o seu contentor conta. A diferença é a fatia de visitantes que recusou ou nunca respondeu: a sua taxa de consentimento, medida em vez de estimada.
• O GA4 pode preencher parte dessa diferença com modelação comportamental, assim que a propriedade atingir os limiares da Google. Os dados modelados aparecem nos relatórios; nunca no seu contentor, porque nunca são enviados.
• Com ad_storage negado, o acompanhamento de conversões do Google Ads não tem a que atribuir e o conversion linker nada tem a ligar. Um contentor de servidor não muda isso, nem deve: first-party não significa sem consentimento.
• O design do banner passa a ser uma decisão de medição. Uma taxa de consentimento de 60% e uma de 85% são o mesmo site com botões diferentes, e a diferença entre as colunas diz-lhe qual tem.

• Carregue o script de consentimento antes da etiqueta Google. O estado predefinido tem de existir antes do primeiro hit.
• Abra uma página com o banner por responder e leia gcs num pedido /g/collect no painel de rede do navegador. Deve dizer G100.
• Aceite e volte a lê-lo na página seguinte. Deve dizer G111.
• Não adicione acionadores de consentimento a nada no contentor de servidor. A etiqueta web já transporta o estado.
• Volte à página do contentor um dia depois e leia o par de números em page_view. O primeiro a dividir pelo segundo é a sua taxa de consentimento.

Escolhemos o CookiePass porque faz exatamente a sequência acima, ficou em produção neste site numa tarde e deixa o banner usar as cores do próprio site. Os números da secção anterior são a prova de que funciona.