Evento Lead no Meta pelo CAPI: o que enviar para o algoritmo otimizar de verdade
O pixel dispara Lead quando o formulário é enviado — e o Meta recebe um evento sem e-mail, sem telefone e às vezes sem cookie. Quem manda o Lead pelo servidor, com a identidade que o formulário acabou de capturar, muda a qualidade da otimização. Este artigo diz campo a campo o que vai no evento.
Lead é o evento que mais campanha brasileira otimiza e o que mais chega pobre ao Meta. O motivo é simples: o pixel dispara o Lead no clique do botão, e naquele instante ele sabe pouco sobre a pessoa. Se o navegador bloqueou o cookie, sabe menos ainda. O Meta recebe um evento que diz "alguém converteu" sem conseguir dizer quem — e a otimização, que é uma máquina de encontrar gente parecida com quem converteu, fica trabalhando com metade da informação.
A Conversions API resolve isso, mas só se o evento enviado pelo servidor for melhor que o do pixel — não uma cópia dele. Este artigo é a lista do que precisa estar dentro de um Lead enviado pelo servidor, na ordem de impacto sobre a qualidade de correspondência.
O que o formulário sabe e o pixel joga fora
No momento em que a pessoa aperta "enviar", o formulário tem nome, e-mail e telefone digitados. O pixel padrão do Meta não lê nada disso: manda o evento Lead com os identificadores de navegador (fbp, fbc, IP, user agent) e mais nada. O e-mail que a pessoa acabou de digitar, que é o identificador mais forte que existe, fica no seu banco e nunca chega ao Meta.
Medimos isso em contas reais: no evento de página, e-mail presente em 11% dos casos; no evento de compra vindo da plataforma de pagamento, 100%. O Lead fica no meio — e onde ele cai depende só de quem monta o evento.
Campo a campo: o que vai num Lead bem enviado
| Campo | De onde vem | Por que importa |
|---|---|---|
| em (e-mail, sha256) | O formulário, normalizado (minúsculo, sem espaços) | O identificador mais forte; sozinho já casa a maioria dos perfis |
| ph (telefone, sha256) | O formulário, com DDI e só dígitos | Segundo mais forte; no Brasil, quase todo formulário pede |
| fn / ln (nome, sha256) | O formulário, separado no primeiro espaço | Melhora a correspondência quando o e-mail não bate |
| fbc / fbp | Cookies do navegador, gravados em first-party | Ligam o evento ao clique no anúncio e à sessão |
| external_id | O id da pessoa no seu CDP | Estável entre dispositivos e entre eventos futuros |
| client_ip_address / client_user_agent | A requisição original do navegador | Obrigatórios para evento de site; sem eles a correspondência cai |
| event_id | O mesmo id que o pixel usou | Deduplica com o evento do navegador, se ele também disparar |
| action_source | Fixo: website | Diz ao Meta onde a ação aconteceu — e não é "server" |
O último campo merece um parágrafo. Muita integração manda tudo que sai do servidor como action_source igual a "server", porque parece descrever a origem técnica. Está errado: o campo descreve onde a PESSOA agiu, e ela agiu no site. Já escrevemos sobre o efeito disso na atribuição — e é um dos erros mais comuns que vemos em auditoria.
Cookie que não existe: fbc e fbp em first-party
Boa parte dos leads chega sem os cookies do Meta, porque o bloqueador impediu o script do pixel ou o navegador limitou o cookie de terceiro. Não tem como inventar o fbc — mas dá para construí-lo a partir do fbclid da URL e persistir por 90 dias, no seu domínio. O fbp também pode nascer do seu lado, com o mesmo formato que o script do Meta usaria. Fizemos exatamente isso e contamos o antes e o depois: a cobertura de fbp subiu de 44% para perto de 100% dos eventos.
A pergunta certa não é "o Meta recebeu o Lead?". É "o Meta recebeu o Lead com o que o meu formulário sabia sobre a pessoa?".
Dedup: o Lead que chega duas vezes
Se o pixel do navegador continua disparando Lead e o servidor também manda, o Meta precisa saber que são o mesmo evento. O event_id resolve o caso simples. Os casos que sobram — o mesmo formulário enviado três vezes por causa de um clique nervoso, ou o mesmo e-mail em dois formulários da mesma página — são os que descrevemos em deduplicação além do event_id. Num formulário real que auditamos, um preenchimento gerava três eventos Lead, e o Meta contava três.
Onde o Lead deve nascer
Existem três lugares para montar o evento de servidor: um script próprio no backend do site, um container de tag server-side, ou um CDP que já recebe o formulário e já sabe quem é a pessoa. O primeiro é barato de começar e caro de manter. O segundo resolve o transporte mas não a identidade. O terceiro é o que faz a diferença acima virar rotina: o evento sai do mesmo lugar onde o lead foi resolvido, com e-mail, telefone, cookies e o id estável da pessoa. É a diferença que detalhamos em CDP, GTM server-side e pixel: quem faz o quê.
No CrazyLeads o Lead sai assim por padrão: o pixel captura o formulário, o resolvedor de identidade liga a pessoa ao histórico dela, e o Envio para o Meta monta o evento com os campos da tabela acima, deduplicado, com action_source de site e a mesma fila de entrega que o Purchase usa.