Se você já usa o server-side GTM, não crie um segundo pipeline de medição concorrente do Google apenas para adicionar o Google Tag Gateway. O padrão combinado recomendado pelo Google separa dois caminhos de mesma origem: um caminho de script encaminha solicitações gtm.js ou gtag.js ao Google, enquanto um caminho de coleta encaminha eventos de medição para seu servidor de tags. O contêiner do servidor continua sendo o local onde os eventos são processados e roteados.
A arquitetura combinada
Uma configuração de mesma origem pode usar caminhos como www.example.com/scripts para carregamento de scripts primários do Google e www.example.com/metrics para o contêiner do servidor. O CDN ou balanceador de carga roteia cada prefixo para uma origem diferente. O Google avisa que ambos os caminhos não devem ser utilizados e não devem conter /gtm.
O navegador carrega o contêiner da web ou a tag do Google por meio do caminho do script. A tag do Google é então configurada para enviar medições ao caminho de coleta. O cliente sGTM reivindica essa solicitação, produz um evento e aciona as tags de servidor apropriadas.
Ao executar ambos é útil
A combinação é útil quando você deseja os benefícios de resiliência do navegador do carregamento de scripts primários e também precisa de transformações, minimização de dados, destinos que não sejam do Google ou observabilidade do sGTM. O Google recomenda explicitamente o carregamento de scripts primários junto com a marcação do lado do servidor para uma configuração durável.
É menos útil quando GTG duplicaria apenas a funcionalidade já fornecida por um carregador sGTM primário e uma rota de coleta corretamente configurados. Audite os caminhos atuais antes de adicionar outra regra. A arquitetura deve ficar mais clara após a mudança e não apenas conter mais produtos.
A armadilha de eventos duplicados
O padrão perigoso é enviar a mesma conversão do Google diretamente por meio de um caminho de encaminhamento GTG e também enviá-la por meio de sGTM, onde uma tag do servidor a envia novamente. Ambas as solicitações de rede podem ser bem-sucedidas, deixando conversões infladas que parecem uma recuperação aprimorada.
Defina um proprietário de entrega para cada evento e destino. IDs de transação ou eventos estáveis ainda são úteis, mas a desduplicação deve ser um mecanismo de segurança, não a arquitetura primária. Visualize os contêineres do navegador e do servidor juntos e conte as solicitações de destino de saída.
A mesma origem é melhor do que um subdomínio de rastreamento aleatório
O Google documenta a mesma origem servindo como prática recomendada para segurança e durabilidade de cookies definidos pelo servidor. Um caminho no host do site, como www.example.com/metrics, tem a mesma origem. Um subdomínio como métricas.example.com é primário, mas não tem a mesma origem.
O roteamento da mesma origem normalmente requer um CDN ou balanceador de carga e precedência de caminho cuidadosa. Encaminhe todos os cookies e strings de consulta exigidos pelo servidor de marcação, roteie cada caminho do cliente, incluindo o subcaminho /_/* documentado, e verifique o endpoint de integridade antes de alterar as tags de produção.
O consentimento e a privacidade ainda controlam o fluxo
A veiculação primária é uma decisão de transporte, não uma permissão. Inicialize os padrões de consentimento antes da medição, passe o estado de consentimento para a solicitação de coleta e configure as tags do servidor para que o armazenamento negado ou as opções de publicidade sejam tratadas conforme planejado.
Minimize os dados no limite do servidor. Revise quais cookies, cabeçalhos, parâmetros de consulta e campos de evento entram no contêiner do servidor e permita apenas os campos que cada destino precisa. GTG descarta cookies primários que não são do Google em seu próprio caminho de encaminhamento, mas seu caminho de coleta sGTM tem suas próprias responsabilidades de tratamento de dados.
Uma regra de decisão clara
Se você não possui sGTM e precisa apenas de medição compatível do Google, apenas GTG pode ser suficiente. Se você tiver sGTM, ative o script primário do Google que serve como parte dessa arquitetura e mantenha a coleta de medidas apontada para o contêiner do servidor.
Se duas equipes possuírem GTG e sGTM, publique um mapa de rotas e uma matriz de propriedade de eventos antes do lançamento. Uma regra CDN, configuração de contêiner da web e tag de servidor podem mudar para onde vai o mesmo evento; a sobreposição não documentada é a fonte habitual de duplicação.
Use dois caminhos, não dois proprietários de medição
O caminho do script e o caminho da coleção são intencionalmente diferentes. O caminho do script carrega o código original do Google; o caminho de coleta envia eventos para sGTM. Não deixe que ambos os caminhos entreguem a mesma conversão de forma independente.
Configurar GTG com server-side GTM
Os menus exatos variam de acordo com o CDN, mas as responsabilidades e a sequência de validação permanecem as mesmas.
- 01
Confirme se o contêiner do servidor está pronto para produção
Use uma implantação de marcação de produção, um servidor de visualização funcional, controles de acesso, monitoramento e um domínio personalizado antes de alterar a rota do navegador.
- 02
Reserve dois caminhos de mesma origem não utilizados
Escolha um caminho de script, como /scripts, e um caminho de coleção, como /metrics. Nenhum dos caminhos pode entrar em conflito com o site ou conter /gtm.
- 03
Roteie o caminho de coleta para sGTM
Configure o CDN ou o balanceador de carga para encaminhar o prefixo completo da coleção, os cookies e as strings de consulta para o servidor de marcação, incluindo os caminhos exigidos pelos clientes do servidor.
- 04
Adicione o URL da coleção nas configurações do contêiner do servidor
Defina o URL do contêiner do servidor para o URL de mesma origem, incluindo seu prefixo de caminho, e confirme se o cliente esperado reivindica uma solicitação de visualização.
- 05
Roteie o caminho do script para GTG
Encaminhe o prefixo do script reservado para a origem do gateway do Google e atualize a origem gtm.js ou gtag.js para carregar por meio desse caminho.
- 06
Aponte os eventos do Google para o caminho da coleta
Defina server_container_url ou a configuração equivalente da tag do Google para o endpoint /metrics para que a medição entre em sGTM em vez de ir diretamente para o mesmo destino duas vezes.
- 07
Configurar clientes, tags e consentimento
Verifique a prioridade do cliente, as transformações de eventos, as verificações de consentimento, as tags de destino e os identificadores de eventos estáveis dentro do contêiner do servidor.
- 08
Teste a rota completa
Confirme se o script é carregado de /scripts, uma solicitação chega a /metrics, o cliente servidor a reivindica e sai exatamente uma solicitação esperada para cada destino.
- 09
Monitorar após o lançamento
Alerte sobre falhas de integridade e volumes incomuns, revise diagnósticos de destino e reconcilie compras ou leads com a verdade do sistema de origem.
Execute camadas complementares, não pipelines paralelos
GTG e sGTM funcionam bem juntos quando o gateway lida com a entrega de scripts primários e sGTM possui o processamento de eventos. O padrão de dois caminhos torna esse limite visível e testável.
A configuração falha quando a mesma conversão tem dois proprietários de delivery. Documente caminhos, preserve a identidade de um evento, teste estados de consentimento e conte as solicitações que realmente saem do servidor.
GTG mais sGTM: perguntas comuns
Toda configuração do sGTM também deve usar o Google Tag Gateway?
A veiculação de scripts primários é recomendada pelo Google, mas primeiro audite seu carregador e rotas existentes. Algumas configurações do sGTM já atendem a dependências primárias e podem precisar apenas de uma atualização de configuração.
GTG e sGTM podem usar o mesmo caminho?
O padrão CDN do Google usa caminhos separados: um para scripts e outro para coleta de eventos. Rotas separadas evitam conflitos de origem e deixam claras as responsabilidades.
Como evito conversões duplicadas do Google?
Escolha um remetente para cada conversão. Se sGTM enviar a solicitação de destino do Google, não envie também uma solicitação direta equivalente ao navegador. Verifique as contagens de solicitações de saída nos diagnósticos de visualização e destino.
Um subdomínio é o mesmo que veiculação da mesma origem?
Não. Um subdomínio é primário, mas mesma origem significa o mesmo esquema, nome de host e porta do site. O Google lista ambos como compatíveis com cookies definidos pelo servidor, mas considera a mesma origem a prática recomendada.
Qual caminho deve enviar eventos Meta ou TikTok?
Essas solicitações de destino devem ser criadas por tags de servidor em sGTM ou outra integração de servidor. O caminho do script do Google de GTG não é uma rota geral da API de conversão que não é do Google.