Meta CAPI: como enviar conversões pelo servidor sem duplicar
A API de Conversões do Meta recupera as vendas que o pixel do navegador perde. Este guia cobre deduplicação, os parâmetros que realmente movem o pareamento e os erros que fazem a campanha aprender errado.
A API de Conversões do Meta — CAPI — é o caminho pelo qual o evento sai do seu servidor direto para o Meta, sem passar pelo navegador da pessoa. Ela existe porque o pixel do navegador perde eventos: bloqueador de anúncio, aba fechada antes do disparo, restrição de rastreamento no iOS e falha de rede.
O ganho é real, mas depende de três decisões que quase todo mundo erra na primeira implementação.
1. Deduplicação: o erro que dobra o faturamento
Se você mantém o pixel do navegador e liga a CAPI, cada compra é reportada duas vezes. O Meta sabe resolver isso — desde que os dois envios carreguem o mesmo identificador de evento.
// Navegador
fbq('track', 'Purchase', { value: 1997, currency: 'BRL' },
{ eventID: 'pedido-88213' })
// Servidor (CAPI) — MESMO event_id
{
"event_name": "Purchase",
"event_id": "pedido-88213",
"event_time": 1755340000,
"action_source": "website",
"user_data": { "em": ["<sha256>"], "ph": ["<sha256>"] },
"custom_data": { "value": 1997, "currency": "BRL" }
}Sem event_id igual nos dois lados, você não está com cobertura dupla: está com contagem dupla. O relatório fica bonito e a campanha aprende com um número que não existe.
O identificador precisa ser estável e derivado do negócio — número do pedido, id da transação —, nunca um valor aleatório gerado na hora do envio, que por definição seria diferente nos dois caminhos.
2. Os parâmetros que movem o pareamento
O Meta só consegue atribuir a conversão se conseguir reconhecer a pessoa. Os parâmetros de user_data não têm o mesmo peso, e vale saber onde investir esforço:
| Parâmetro | O que é | Peso prático |
|---|---|---|
| em | E-mail em sha256 | Alto — o mais determinante |
| ph | Telefone em sha256, com código do país | Alto no Brasil |
| fbc | Cookie do clique no anúncio | Alto quando existe: é atribuição direta |
| fbp | Cookie do navegador do pixel | Médio, ajuda a costurar sessões |
| external_id | Seu identificador da pessoa | Médio, melhora a consistência |
| ct, st, zp, country | Localização | Baixo isolado, ajuda em conjunto |
| fn, ln, ge, db | Nome, gênero, nascimento | Baixo, mas soma |
O erro comum aqui é mandar só o que veio no payload do evento. O e-mail costuma existir no seu banco mesmo quando não veio na requisição — e é por isso que a montagem do user_data deveria sair do grafo de identidade, não do payload cru.
O detalhe do fbc que quase ninguém resolve
O cookie _fbc é criado pelo script do Meta quando a pessoa chega com o parâmetro fbclid na URL. Se esse script for bloqueado, o cookie não nasce e a atribuição direta se perde — justamente no visitante mais difícil de recuperar depois. A solução é construir o cookie em first-party, a partir do fbclid da URL, com o mesmo formato que o Meta espera.
3. Filtrar o que sobe
Este é o erro mais caro e o mais silencioso. Se você manda todo evento de compra sem olhar o status, um PIX gerado e nunca pago vira uma conversão. A campanha então aprende a procurar pessoas que geram PIX e não pagam — e ela é muito boa em obedecer.
- Mande apenas status aprovado ou concluído; boleto impresso e PIX expirado não são venda.
- Separe primeira compra de renovação de assinatura, senão toda mensalidade vira aquisição nova.
- Cuidado com o mesmo pedido chegando por dois caminhos (webhook e sincronização de histórico) — precisa deduplicar por identidade de negócio.
- Não envie evento de venda antiga em reprocesso: o Meta recusa evento com mais de sete dias, e o que passa distorce a janela.
Como saber se está funcionando
O Gerenciador de Eventos do Meta mostra a qualidade da correspondência, mas com atraso e em nível agregado. O sinal mais útil é medir do seu lado: nos payloads que você realmente entregou, qual a porcentagem que levou e-mail, telefone, fbc e external_id. Se o e-mail está em 30% dos envios, nenhuma configuração do lado do Meta vai salvar o pareamento — o problema é de captura.
Cobertura de parâmetro é uma métrica de engenharia, não de mídia. Ela se resolve na coleta, e é medível antes de qualquer campanha rodar.
No CrazyLeads, esses três pontos são o comportamento padrão: o event_id vem da identidade de negócio, o user_data é montado a partir do grafo de identidade, e o filtro de status é configurado sobre o payload real da sua fonte, testado contra os últimos eventos antes de publicar.