Existe uma conta que todo anunciante já fez de cabeça e quase ninguém fez no papel: o número de vendas que a plataforma de pagamento mostra e o número que o Gerenciador de Anúncios mostra não batem. Nunca batem. E a diferença quase sempre vai para o mesmo lugar — a conclusão de que “o Meta é impreciso” — quando a causa costuma estar antes disso, no jeito como o dado sai da página de vendas.
Este texto é sobre essa diferença: por que ela existe, quanto ela custa, e o que muda quando o rastreamento deixa de depender do navegador de quem comprou.
Como funciona o rastreamento que só roda no navegador
No modelo clássico, tudo acontece na máquina do visitante. Um script carrega na sua página de vendas, lê os parâmetros da URL, grava um cookie, e quando a compra é confirmada dispara um evento direto do navegador para a Meta. É simples, é o padrão há uma década, e funciona — quando funciona.
- Visitante clica no anúncioos parâmetros chegam na URL
- O script precisa carregarBloqueador de anúncio impede
- O cookie precisa sobreviverNo iOS, sete dias — ou um
- O evento sai do navegadorse as duas etapas acima passaram
São três pontos de falha em sequência, e nenhum deles avisa quando falha. O script não quebra a página, o cookie não some com alarde, e o evento que não sai não deixa rastro nenhum — nem no seu painel, nem no console do navegador. O sintoma é sempre o mesmo e sempre tardio: um número menor que a realidade, que parece apenas um mês ruim.
Bloqueador de anúncio
As listas de bloqueio mais usadas incluem o domínio do pixel da Meta por padrão. Não é preciso configurar nada: quem instalou a extensão para não ver propaganda também parou de ser contado. As estimativas de adoção no Brasil variam bastante conforme a fonte e o público — em audiência mais jovem e mais técnica, a fatia é maior. O ponto não é cravar a porcentagem, é entender que ela não é zero e você não controla.
As restrições do navegador
O Safari limita a vida de cookies gravados por JavaScript a sete dias, e a um dia quando o visitante chegou por um link com parâmetros de rastreamento — que é exatamente o caso de quem vem de anúncio. O Firefox bloqueia rastreadores conhecidos por padrão. O Chrome vem apertando o cerco há anos.
Para uma venda que acontece no mesmo dia, isso não muda nada. Para o boleto pago em dois dias, para o Pix gerado à noite e pago de manhã, ou para quem viu o anúncio na segunda e comprou na quinta, a ligação entre o clique e a venda simplesmente não existe mais quando a compra acontece.
O que muda no server-side
A ideia é tirar o navegador do caminho crítico. Em vez de o dado sair da máquina do visitante, ele sai de um servidor que você não precisa manter — e chega em outro pelo mesmo caminho.
- Visitante clica no anúncioos parâmetros chegam na URL
- A plataforma de pagamento confirmaHotmart, Kiwify, Cakto, Wiapy
- Webhook, servidor a servidoro navegador não participa
- API de Conversões da Metao Purchase sai do servidor
Repare no que sumiu: não há passo que dependa de o script carregar nem de o cookie sobreviver. Quando o pagamento é confirmado, a plataforma avisa diretamente, e a conversão volta para a Meta pela API de Conversões — o caminho oficial que a própria Meta criou justamente porque o pixel de navegador parou de dar conta.
Server-side não é o mesmo que sem script
O script continua existindo, e continua sendo necessário: é ele que captura de qual anúncio a pessoa veio, no momento em que ela chega na página. Sem isso, a venda entra sem campanha — você sabe que vendeu, mas não sabe a quem agradecer.
O que muda é que ele deixa de ser o único caminho. Ferramenta que promete rastreamento “100% server-side, sem script” está descrevendo algo que não existe: alguém precisa observar a chegada.
O elo entre os dois caminhos
Fica uma pergunta óbvia: se o webhook vem da plataforma de pagamento, e a plataforma não sabe nada de anúncio, como a venda encontra a campanha que a gerou?
Pelo campo livre. Toda plataforma de vendas séria devolve, no webhook, os parâmetros que estavam na URL do checkout — a Hotmart chama de src e sck, a Kiwify agrupa em TrackingParameters, a Cartpanda usa os mesmos nomes da Hotmart. O script empacota o identificador do clique ali antes de mandar a pessoa para o checkout:
u1.<id do clique>.<campanha>.<conjunto>.<anúncio>Esse texto atravessa o checkout, é gravado pela plataforma junto do pedido, e volta no webhook. Do outro lado, o identificador reencontra o clique guardado e a venda nasce com a campanha certa.
A consequência prática é a que mais surpreende quem está comparando ferramentas: a venda é atribuída ao anúncio correto mesmo quando o script foi bloqueado no momento da compra — desde que a pessoa tenha chegado pelo link rastreado. O elo já estava na URL do checkout antes de qualquer bloqueador entrar em cena.
Por que manter os dois, e não só o servidor
A pergunta natural é: se o servidor é mais confiável, por que não desligar o pixel do navegador?
Porque a Meta usa os dois para coisas diferentes, e porque eventos duplicados não são um problema — são o desenho previsto. Cada evento leva um identificador próprio, e quando o mesmo evento chega pelos dois caminhos, a Meta descarta o segundo e fica com o mais completo. É o que a documentação dela chama de deduplicação, e é por isso que enviar pelos dois lados é melhor que escolher um.
| Só navegador | Só servidor | Os dois | |
|---|---|---|---|
| Sobrevive a bloqueador | não | sim | sim |
| Sobrevive a limite de cookie | não | sim | sim |
| Vê o comportamento na página | sim | não | sim |
| Dados de correspondência do comprador | parcial | sim | sim |
| Nota de correspondência do evento | menor | maior | maior |
Como conferir o seu
Não é preciso acreditar em ninguém — dá para medir. Três verificações, na ordem em que costumam revelar problema:
- Compare os totais. Pegue as vendas aprovadas de uma semana na sua plataforma de pagamento e as conversões que o Gerenciador de Eventos registrou no mesmo período. Uma diferença de poucos por cento é normal e esperada. Uma diferença de dois dígitos é rastreamento perdendo evento.
- Abra a sua página com um bloqueador ligado. Se a venda feita nessa sessão não aparecer no seu painel de rastreamento, você acabou de reproduzir o que acontece com uma fatia dos seus visitantes todos os dias.
- Olhe a nota de correspondência no Gerenciador de Eventos. Se o Purchase está abaixo de 6, faltam dados de correspondência — e o caminho de servidor é justamente o que consegue enviá-los, porque a plataforma de pagamento conhece o comprador e o navegador não.
O erro que ninguém vê chegar
Rastreamento não falha com erro na tela. Ele falha com um número menor, e número menor se confunde com mês fraco. Quando a diferença aparece no relatório, ela já custou semanas de decisão tomada com dado incompleto — campanha pausada que estava dando lucro, criativo desligado que estava vendendo.
É por isso que vale conferir mesmo quando parece que está tudo bem. Especialmente quando parece.
Em uma frase
Rastreamento de navegador depende de três coisas fora do seu controle: o script carregar, o cookie sobreviver e o visitante não usar bloqueador. Rastreamento server-side depende de a plataforma de pagamento avisar que houve uma venda — que é a única coisa dessa lista pela qual alguém já está pagando para acontecer.
Veja como fica no seu caso
O UTMizey recebe a venda pelo webhook da plataforma de pagamento e devolve a conversão pela API de Conversões — sem depender do navegador de quem comprou. A instalação são duas colagens geradas prontas no painel: o script na página de vendas e a URL do webhook na plataforma. Não há VPS para manter nem programador para chamar, e o plano gratuito não pede cartão.