Nos últimos meses, o Google Tag Gateway (também chamado de GTG) deixou de ser um assunto de nicho e passou a ser uma das perguntas mais frequentes no universo do traqueamento. O Google começou a promovê-lo ativamente, e a demanda por tracking first-party nunca foi tão alta.
Mas o que exatamente é o GTG? É um substituto do GTM Server Side? Vale a pena implementar? Neste artigo, vamos responder essas perguntas de forma clara e direta, começando pelos conceitos básicos e chegando a um framework prático para você decidir o que usar em cada situação.
Primeiro: o que é traqueamento client-side e por que ele tem limitações?
Todo setup de análise começa com o rastreamento client-side. Na prática, isso significa instalar o GA4 no seu site via GTM ou diretamente via integração da plataforma. Em ambos os casos, os scripts rodam no navegador do visitante e as requisições são enviadas para domínios do Google, como:
- www.googletagmanager.com (script do GTM)
- www.google-analytics.com (eventos do GA4)
- googleads.g.doubleclick.net (conversões do Google Ads)
O ponto importante é que esses são domínios do Google, não do seu site. Do ponto de vista do navegador do visitante, essas são requisições third-party, ou seja, de terceiros.
E requisições third-party têm um problema crescente: elas são bloqueadas. Por extensões de AdBlock, por políticas de privacidade do Safari (ITP) e por uma série de outras restrições que vêm sendo implementadas pelos navegadores modernos.
Enquanto o volume de tráfego é baixo e o orçamento de mídia é pequeno, essa perda de dados é tolerável. Mas à medida que os investimentos crescem, a diferença entre “o que disparou” e “o que foi realmente registrado” começa a pesar, e é aí que o rastreamento first-party entra na conversa.
O que é um Gateway? Entendendo o conceito com uma analogia
Antes de falar do GTG especificamente, é importante entender o que é um gateway em termos técnicos.
Um gateway é um reverse proxy: ele fica entre o seu visitante e o endpoint do fornecedor, e re-encaminha a requisição como se ela tivesse vindo do seu próprio domínio. O conteúdo da requisição não muda em nada, apenas o hostname, ou seja, o endereço de onde a requisição parece estar vindo.
Para tornar isso mais concreto, imagine a seguinte situação:
Um professor pede pizza para a sala e o entregador chega à escola. A escola não permite que o entregador circule pelos corredores porque ele é um terceiro, sem credencial interna. Então, o entregador leva a pizza até a secretaria, e a funcionária da escola, que tem acesso a todos os corredores, leva a pizza até a sala.
A pizza que chega à sala é exatamente a mesma que o entregador trouxe. Mesma caixa, mesmo sabor, ainda quente. O que mudou foi apenas quem a carregou pelo corredor: em vez de um terceiro desconhecido, foi alguém credenciado pela própria escola.
Isso é um gateway. O conteúdo da requisição não muda. Apenas o hostname muda, de um domínio de terceiro para o seu próprio domínio. Para o navegador do visitante, a requisição parece ter vindo do seu site, e não do Google, o que evita que ela seja bloqueada.
Gateways são amplamente usados hoje. O Meta tem o Conversions API Gateway, o TikTok tem o Events API Gateway, e o Google tem o Google Tag Gateway. Todos resolvem o mesmo problema fundamental: os scripts de terceiros estão sendo bloqueados e os dados se perdem no caminho.
O que é o Google Tag Gateway?
Segundo a própria definição do Google:
“O Google Tag Gateway permite que você implante uma Google Tag ou um container GTM usando seu próprio domínio, melhorando a privacidade de dados e recuperando a medição de sinais.”
Em termos práticos, o GTG é um reverse proxy que substitui o hostname das requisições do GA4 e do Google Ads, trocando os domínios do Google pelo domínio do seu site. O conteúdo das requisições, como eventos, parâmetros, cookies e estado de consentimento, permanece exatamente o mesmo.
Antes de avançar, três pontos fundamentais precisam ficar claros:
GTG é exclusivo para o ecossistema Google. Ele foi desenvolvido para re-encaminhar apenas scripts do Google, como GA4 e Google Ads. Meta Pixel, LinkedIn Insight, TikTok e qualquer outro rastreador de terceiros continuam sendo requisições third-party e não são afetados pelo GTG.
Os cookies continuam sendo JavaScript cookies. O GTG não muda como os cookies são escritos. O script do GA4 ainda roda no navegador e os cookies ainda são gravados via JavaScript. Isso significa que as limitações do Safari ITP, incluindo o limite de 7 dias para cookies JavaScript, continuam valendo normalmente.
O GTG não transforma nem remove dados. Ele apenas ajusta o header da requisição. O corpo da requisição, ou seja, os dados que você está enviando, permanece exatamente o mesmo. Se você precisa enriquecer, filtrar ou transformar dados antes de enviá-los, o GTG por si só não resolve isso.
As três formas de implementar o Google Tag Gateway
O Google documenta três opções de implementação do GTG. Na prática, cada opção constrói sobre a anterior, como camadas de uma mesma estrutura, e não como alternativas independentes.
Opção 1: Tornar as requisições do GA4 e Google Ads first-party
Esta é a implementação mais simples e o ponto de entrada para quem quer migrar o rastreamento Google para first-party rapidamente.
Com apenas alguns cliques em um CDN compatível como o Cloudflare, as requisições de coleta do GA4 e as conversões do Google Ads passam a ser enviadas pelo seu domínio em vez dos domínios do Google. A diferença é visível diretamente no DevTools do navegador: em vez de google-analytics.com, a requisição aparece com o seu próprio domínio.
O que muda: as requisições de dados do GA4 e do Google Ads passam de third-party para first-party. Elas deixam de ser bloqueadas por AdBlockers que filtram domínios do Google.
O que não muda: o script do container GTM ainda carrega a partir de googletagmanager.com, ou seja, ainda é uma requisição third-party. E qualquer outra plataforma como Meta, TikTok e LinkedIn continua sendo third-party.
Opção 2: Mover o container GTM para first-party
A Opção 2 resolve o que ficou pendente na Opção 1. Usando um container server-side (sGTM), você configura o container web do GTM para carregar a partir do seu próprio domínio em vez de googletagmanager.com.
Pense assim: na Opção 1, os dados que saem do GA4 já viajam pelo seu domínio. Mas o próprio script que carrega o GTM ainda vem de um domínio do Google. A Opção 2 resolve isso movendo também esse script para first-party.
O que muda: o script gtm.js passa a carregar do seu domínio. Com isso, GTM, GA4 e Google Ads estão todos em first-party do ponto de vista do navegador do visitante.
O que não muda: Meta Pixel, TikTok, LinkedIn e qualquer outro rastreador não-Google continuam sendo third-party.
Opção 3: GTG com CDN e sGTM (recomendação do Google)
Esta é a implementação mais completa e a que o Google recomenda oficialmente. Aqui, em vez dos dados fluírem diretamente pelo CDN até o Google, eles passam pelo container server-side primeiro.
Isso muda tudo do ponto de vista do controle sobre os dados. Até a Opção 2, os dados saíam do navegador do visitante e iam direto para o Google, sem passar por nenhuma camada de processamento. Na Opção 3, esses dados chegam primeiro ao seu servidor, onde você pode transformá-los, enriquecê-los ou filtrá-los antes de qualquer envio.
O que muda: os eventos agora fluem pelo sGTM, onde podem ser processados antes de serem enviados para qualquer plataforma downstream. Essa configuração também abre a possibilidade de mover tags não-Google como Meta CAPI e TikTok para first-party, desde que essas tags sejam configuradas dentro do container server-side.
O que não muda: o script GTM ainda é servido pelo servidor sGTM e as chamadas de configuração do GA4 ainda passam pelo CDN.
Google Tag Gateway vs GTM Server Side: qual a diferença?
Essa é a dúvida mais comum depois de entender o que o GTG faz. E a resposta direta é: eles não são produtos concorrentes, são ferramentas com propósitos diferentes.
O Google Tag Gateway resolve um problema de transporte: ele garante que a requisição chegue ao seu destino sem ser bloqueada no caminho, trocando o hostname de third-party para first-party. O conteúdo não muda, apenas o caminho.
O GTM Server Side resolve um problema de controle: ele coloca você no meio da equação, permitindo que você decida o que fazer com os dados antes de enviá-los para qualquer plataforma.
Para ficar mais claro, veja a comparação:
| Google Tag Gateway | GTM Server Side | |
| O que é | Um reverse proxy que torna o header das requisições first-party | Um servidor que processa e distribui dados antes de enviá-los às plataformas |
| O que muda | Apenas o hostname das requisições | Os próprios dados, que podem ser transformados, enriquecidos e filtrados |
| Para quem envia | Apenas Google (GA4, Google Ads, GTM) | Qualquer plataforma: Meta CAPI, TikTok, LinkedIn, BigQuery, CRM e muito mais |
| Complexidade | Baixa, alguns cliques com CDN compatível na Opção 1 | Média, requer servidor, container e configuração contínua de tags |
| Custo | Gratuito, apenas o custo do CDN se houver | Custo de hospedagem do servidor via Stape, Google Cloud e outros |
Em resumo: o GTG é uma vitória rápida para o rastreamento Google. O Server Side é controle real sobre todos os dados de todas as plataformas.
Quando usar cada um: um guia prático de decisão
A decisão entre client-side, Google Tag Gateway e server-side não é feita uma única vez. Ela deve ser revisitada à medida que o negócio cresce e as necessidades evoluem.
Use client-side tracking quando o volume de tráfego é baixo, o orçamento de mídia ainda é pequeno e a perda de dados por bloqueadores não representa um impacto relevante nos resultados.
Use o Google Tag Gateway quando você quer um resultado rápido para rastreamento Google-only, sem precisar configurar um servidor. Em poucos cliques, suas requisições de GA4 e Google Ads já se tornam first-party, com custo praticamente zero e baixíssima complexidade de implementação.
Use o GTM Server Side quando você precisa de controle total sobre os dados, quer enviar eventos para múltiplas plataformas em first-party, precisa transformar ou enriquecer dados antes do envio, ou quer integrar com backend, CRM ou webhooks.
Um ponto importante: se o seu objetivo final é o controle total dos dados em todas as plataformas, a Opção 3 do GTG acaba sendo quase tão trabalhosa quanto implementar server-side diretamente, porque você estará configurando boa parte da mesma infraestrutura de qualquer forma. Nesse caso, vale considerar ir direto para o server-side desde o início e não dividir o esforço em etapas.
Conclusão
O Google Tag Gateway é uma excelente vitória rápida para quem quer migrar o rastreamento Google para first-party com o mínimo de esforço e custo.
Mas se o objetivo é controle real sobre os dados, capacidade de enriquecer eventos, integrar com múltiplas plataformas e tomar decisões com base em dados confiáveis e completos, o caminho é o GTM Server Side. E quanto mais cedo essa estrutura for construída, mais rápido os resultados aparecem.
Também siga o Mundo do Traqueamento em outras redes sociais:
Inscreva-se no https://www.youtube.com/channel/UC6mX6bbcEmQoaznI0D7Aw5Q
Siga e curta no https://www.instagram.com/mundodotraqueamento/
Siga e comente no https://twitter.com/traqueamento
Siga também no https://www.linkedin.com/company/mundo-do-traqueamento
