Traqueamento client-side significa que o script roda no navegador do usuário e coleta 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. A diferença parece técnica, mas o impacto na qualidade dos dados é direto e mensurável.
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 entender a API de Conversões — que é a implementação server-side mais relevante para o Meta — 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 ser superior 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 iOS 14, usuários de iPhone podem recusar rastreamento de apps e Safari. Quando recusam, o Meta não recebe os identificadores que precisaria para associar o clique no anúncio à compra posterior.
A soma desses fatores resulta em perda estimada de 20-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.
O fluxo: usuário compra → seu servidor recebe a confirmação → seu servidor envia para a API do Meta → dado chega na plataforma.
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.
Vantagens do server-side sobre client-side
1. Imunidade a ad blockers e ITP: o envio acontece servidor a servidor. Não há script no navegador para bloquear no contexto dos eventos de conversão.
2. Dados mais ricos e confiáveis: no servidor, você tem acesso a informações que o navegador nunca teria — dados do banco de dados, confirmação de pagamento real, dados do CRM, histórico do cliente. Você envia um evento Purchase com valor real, produto real e dados do comprador — não uma estimativa.
3. Controle total sobre os dados: você decide o que enviar, quando enviar, e para quem. Quer enviar o mesmo evento para Meta, Google, TikTok e um webhook customizado? Configura uma vez no servidor GTM e todos recebem.
4. Melhor Connect Rate na CAPI: como você pode incluir mais identificadores (FBC, FBP, email, telefone capturados no servidor), o Event Match Quality tende a ser maior do que em implementações client-side.
5. Performance de página: menos scripts de terceiros rodando no navegador pode melhorar LCP e outros Core Web Vitals.
Desvantagens e limitações do server-side
1. Custo de infraestrutura: você precisa pagar por um servidor rodando 24/7. O Stape (opção gerenciada) começa em US$ 10/mês para volumes baixos. No GCP ou AWS diretamente, o custo é similar — mas exige mais configuração.
2. Complexidade de setup: a configuração do GTM Server-Side é mais trabalhosa do que a do GTM Web. Você precisa entender containers client e server, configurar o transport URL, e mapear os eventos corretamente entre os dois containers.
3. Dados comportamentais ainda são client-side: scroll, tempo na página, cliques — esses dados comportamentais ainda vêm do JavaScript no navegador. O server-side resolve eventos de conversão, não a coleta de comportamento.
4. Latência adicional: o evento precisa ir do navegador ao servidor GTM antes de chegar ao Meta. Para eventos de PageView em tempo real, isso pode adicionar uns poucos milissegundos — geralmente irrelevante.
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.
O plano básico do Stape começa em US$ 10/mês para volumes baixos (até 150 mil requests/mês). Para a maioria dos sites de infoprodutos e e-commerce pequeno, esse volume é suficiente. Para volumes maiores, 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?
Com o Stape, o SLA é de 99.9% de uptime. Para eventos críticos como Purchase, você deve configurar um fallback: se o envio via CAPI falhar, o Pixel client-side ainda está ativo como segundo canal. Para o Hotmart e Kiwify, a integração nativa já é um backup automático.
Se quiser ver como seus dados de traqueamento chegam ao Tracker — atribuição real, sessões, perfis — comece os 30 dias grátis.