O Google Consent Mode está mesmo a funcionar?

Estado default definido antes das tags

O default tem de ser declarado antes de o gtag.js ou o contentor do GTM ser executado. Se chegar depois, a Google regista os primeiros hits como totalmente consentidos. Um contentor que define o seu próprio default através de um acionador Consent Initialization está bem: o que importa é que nada tenha sido medido antes.

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

Parâmetros v2 presentes

O Consent Mode v2 acrescentou dois parâmetros em março de 2024. Sem eles, o Google Ads deixa de construir públicos do EEE e de modelar conversões, e a implementação não é aceite ao abrigo da política de consentimento de utilizadores da UE da Google.

ad_user_data: "denied",
ad_personalization: "denied"

Update na alteração do consentimento

O banner tem de enviar a escolha do visitante à Google assim que ela muda, caso contrário as tags continuam a funcionar com o default. Não clicamos no seu banner, por isso um update que não vemos é indicado como não confirmado e não como falha: aceite uma categoria e observe a consola.

gtag("consent", "update", {
  analytics_storage: "granted"
});

Region e wait_for_update

Um array region deixa o tráfego de fora do EEE sem restrições, e wait_for_update impede que pings iniciais disparem com o estado errado. Recusar globalmente sem region é seguro, apenas mais restritivo do que o necessário.

region: ["EEA", "GB", "CH"],
wait_for_update: 500

O parâmetro gcs é a prova

Ler o seu código-fonte diz o que uma página pretendia fazer. O valor gcs nos pedidos que saem para a Google diz o que lá chegou de facto: G1 seguido de ad_storage e analytics_storage, por isso G100 é ambos recusados e G111 é ambos concedidos. Uma página pode ter um bloco de consentimento perfeito e mesmo assim não enviar gcs nenhum.