A diferença entre GTM server-side e client-side é onde as tags rodam. No client-side, elas disparam no navegador do visitante e mandam os dados direto para Meta, Google e outras plataformas. No server-side, os eventos passam primeiro por um container hospedado no seu próprio domínio, que recebe do navegador e encaminha para as plataformas via API.
O server-side melhora a resistência a adblocker e a durabilidade dos cookies de atribuição, mas custa dinheiro e trabalho, e não substitui o client-side. Abaixo está o que cada abordagem resolve, quanto custa e quando vale a pena migrar. Para ver como isso pesa no score da sua implementação, veja o guia de auditoria de container GTM.
Client-side vs server-side: comparação rápida
| Critério | GTM client-side | GTM server-side |
|---|---|---|
| Onde a tag roda | No navegador do visitante | Em container hospedado no seu domínio |
| Requisições | Direto para domínios de terceiros (facebook.com, google.com) | Para o seu domínio (first-party), que reencaminha via API |
| Adblocker | Bloqueado quando o domínio de traqueamento é conhecido | Bypass parcial: seu domínio raramente entra na lista |
| Cookies e ITP do Safari | Cookies first-party via JavaScript (_fbp/_fbc) limitados a ~7 dias | Cookies setados pelo servidor, com duração configurável |
| Dados comportamentais (clique, scroll, formulário) | Capturados no navegador | Continuam sendo capturados no navegador e enviados ao servidor |
| Custo de infraestrutura | Zero (o GTM é gratuito) | Servidor dedicado, de US$ 10 a US$ 200+/mês |
| Complexidade de setup | Baixa | Alta (reconfigurar tags e manter servidor) |
Obs.: o server-side não elimina o client-side. Você continua precisando de um container no navegador para originar os eventos e capturar comportamento. O servidor processa e distribui, ele não substitui a coleta.
Como funciona o GTM client-side
No GTM client-side, o modelo padrão da maioria dos containers, o JavaScript é carregado no browser do visitante. Cada tag roda ali, faz requests diretos para plataformas externas (Facebook, Google, TikTok), e depende completamente do ambiente do browser para funcionar.
O processo é: usuário acessa o site → browser faz download do script do GTM → script carrega o container → tags disparam conforme os triggers → cada tag faz suas próprias requisições para GA4, Meta, Google Ads, etc.
Esse modelo funciona muito bem para a maioria dos sites. O problema começa quando o ambiente do browser começa a interferir com as requisições. Para o comparativo aprofundado, veja traqueamento server-side vs client-side no blog do Tracker.
As limitações do GTM client-side
Três fatores degradam a qualidade do traqueamento client-side:
Bloqueadores de anúncio e extensões de privacidade
AdBlock, uBlock Origin, Brave Shield e similares bloqueiam requests para domínios conhecidos de traqueamento, incluindo facebook.com/tr, googletagmanager.com e analytics.google.com. A penetração dessas ferramentas varia por público, mas em audiências de tecnologia pode chegar a 30-40% dos visitantes.
iOS ITP (Intelligent Tracking Prevention)
O ITP do Safari bloqueia cookies de terceiros por padrão. Não é um limite de dias, é bloqueio total. O prazo de ~7 dias é outra coisa: vale para cookies first-party setados via JavaScript, como o _fbc e o _fbp do Meta Pixel. O Safari trata esse tipo de cookie como suspeito de traqueamento e reduz a vida útil dele para até 7 dias (às vezes 1, dependendo do sinal detectado no domínio).
Isso afeta a janela de atribuição do Meta Pixel e do Google Ads: uma conversão que acontece 10 dias depois do clique pode não ser atribuída corretamente, porque o cookie que ligava o clique à conversão já expirou.
Cookies de terceiros em extinção
O Chrome está eliminando suporte a cookies de terceiros. Plataformas de mídia que dependiam desse mecanismo para rastrear visitantes entre sites estão migrando para soluções first-party, e o server-side é parte dessa estratégia.
Como funciona o GTM server-side
No GTM server-side, você cria um segundo container GTM (o Server Container) que roda em um servidor dedicado, gerenciado por você ou por um provedor como o Stape. Em vez de tags disparando direto do browser do visitante para as plataformas externas, os eventos vão primeiro para o seu servidor, que os repassa para as plataformas.
O fluxo é: usuário acessa o site → container client-side dispara → em vez de enviar para facebook.com/tr, envia para seudominio.com/measurement (o servidor GTM) → o servidor GTM recebe o evento e o encaminha para Meta, GA4, Google Ads, etc.
A chave aqui é o domínio: o request vai para o seu próprio domínio (first-party), não para domínios externos de terceiros. Isso muda o comportamento em relação a bloqueadores e ITP.
O que o GTM server-side resolve
Sendo direto sobre o que o server-side efetivamente melhora:
- Bypass parcial de adblockers — requests para seu próprio domínio geralmente não são bloqueados pelos adblockers (que bloqueiam domínios conhecidos de traqueamento). Digo "parcial" porque bloqueadores sofisticados e o Brave podem ainda bloquear dependendo da configuração
- Cookies first-party com maior durabilidade — cookies setados via server têm vida útil configurável por você (30, 90, 365 dias) e não são afetados pelo ITP do Safari que limita cookies JavaScript
- Controle total sobre os dados antes de enviá-los — você pode filtrar, enriquecer ou transformar os dados no servidor antes de repassar para as plataformas
- Performance do site — scripts de terceiros não rodam no browser do usuário, reduzindo o impacto no tempo de carregamento
O que o GTM server-side NÃO resolve
Isso é importante e frequentemente omitido nas discussões:
- Não elimina a necessidade de consentimento do visitante — o LGPD e o GDPR se aplicam independente de como os dados são transmitidos. Se o visitante não consentiu com o traqueamento, você não pode rastreá-lo, nem via client-side nem via server-side
- Não funciona sem ao menos um script client-side básico — você ainda precisa do container client-side para capturar os eventos iniciais e enviá-los para o servidor. O server-side processa, não origina os dados
- Não garante 100% de cobertura de eventos — visitantes com JavaScript desabilitado, ou em contextos muito restritivos, ainda ficam fora do traqueamento
- Não é substituto da API de Conversões — o server-side GTM e a API de Conversões são abordagens diferentes. Você pode usar o server-side para enviar dados para a API de Conversões, mas se fizer isso, o
event_iddo Pixel e oevent_idenviado pela API de Conversões precisam ser idênticos, senão a Meta conta o mesmo evento duas vezes. Entenda a diferença entre server-side e a API de Conversões
Custo real do GTM server-side
O server-side exige um servidor dedicado. O Google recomenda o App Engine no GCP, que pode custar entre $50-200/mês dependendo do tráfego. Para operações com alto volume de eventos, esse custo sobe.
Uma alternativa popular é o Stape, que oferece infraestrutura gerenciada para server-side GTM a partir de $10-25/mês para sites de médio porte. O Stape abstrai a complexidade de configurar e manter o servidor, e inclui recursos extras como Stape Data Tag para melhorar a cobertura de eventos.
Além do custo de servidor, há o custo de implementação: configurar um Server Container no GTM, criar as client-side tags que enviam para o servidor em vez de direto para as plataformas, configurar os server-side tags que repassam para Meta, GA4, etc. Dependendo da complexidade do container atual, isso pode levar de 4 a 20 horas de trabalho técnico.
Quando vale a pena migrar para GTM server-side
O server-side faz sentido quando:
- Seu público tem alta penetração de adblockers (audiências técnicas, jovens em desktop, usuários de Brave)
- Você opera e-commerce com ticket médio alto onde cada evento de conversão perdido tem impacto real na otimização
- Campanhas de retargeting e lookalike dependem muito de cookies e a janela de atribuição está sendo prejudicada pelo ITP
- Você tem volume de tráfego suficiente para justificar o custo: abaixo de 50 mil sessões/mês, o ROI da implementação raramente compensa
- Você já tem a API de Conversões implementada e quer usar o server-side como ponto de distribuição centralizado de eventos
Para quem o GTM client-side ainda é suficiente
A maioria dos sites e operações de mídia se beneficia mais de melhorar a qualidade do GTM client-side do que migrar para server-side. Se o seu container tem tags duplicadas, eventos de conversão faltando ou Meta Pixel via Custom HTML, o investimento em corrigir esses problemas gera muito mais retorno do que migrar para server-side sem corrigir a base.
O client-side é suficiente quando: seu público não tem alta penetração de adblockers, sua janela de atribuição cabe em 7 dias (suficiente para evitar o pior do ITP), e seu container já está com boa qualidade de implementação.
Antes de considerar server-side, audite seu container client-side. O score de qualidade do traqueamento explica os critérios que fazem a diferença na prática. Ou rode a auditoria agora e veja onde seu container perde pontos antes de decidir migrar.
FAQ
GTM server-side e API de Conversões são a mesma coisa?
Não. A API de Conversões é uma integração direta do servidor com a Meta: envia eventos de conversão do seu backend sem depender do browser. O GTM server-side é uma camada de gerenciamento de tags no servidor. Você pode usar o GTM server-side para enviar eventos para a API de Conversões, mas são coisas diferentes que podem ser usadas de forma independente.
O server-side GTM requer mudanças no container client-side existente?
Sim. Para que os eventos passem pelo servidor, as tags client-side precisam ser reconfiguradas para enviar para o endpoint do seu servidor em vez de diretamente para as plataformas. Isso exige modificar cada tag no container client-side, o que pode ser trabalhoso em containers grandes. Uma abordagem gradual é configurar o server-side para novos eventos e migrar os existentes progressivamente.
Qual a diferença entre o Stape e o App Engine do Google para server-side?
O App Engine é a infraestrutura do Google Cloud onde você hospeda o server container. É flexível e escalável, mas requer configuração técnica de infraestrutura. O Stape é um serviço gerenciado que abstrai essa configuração: você não precisa gerenciar o servidor, tem um painel de controle simplificado e inclui recursos adicionais como o Stape Data Tag. Para a maioria das operações que não têm time de DevOps, o Stape é mais prático.
Como saber se vale a pena server-side para minha operação?
Comece medindo a perda atual: compare o número de sessões no GA4 com o tráfego real do servidor (logs de acesso). A diferença indica quantos visitantes não estão sendo traqueados. Se essa perda for acima de 15-20%, o server-side provavelmente se paga. Se for menor, corrija a base do client-side primeiro: é mais rápido, mais barato e tem impacto garantido.
Se você não sabe ainda qual é a sua perda de traqueamento, comece por aí. Audite seu container GTM agora e veja o score de qualidade, os eventos ausentes e os quick wins antes de decidir entre client-side e server-side.