O modelo ideal de rastreamento do Facebook, de ponta a ponta

Navegador sozinho perde evento; servidor sozinho perde match. O modelo que funciona usa os dois com o mesmo event_id — e uma camada de identidade que faz a venda do checkout voltar ao anúncio dias depois. A arquitetura completa, com os erros que já vimos custarem caro.

Quem opera tráfego no Meta convive com três números que nunca batem: o do gestor de anúncios, o do checkout e o da planilha. Uma parte disso é inevitável — janela e modelo de atribuição são decisões do Meta. Mas a parte maior tem conserto, e o conserto tem nome: arquitetura de rastreamento. Este texto descreve o modelo que consideramos ideal — o que montamos para os nossos clientes e usamos nas nossas próprias campanhas.

Por que um caminho só não basta

O pixel no navegador vê o contexto que importa para o match — o cookie do navegador (fbp) e o clique do anúncio (fbc) — mas é bloqueado por adblock, encurtado pelo iOS e morre quando a compra acontece fora do site, no checkout de terceiro. O servidor não é bloqueado por ninguém e sabe da venda com certeza — mas, sozinho, não tem fbp nem fbc, e o Meta não consegue ligar o evento ao clique que o gerou.

A pergunta certa não é "pixel ou API de conversões?". É "como mando o MESMO evento pelos dois caminhos sem contar duas vezes?" — e a resposta é um identificador compartilhado: o event_id.

O modelo em quatro peças

1. 01Um pixel first-party no site, que coleta os eventos, captura o fbclid na chegada e gera o fbp por conta própria — sem depender do script do Meta, que é o primeiro que o adblock derruba.
2. 02O espelhamento para o pixel do Meta no navegador, com um event_id único por evento.
3. 03O mesmo evento saindo pelo servidor via Conversions API, com o MESMO event_id — o Meta deduplica e conta uma vez.
4. 04Uma camada de identidade no meio: quem é essa pessoa, que e-mail e telefone ela já deixou, de que cliques ela veio. É ela que enriquece o evento de servidor com dados que o navegador daquele momento não tem.

EMQ: o número que decide o seu CPA

O Event Match Quality mede quanto dos seus eventos o Meta consegue ligar a uma pessoa logada. A conta é direta: evento que não casa com ninguém não vira conversão atribuída, não ensina o algoritmo e não otimiza a entrega. Elevar o EMQ é o trabalho de maior alavancagem em rastreamento — e ele sobe com parâmetros de identidade: e-mail, telefone, fbc, fbp, ID estável e geografia.

Aqui está o motivo de o modelo precisar de uma camada de identidade, e não só de dois scripts. O evento de compra que chega do checkout não traz cookie nenhum. Mas se a plataforma sabe que aquele comprador é o visitante que clicou no anúncio na terça, o evento de servidor sai com fbc, fbp, e-mail e telefone juntos — um evento de servidor com match de navegador. Nos nossos números, é a diferença entre um Purchase que o Meta aproveita e um que ele ignora.

A venda que acontece longe do site

Em infoproduto e e-commerce com checkout de terceiro (Hotmart, Kiwify), a compra acontece fora do seu domínio — às vezes dias depois do clique, em outro dispositivo. O elo é um identificador de sessão injetado no link do checkout. Quando o webhook da venda chega, ele liga a compra ao visitante, e o Purchase sai pelo CAPI com a atribuição inteira: campanha, conjunto, anúncio.

Um detalhe que medimos em produção: a Hotmart corta o campo de rastreio (sck) em 283 caracteres. Se o identificador de sessão estiver no FIM do template, ele é sempre a vítima do corte — e a venda cai para atribuição por identidade, mais fraca. No INÍCIO, o corte leva só a cauda das UTMs. Um caractere de posição, pontos de atribuição.

Os cinco erros que mais custam

1. 01Duplicar eventos — navegador e servidor sem event_id compartilhado. A conversão infla, o algoritmo aprende errado e a confiança no número morre.
2. 02Disparar Purchase no evento errado — boleto gerado e PIX criado não são venda. Só venda aprovada vira Purchase; o resto é outro evento.
3. 03Re-disparar a mesma venda — sincronização de histórico que reprocessa o pedido não pode emitir Purchase de novo. Idempotência por transação é obrigatória.
4. 04Ignorar o EMQ — mandar evento "pelado", sem e-mail, telefone ou fbp, e estranhar o CPA. O Events Manager mostra a nota por evento; olhe.
5. 05Testar em produção — o test_event_code existe para validar o fluxo inteiro antes de um real gastar verba com evento quebrado.

Como saber se o seu está certo

• No Events Manager: cada evento aparece com as duas origens (navegador + servidor) e a marca de deduplicação.
• EMQ dos eventos de fundo de funil (Purchase, Lead) em "Bom" ou acima.
• Cobertura de fbc/fbp na maioria dos eventos — se o fbp depende só do script do Meta, o adblock está comendo uma fatia.
• Uma venda de teste do checkout aparecendo no Meta com campanha, conjunto e anúncio atribuídos.

É exatamente esse modelo que o CrazyLeads monta: o pixel first-party espelha o fbq com event_id compartilhado, o grafo de identidade enriquece o evento, e os Envios entregam pelo CAPI com filtro e mapeamento medidos contra eventos reais. O passo a passo está no guia de rastreamento ideal para o Meta, na documentação.