Guia de fundamentos
Rastreamento server-side vs ferramentas de UTM tradicionais
Atualizado em 20 de agosto de 2026
Rastreamento server-side é quando os eventos de conversão são coletados e enviados por um servidor rodando no domínio da própria marca, em vez de dependerem só de um script de terceiro no navegador. Ferramentas tradicionais de UTM leem parâmetros de URL no navegador e param aí: quando o iOS, um adblocker ou o bloqueio de cookies corta o script, o evento se perde e a venda fica sem origem.
Como funciona o rastreio tradicional por UTM
O modelo clássico é simples: o anúncio carrega parâmetros de UTM na URL, um script no navegador lê esses parâmetros, grava um cookie e tenta casar a venda com a origem quando o checkout dispara o webhook. Funciona bem no cenário ideal: mesmo navegador, mesmo dispositivo, cookie vivo e script carregado.
O problema é que o cenário ideal ficou raro. O iOS limita a vida de cookies, os adblockers cortam scripts de rastreio conhecidos, navegadores bloqueiam third-party por padrão e boa parte das jornadas troca de dispositivo no meio do caminho. Cada uma dessas condições derruba uma parte dos eventos, e a conta chega no gestor de tráfego: vendas sem origem, ROAS distorcido e algoritmo otimizando com dado incompleto.
No Brasil tem um agravante que ferramenta genérica ignora: a venda muitas vezes nem acontece no site. Ela fecha no WhatsApp, num boleto compensado dias depois ou num pagamento na entrega. Para o rastreio por UTM puro, tudo isso é invisível.
O que muda com server-side first-party
No modelo da Metrito, você aponta um subdomínio do seu próprio domínio (por exemplo, sst.suamarca.com) para a infraestrutura de rastreio. O navegador passa a tratar o pixel como first-party: mesmo dono, mesma origem. Em paralelo, os eventos também são coletados no servidor, e as duas vias são deduplicadas, então o evento que o navegador perdeu chega pela via do servidor.
O retorno pro algoritmo muda junto. Em vez de depender do que o pixel do navegador conseguiu ver, as compras confirmadas pelo checkout voltam para o Meta Ads via API de Conversões com correspondência avançada de dados. O algoritmo aprende com a venda real, incluindo a que fechou no WhatsApp ou no boleto compensado.
Comparação lado a lado
| Critério | Ferramenta de UTM tradicional | Metrito (server-side first-party) |
|---|---|---|
| Onde o rastreio roda | Script e domínio de terceiro, tratado como third-party pelo navegador | Subdomínio do seu próprio domínio (first-party de verdade) |
| iOS, adblockers e cookies bloqueados | Eventos se perdem quando o navegador corta script ou cookie de terceiro | Redundância navegador + servidor com deduplicação de eventos |
| Venda no WhatsApp | A jornada morre no clique; a venda no chat fica invisível | Conversa ligada ao clique de origem, do anúncio à venda fechada no chat |
| Retorno pro algoritmo | Só o que o pixel do navegador conseguiu ver | Eventos server-side via API de Conversões com correspondência avançada |
| Contexto Brasil | UTM genérica, sem noção de gateway, Pix, boleto ou COD | Integrações nativas com checkouts e gateways brasileiros, Pix, boleto e COD |
| Auditoria do dado | Caixa-preta: você confia no número que aparece | Timeline e payload de cada evento auditáveis, evento a evento |
Quando uma ferramenta de UTM dá conta
Nem toda operação precisa de server-side no dia um. Se você vende só no site, com checkout que preserva UTMs, volume baixo e sem WhatsApp no funil, uma ferramenta de UTM simples resolve o básico por menos. A troca passa a valer quando a perda de eventos vira dinheiro: escala em iOS, funil com WhatsApp, boleto ou COD, ou decisões de orçamento tomadas em cima de ROAS que você não consegue auditar.
Como a Metrito implementa isso
A Metrito instala o rastreio server-side sem desenvolvedor: você aponta um subdomínio, instala um script único e conecta o checkout por webhook. São dezenas de integrações nativas com plataformas brasileiras, como Hotmart, Kiwify, Payt e Kirvano, além do rastreamento de conversas do WhatsApp do clique à venda.