O modelo ideal de rastreamento para o Meta
A arquitetura completa: pixel no navegador e Conversions API no servidor com o mesmo event_id, identidade first-party para elevar o EMQ, e a venda do checkout voltando ao anúncio dias depois.
Rastreamento só no navegador perde o que o adblock e o iOS bloqueiam. Rastreamento só no servidor perde o contexto do navegador (fbp, fbc) que faz o Meta casar o evento com o clique. O modelo ideal usa os dois — o mesmo evento pelos dois caminhos, com o mesmo event_id, e o Meta descarta a cópia. Este guia mostra como o CrazyLeads monta isso de ponta a ponta.
A arquitetura em uma imagem
- 01O pixel CrazyLeads roda no site: coleta pageviews e eventos, captura fbclid, gera fbp first-party e resolve a identidade do visitante.
- 02No navegador, o evento vai ao pixel do Meta (fbq) com um event_id único.
- 03No servidor, o mesmo evento sai pela Conversions API com o MESMO event_id — enriquecido com e-mail, telefone e geografia do grafo de identidade.
- 04O Meta deduplica pelo event_id: contou uma vez, com o melhor dos dois mundos.
Duplicação é o erro mais caro: evento contado duas vezes infla conversão, engana o algoritmo de otimização e corrói a confiança no número. A deduplicação por event_id não é opcional — é a peça central do modelo.
Event Match Quality: o que decide o custo
O EMQ (Event Match Quality) mede quanto do evento o Meta consegue ligar a uma pessoa logada. EMQ alto = mais conversões atribuídas = otimização melhor = CPA menor. Cada parâmetro de user_data soma:
| Parâmetro | De onde o CrazyLeads tira | Peso no match |
|---|---|---|
| em / ph (e-mail, telefone) | Grafo de identidade: formulários, checkout, identify | Os mais fortes |
| fbc (clique do anúncio) | Construído do fbclid na chegada — não depende do cookie do Meta | Forte |
| fbp (cookie do navegador) | Gerado first-party pelo pixel; sobrevive a adblock do fbevents | Forte |
| external_id | ID estável do lead no CDP (enviado com hash) | Médio |
| ct / st / zp (geografia) | Endereço declarado no checkout, senão geolocalização da visita | Médio |
É aqui que um CDP muda o jogo: o evento de compra da Hotmart não traz cookie nenhum — mas o grafo sabe qual visitante virou aquele comprador, e o CAPI sai com fbc, fbp, e-mail e telefone juntos. Evento de servidor com match de navegador.
A venda voltando ao anúncio (server-side)
O clique acontece no site; a compra, no checkout da Hotmart ou Kiwify — às vezes dias depois, em outro dispositivo. O elo é um identificador nosso (cl_ussid) que o pixel injeta no link do checkout (parâmetros sck/xcod). Quando o webhook da venda chega, o identificador liga a compra ao visitante, e o Purchase sai pelo CAPI com a atribuição inteira.
Regra aprendida em produção: se o seu checkout monta o sck com UTMs, ponha o cl_ussid no INÍCIO do template. A Hotmart corta o campo em 283 caracteres — no fim, o identificador é sempre a vítima; no início, o corte leva só a cauda das UTMs.
Montando no CrazyLeads
- 01Instale o pixel no site (guia "Instalar o pixel") e cadastre o pixel do Meta na fonte — o fbq passa a ser espelhado com event_id compartilhado.
- 02Crie o destino Meta CAPI em Envios, com o token de System User do Events Manager, e teste a conexão.
- 03Crie um Envio por evento que importa: Purchase (venda aprovada), Lead, InitiateCheckout — com filtro (ex.: status APPROVED) e mapeamento medidos contra eventos reais na própria tela.
- 04Confira no painel de Qualidade do destino a cobertura de cada parâmetro (em, ph, fbc, fbp) — e no Events Manager, o EMQ e a deduplicação.
Checklist do modelo ideal
- Navegador E servidor enviando o mesmo evento com o mesmo event_id (dedup visível no Events Manager).
- Purchase disparando UMA vez por venda — venda aprovada, não boleto gerado nem PIX expirado.
- fbc e fbp presentes na maioria dos eventos (cobertura no painel de Qualidade).
- E-mail e telefone chegando nos eventos de fundo de funil.
- cl_ussid no início do sck do checkout.
- test_event_code usado ANTES de ligar o tráfego real.
O porquê de cada peça — e os erros que já vimos custarem caro — está no artigo completo do blog sobre o modelo ideal de rastreamento, e o detalhe do payload na referência técnica de Envios.