O Google tag gateway precisa de consentimento de cookies?

Todos os artigos

Sim. O Google tag gateway muda de onde a sua tag do Google carrega, não o consentimento de que ela precisa. A tag é servida a partir de um caminho no seu próprio domínio, mas continua lendo o Consent Mode, então o seu banner, os seus padrões de consentimento e as configurações de consentimento de cada tag continuam valendo. A única coisa a conferir é a ordem de carregamento: os seus padrões ainda precisam ser definidos antes de qualquer tag do Google disparar.

Esse último ponto é o que merece o seu tempo. O lado jurídico da questão tem uma resposta curta, e o lado prático tem um checklist curto. Os dois estão abaixo.

O que o Google tag gateway muda de fato?

O Google tag gateway for advertisers carrega a sua tag do Google ou o seu contêiner do Tag Manager a partir de um caminho no seu próprio domínio, como /metrics/, em vez de googletagmanager.com. As requisições de medição também vão para esse caminho, e a sua CDN ou o seu balanceador de carga as encaminha para o Google. A página do Google para desenvolvedores descreve isso como rodar a sua tag na sua própria infraestrutura (first party).

Há duas formas de ativá-lo. Se o seu site fica atrás da Cloudflare, você pode fazer isso no Tag Manager em Admin, Google tag gateway, depois autorizar o Google na Cloudflare e escolher os domínios. Em qualquer outra CDN, você direciona o caminho de medição para o endereço fps.goog da sua tag, encaminha os cabeçalhos de localização do visitante e troca o src no seu trecho de código pelo novo caminho.

De um jeito ou de outro, três coisas mudam: o endereço de onde o script vem, o endereço para onde vão as requisições e quem as encaminha. Nada nessa lista mexe no consentimento.

Servir tags do seu próprio domínio muda as suas obrigações de consentimento?

Não. A regra de consentimento da UE no artigo 5(3) da Diretiva ePrivacy trata de armazenar ou ler informações no dispositivo do visitante. Ela não pergunta de qual domínio o script veio. Um cookie do Google Analytics gravado por uma tag carregada de /metrics/ continua sendo um cookie que precisa de consentimento onde o consentimento é exigido.

O Google diz o mesmo na sua própria página de configuração. O guia de configuração do tag gateway na Cloudflare avisa que ativar o recurso afeta como as tags do Google disparam, e orienta você a adotar o Consent Mode e revisar as suas configurações de consentimento se o consentimento já condiciona as suas tags.

Então um gateway não é um jeito de contornar o banner de cookies. Se o seu banner era necessário antes da mudança, ele é necessário depois dela.

O tag gateway pode quebrar a sua configuração de consentimento?

Pode, pela ordem, não pela lei. O Consent Mode só funciona quando o estado de consentimento padrão é definido antes de qualquer tag do Google disparar, como o guia de configuração de consentimento do Google deixa claro. Se o gateway atrapalha isso depende de onde vêm os seus padrões.

• A sua plataforma de consentimento roda dentro do Tag Manager. O template fica no gatilho Consent Initialization, que roda antes de todos os outros gatilhos do contêiner. O contêiner continua carregando como uma peça só, apenas de outro endereço, então os padrões continuam vindo primeiro.
• A sua plataforma de consentimento é um script separado na página. Aqui a ordem depende da página. Se a CDN agora serve ou injeta a tag do Google mais cedo do que antes, ela pode rodar antes do seu script de consentimento. As ferramentas do Google então informam que o padrão foi definido tarde.

Vemos o primeiro caso no nosso próprio site. O veloconsent.com carrega o seu contêiner do Tag Manager a partir de um caminho no próprio domínio, por meio de um Cloudflare Worker. Esse é o nosso próprio proxy, e não o gateway do Google, mas a ideia é a mesma, e o template do Velo em Consent Initialization continua definindo os padrões negados antes de qualquer outra tag rodar.

Se você está no segundo caso, a correção está na sua página ou na sua configuração, não nas regras de consentimento. Qualquer uma destas medidas restaura a ordem:

• Carregue o script de consentimento acima do trecho de código do Google, para que os padrões dele rodem primeiro.
• Leve os padrões de consentimento para o Tag Manager, no gatilho Consent Initialization.
• Se foi a configuração automática da Cloudflare que mudou a tag de lugar, use a configuração manual. Você mesmo edita o trecho de código, então decide onde ele fica.

Depois confirme no Tag Assistant, como nas verificações abaixo. O nosso post sobre bloquear ou não as tags do Google até o consentimento explica como o Consent Mode básico e o avançado tratam as tags que carregam antes de uma escolha.

O que continua igual depois da mudança?

Quase tudo o que você configurou para o consentimento continua valendo, e o gateway não faz nada disso por você.

• As tags do Google Analytics, do Google Ads e do Floodlight leem o Consent Mode sozinhas. Tags de Custom HTML e a maioria dos templates da comunidade não, então as configurações de consentimento delas no Tag Manager continuam importando.
• As conversões otimizadas continuam dependendo de ad_user_data. Se o visitante recusa publicidade, esses dados não devem ser enviados, seja qual for o caminho que a tag usa.
• O script da sua plataforma de consentimento continua carregando de onde carregava. Com o Velo, é o endereço do Velo, e isso é o esperado.
• Um contêiner de servidor continua recebendo o estado de consentimento em cada requisição. As tags de servidor do Google o seguem. As tags de servidor de outros fornecedores precisam das suas próprias verificações de consentimento, como explica o nosso guia sobre enviar o consentimento para um contêiner do lado do servidor.

O nosso guia de ajuda percorre a configuração em ordem, de servir tags do Google pelo tag gateway a levar o consentimento para a marcação do lado do servidor.

Como conferir que o consentimento ainda funciona depois da mudança?

Rode o mesmo teste de consentimento que você rodou antes da mudança, mais duas verificações do próprio gateway. Comece cada teste em uma sessão nova do navegador, no site publicado.

1. Confira se o gateway está saudável

   Abra /metrics/healthy e /metrics/?validate_geo=healthy no seu domínio, usando o seu próprio caminho. Os dois devem retornar ok. Se só o segundo falhar, os cabeçalhos de localização não estão sendo encaminhados.

2. Confirme que o novo caminho está em uso

   Na aba de rede do navegador, a tag do Google e as requisições dela devem ir para o seu caminho de medição. Se ainda forem para googletagmanager.com, uma cópia antiga do trecho de código ainda está na página.

3. Confira se os padrões vêm primeiro

   No Tag Assistant, o padrão de consentimento deve aparecer antes de qualquer tag do Google disparar. Um padrão informado como tardio significa que o seu script de consentimento agora carrega depois da tag.

4. Teste aceitar, recusar e uma escolha parcial

   Confira o estado de consentimento em cada tag nos três casos. Tags com configurações de consentimento adicionais devem continuar bloqueadas depois de uma recusa.

5. Mude de ideia numa página seguinte

   Reabra o banner, mude a escolha e confira se a atualização chega às tags na página seguinte.

O tag gateway traz de volta os dados que o consentimento esconde?

Não. Um visitante que recusa é tratado da mesma forma, seja qual for o domínio de onde a tag carrega. O Google apresenta o gateway como uma forma de tornar a medição mais durável, o que tem a ver com o script chegar a carregar, por exemplo onde um bloqueador o impediria. Esse é um problema separado do consentimento, e o gateway não o muda. Se você quer entender o que uma recusa faz com os seus relatórios, comece por o que acontece com os dados do GA4 quando os usuários recusam cookies.

O template do Velo para o Tag Manager fica em Consent Initialization, então os padrões vêm primeiro seja qual for o endereço que serve o seu contêiner. Ativar o gateway passa a ser uma mudança de roteamento, seguida de uma rodada de testes.