Google Tag Gateway não substitui server-side Google Tag Manager. Isso muda a forma como os scripts e solicitações de medição compatíveis do Google chegam ao Google. sGTM recebe eventos em um contêiner de servidor que você controla e permite que clientes, gatilhos, variáveis e tags validem, transformem e roteem esses eventos. A linguagem original compartilhada faz com que os produtos pareçam intercambiáveis, mas suas funções são diferentes.
A resposta curta: a entrega não está sendo processada
Em uma configuração padrão de tag do Google, o navegador carrega um script de um domínio do Google e envia a medição diretamente para um produto do Google. Google Tag Gateway move scripts compatíveis e caminhos de solicitação para o domínio do seu site, com seu CDN, balanceador de carga ou servidor da web encaminhando o tráfego para o Google.
O GTM do lado do servidor adiciona um tempo de execução de processamento de eventos. As solicitações HTTP recebidas são reivindicadas por um cliente, convertidas em eventos e avaliadas pelo contêiner do servidor. Você decide quais tags serão executadas, quais campos sairão do servidor e quais destinos receberão o evento. Isso é muito mais amplo do que encaminhar o tráfego suportado pelo Google.
O que Google Tag Gateway pode e não pode fazer
GTG pode reduzir as interações de terceiros no navegador e recuperar alguns sinais que falham apenas porque um nome de host conhecido do Google está bloqueado. Também permite que o Google use cookies primários selecionados do Google na solicitação encaminhada; O Google diz que os cookies primários que não são do Google foram descartados.
Ele não cria eventos de comércio eletrônico ausentes, repara uma camada de dados fraca, valida receitas, enriquece um evento do seu CRM ou envia solicitações Meta CAPI e TikTok Events API. Também não elimina deveres de consentimento. A tag do Google ainda é executada no navegador, e as falhas do navegador, o estado de consentimento e os erros de implementação ainda são importantes.
O que server-side GTM adiciona
sGTM é útil quando o servidor precisa funcionar antes que um fornecedor receba um evento. Os exemplos incluem a remoção de parâmetros não aprovados, normalização de nomes de eventos, derivação de cargas específicas de destino, configuração de cookies de servidor, aplicação de lógica de consentimento e registro de respostas de saída para solução de problemas.
A compensação é a propriedade. Um contêiner de servidor precisa de hospedagem, configuração de produção e visualização, monitoramento, controle de acesso, revisão de modelos e alguém que possa diagnosticar o caminho completo. sGTM cria controle, não correção automática.
Por que o mito da substituição persiste
Ambos os produtos usam um endpoint original e ambos são descritos como melhorando a qualidade do sinal. No painel de um profissional de marketing, cada um pode parecer uma forma de tornar a medição do Google mais durável. A diferença arquitetônica está oculta por trás de uma linguagem de resultados semelhante.
Um teste útil é perguntar o que acontece depois que a solicitação chega ao seu domínio. Se o caminho simplesmente encaminhar uma solicitação compatível do Google para o Google, esse será um comportamento de gateway. Se o seu contêiner reivindicar a solicitação, criar um evento e decidir quais tags e destinos serão executados, isso será server-side GTM.
Qual você deve escolher?
Escolha GTG sozinho quando seu escopo for compatível principalmente com medição do Google, você já usa um CDN ou balanceador de carga compatível e não precisa de uma camada de dados compartilhada no lado do servidor. É o menor compromisso operacional.
Escolha sGTM quando precisar de APIs de conversão, transformações, minimização de dados, governança de eventos ou entradas de back-end que não sejam do Google. Se você já executa o sGTM, o Google orienta você a ativar o comportamento do gateway na configuração do servidor. Os produtos podem, portanto, ser complementares sem se tornarem dois canais de eventos concorrentes.
Um URL próprio não é prova de processamento no servidor
Inspecione a rota completa. Uma solicitação do navegador para seu próprio domínio ainda pode ser um proxy direto para o Google. Isso pode ser valioso, mas não é o mesmo que um evento sendo processado pelo contêiner do servidor.
Escolha a arquitetura certa em seis verificações
Utilize estas verificações antes de substituir uma configuração existente ou aprovar uma nova.
- 01
Liste todos os destinos
Inclui GA4, Google Ads, Floodlight, Meta, TikTok, LinkedIn, sistemas CRM e armazéns. GTG não é um roteador geral para esta lista.
- 02
Liste o processamento necessário
Marque todos os eventos que precisam de validação, enriquecimento, redação, alterações de nomenclatura, regras de consentimento ou desduplicação antes da entrega.
- 03
Desenhe os caminhos reais da solicitação
Mostre onde os scripts são carregados, onde chegam os eventos do navegador e do back-end, qual componente os processa e qual endpoint finalmente os recebe.
- 04
Atribuir um proprietário por evento
Para cada destino, defina se o navegador, caminho GTG ou tag sGTM envia o evento. Dois proprietários criam duplicatas.
- 05
Consentimento de teste e estados de falha
Teste consentimento concedido e negado, bloqueadores, cargas inválidas, IDs de transação duplicados e um destino upstream indisponível.
- 06
Reconcilie-se com a verdade da fonte
Compare conversões e receitas aceitas com registros de comércio eletrônico ou CRM. Uma solicitação de rede bem-sucedida não é prova de que os números estão corretos.
GTG é uma camada de entrega focada, não sGTM lite
Google Tag Gateway resolve um problema real, porém mais restrito: fornecer scripts e medições compatíveis do Google por meio de infraestrutura própria. O GTM do lado do servidor é um ambiente de processamento e roteamento de eventos. Um não elimina a necessidade do outro.
Comece com requisitos em vez de rótulos de produtos. Se a entrega primária do Google for o requisito, GTG pode ser suficiente. Se o requisito for controlado, medição do lado do servidor de vários destinos, você ainda precisará do sGTM ou de outra camada de processamento.
Google Tag Gateway vs sGTM: perguntas comuns
O Google Tag Gateway substitui o server-side GTM?
Não. GTG encaminha tags e solicitações do Google compatíveis por meio de infraestrutura própria. sGTM processa eventos em um contêiner de servidor programável e pode roteá-los para diversas plataformas.
O Google Tag Gateway é rastreado no lado do servidor?
Ele usa a infraestrutura do servidor como gateway, mas um evento do navegador não é processado em seu próprio contêiner programável. Chamá-lo de substituto do server-side GTM é, portanto, enganoso.
GTG pode enviar eventos para Meta ou TikTok?
Não. GTG concentra-se em tags e destinos suportados pelo Google. Use sGTM ou outra integração do lado do servidor para APIs de conversão que não sejam do Google.
GTG elimina a necessidade de consentimento?
Não. Uma rota primária não altera a finalidade do processamento ou a escolha do usuário. Configure e teste o comportamento de consentimento para cada região onde você opera.
Posso usar GTG e sGTM juntos?
Sim. O Google documenta uma configuração combinada na qual a veiculação de scripts primários e o caminho de coleta sGTM têm responsabilidades separadas.