Traqueamento client-side significa que o script roda no navegador do usuário e coleta os dados do lado dele. Traqueamento server-side significa que um servidor intermediário coleta e processa os dados antes de enviá-los para o destino final. No modelo puramente client-side, você perde de 20% a 40% dos eventos de conversão. É essa diferença que decide a qualidade da otimização das suas campanhas.
No ecossistema Meta, essa implementação server-side tem nome próprio: chama-se API de Conversões. É ela que envia o evento direto do seu servidor para a Meta, sem depender do navegador do usuário.
Para o contexto completo de como esses dois modelos se encaixam na infraestrutura de tracking, veja o guia completo de traqueamento de conversões. Para se aprofundar na implementação, veja o artigo específico sobre API de Conversões do Meta.
Como funciona o traqueamento client-side
No modelo client-side, você instala scripts de terceiros no HTML do seu site. Quando o usuário carrega a página, o navegador executa esses scripts. Os scripts coletam informações do contexto do navegador — cookies, parâmetros de URL, resolução de tela, referrer — e enviam para as plataformas de tracking (Meta, Google Analytics, etc.) via requisição HTTP saindo do próprio navegador.
O fluxo completo: usuário visita a página → navegador executa o script → script coleta dados → script envia para connect.facebook.net (ou analytics.google.com, etc.) → dado chega na plataforma.
Esse modelo tem três vulnerabilidades estruturais:
- Ad blockers: extensões como uBlock Origin têm listas que bloqueiam domínios de tracking conhecidos. O domínio
connect.facebook.netestá nessas listas. Em usuários tech, a taxa de bloqueio pode chegar a 20% a 30%. - Intelligent Tracking Prevention (ITP) do Safari: Safari bloqueia cookies third-party e limita cookies first-party definidos via JavaScript a 7 dias (ou 24h em alguns cenários). Como o Pixel define seus cookies via JavaScript, eles têm vida mais curta no Safari — comprometendo a atribuição de ciclos de compra mais longos.
- App Tracking Transparency (ATT) do iOS: desde o iOS 14, usuários de iPhone podem recusar que apps e sites rastreiem sua atividade (ATT). Quando recusam, o Meta não recebe os identificadores que precisaria para associar o clique no anúncio à compra posterior.
A perda vem principalmente de duas frentes que se somam: o bloqueio por ad blockers e a limitação de identificadores no iOS (ITP no Safari e ATT no iPhone). Juntas, elas tiram de 20% a 40% dos eventos de conversão no modelo puramente client-side, dependendo do nicho e da composição da audiência.
Como funciona o traqueamento server-side
No modelo server-side, há um servidor intermediário entre o site do usuário e as plataformas de destino. Quando o usuário faz uma ação (ex.: compra), seu servidor backend recebe a informação, monta o payload com os dados do evento, e envia diretamente para a API do Meta (ou GA4 Measurement Protocol, etc.) — sem passar pelo navegador.
Repare que aqui o navegador sai do caminho. Quando a compra acontece, seu servidor backend recebe a confirmação, monta o payload e dispara o evento direto para a API de Conversões do Meta. Nada depende de o browser do usuário estar disposto a colaborar.
O servidor intermediário mais comum para esse fim é o GTM Server-Side. Em vez de um container GTM rodando no navegador, você tem um container GTM rodando em um servidor (hospedado no Google Cloud Platform, AWS, ou em um serviço gerenciado como o Stape). Esse servidor recebe os eventos do GTM client-side, processa, e os encaminha para as plataformas via API.
A vantagem crítica: nenhum dado sai do servidor. Ad blockers só bloqueiam requisições que saem do navegador — não podem interceptar o que seu servidor envia para o Meta.
Client-side vs server-side: a comparação direta
Antes de entrar em vantagens e desvantagens, o resumo lado a lado. É essa tabela que responde, em dez segundos, qual modelo cobre cada ponto:
| Critério | Client-side | Server-side |
|---|---|---|
| Onde roda | No navegador do usuário | Em um servidor intermediário (GTM Server-Side) |
| Imunidade a ad blocker | Nenhuma — o domínio de tracking é bloqueável | Alta — o envio sai do servidor, não do navegador |
| Dados comportamentais (scroll, cliques, tempo) | Coleta nativa | Não coleta — continua dependendo do client-side |
| Perda por ITP / ATT (iOS e Safari) | Alta — cookies via JavaScript e identificadores limitados | Baixa — identificadores enviados direto do servidor |
| Custo | Zero de infraestrutura | Servidor 24/7 (a partir de ~US$ 10/mês gerenciado) |
| Complexidade de setup | Baixa — cola o script e pronto | Alta — dois containers, transport URL, mapeamento de eventos |
Vantagens e desvantagens do server-side
Onde o server-side ganha
A vantagem que sozinha justifica a migração é a imunidade a ad blockers e ITP. O envio acontece servidor a servidor: não há script no navegador para uma extensão bloquear no momento do evento de conversão. O que o client-side perde por bloqueio, o server-side entrega.
Junto vem a qualidade do dado. No servidor você tem acesso a informação que o navegador nunca teria: confirmação de pagamento, dados do CRM, histórico do cliente. Você envia um evento Purchase com o valor real da venda e os identificadores do comprador, não uma estimativa montada no browser. E como dá para incluir mais identificadores (FBC, FBP, email e telefone capturados no servidor), o Connect Rate na API de Conversões tende a subir, e Event Match Quality maior significa otimização melhor das campanhas.
Controle e performance: você decide o que enviar, quando e para quem. Quer o mesmo evento indo para Meta, Google, TikTok e um webhook próprio? Configura uma vez no servidor GTM e todos recebem. De quebra, menos scripts de terceiros rodando no navegador ajuda o LCP e os outros Core Web Vitals.
O que você paga por isso
Server-side não sai de graça, e o custo maior não é o do servidor: é a complexidade. A configuração do GTM Server-Side é mais trabalhosa do que a do GTM Web. Você precisa entender os containers client e server, configurar o transport URL e mapear os eventos corretamente entre os dois. Na maioria dos casos é um setup que você faz uma vez, mas que exige quem sabe o que está fazendo.
Tem também um limite que costuma passar batido: o server-side resolve os eventos de conversão, não a coleta de comportamento. Scroll, tempo na página e cliques continuam vindo do JavaScript no navegador. Migrar para o servidor não elimina o client-side, os dois convivem.
Latência e infraestrutura: o evento precisa ir do navegador até o servidor GTM antes de chegar ao Meta, o que adiciona dezenas de milissegundos conforme a região do servidor. Raramente é o suficiente para afetar suas métricas de negócio. E você passa a pagar por um servidor rodando 24/7: à época desta publicação, a opção gerenciada do Stape começa em torno de US$ 10/mês para volumes baixos. Confira o valor atual no site deles.
Quando faz sentido migrar para server-side
A decisão de migrar deve ser baseada em custo vs benefício. As regras gerais:
Migrar faz sentido quando:
- Você gasta mais de R$ 20-30 mil/mês em tráfego pago no Meta — a perda de dados no client-side é cara o suficiente para justificar o custo do servidor
- Seu público tem alta penetração de iOS (ex: mulheres 25-45, nichos de beleza e educação) — o impacto do ATT é maior
- Você precisa enviar dados de múltiplas plataformas (Meta, Google, TikTok) para uma fonte única — o servidor GTM resolve isso de forma elegante
- Você tem requisitos específicos de privacidade que exigem controle sobre os dados antes de enviá-los
Pode esperar quando:
- Seu gasto mensal é abaixo de R$ 10 mil — o custo do servidor pode não justificar
- Você já tem a CAPI configurada via integração nativa da plataforma de vendas (Hotmart, Kiwify) — boa parte do problema já está resolvido sem server-side
- Seu público é majoritariamente Android ou desktop — o impacto do iOS é menor
Obs.: o GTM Server-Side não é binário — você pode migrar gradualmente. Comece pelos eventos de conversão (Purchase, Lead) no servidor e mantenha os comportamentais (PageView, cliques) no client. O ganho de qualidade vem dos eventos de conversão. Antes de decidir migrar, vale medir o score de qualidade do seu container GTM — boa parte do ganho pode estar em corrigir o client-side primeiro.
Stape como opção gerenciada de GTM Server-Side
O Stape (stape.io) é um serviço que gerencia a infraestrutura de GTM Server-Side por você. Em vez de provisionar um servidor no GCP ou AWS, você cria um servidor no Stape em alguns minutos — ele cuida do provisionamento, uptime e escalabilidade.
À época desta publicação, o plano básico do Stape começa em torno de US$ 10/mês para volumes baixos (na casa de 150 mil requests/mês). Confira o valor e os limites atuais no site deles. Para a maioria dos sites de infoprodutos e e-commerce pequeno, esse volume já é suficiente; acima disso, os planos escalam.
A configuração no Stape segue o mesmo processo do GTM Server-Side padrão — você configura o container server no GTM e aponta para o servidor do Stape via transport URL. A diferença é que você não precisa gerenciar a infraestrutura.
Para o passo a passo de configuração do Pixel via GTM (client-side), veja o artigo sobre como instalar o Pixel do Meta com GTM.
FAQ
GTM Server-Side substitui o Pixel do Meta completamente?
Não. O Pixel client-side ainda captura dados comportamentais (scroll, cliques, tempo na página) e o FBC/FBP do navegador. O GTM Server-Side complementa o Pixel para os eventos de conversão. A arquitetura ideal é Pixel client-side + API de Conversões via GTM Server-Side, com deduplicação via event_id.
Preciso de dev para implementar o GTM Server-Side?
A configuração básica não exige dev — é feita no painel do GTM e do Stape. Mas se você precisa enriquecer os eventos com dados do backend (ex: valor real da venda, dados do cliente do CRM), vai precisar de um endpoint no seu servidor que o GTM Server-Side possa chamar. Esse passo pode exigir desenvolvimento.
O servidor GTM fica no meu domínio ou em um domínio separado?
Fica em um subdomínio seu (ex.: metrics.seusite.com.br) apontando para o servidor Stape ou GCP. Esse mapeamento é importante porque requests saindo do seusite.com.br são first-party — menos propensos a serem bloqueados por ad blockers do que requisições para server-gtm-stape.io.
Qual o risco de downtime do servidor GTM?
À época desta publicação, o Stape anuncia SLA de 99,9% de uptime (confira o número vigente no plano que você contratar). De qualquer forma, para eventos críticos como Purchase você deve configurar um fallback: se o envio via API de Conversões falhar, o Pixel client-side ainda está ativo como segundo canal. Para Hotmart e Kiwify, a integração nativa já funciona como backup automático.
A migração para server-side vale pelo que ela recupera: os 20% a 40% de conversões que o client-side deixa na mesa. No Tracker, mais de 85% das vendas chegam com o fbclid capturado e atribuído à campanha certa, mesmo quando o Pixel do navegador é bloqueado. É esse dado que decide para onde a Meta manda o seu orçamento.
Se quiser ver como seus dados de traqueamento chegam ao Tracker, com atribuição real, sessões e perfis, comece os 30 dias grátis.