Google Tag Gateway: o que é, por que e quando usar

Nos últimos meses, o Google Tag Gateway (também chamado de GTG) passou de um lançamento discreto a um tema frequente de discussão. Acredito que isso aconteça porque o Google começou a promovê-lo durante as reuniões e porque a demanda por rastreamento de primeira parte aumentou.

Sou Manisha Mistry, Technical Lead da MeasureU. Gosto de ensinar temas como rastreamento do lado do servidor, o que fez com que eu recebesse cada vez mais perguntas sobre o Google Tag Gateway. Especificamente, nos últimos meses, fizeram-me repetidamente as quatro perguntas a seguir.

• O que é o Google Tag Gateway?
• Devo usá-lo?
• Qual é a diferença em relação ao rastreamento do lado do servidor?
• Preciso dele se já uso rastreamento do lado do servidor?

Meu objetivo neste artigo é responder às quatro perguntas. Como sempre, começarei pelo básico e depois explicarei em detalhes como o Google Tag Gateway funciona e como ele difere do rastreamento do lado do servidor. Para finalizar, apresentarei um framework de decisão ao qual você poderá voltar de tempos em tempos para decidir qual solução de rastreamento funciona melhor para você e seu cliente.

Uma observação rápida antes de começarmos: este artigo foi escrito com base na minha própria configuração e nos testes do GTG realizados no momento da redação. O Google está sempre evoluindo o GTM, o GTG, o sGTM e o ecossistema de tagueamento como um todo, portanto, alguns elementos podem mudar com o tempo à medida que o Google aprimora o produto. Os conceitos fundamentais permanecerão; os caminhos, as opções e as telas exatos podem mudar.

Toda configuração de Analytics começa com o rastreamento do lado do cliente.

Normalmente, isso envolve instalar o GA4 no seu site, usando o Google Tag Manager (minha opção preferida) ou uma integração com o site. Em ambos os casos, os scripts são executados no navegador do visitante, e os domínios desses scripts geralmente pertencem ao Google.

Por exemplo, eles podem ser algo como...

• www.googletagmanager.com (para o script do contêiner GTM)
• www.google-analytics.com (para eventos de coleta do GA4)
• googleads.g.doubleclick.net (para conversões do Google Ads)

O ponto principal é que os hostnames são domínios do Google, e não o domínio do seu site. Do ponto de vista do navegador do visitante, isso torna essas solicitações de terceiros, e não solicitações de primeira parte.

As solicitações de terceiros não são um problema até que você comece a perder dados por causa de bloqueadores de anúncios, do Safari Intelligent Tracking Prevention (ITP) e de tudo o mais que as bloqueie.

Quando você está apenas começando sua jornada de rastreamento ou tem um site com pouco tráfego e baixo investimento, o rastreamento do lado do cliente é um ótimo ponto de partida e pode continuar sendo suficiente. No entanto, à medida que o tráfego aumenta e os orçamentos de marketing crescem, você (ou seu cliente) começa a se preocupar de verdade com a diferença entre “o que foi acionado” e “o que foi realmente registrado”. É aí que o rastreamento de primeira parte entra em cena.

Antes de entrarmos especificamente no Google Tag Gateway, vamos parar um momento para entender o que é um gateway e como ele funciona.

A definição técnica de um gateway é um reverse proxy. Ele fica entre seus visitantes e o endpoint de um fornecedor e reapresenta a solicitação como se ela viesse do seu domínio. O conteúdo da solicitação não muda NADA; apenas o carrier, que é o hostname, muda.

Os gateways estão por toda parte hoje. Por exemplo, a Meta tem o Conversions API Gateway, o TikTok tem o Events API Gateway, e muitas outras plataformas também estão criando gateways. Eles são populares porque todos os fornecedores enfrentam o mesmo problema: o script é executado no navegador, é bloqueado e perdemos sinais. Configurar um gateway é a maneira mais rápida de transformar as solicitações de terceiros em solicitações de primeira parte.

Como sempre, gosto de analogias. Para me ajudar a entender os gateways e explicá-los aos clientes, uso uma analogia que parece funcionar muito bem.

Todos nós frequentamos a escola em algum momento da vida ou temos filhos que estudam atualmente. Às vezes, para comemorar alguma coisa, um professor pedia uma pizza para a turma e mandava entregá-la na escola.

Onde moro, as escolas não deixam um entregador entrar pela porta da frente, andar pelo corredor e ir direto até uma sala de aula. Isso acontece porque o entregador é um terceiro para a escola. Ele não passou por uma verificação de antecedentes e não tem uma identificação da escola.

A função da escola é manter terceiros como esse entregador fora dos corredores durante o dia para manter os alunos seguros.

Em vez disso, o entregador não leva a pizza diretamente para a sala. Ele vai até a escola, entra na recepção, entrega a pizza a um funcionário da administração e, então, esse funcionário leva a pizza pelo restante do caminho até a sala de aula.

A pizza que chega à sala de aula é exatamente a mesma pizza que o entregador levou à escola. Continua sendo uma pizza de pepperoni, ainda está quente e continua na mesma caixa. O que mudou foi a pessoa que carrega a pizza pelo corredor. Em vez de ser carregada por um entregador terceiro, ela é carregada por um funcionário da escola, que passou por todas as verificações de antecedentes necessárias e tem permissão para circular pelos corredores. A turma recebe exatamente a mesma pizza, mas, do ponto de vista da escola, a entrega é completamente diferente.

Em termos simples, isso é um gateway.

O conteúdo da solicitação não mudou. Ainda era uma pizza, mas a pessoa que a carregava mudou. Todos que viram a pizza passando pelo corredor não tiveram problema com isso, porque o funcionário da escola fazia parte da escola. Ele trabalhava lá e estava autorizado a estar ali.

Por outro lado, se o entregador tivesse caminhado pela escola, isso seria um problema. Muito provavelmente ele seria impedido de entrar ou parado em algum ponto do caminho, porque não tem permissão para entrar na escola.

Agora que entendemos o que é um gateway, vamos entrar no Google Tag Gateway (GTG).

Esta é a definição do próprio Google, diretamente da página de ajuda:

Em termos simples, o GTG é um reverse proxy que altera o hostname das suas solicitações do GA4 e do Google Ads, substituindo os domínios do Google pelo domínio do seu site. O conteúdo das solicitações, como eventos, parâmetros, cookies e o estado do consentimento, não muda; apenas o carrier muda. Pense novamente na analogia da pizza: a pizza permaneceu igual, apenas o transportador mudou.

Antes de aprofundarmos o GTG, há alguns detalhes importantes que você precisa conhecer...

• O GTG é exclusivo do Google - o GTG foi desenvolvido apenas para reapresentar scripts do Google, como GA4 e Google Ads. Isso significa que o Meta Pixel, o LinkedIn Insight e quaisquer outras solicitações continuarão sendo solicitações de terceiros.
• Os cookies continuam sendo cookies JavaScript - o GTG não altera a forma como os cookies são definidos. O navegador continua executando o script do cliente GA4 e os cookies continuam sendo gravados via JavaScript. Portanto, você ainda pode ficar limitado pelo limite de 7 dias do Safari ITP para cookies JavaScript.
• O GTG, por si só, não transforma nem remove dados - o GTG não permite ajustar ou modificar dados na própria solicitação. Ele apenas ajusta o cabeçalho; o corpo da solicitação (o conteúdo da solicitação) permanece exatamente igual.

É fundamental entender esses três detalhes ao considerar Google Tag Gateway vs rastreamento do lado do servidor.

A página de documentação do Google apresenta três opções de implementação do GTG. Cada uma move uma parte diferente do seu rastreamento de terceiros para primeira parte e tem seu próprio nível de complexidade. Configurei as três no meu próprio site de demonstração, datadrivenuniversity.com, para que, em cada opção, você veja uma imagem real de antes e depois mostrando como o rastreamento mudou.

Quero destacar uma coisa antes de entrarmos nas opções. O Google apresenta essas possibilidades como três opções separadas, mas, depois de configurar cada uma, não penso nelas dessa forma. Em vez disso, considero que cada opção se baseia na anterior. Esta é minha opinião pessoal, baseada na minha experiência. Dito isso, vamos analisar cada opção.

Esta é a versão mais simples do GTG, pois você não precisa alterar sua configuração atual e tudo leva apenas alguns cliques.

O que muda: as coletas do GA4 e as conversões do Google Ads são disparadas usando your-domain.com em vez de google-analytics.com / googleads.g.doubleclick.net. Elas se tornam solicitações de primeira parte.

O que não muda: o próprio script do contêiner GTM continua sendo carregado de googletagmanager.com. Confirmei isso na minha própria configuração. O conteúdo das suas solicitações do GA4 e do GAds também permanece exatamente igual.

Para mostrar isso na prática, configurei o Google Tag Gateway com Cloudflare no meu site de teste datadrivenuniversity.com. Abaixo está a aparência das minhas solicitações do GA4 antes de eu ativar o Google Tag Gateway.

Depois, configurei o GTG usando Cloudflare e GTM. Toda a configuração levou cerca de três cliques. Depois disso, você pode ver que o mesmo hit do GA4 agora chega pelo meu próprio domínio datadrivenuniversity.com/bppc.

Nota: você verá que os hits do GA4 agora começam com c? em vez de collect?; isso acontece por causa do GTG.

Com essa implementação, movi minhas solicitações do GA4 de terceiros para solicitações de primeira parte. Agora elas passam por datadrivenuniversity.com/bppc em vez de google-analytics.com. O mesmo se aplica às minhas conversões do Google Ads, que passam de googleads.g.doubleclick.net para o mesmo caminho de primeira parte.

Ao testar a Opção 1, percebi que minhas solicitações do Google Ads e do GA4 passaram para primeira parte, mas o script do meu contêiner do Google Tag Manager ainda era carregado de googletagmanager.com. O GTM ainda era uma solicitação de terceiros, e é aqui que entra a Opção 2. A comparação Google Tag Gateway vs Google Tag Manager se torna relevante neste ponto.

O que muda: gtm.js agora é carregado do seu próprio domínio, por exemplo, datadrivenuniversity.com/metrics/custom-path, em vez de googletagmanager.com. Agora, GTM, GA4 e Google Ads são todos hits de primeira parte do ponto de vista do navegador do visitante.

Configurei isso com um contêiner sGTM, usando um Google Tag Manager: web container client que me permite carregar o contêiner GTM da web a partir do contêiner do servidor e definir um caminho personalizado. Existem outras maneiras de tornar o GTM de primeira parte, mas o sGTM foi o caminho que testei.

O que não muda: seus hits que não são do Google, como Meta Pixel, TikTok Pixel, LinkedIn Insight e qualquer outra tag que não seja do Google, continuam sendo solicitações de terceiros.

Para mostrar isso na prática, veja como o script do meu contêiner GTM da web aparecia no DevTools antes de eu adicionar o contêiner sGTM e fazer com que ele carregasse meu contêiner da web.

Depois de criar um servidor e configurar o contêiner sGTM, onde configurei um cliente e especifiquei o caminho de veiculação das tags, esta é a aparência da solicitação agora, usando meu domínio e o caminho personalizado.

Neste ponto, minhas solicitações do GA4 e do Google Ads chegam pelo Cloudflare como primeira parte, e meu contêiner sGTM também carrega meu contêiner GTM da web a partir de um domínio de primeira parte. Todas as outras plataformas continuam sendo de terceiros.

A Opção 3 é a implementação do GTG recomendada pelo Google e, na verdade, foi a mais confusa de configurar e entender. Ela também mudou minha visão sobre Google Tag Gateway do lado do servidor em comparação com o rastreamento do lado do servidor, mas vou deixar essa conclusão para o final, para que faça mais sentido depois que você tiver visto toda a configuração.

Um rápido resumo de onde estamos:

• Na Opção 1, movemos nossas solicitações do GA4/Google Ads de terceiros para primeira parte por meio do gateway (por exemplo, Cloudflare). Isso significa que as solicitações tanto dos scripts do GA4/GAds (somente Google) quanto da coleta de dados passaram para primeira parte.
• Na Opção 2, movemos o script do nosso contêiner GTM de terceiros para primeira parte por meio de um contêiner do servidor; nossa coleta de dados para rastreamento somente do Google continuou usando o gateway.
• Na Opção 3, nossos scripts continuam sendo carregados exatamente da mesma maneira (scripts do GA4 pelo gateway, GTM pelo contêiner sGTM). O que muda é que a coleta de dados passa pelo servidor, permitindo transformá-la antes de enviá-la para os sistemas de destino.

O que muda: em vez de nossos dados de eventos passarem pelo CDN como hits de primeira parte enviados diretamente ao Google, os dados agora passam pelo nosso contêiner sGTM. O contêiner sGTM recebe os eventos e, a partir daí, podemos transformar, enriquecer ou remover dados antes que sejam enviados para qualquer sistema de destino. Na prática, o rastreamento do lado do servidor funciona em paralelo ao GTG. Estamos usando os dois ao mesmo tempo.

Essa configuração também abre a possibilidade de mover tags que não são do Google, como Facebook, LinkedIn e TikTok, para primeira parte. No entanto, isso exigiria configurar essas tags no nosso contêiner sGTM e realizar uma implementação completa do rastreamento do lado do servidor. Depois de concluirmos essa configuração no contêiner sGTM, esses hits também passam pelo servidor e se tornam hits de primeira parte.

O que não muda: nosso script do contêiner GTM continua sendo servido pelo nosso servidor sGTM (trazido da Opção 2). As chamadas de configuração do GA4 continuam sendo servidas pelo nosso CDN (trazidas da Opção 1).

Para mostrar isso na prática, veja como estavam meus hits de coleta do GA4 na Opção 2, passando pelo meu caminho do Cloudflare.

Depois de definir a URL do contêiner do servidor na tag de configuração do meu contêiner GTM da web e configurar um cliente e uma tag do GA4 no meu contêiner sGTM, minhas coletas agora passam pelo servidor sGTM.

Com essa implementação, a coleta de dados dos meus eventos do GA4 agora passa pelo meu contêiner sGTM, onde posso direcionar, enriquecer ou remover os dados antes que sejam enviados para qualquer sistema de destino. O mesmo pode ser aplicado a qualquer outra plataforma, incluindo plataformas que não sejam do Google, desde que eu configure as tags e os acionadores necessários no meu contêiner da web/servidor.

Agora que entendemos o que é o Google Tag Gateway e as três maneiras de implementá-lo, a próxima pergunta natural que sempre recebo é: qual é a diferença entre o Google Tag Gateway e o rastreamento do lado do servidor?

Na minha opinião, eles não são produtos concorrentes.

O Google Tag Gateway, especificamente a Opção 1, trata de encaminhar seus eventos para que eles passem de terceiros para primeira parte no nível do cabeçalho da solicitação. O rastreamento do lado do servidor trata de controle: ter mais controle sobre seus dados e, como resultado, migrar para o rastreamento de primeira parte. Isso pode ser visto na própria documentação do Google: na Opção 3 descrita acima, para ter mais controle sobre seus dados, é necessário introduzir um contêiner do servidor e encaminhar seus eventos por esse contêiner.

Para ajudar a explicar a diferença entre os dois, veja uma tabela rápida de comparação:

Resumindo, o Google Tag Gateway e o rastreamento do lado do servidor não são produtos concorrentes. Um leva você rapidamente ao rastreamento de primeira parte, puramente do ponto de vista da solicitação. O outro oferece controle total sobre seus dados. Você pode começar com um e migrar para o outro conforme suas necessidades mudarem, e é exatamente aí que entra o framework de decisão.

Ao avaliar Google Tag Gateway vs lado do servidor, decidir entre o Google Tag Gateway, o rastreamento do lado do servidor ou até mesmo permanecer no rastreamento do lado do cliente é uma das perguntas mais comuns que recebo, tanto na MeasureU quanto na comunidade do LinkedIn. Também é uma das primeiras coisas que os clientes perguntam quando começamos o trabalho de implementação. Por isso, criei um framework de decisão para ajudar nessa escolha.

O ponto principal é que esse framework não foi criado para ser usado uma única vez. Você passa por ele uma vez e depois volta a ele repetidamente à medida que sua jornada de mensuração continua. Você pode começar com o rastreamento do lado do cliente, migrar para o GTG e, mais tarde, passar para o rastreamento do lado do servidor conforme suas necessidades mudarem.

Passe pelo framework hoje e descubra em que ponto da sua jornada você está. Depois, após algumas semanas ou meses de trabalho, volte a ele e faça o processo novamente. Use-o como um guia para saber quando aprimorar sua mensuração, seja para o seu site ou para o site do seu cliente.

Na minha opinião, depois de experimentar e testar o Google Tag Gateway, ele é uma ótima solução rápida para rastreamento exclusivamente do Google. Se você fizer apenas a Opção 1, em cerca de três cliques suas solicitações do GA4 e do Google Ads passam de terceiros para primeira parte.

Dito isso, como vimos na própria documentação do Google, no momento em que você quiser mais controle sobre seus dados, precisará passar para a Opção 3. Isso significa configurar um servidor e um contêiner do servidor e, em seguida, encaminhar sua coleta de dados pelo contêiner sGTM. Cada organização tem sua própria stack de mensuração, um nível de tráfego diferente e requisitos específicos para o controle dos dados. É exatamente para isso que serve o framework de decisão, e é por isso que o criei para ser usado mais de uma vez.

Como alguém que fez as duas coisas, posso dizer: o Google Tag Gateway, especificamente a Opção 1, é uma ótima solução rápida para rastreamento exclusivamente do Google. Dito isso, na minha opinião, se você realmente quer controlar seus dados em todas as plataformas, a Opção 3 dá mais trabalho do que simplesmente fazer o rastreamento do lado do servidor desde o início, porque você acabaria fazendo a maior parte desse trabalho de qualquer forma. Se esse for o seu objetivo, recomendo começar diretamente com o rastreamento do lado do servidor. Você pode configurar seu próprio servidor e contêiner aqui.