GTM, Pixel e LinkedIn já rodavam. A verificação achou um 503 assustador — que era só a ferramenta de teste mentindo.
tag isolada · prova fraca × prova forte · teste fora do prédio · quatro tags, zero quebra
No nosso próprio site já rodavam três tags: GTM (com uma conversão do Google Ads dentro), Meta Pixel e LinkedIn Insight. A tarefa era simples de descrever — adicionar o GA4 — e perigosa de errar: qualquer tag mal colocada pode quebrar uma das outras três, e aí a agência perde dado de verdade sobre o próprio tráfego.
Esse post é sobre as duas partes que importam de verdade nesse tipo de tarefa: onde a tag nova entra sem encostar nas outras, e como provar que ela realmente está mandando dado — não só que o código está lá.
O GA4 podia ter entrado de duas formas: como uma tag dentro do GTM que já existe, ou direto no código, do lado das outras três. Escolhemos direto no código — cada tag no seu próprio bloco, visível, sem depender de mexer numa configuração que vive fora do repositório.
O guard __PRERENDER__ já existia nas outras três — o build gera versão estática de cada página pra SEO rodando um navegador headless, e sem essa trava toda página gerada no build viraria uma visita falsa nas quatro ferramentas ao mesmo tempo. Reusar o padrão em vez de inventar um novo é o que faz o diff dar pra revisar em 10 segundos.
Regra: tag nova entra do lado das existentes, nunca por cima. Se o diff mexe numa linha de uma tag que não é a que você está adicionando, alguma coisa saiu do escopo.
Depois do deploy, a primeira checagem foi ver se G-XXXXXXXXXX aparecia no HTML da página em produção. Apareceu. Isso prova quase nada — só que o texto certo foi parar no arquivo certo. Não prova que o navegador de alguém carregou o script, nem que o evento chegou no servidor do Google.
Aba de rede do navegador aberta na página real: os quatro scripts carregando (200), incluindo — coisa que a gente nem sabia — uma tag de conversão do Google Ads já configurada dentro do GTM, disparando junto. Até aqui, tudo certo. Console sem erro nenhum.
Regra: “o código tem a tag” e “a tag está funcionando” são duas afirmações diferentes. A segunda só se prova olhando o pedido de rede saindo, ou o dado chegando no relatório.
Só que o pedido específico que manda o dado pro GA4 (google-analytics.com/g/collect) voltou 503 — serviço indisponível. Script carregou, evento foi montado certo, mas o envio final falhava. Primeira suspeita óbvia: configuramos alguma coisa errado.
Antes de sair mexendo, um teste rápido: o mesmo tipo de pedido, no mesmo navegador, mas num site que a gente não tem nenhuma ligação — o site do próprio Google para desenvolvedores. Resultado: 503 também. No site deles. Com o GA4 configurado por eles mesmos.
Se o site do Google, com o GA4 deles mesmos, também toma 503, o defeito não está em nenhuma configuração de cliente — está em algo do ambiente onde o teste rodava. No caso, uma extensão de depuração de tags instalada no navegador de automação, interceptando exatamente esse tipo de chamada. Ferramenta de diagnóstico virando fonte do próprio alarme.
Regra: quando o teste dá errado, primeiro pergunte se o teste é confiável. Reproduzir a falha num sistema que você não controla é o jeito mais rápido de separar “meu código quebrou” de “meu ambiente de teste está mentindo”.
tag nova no seu próprio bloco, guard __PRERENDER__ reaproveitado — diff pequeno, fácil de revisar, zero linha tocada nas outras três.
o texto do ID aparecer no HTML só prova que o arquivo certo foi deployado — não prova que a tag funciona.
aba de rede mostrando o script carregando e o evento sendo montado e enviado — é o nível que realmente importa.
erro reproduzido num site que você não controla (o do próprio fornecedor) prova que o problema é do ambiente de teste, não do seu código.
Adicionar uma tag nova num stack que já funciona não é sobre escrever o snippet certo — é sobre provar, com dado saindo de verdade, que as quatro continuam rodando juntas. E quando a prova falha, testar fora do prédio antes de assumir a culpa.