Como Verificar se o Server-Side GTM (sGTM) Está Funcionando

"Configuramos o server-side GTM (sGTM), mas não tenho certeza de que a medição realmente está passando pelo servidor." Essa é uma preocupação muito comum entre equipes que adotaram o sGTM. Diferente da configuração tradicional, em que as tags disparam diretamente do navegador, o sGTM adiciona um salto pelo servidor no meio do caminho — o que torna muito mais difícil enxergar onde as coisas quebram. Você acha que configurou tudo, mas se o servidor nunca recebe a requisição, nada é registrado no GA4 ou no Ads.

Alguma dessas situações soa familiar?

• Depois de migrar para o sGTM, seus eventos do GA4 caíram ou pararam
• Observando o tráfego do navegador, as requisições não estão indo para o domínio do seu próprio servidor de tags
• Nenhuma requisição aparece na preview do sGTM
• O GA4 funcionava antes, mas a medição sumiu no exato momento em que você configurou o transport_url

Este guia organiza como verificar se o sGTM está funcionando, o que observar e as falhas mais comuns — tudo sob uma perspectiva prática e operacional.

Princípio básico: por onde o sGTM realmente passa?

O maior motivo pelo qual a verificação do sGTM dá errado é não visualizar o fluxo de dados como uma linha única. Com o sGTM, o navegador não envia diretamente para o GA4 — um servidor no seu próprio domínio (o servidor de tags) fica no meio. Comece internalizando esse fluxo.

Etapa	O que acontece	Armadilha comum
① Envio	O navegador envia para um servidor de tags first-party (ex.: gtm.example.com)	transport_url não configurado, então vai direto para o Google
② Recebimento	O container no servidor (Cloud Run, etc.) recebe a requisição	Container não implantado / URL errada
③ Encaminhamento	O servidor distribui e encaminha para GA4, Ads, Meta	Mapeamento de cliente/tag configurado incorretamente

O ponto principal: o sGTM tem dois containers — um "web container" (lado do navegador) e um "server container" (lado do servidor). Mesmo que uma tag dispare no lado do navegador, se o destino não estiver apontado para o servidor, ela está indo direto para o Google como antes — isso não é "passar pelo sGTM". O objetivo do sGTM é tornar os cookies first-party através do seu próprio domínio, para que sejam menos afetados pela ITP (a prevenção de rastreamento do Safari) e por ad blockers. É exatamente por isso que você precisa verificar se o servidor está sendo utilizado de fato.

Passo 1: verifique o destino do navegador (transport_url)

Primeiro, veja para onde o navegador está enviando. Se isso não estiver apontado para o seu próprio servidor de tags, o sGTM nem sequer começa.

1. Abra a página que deseja verificar e abra a aba "Network" (Rede) no DevTools
2. Filtre por collect
3. Observe a requisição /g/collect que dispara durante a interação na página e veja seu domínio de destino
4. Confirme que o destino é um domínio first-party seu, como gtm.example.com (se ainda for google-analytics.com ou analytics.google.com, não está configurado)

O que direciona o navegador para o seu próprio domínio é o parâmetro transport_url na tag de configuração do GA4 (ou tag do Google). Se estiver em branco ou digitado incorretamente, o navegador continua enviando diretamente para o Google.

Armadilha comum: você colocou a URL do seu server container no transport_url, mas o DNS daquele subdomínio não aponta para o servidor — então a requisição nunca chega e falha. Mesmo que o domínio de destino pareça correto, se esse domínio realmente resolve para o servidor é uma questão à parte.

Passo 2: o server container está implantado e recebendo?

Mesmo que o destino seja o seu próprio domínio, se o server container por trás dele não estiver rodando, nada é recebido.

• O servidor de tags (Cloud Run ou hospedagem similar) está implantado e em execução?
• Ao acessar a URL do servidor de tags (ex.: https://gtm.example.com), ele retorna uma resposta saudável?
• O domínio de destino do Passo 1 coincide com o domínio onde você realmente implantou o servidor?

O que isso revela: se o servidor existe e consegue aceitar requisições (②). O que isso não revela: se ele então encaminha corretamente para o GA4 ou o Ads (o ③ vem no próximo passo).

Armadilha comum: o container pode estar implantado, mas se você esqueceu do Container Config ID necessário, o servidor inicializa vazio — ele recebe requisições, mas não processa nada. "Está rodando" não significa "a configuração está carregada".

Passo 3: rastreie o fluxo recebimento-para-encaminhamento na preview do sGTM

O sGTM tem um modo de preview dedicado ao lado do servidor. Esse é o coração da verificação.

• Inicie a "Preview" no painel administrativo do sGTM (server container)
• Abra o site em outra aba, interaja com ele e observe se as requisições chegam na preview
• Para cada requisição recebida, confirme se a tag do GA4, a tag do Ads, etc., disparam, e se os destinos (Outgoing HTTP Requests) são os que você pretendia

O que isso revela: se o servidor está recebendo a requisição e encaminhando-a para cada destino (a cadeia completa ② → ③). Só quando você consegue ver isso você pode dizer que está "passando pelo sGTM".

Armadilha comum: se nenhuma requisição chega na preview, o problema está a montante (Passos 1–2), não no servidor. Por outro lado, se as requisições chegam mas a tag do GA4 não dispara, suspeite de uma configuração incorreta de cliente, gatilho ou mapeamento. "Não chega" e "chega mas não é encaminhado" te levam a caminhos completamente diferentes.

Passo 4: verifique o comportamento de cookies first-party e a resiliência a ad blockers

O modo preview confirma o fluxo de dados, mas dois dos principais benefícios do sGTM — vida útil de cookie mais longa e menor impacto de ad blockers — precisam de suas próprias verificações.

Verifique a expiração de cookies no Safari

Abra o Safari no site em questão, depois vá em Develop > Show Web Inspector > Storage > Cookies. Encontre seus cookies de rastreamento (_ga, _gcl_aw, ou qualquer cookie personalizado definido pelo seu sGTM). Verifique a data de expiração:

• Se mostrar 1 a 2 anos a partir de hoje, o cookie está sendo configurado corretamente como first-party pelo seu servidor.
• Se mostrar 7 dias a partir de hoje, a ITP do Safari está limitando o cookie — isso geralmente significa que o endereço IP do subdomínio do seu servidor de tags não coincide com o IP do domínio principal, então o Safari classifica isso como um "CNAME cloak" e reduz a vida útil.

Isso é fácil de passar despercebido, porque o Chrome não apresenta o mesmo comportamento. Relacionado: como a ITP do Safari causa perda de conversões.

Teste com um ad blocker ativo

Ative um ad blocker popular (uBlock Origin, AdGuard) no seu navegador, carregue seu site e verifique a aba Network:

• As requisições /g/collect ainda chegam ao seu domínio first-party?
• A preview do sGTM ainda mostra requisições chegando?

Fique atento ao fato de que as principais listas de filtros (EasyPrivacy, AdGuard) agora incluem regras que visam padrões comuns de subdomínio do sGTM, como prefixos sgtm. ou gtm.. Se o seu subdomínio estiver sendo bloqueado, considere escolher um nome de subdomínio menos óbvio. Para mais detalhes sobre como ad blockers afetam o rastreamento, veja como ad blockers bloqueiam pixels e o que fazer a respeito.

Verifique os logs do Cloud Run para falhas silenciosas em produção

A preview é uma ferramenta de depuração — ela não conta o que acontece em produção quando você não está olhando. O sGTM não tem um painel de saúde integrado, então falhas em produção são silenciosas, a menos que você monitore ativamente.

No Google Cloud Console, vá em Cloud Run > seu serviço de tags > Logs (ou use o Logs Explorer) e procure por:

• Entradas de nível Error ou Warning — geralmente indicam uma tag falhando ao encaminhar, uma variável mal configurada, ou um timeout ao alcançar um endpoint de destino.
• Quedas de volume — uma queda repentina no volume de requisições pode indicar uma mudança de DNS, um certificado expirado, ou um problema de escalonamento do container, nenhum dos quais aparece no modo preview.
• Saída do logToConsole — se você usa uma tag Logger ou templates personalizados que chamam a API logToConsole, a saída deles aparece nos logs de stdout. Filtre com logName: "stdout" no Logs Explorer.

Configure um alerta do Cloud Monitoring sobre taxa de erro ou contagem de requisições para ser notificado quando algo quebrar, em vez de descobrir dias depois quando os números de conversão caírem.

Falhas comuns com o sGTM

Quando você não está passando pelo sGTM, a causa geralmente se resume ao seguinte. Suspeite de cima para baixo.

1. O transport_url não está configurado

A mais frequente. Se você não adicionar o transport_url à tag de configuração do GA4 (tag do Google) no lado do web container, o navegador continua enviando diretamente para o Google e o servidor nunca é acionado.

2. O server container não está implantado / está parado

Quando você não implantou o container na hospedagem (Cloud Run, etc.), ou ele está parado. O Passo 2 verifica se a URL responde.

3. O DNS do domínio first-party (subdomínio) não está configurado

Mesmo que você prepare um subdomínio como gtm.example.com, as requisições não chegarão a menos que o DNS aponte para o servidor. Verifique a configuração do DNS e a validade do certificado (HTTPS).

4. Configuração incorreta de mapeamento / cliente

Casos em que o servidor recebe mas não encaminha — o cliente GA4 não está habilitado, ou as condições de gatilho da tag não correspondem. Rastreie o encaminhamento na preview do Passo 3.

O que a verificação na sua própria máquina não pode revelar

Todos os passos acima são úteis, mas verificar uma única vez na sua própria máquina tem duas limitações estruturais.

1. O seu ambiente não é o ambiente dos seus visitantes. Um dos principais propósitos do sGTM é reduzir o impacto da ITP (como a ITP do Safari causa perda de conversões) e de ad blockers. No entanto, se o navegador que você usa para verificar é o Chrome com as extensões desativadas, você não consegue reproduzir exatamente as condições que estava tentando contornar. Perdas que aparecem no Safari real ou em outro ambiente não vão aparecer na sua única passagem local.
2. Conversões que envolvem um clique em anúncio são difíceis de verificar. Para realmente checar "isso está sendo rastreado pelo servidor via um anúncio", você precisaria clicar em um anúncio ao vivo para recriar o caminho — o que carrega o risco de violação da política de anúncios como um autoclique.

Como o sGTM insere um salto pelo servidor, ele é estruturalmente propenso a "funciona na minha máquina, mas some nas condições reais dos visitantes". É exatamente por isso que verificar no caminho real de produção importa.

Um checklist para verificar com confiança

Comece pelo que é gratuito e fácil, e vá resolvendo item por item, em ordem.

• O destino do navegador (/g/collect) é um domínio first-party seu (transport_url)?
• O DNS desse subdomínio aponta para o servidor, com HTTPS válido?
• O server container (Cloud Run, etc.) está implantado e em execução?
• O Container Config ID foi inserido corretamente?
• As requisições chegam na preview do sGTM?
• Para as requisições que chegam, as tags GA4/Ads disparam e encaminham?
• Os destinos (propriedade do GA4, ID de conversão do Ads) são os pretendidos?
• Falta alguma coisa em condições reais de visitantes, como um Safari real?
• No Safari, as datas de expiração dos cookies de rastreamento estão 1 a 2 anos à frente (não limitadas a 7 dias pela ITP)?
• Com um ad blocker ativado, as requisições ainda chegam ao seu domínio de tags first-party?
• Os logs do Cloud Run estão livres de entradas Error/Warning e quedas de volume?

Perguntas frequentes

P. Por que meus eventos do GA4 caíram depois que configurei o sGTM? R. Um caso comum: no momento em que você configura o transport_url, o destino do navegador muda para o seu próprio servidor — mas esse servidor (deploy do container, DNS) não estava pronto, então a requisição chega a um beco sem saída. Percorra os Passos 1–3, verificando destino, recebimento e depois encaminhamento, nessa ordem.

P. Se as tags disparam no lado do navegador, o sGTM está funcionando? R. Não. Mesmo que a tag do web container dispare, se o destino ainda for o Google (transport_url não configurado), é o envio direto tradicional e o servidor não está sendo utilizado. Você só pode avaliar depois de confirmar que o destino é o seu próprio domínio e que o servidor está recebendo.

P. Nenhuma requisição chega na preview do sGTM. R. É muito provável que seja um problema a montante, não no servidor. Verifique ① a configuração do transport_url, ② o DNS do subdomínio, e ③ o status de deploy do container. "Nada chega na preview" isola o problema em "não está alcançando o servidor".

P. O GA4 está funcionando, mas apenas as conversões do Google Ads não chegam. R. Uma lacuna clássica de isolamento: no server container do sGTM, o GA4 encaminha normalmente, mas a tag/mapeamento do Ads não está configurado. Na preview, confirme se a requisição de saída para o Ads está realmente sendo enviada. Relacionado: o que verificar quando as conversões do Google Ads não estão sendo rastreadas.

P. Posso verificar o Meta e as conversões avançadas também através do sGTM? R. A abordagem é a mesma — rastreie o encaminhamento para cada destino na preview. Para verificações individuais, veja verificando a Meta CAPI (Conversions API) e verificando se as conversões avançadas estão sendo enviadas corretamente, e para uma visão geral, o guia de rastreamento de conversões do GA4.

Conclusão: não pare no disparo — verifique se passa pelo servidor e é encaminhado

Verificar o sGTM não está completo apenas com o disparo da tag no lado do navegador. O que importa é ir além: confirmar que o destino aponta para o seu próprio domínio (①), o servidor recebe (②), e ele encaminha corretamente para o GA4 e o Ads (③) — que toda essa cadeia se conecta em produção. Se parar a montante, nenhuma quantidade de disparo saudável no lado do navegador faz com que os dados sejam registrados.

O ConversionOK executa a sua página real em um navegador independente e isolado e intercepta as requisições realmente enviadas ao seu servidor de tags, verificando-as — sem necessidade de clicar no seu próprio anúncio e sem interferência do ambiente do seu escritório. Comece com uma verificação estática gratuita para confirmar o ponto de entrada da sua medição server-side.