O GA4 perde evento por bloqueador e por prazo de cookie. O servidor de tags resolve parte disso — e três detalhes decidem se vai funcionar antes de você contratar.
Em algum momento alguém compara o número de pedidos do sistema com o número de compras do GA4 e descobre uma diferença de dois dígitos percentuais. A partir daí a conversa sobre server-side tagging aparece — geralmente com a promessa de "recuperar os dados perdidos".
Ela recupera parte. Este texto é sobre qual parte, e sobre três detalhes que decidem se vai funcionar no seu caso — os três melhores de saber antes de contratar, não depois.
São duas causas diferentes, e elas pedem remédios diferentes:
1. O beacon não sai. Bloqueadores de anúncio e as proteções nativas do navegador barram requisições para domínios conhecidos de rastreamento. O evento não chega porque nunca saiu do aparelho.
2. O cookie morre cedo. No Safari, cookie gravado por JavaScript de terceiro tem prazo curto — e isso quebra a continuidade: quem visitou hoje e comprou daqui a duas semanas volta como visitante novo. O evento chega; a atribuição é que se perde, e a campanha some do relatório.
Server-side tagging ataca as duas, por caminhos distintos — e deixa várias outras intactas. Esta tabela é o texto inteiro resumido:
| por que o evento se perde | o servidor de tags resolve? |
|---|---|
| Bloqueio por lista de domínio | sim — desde que o subdomínio não se denuncie (ver adiante) |
| Prazo curto do cookie no Safari | sim — o cookie passa a ser gravado pelo servidor |
| Bloqueio por comportamento, não por domínio | não |
| Visitante que recusou o consentimento | não — e não deve |
| JavaScript desativado | não |
| Evento disparado no lugar errado | não — ele encaminha o erro com mais fidelidade |
As três primeiras linhas explicam por que a recuperação costuma ser parcial; as três últimas, por que ninguém honesto promete cem por cento.
Em vez de o navegador falar direto com o Google, ele fala com um servidor no seu
próprio domínio — sst.suaempresa.com.br, por exemplo. Esse servidor recebe o
evento e encaminha.
Duas consequências caem de graça:
E uma consequência que raramente se menciona: o payload passa a ser seu. Você decide o que segue adiante e o que fica. Dá para cortar um parâmetro sensível antes de ele sair da sua infraestrutura — o que, sem servidor no meio, não é possível.
Este é o mais cruel, porque é fácil de errar e o erro passa despercebido.
Se o subdomínio se chamar gtm., analytics., track. ou pixel., ele é
bloqueado por padrão pelas mesmas listas que bloqueiam o Google — casam por
palavra no nome, não por destino. Você monta a infraestrutura inteira para
recuperar quem usa bloqueador, e entrega um endereço que o bloqueador reconhece
na primeira olhada.
Escolha um nome que não anuncie a função. É a diferença entre o recurso funcionar e o recurso existir.
O detalhe mais caro que encontramos, e ele apareceu com um cliente real.
Server-side tagging só funciona plenamente se o <script src> do site apontar
para o seu servidor. Acontece que, quando a loja roda numa plataforma
(e-commerce de terceiro, headless de agência), esse endereço às vezes está
cravado no código da plataforma — e não há campo nenhum no painel que o mude.
No primeiro cliente real que atendemos, o bloco de configuração da plataforma usava o nosso endereço só para um dos dois campos; o endereço do loader estava fixo no bundle dela, apontando para o Google. Chegamos a mandar um pedido à agência solicitando uma troca que ela não tinha como fazer — era mudança de uma linha na plataforma, não dela.
A conferência custa dois minutos e evita semanas: abra o site, F12 → aba Rede, recarregue e olhe de onde vem o arquivo do gtag. Se vier do Google, a conversa é com quem mantém a plataforma — antes de contratar servidor nenhum.
gtag.js pelo servidor muda a conta de bandaUm evento comum de medição custa cerca de 14 bytes de tráfego. Servir a biblioteca de tags pelo mesmo servidor custa dezenas de KB por visita — três ordens de grandeza de diferença.
As duas coisas são legítimas e a segunda é um uso comum. Mas elas têm perfis de custo muito diferentes, e vale saber em qual você vai cair antes de dimensionar.
Aqui é onde a maior parte do material sobre o assunto fica em silêncio.
Não é jeito de driblar consentimento. Se o visitante recusou, o evento não deve ser enviado — de onde quer que ele saia. O servidor muda o caminho do dado, não a base legal para tratá-lo. Quem contrata SST esperando "medir quem disse não" está comprando um problema jurídico com dinheiro.
Não recupera tudo. Quem bloqueia por comportamento (e não por lista de domínio), quem usa navegador com proteção agressiva e quem desativa JavaScript continuam fora. A recuperação é parcial por construção.
Não conserta medição errada. Se o evento dispara no lugar errado, ou se a URL vaza um dado que não devia, o servidor encaminha o problema com mais fidelidade. Ele não é uma camada de correção.
Não é gratuito em complexidade. Passa a existir uma peça de infraestrutura no caminho da sua medição: ela tem custo, precisa de monitoramento, e quando ela cai a medição cai junto.
Vale a pena quando as três forem verdade:
Se a resposta for não em qualquer uma delas, há trabalho mais barato com retorno maior antes deste.
O getbyte.co roda a própria medição por trás de um servidor de tags no nosso
domínio — e é também o produto que a gente vende, o
Server-Side Tagging.
Vale dizer o que isso custou em honestidade: ao migrar de um container para outro aqui mesmo, trocamos um identificador antes de o novo estar autorizado, e o servidor passou a devolver erro mudo — o script falhava sem reclamar em lugar nenhum, e ficamos cerca de 40 minutos sem medir nada, com campanha rodando.
Fica a lição, que é a mais útil deste texto inteiro: depois de mexer em medição, confira na aba Rede que a requisição sai e volta 200. O painel de debug mostra o evento na fila e diz que está tudo certo — ele não sabe se o beacon chegou ao destino.