Rastreamento server-side x pixel: o que muda na prática para quem compra tráfego

Quem compra mídia convive com dois números que nunca batem: o que aparece no gerenciador de anúncios e o que aparece no painel da oferta. A explicação quase sempre está na diferença entre os dois mecanismos de medição que estão rodando ao mesmo tempo — um dentro do navegador, outro entre servidores.

Este artigo trata do que muda operacionalmente entre eles, onde cada um quebra e como montar a estrutura sem depender de um só.

O que é cada coisa, em uma frase técnica

Pixel (client-side): um trecho de JavaScript na página de conversão que, ao ser executado pelo navegador do usuário, envia um evento para a plataforma de anúncios. A identificação de quem converteu depende de cookie, de armazenamento local e do parâmetro de clique que sobreviveu até ali.

Server-side (S2S): o clique gera um identificador único no seu servidor, esse identificador viaja junto com o usuário até o destino, e quando o evento acontece o servidor do destino chama o seu servidor de volta com esse mesmo identificador. Nenhum navegador participa da confirmação.

A consequência prática é direta: no pixel, a medição só existe se o navegador cooperar. No server-side, a medição existe se dois servidores conseguirem trocar uma requisição HTTP.

Onde o pixel quebra

Não é um problema só, são cinco, e eles se acumulam.

1. A conversão não acontece no seu domínio. Se o usuário clica no anúncio, passa pelo seu site e finaliza a compra no checkout do anunciante, seu pixel simplesmente não está naquela página. Você não pode instalar script no domínio de terceiro.
2. A aprovação vem depois. Boleto, Pix pendente, análise antifraude, aprovação de crédito, período de validação da oferta. O pixel dispara na página de obrigado; o dinheiro é confirmado horas ou dias depois, quando o navegador já fechou.
3. Cookies e armazenamento. Restrições de cookie de terceiros, navegadores com proteção antirrastreamento e bloqueadores cortam parte dos disparos. O evento existe, o registro não.
4. Perda de parâmetro no caminho. Redirecionamentos que não repassam a query string, links de app, encurtadores mal configurados e páginas que fazem window.location limpo eliminam o gclid ou fbclid antes da conversão. Esse é o assunto do artigo sobre como gclid, fbclid e ttclid se perdem no caminho.
5. Falha de execução. Página lenta, erro de JavaScript antes da linha do pixel, usuário fechando a aba durante o carregamento. Tudo isso é conversão real sem evento registrado.

Nenhum desses cinco pontos é resolvido escrevendo o pixel melhor. São limites do meio.

Onde o server-side quebra

Server-side não é mágica. Ele tem um conjunto de falhas próprio, e é honesto listá-las:

• Se o identificador não chega ao destino, não volta nada. Toda a cadeia depende de o clique carregar um click_id e de a oferta aceitar e devolver esse valor.
• O destino precisa disparar o postback. Se o merchant não configurou a URL de retorno, ou configurou com o parâmetro errado, o evento não existe do seu lado.
• Duplicação. Sistemas que reenviam o mesmo evento em retry geram contagem dobrada se não houver deduplicação por transação.
• Eventos órfãos. Postback que chega com um click_id desconhecido — normalmente porque o clique veio de outra origem ou o valor foi truncado.

A diferença é que todas essas falhas são auditáveis. Você consegue ver o log, identificar o problema e corrigir. Falha de pixel no navegador de terceiro é invisível por definição.

Comparativo direto

Leia a tabela como divisão de trabalho, não como disputa. Uma coluna serve para ensinar o algoritmo; a outra serve para você decidir onde colocar dinheiro.

Como a cadeia server-side funciona na prática

O fluxo tem quatro etapas e vale detalhar cada uma porque é onde os erros aparecem.

1. O clique gera um identificador

O usuário clica no seu anúncio e cai num link de redirect /r/{slug}. Nesse instante o servidor cria um click_id único e registra o contexto do clique: gclid ou fbclid ou ttclid, utm_source, utm_medium, utm_campaign, utm_term, utm_content, sub1 a sub5, país e dispositivo.

Um link de campanha de Google Ads típico chega assim:

https://track.seudominio.com.br/r/oferta-x
  ?gclid={gclid}
  &utm_source=google
  &utm_medium=cpc
  &utm_campaign=brand-br
  &utm_term={keyword}
  &sub1={campaignid}
  &sub2={adgroupid}

Esses valores de chave entre chaves são macros da própria plataforma, substituídas por ela no momento do clique. O detalhe de configuração de cada uma está em como configurar o rastreamento de Google Ads, os parâmetros de Meta Ads e o setup de TikTok Ads.

2. O redirect leva o identificador adiante

O servidor monta a URL de destino aplicando as macros configuradas na oferta e redireciona. São 33 macros disponíveis — {click_id}, {country}, {keyword}, {campaign_id}, {device} e outras — e uma regra importante: macro que o sistema não reconhece fica intacta. Isso evita quebrar placeholders que a própria rede de afiliados espera receber.

Na prática a URL final fica parecida com:

https://oferta.exemplo.com/lp
  ?aff_sub={click_id}
  &kw=camiseta+preta
  &geo=BR
  &dev=mobile

O parâmetro que carrega o click_id muda de rede para rede: pode ser aff_sub, subid, s1, clickid, transaction_id. O que não muda é a regra — tem que ser um parâmetro que o destino preserve e devolva.

3. O evento acontece e o merchant chama de volta

Quando a conversão é registrada, o servidor do merchant faz uma requisição para a sua URL de postback, carregando o mesmo identificador:

https://track.seudominio.com.br/postback
  ?click_id=8f2c1a7e-4b9d-4e11-9f30-2a5c7d10b4aa
  &event=sale
  &amount=249.90
  &txn_id=PED-99183

Cada merchant nomeia esses campos de um jeito. Por isso o mapeamento é por merchant: qual parâmetro é o evento, qual é o valor, qual é o identificador de transação. O passo a passo dessa configuração está detalhado em como funciona o postback server-side, e um exemplo real de casa de apostas em configuração de postback da Betano e Superbet.

4. A conversão é casada e deduplicada

O sistema encontra o clique original pelo click_id, associa o evento e usa o txn_id para descartar reenvio do mesmo pedido. A partir daí o relatório tem clique, lead, venda, receita e custo no mesmo recorte.

O log é a parte que ninguém valoriza até precisar

Todo postback recebido fica registrado com seu status:

• Casado — encontrou o clique, gravou a conversão.
• Duplicado — mesma transação já registrada, ignorado.
• Órfão — click_id não existe na base.
• Inválido — faltou parâmetro obrigatório ou o formato está errado.

Esse log é o que transforma "o número não bate" em "o merchant está mandando amount com vírgula decimal e o campo esperado é ponto". Sem ele, a conversa com o gerente de afiliados vira opinião. Com ele, vira evidência. É o mesmo raciocínio aplicado nos casos de atribuição quebrada.

O que muda na sua rotina de compra de mídia

Com server-side funcionando, três decisões mudam de base:

Escala. Você para de escalar com base em conversão registrada pelo pixel e passa a escalar com base em conversão confirmada pelo merchant. A diferença entre as duas costuma ser grande em ofertas com aprovação, e é justamente a margem que some.

Corte. Campanha que parecia positiva no gerenciador e negativa no extrato da rede finalmente tem um número intermediário que explica o porquê. A visão por fonte, campanha e dia está em como ler os relatórios.

Custo. Sem integração de API puxando gasto automático, o custo entra por modelo — CPC, CPM ou CPA fixo — ou por lançamento manual por dia e campanha. É menos automático, e em compensação é explícito: você sabe exatamente qual número está sendo usado no cálculo.

Devo desligar o pixel?

Não. A recomendação prática é rodar os dois com papéis definidos:

• Pixel: alimenta o aprendizado da plataforma. É ele que faz o Google, o Meta e o TikTok encontrarem mais gente parecida com quem converteu.
• Server-side: alimenta seu relatório, sua reconciliação com a rede e sua decisão de orçamento.

Quando os dois divergem, a pergunta não é "qual está certo", é "o que essa diferença está dizendo". Pixel maior que postback costuma indicar conversão não aprovada. Postback maior que pixel costuma indicar perda de parâmetro ou bloqueio no navegador. Os dois casos são diagnósticos úteis.

Checklist de implantação

1. Configurar o domínio de tracking próprio por CNAME, com certificado automático, para o clique rodar no seu domínio.
2. Criar o template da fonte de tráfego com o mapa de parâmetro para macro — por exemplo kw={keyword} — conforme o modelo de tracking e atribuição.
3. Montar o link /r/{slug} e testar clicando de verdade, no celular, com rede móvel.
4. Confirmar que o click_id chegou íntegro na URL de destino, sem truncamento e sem codificação dupla.
5. Passar a URL de postback ao merchant e mapear evento, valor e transação.
6. Disparar um evento de teste e abrir o log para confirmar o status "casado".
7. Só então ligar o orçamento de verdade.

Se a etapa 4 falhar, nada depois dela funciona. Vale gastar tempo ali.

Vocabulário e próximos passos

Termos como click_id, postback, S2S, órfão e deduplicação estão descritos no glossário, e as dúvidas mais frequentes de implantação em perguntas frequentes. Se você ainda está avaliando se essa estrutura se paga no seu volume, os planos e limites ajudam a dimensionar. Para entender o conjunto de recursos, comece pela visão geral da plataforma.

Nada aqui garante resultado de campanha. O que a estrutura server-side entrega é medição que não depende do navegador do usuário — e, com isso, decisões tomadas sobre um número que você consegue auditar.