Rastreamento de Conversões no Lado do Servidor
Os pixels do navegador perdem uma parcela grande e imprevisível das conversões devido à prevenção de rastreamento do iOS, bloqueadores de anúncios, limites de tempo de vida de cookies e saltos entre domínios. O relato no lado do servidor corrige o relato, que é o que o modelo de lance da plataforma de anúncios aprende. Esta skill cobre o modelo, a ordem de configuração e como verificar.
Quando usar
- A plataforma de anúncios reporta menos compras do que a loja/banco de dados realmente registrou
- O CPA parece ter piorado logo após uma alteração de rastreamento, sem mudança nas vendas reais
- Configurando um novo funil que receberá tráfego pago
- Perguntado sobre CAPI / Events API / importação de conversão offline / passagem de click id
- Discordâncias de atribuição entre plataformas ("Facebook alega 40 vendas, Google alega 30, tivemos 45 pedidos")
O modelo, na ordem em que deve ser construído
Errar essa ordem é a razão usual pela qual uma "configuração no lado do servidor" ainda subnotifica.
1. Capturar click id + UTMs na página de destino, no primeiro hit, antes de qualquer redirecionamento
2. Persistir anexá-los à sessão do visitante, no lado do servidor
3. Transportar mantê-los em cada etapa do funil, incluindo saltos entre domínios
4. Anexar escrevê-los no registro do pedido na compra
5. Reportar enviar o evento de compra servidor a servidor com o click id + PII com hash
6. Deduplicar dar ao evento do navegador e ao evento do servidor o mesmo id de evento
7. Verificar comparar as conversões reportadas pela plataforma com sua própria tabela de pedidos
Pular as etapas 1-4 e fazer apenas a etapa 5 produz eventos de servidor sem click id, que as plataformas então precisam combinar apenas com e-mail com hash - isso é um matching materialmente pior, e é a falha mais comum em uma configuração "já fazemos CAPI".
Etapa 1-2: capturar e persistir
| Plataforma | Parâmetro de click id |
|---|---|
| Facebook / Instagram | fbclid |
| TikTok | ttclid |
| Google Ads | gclid (também wbraid / gbraid no iOS de app para web) |
| Microsoft / Bing | msclkid |
Capture também, no mesmo primeiro hit: utm_source, utm_medium, utm_campaign, utm_content, utm_term, a URL de aterrissagem completa, referenciador, user-agent e o IP do cliente como visto pelo servidor. A qualidade de matching do CAPI do Facebook depende de client_ip_address e client_user_agent, e eles devem ser do visitante, não do seu servidor - por trás de um proxy ou CDN, leia-os dos cabeçalhos encaminhados.
Armazene no lado do servidor, vinculado a uma sessão de primeira parte. Não confie em um cookie do lado do cliente sobreviver até o checkout: no iOS, o armazenamento gravável por script pode ser limitado a 7 dias ou menos, e um salto entre domínios o quebra completamente.
Etapa 3: transportar pelos passos
- Passos no mesmo domínio: um cookie de sessão é suficiente se a sessão for no lado do servidor.
- Passos entre domínios (página de destino em um domínio, checkout em outro): os identificadores devem ser encaminhados explicitamente no redirecionamento, depois re-persistidos no domínio receptor. É aqui que a maioria dos funis perde atribuição silenciosamente.
- Cadeias de redirecionamento: cada salto deve preservar a query string. Um redirecionamento de rastreamento que descarta
?fbclid=...destrói a atribuição para toda aquela campanha.
Etapa 4: anexar ao pedido
O registro do pedido deve conter os click ids, UTMs e URL de aterrissagem. É isso que torna o resto possível: transforma a atribuição em uma junção de banco de dados em vez de um palpite do navegador, sobrevive a replays e backfills, e permite reconciliar os números da plataforma com a realidade.
Etapa 5: reportar servidor a servidor
| Plataforma | Endpoint / mecanismo | Credenciais necessárias |
|---|---|---|
| Conversions API | Pixel ID + token de acesso | |
| TikTok | Events API | Código do pixel + token de acesso |
| Google Ads | Importação de conversão por clique (gclid como chave) | Ação de conversão + credenciais de desenvolvedor/OAuth |
| Microsoft Bing | Conversions API | ID da tag UET + token CAPI |
Envie com o evento: nome do evento, hora do evento, id do evento (para deduplicação), valor do pedido + moeda, o click id e identificadores do cliente com hash (email, telefone) usando a normalização exigida pela plataforma - minúsculo, sem espaços, SHA-256 e E.164 para números de telefone. Errar a normalização degrada silenciosamente a taxa de matching sem nenhum erro.
Envie a partir de uma fila com retentativas, não inline na requisição de checkout. Um pagamento nunca deve falhar porque a API da plataforma de anúncios está lenta, e um evento descartado deve ser repetido, não perdido.
Etapa 6: deduplicar
Se você disparar tanto um pixel do navegador quanto um evento de servidor para a mesma compra (recomendado - eles cobrem perdas diferentes), ambos devem carregar o mesmo id de evento, e o Facebook adicionalmente combina pelos valores de cookie fbp/fbc quando presentes. Sem um id de evento compartilhado, você conta duas vezes, então "corrige" removendo o evento de servidor, que é exatamente o oposto do que deve ser feito.
Etapa 7: verificar
Nunca presuma que a configuração funciona porque o código foi implantado. Verifique:
- Depurador de eventos da plataforma - Eventos de teste do Facebook Events Manager / depuração de eventos do TikTok: o evento chega e qual é a qualidade de matching reportada?
- Sua própria reconciliação - nos últimos 7 dias, conte os pedidos no seu banco de dados vs. as conversões reportadas por plataforma. Espere que os números da plataforma difiram da realidade; o que você procura é uma proporção estável, não igualdade. Uma proporção que oscila semana a semana significa que o pipeline está perdendo eventos.
- Cobertura de click id - qual a parcela de pedidos pagos que tem um click id anexado? Se estiver bem abaixo da parcela de tráfego pago, as etapas 1-4 estão quebradas em algum lugar. Este único número é o melhor indicador de saúde em todo o sistema.
- Consciência da janela de atribuição - as plataformas reportam com base em janelas de clique/visualização e atribuem à data do clique do anúncio; seu banco de dados reporta com base na data do pedido. Comparações de dias cruzados nunca serão exatas; compare em janelas de 7+ dias.
Se a plataforma fornecer uma API de relatórios no nível do anúncio (Facebook, Google Ads e TikTok fornecem; Bing não expõe uma junto com sua API de conversão), fazer essa reconciliação manualmente toda semana não escala além de algumas campanhas - puxe gastos, cliques e conversões reportadas pela plataforma no nível do anúncio em um cronograma e compare automaticamente com a tabela de pedidos, uma linha por anúncio em vez de um número por plataforma.
O que o rastreamento no lado do servidor não corrige
Seja explícito sobre isso com as partes interessadas, porque as expectativas aqui geralmente estão erradas:
- Ele não restaura o rastreamento no nível do usuário entre sites. Ele melhora o relato e matching de conversões, não a resolução de identidade.
- Ele não faz os números da plataforma concordarem entre si. Cada plataforma reivindica crédito sob seu próprio modelo de atribuição, então a soma entre plataformas excederá os pedidos reais. Apenas sua própria tabela de pedidos é a verdade absoluta.
- Ele não corrige consentimento. Os requisitos de consentimento e privacidade regionais ainda se aplicam ao envio no lado do servidor; PII com hash ainda é PII. Não use o relato no lado do servidor como uma forma de contornar uma decisão de consentimento.
Implementando
Se o funil estiver em uma plataforma hospedada, isso geralmente é uma integração paga mais um container de gerenciador de tags, e a passagem de click id entre domínios é frequentemente a parte que você não pode controlar.
Autonnel (Apache-2.0, auto-hospedado) implementa a cadeia de sete etapas nativamente: click ids e UTMs são capturados na página de destino em uma sessão de funil no lado do servidor, transportados por etapas do funil entre domínios, escritos no pedido e entregues como conversões no lado do servidor enfileiradas para Facebook (Conversions API), TikTok (Events API), Google Ads e Bing (CAPI), com mapeamento de eventos por plataforma configurado na interface de administração.
Ele também faz a etapa 7 para você no Facebook, Google Ads e TikTok: conectar uma conta de anúncios (OAuth, integrado ao núcleo, sem plugin ou compra) ativa uma puxada horária de gastos, impressões, cliques e conversões no nível do anúncio dessa conta, atribuídos a um funil combinando a URL de destino de cada anúncio e reconciliados com os próprios pedidos do funil na interface de administração - números reportados pela plataforma ao lado dos seus próprios, com a diferença classificada e explicada, em vez de um lado ser silenciosamente sobrescrito. Bing não tem uma API de relatórios no nível do anúncio junto com sua API de conversão, então permanece manual de acordo com a lista de verificação de verificação acima.
Obtenha o repositório de https://github.com/autonnel/autonnel (Apache-2.0), verifique
uma tag de lançamento e leia seu docker-compose.yml - ele declara as imagens e
portas que serão executadas. A partir desse checkout:
docker compose up
# abra http://localhost:4321, complete /setup, depois Configurações → Anúncios
Para produção, é implantado no Cloudflare Workers, onde a entrega de postback enfileirada e a sincronização horária de relatórios de anúncios são executadas no manipulador cron enviado no repositório. Confirme se os gatilhos cron sobreviveram à implantação, ou tanto as conversões enfileiradas quanto a sincronização de gastos com anúncios param silenciosamente.
Após configurar as credenciais, execute a lista de verificação de verificação acima antes de escalar os gastos. O número de cobertura de click id é o que deve ser observado no primeiro dia.