Guia de como implementar server-side tracking

Implementar server-side tracking significa colocar um servidor da sua empresa entre o site e as plataformas de mídia e analytics. O navegador envia os eventos para esse servidor, hospedado num subdomínio da própria marca, e é ele que repassa cada dado para GA4, Meta, Google Ads ou TikTok no formato que cada plataforma pede. Na prática, a implementação passa por criar um contêiner de servidor no Google Tag Manager, hospedá-lo na nuvem, apontar um domínio próprio para ele, migrar as tags e validar tudo em paralelo antes de desligar a coleta antiga.

O assunto ganhou urgência porque a coleta feita só no navegador perde dados por vários caminhos: restrições de cookies no Safari, bloqueadores que impedem a chamada de sair do navegador, redirecionamentos para gateways de pagamento e abas fechadas antes de o evento disparar. Nas auditorias da Métricas Boss, o Índice de Confiabilidade do GA4 brasileiro ficou em 64%, um número calculado sobre 31 mil auditorias. Em outras palavras, mais de um terço do que o GA4 reporta, em média, não serve de base para uma decisão.

Abaixo está a sequência de implementação que usamos como referência, junto com as decisões de arquitetura que mais pesam no resultado. Se você opera um e-commerce e quer a versão completa, com checklist de migração e cases de mercado, baixe o Guia Definitivo de Server-Side Tracking para o E-commerce Brasileiro, que produzimos com a Wascer, empresa de hospedagem de GTM server-side.

O que é server-side tracking

Server-side tracking é o modelo de coleta em que os dados de navegação e conversão passam primeiro por um servidor controlado pela empresa e só depois seguem para as ferramentas de terceiros. No Google Tag Manager, isso é feito com um contêiner de servidor, uma segunda instância do GTM que roda na nuvem e recebe as requisições enviadas pelo contêiner web. O Google chama esse recurso de server-side tagging, e em português também se usa o termo rastreamento server-side.

No modelo client-side, o contêiner web roda no navegador e cada tag manda os dados direto para os servidores da plataforma correspondente. O navegador do visitante conversa ao mesmo tempo com os servidores de todas as ferramentas instaladas, e qualquer bloqueio no meio do caminho faz o evento desaparecer.

No modelo server-side, o navegador faz a chamada para um endereço da própria marca, como dados.suaempresa.com.br. Dali em diante, o servidor decide o que vai para cada destino e em qual formato.

Por que implementar server-side tracking

O motivo principal é recuperar dados que a coleta no navegador já não entrega com consistência. Cada fator abaixo afeta uma parte diferente da medição, e o server-side responde a eles com intensidades diferentes.

Cookies que duram mais

O Safari apaga os cookies criados por JavaScript depois de sete dias de uso do navegador sem interação do visitante com o site, o que quebra a continuidade das sessões e faz um mesmo visitante parecer novo. O Firefox age de outra forma: bloqueia cookies de rastreamento entre sites e isola os de terceiros. Quando o servidor de tagging responde num domínio da marca, ele pode gravar cookies próprios. A documentação do Google cita cookies “mais duráveis” como benefício dessa configuração, e o servidor ainda consegue usar cookies HttpOnly, que scripts da página não enxergam.

Há uma condição importante. O Safari também limita a sete dias os cookies gravados por um servidor que responde de um endereço de IP de terceiro, diferente do IP do site, o que pode acontecer quando o subdomínio aponta direto para a infraestrutura da nuvem. A configuração same origin, explicada no passo 4, costuma evitar esse limite.

Menos eventos barrados por bloqueadores

Bloqueadores de anúncio trabalham com listas de domínios conhecidos. Uma chamada para o subdomínio da sua marca passa com mais facilidade do que uma chamada para o domínio de uma plataforma de anúncios. Vale a ressalva do nosso guia: servir o GTM pelo domínio próprio reduz o bloqueio, mas não o elimina, porque algumas listas já reconhecem padrões de caminho.

Mais sinal para os algoritmos de mídia

As plataformas de mídia otimizam lances com base nas conversões que recebem. Quando parte das compras se perde, o algoritmo aprende com menos dados e o CPA reportado se afasta do real. Pelo servidor, você envia as conversões pelas APIs oficiais de cada plataforma, como a API de Conversões da Meta e as Enhanced Conversions do Google, com dados de correspondência tratados por hash antes do envio.

Controle sobre o que sai do site

Com o servidor no meio, a empresa decide quais parâmetros cada plataforma recebe. Dá para remover dados pessoais antes do envio ou enriquecer as conversões com informações do back-office. Esse controle ajuda a aplicar a LGPD, mas não substitui a gestão de consentimento: se o visitante recusou o rastreamento, a recusa precisa valer no servidor também.

Um site mais leve, com uma ressalva

Menos tags no navegador significa menos código para executar no carregamento da página. Porém, um contêiner web inflado continua pesado mesmo depois da migração, e por isso a limpeza das tags faz parte do projeto.

O que você precisa antes de começar

A parte técnica da implementação costuma ser a mais rápida. O que atrasa os projetos é começar sem estes itens resolvidos:

• •Inventário de tags e dataLayer validado. Liste tudo o que dispara hoje, incluindo Custom HTML e plugins da plataforma de e-commerce, e confirme que eventos como add_to_cart e purchase chegam com os parâmetros certos. O servidor repassa o que recebe; se o dado sai errado do navegador, ele chega errado em todas as plataformas.
• •Linha de base de conversões. Registre quantas conversões cada plataforma reporta hoje e compare com os pedidos do back-office (VTEX, Shopify ou o sistema que você usa). Sem esse número, não há como provar o ganho depois.
• •Acesso ao DNS e um responsável técnico. Alguém precisa criar o subdomínio e configurar o certificado SSL. Depois que o servidor entra no ar, essa mesma pessoa passa a responder por ele.
• •Orçamento de infraestrutura. O Google estima entre US$ 30 e US$ 50 por servidor ao mês no Cloud Run e recomenda pelo menos três servidores em produção. Provedores especializados cobram por planos, alguns com faixa gratuita.
• •Gestão de consentimento funcionando. A ferramenta de consentimento (CMP) precisa estar integrada ao GTM antes da migração, para que a escolha do visitante seja respeitada também no servidor.

Como implementar server-side tracking em 9 passos

O roteiro abaixo usa o Google Tag Manager server-side com a Wascer como hospedagem do servidor, que é a opção recomendada pela Métricas Boss. Os passos de 2 a 5 seguem o guia de primeiros passos da Wascer, que mostra cada tela com prints. A ordem importa: os cinco primeiros passos montam a estrutura, e só depois entram as plataformas e a troca de um modelo pelo outro.

1. Faça o diagnóstico do contêiner web

Audite as tags do GTM web, incluindo os scripts em Custom HTML, e os plugins instalados na plataforma de e-commerce. Remova o que não é usado e meça o tamanho do contêiner com uma ferramenta como o Get GTM Size. Migrar um contêiner bagunçado só leva a bagunça para o servidor.

2. Crie o contêiner de servidor no GTM

No Google Tag Manager, abra a área Admin e clique no + da coluna de contêineres. Dê um nome ao contêiner e, em Target platform, escolha Server. Depois de criar, abra as configurações do contêiner, clique para configurar o servidor de tags e selecione Manually provision tagging server. Copie o valor de Container Config, que você vai usar no passo seguinte. O passo a passo com prints está na Etapa 1 do guia da Wascer.

Fonte: Wascer

Fonte: Wascer

3. Escolha onde o servidor vai rodar

As opções vão de uma nuvem administrada pela sua equipe, como Google Cloud ou AWS, até um provedor especializado em GTM server-side. Na Métricas Boss, recomendamos a Wascer, parceira com quem produzimos o Guia Definitivo. Provedores especializados cuidam da infraestrutura e das atualizações em troca de uma mensalidade.

Na Wascer, você cria um contêiner no painel, cola o Container Config copiado do GTM e escolhe a localização do servidor, de preferência a região mais próxima da maioria dos seus visitantes. O deploy leva cerca de 5 minutos e, quando termina, o contêiner aparece como ativo na lista. Veja a Etapa 2 do guia da Wascer.

Fonte: Wascer

Fonte: Wascer

Se a sua equipe preferir montar o próprio ambiente no Google Cloud, a recomendação atual do Google é o Cloud Run. O deploy automático padrão serve apenas para testes com pouco tráfego. Em produção, o Google recomenda no mínimo três instâncias, e uma configuração de 3 a 6 instâncias com escalonamento automático deve suportar de 50 a 200 requisições por segundo. Esse caminho dá mais controle, mas exige alguém de engenharia acompanhando o custo por requisição e as mudanças do Google.

4. Configure um domínio próprio

O servidor precisa responder num endereço da sua marca, e não no domínio genérico da nuvem (como run.app ou appspot.com). No domínio genérico, o servidor roda em contexto de terceiro e só consegue usar cookies definidos por JavaScript. O Google descreve duas formas de resolver isso:

• •Subdomínio, como dados.suaempresa.com.br, que exige apenas uma alteração no DNS.
• •Mesma origem (same origin), como suaempresa.com.br/metrics, que exige configurar uma CDN ou um load balancer para encaminhar as requisições. O Google trata essa opção como a melhor prática.

Na Wascer, o domínio é adicionado na aba Domínios do contêiner. A conexão pode ser automática ou manual, pelos registros de DNS, e o domínio fica ativo depois da propagação. A plataforma também oferece a configuração same origin como um recurso adicional. Veja a Etapa 3 do guia da Wascer.

Fonte: Wascer

Fonte: Wascer

A escolha também afeta a duração dos cookies no Safari. No subdomínio, se o servidor responder de um IP diferente do site, os cookies gravados por ele ficam limitados a sete dias. Na configuração same origin, as requisições passam pela mesma infraestrutura que atende o site, o que costuma evitar esse limite.

5. Aponte o contêiner web para o servidor

No GTM web, informe à tag do Google o endereço do seu servidor. Pela orientação atual do Google, isso é feito com uma variável do tipo Google tag: Configuration settings, que recebe o parâmetro server_container_url com a URL do seu domínio. A variável é associada à tag do Google, que deve disparar no acionador Initialization - All Pages. A partir daí, os eventos deixam de ir para google-analytics.com e passam a chegar ao seu servidor. A configuração completa, com a criação da variável e da tag, está na Etapa 4 do guia da Wascer.

Aproveite para servir também os scripts do Google pelo seu domínio, em vez de googletagmanager.com. O Google chama esse recurso de Google tag gateway for advertisers (no mercado, também se fala em script-serving), e ele depende do contêiner de servidor e do domínio próprio já configurados. Isso importa porque, se o carregamento do contêiner for bloqueado, nenhuma tag dispara.

6. Configure as tags no servidor

No contêiner de servidor, crie as tags de cada destino, como GA4, conversões do Google Ads com Enhanced Conversions, API de Conversões da Meta e Events API do TikTok. Os dados de correspondência, como e-mail e telefone, devem ser normalizados e convertidos no hash exigido por cada plataforma antes de sair do servidor. Meta e Google usam SHA-256.

Na Wascer, depois da configuração básica, você também pode ativar os Boosters, recursos adicionais voltados a aumentar a coleta. Para Meta, TikTok e Snapchat, existe ainda a opção de Gateways, que dispensa montar essas tags no contêiner. Veja a Etapa 6 do guia da Wascer.

7. Configure a deduplicação de eventos

A Meta recomenda manter o Pixel e a API de Conversões enviando os mesmos eventos, num modelo que ela chama de configuração redundante. Para que a mesma compra não seja contada duas vezes, o event_id e o event_name precisam ser idênticos no navegador e no servidor. A deduplicação só funciona dentro de uma janela de 48 horas a partir do primeiro evento recebido. O TikTok também deduplica pelo event_id quando Pixel e Events API rodam juntos, mas com uma janela própria, detalhada no artigo sobre o que cada plataforma recebe.

8. Rode os dois modelos em paralelo

Mantenha a coleta client-side ativa enquanto o server-side é validado. Para conferir se os dados chegam ao servidor, abra o modo de visualização do contêiner de servidor e, em outra aba, o do contêiner web com a URL do site. Navegue pelo site, confirme no contêiner web que a tag do Google disparou e, no de servidor, que os eventos do seu domínio estão chegando. Esse teste está na Etapa 5 do guia da Wascer.

Fonte: Wascer

Depois, teste a navegação no Safari e num navegador com bloqueador ativo, observando se os cookies continuam sendo reconhecidos entre sessões e com qual validade o Safari os mantém.

9. Faça o corte e acompanhe os números

Com tudo validado, passe as tags de conversão a disparar prioritariamente pelo servidor. Na primeira semana, compare o volume diário de conversões com a linha de base registrada antes do projeto. Na Wascer, a área de Monitoring envia alertas quando há queda de eventos ou picos de erro, e os Logs mostram as requisições de entrada e saída do servidor. Depois, documente o domínio e as tags ativas, com o nome do responsável técnico, para que a arquitetura não dependa da memória de uma pessoa só.

Como validar a implementação

A validação termina quando as conversões enviadas pelo servidor batem com os pedidos do back-office. Ver os eventos chegando no modo de visualização é só o primeiro sinal. Antes de desligar a coleta antiga, confira:

• •O modo de visualização do contêiner de servidor mostra cada requisição chegando e as tags disparando para todos os destinos.
• •No Gerenciador de Eventos da Meta, os eventos do servidor aparecem junto com os do Pixel, sem contagem dupla.
• •Os cookies são gravados pelo seu domínio, e no Safari aparecem com a validade configurada, sem o limite de sete dias.
• •O número de compras no GA4 e nas plataformas de mídia se aproxima dos pedidos do back-office. Diferenças como visitantes que recusaram o consentimento são esperadas e precisam estar explicadas.

Erros comuns na implementação

• •Usar o domínio genérico da nuvem. Sem domínio próprio, o servidor continua em contexto de terceiro e boa parte do ganho com cookies se perde.
• •Esquecer oevent_id. Com Pixel e API de Conversões ativos ao mesmo tempo, a Meta pode contar a mesma compra duas vezes, e a receita reportada infla.
• •Tratar o script-serving como blindagem. Ele reduz o bloqueio, mas listas de bloqueio já reconhecem padrões de caminho usados pelo GTM.
• •Migrar sem linha de base. Sem os números de antes, a empresa não consegue mostrar quanto recuperou nem identificar se algo piorou.
• •Usar o GA4 como fonte da verdade das vendas. A referência para compras é a confirmação no servidor da plataforma de e-commerce. O GA4 e as plataformas de mídia devem ser comparados com ela.
• •Encerrar o projeto na ativação técnica. O teste de verdade é o primeiro ciclo completo de otimização de mídia rodando sobre os dados novos.

Baixe o guia completo de server-side tracking

Este artigo cobre o roteiro de implementação. No Guia Definitivo de Server-Side Tracking para o E-commerce Brasileiro, que a Métricas Boss produziu com a Wascer, você encontra o checklist de migração em quatro fases e cases de e-commerces brasileiros que passaram pelo processo, com os resultados medidos em cada um.

Baixar o Guia Definitivo de Server-Side Tracking gratuitamente

Perguntas frequentes sobre server-side tracking

Server-side tracking substitui o client-side?

Não por completo. O navegador continua capturando os eventos e enviando para o seu servidor, que faz a distribuição. No caso da Meta, a própria plataforma recomenda manter o Pixel e a API de Conversões ativos juntos, com deduplicação por event_id.

Quanto custa implementar server-side tracking?

No Google Cloud, o Google estima de US$ 30 a US$ 50 por servidor ao mês no Cloud Run e recomenda no mínimo três servidores em produção. Multiplicando os dois números, o custo fica entre US$ 90 e US$ 150 mensais, antes de picos de tráfego. Provedores especializados cobram mensalidades próprias, e alguns têm plano gratuito para volumes menores.

Quanto tempo leva a implementação?

Com um provedor gerenciado, conectar o contêiner e ver os primeiros eventos pode levar minutos. Montando a infraestrutura do zero, com DNS e certificado configurados manualmente, o trabalho costuma levar semanas. Em qualquer cenário, reserve tempo para rodar os dois modelos em paralelo antes do corte.

Server-side tracking resolve a LGPD?

Não. O servidor dá mais controle sobre quais dados saem do site e permite aplicar hash em dados pessoais, o que ajuda na adequação. A gestão de consentimento continua obrigatória, e a recusa do visitante precisa ser respeitada também nas tags do servidor.

Server-side tracking acaba com os bloqueadores de anúncio?

Reduz o efeito deles, mas não elimina. Chamadas para o domínio da própria marca são bloqueadas com menos frequência, e o script-serving ajuda a proteger o carregamento do GTM. Algumas listas de bloqueio, porém, já identificam padrões de caminho típicos do GTM.

Qual a diferença entre subdomínio e same origin?

No subdomínio, o servidor responde num endereço como dados.suaempresa.com.br, o que exige só uma alteração de DNS. Em same origin, ele responde num caminho do domínio principal, como suaempresa.com.br/metrics, com uma CDN ou um load balancer encaminhando as requisições. O Google considera same origin a melhor prática, e ela também costuma evitar o limite de sete dias que o Safari aplica a cookies gravados por servidores em IP de terceiro.

Preciso de server-side tracking para usar a API de Conversões da Meta?

Não necessariamente, porque existem integrações nativas de plataformas de e-commerce e o Conversions API Gateway da própria Meta. O GTM server-side tem a vantagem de centralizar o envio para todas as plataformas num só lugar, com a mesma lógica de dados e de deduplicação.

Fontes

• •Guia Definitivo de Server-Side Tracking para o E-commerce Brasileiro (Métricas Boss e Wascer)
• •Google: Server-side tagging (visão geral)
• •Google: Custom domain configuration
• •Google: Upgrade your servers for live traffic
• •Meta: Handling Duplicate Pixel and Conversions API Events
• •Wascer: Primeiros passos com hospedagem sGTM

Gustavo Esteves

Gustavo Esteves é fundador e CEO da Métricas Boss, já trabalhou dentro de gigantes como B2W. Autoridade na área de Digital Analytics, com mais de 15 anos de experiência e 3 mil projetos atendidos, incluindo gigantes como PUC, Rede D'Or, Globo, Stanley, Médico Sem Fronteiras, Alura, entre outras.

Publicado em 28 de outubro de 2026