The Lead event on Meta via CAPI: what to send so the algorithm can actually optimize
The pixel fires Lead when the form is submitted, and Meta receives an event with no e-mail, no phone and sometimes no cookie. Sending Lead from the server, with the identity the form just captured, changes the quality of optimization. This article lists, field by field, what goes into the event.
Lead is the event most campaigns optimize for and the one that reaches Meta poorest. The reason is simple: the pixel fires Lead on the button click, and at that instant it knows little about the person. If the browser blocked the cookie, it knows even less. Meta receives an event that says “someone converted” without being able to say who — and optimization, which is a machine for finding people similar to those who converted, works with half the information.
The Conversions API fixes this, but only if the event sent by the server is better than the pixel’s, not a copy of it. This article is the list of what needs to be inside a server-sent Lead, ordered by impact on match quality.
What the form knows and the pixel throws away
The moment the person presses “submit”, the form holds a typed name, e-mail and phone. Meta’s standard pixel reads none of it: it sends the Lead event with browser identifiers (fbp, fbc, IP, user agent) and nothing else. The e-mail the person just typed, the strongest identifier there is, stays in your database and never reaches Meta.
We measured this in real accounts: on the page-view event, e-mail is present in 11% of cases; on the purchase event coming from the payment platform, 100%. Lead sits in between, and where it lands depends only on who builds the event.
Field by field: what goes into a well-sent Lead
| Field | Where it comes from | Why it matters |
|---|---|---|
| em (e-mail, sha256) | The form, normalized (lowercase, trimmed) | The strongest identifier; alone it matches most profiles |
| ph (phone, sha256) | The form, with country code, digits only | Second strongest; in Brazil nearly every form asks for it |
| fn / ln (name, sha256) | The form, split at the first space | Improves matching when the e-mail does not |
| fbc / fbp | Browser cookies, stored first-party | Tie the event to the ad click and the session |
| external_id | The person’s id in your CDP | Stable across devices and future events |
| client_ip_address / client_user_agent | The original browser request | Required for website events; without them matching drops |
| event_id | The same id the pixel used | Deduplicates against the browser event, if it also fires |
| action_source | Fixed: website | Tells Meta where the action happened — and it is not “server” |
The last field deserves a paragraph. Many integrations send everything that leaves the server with action_source equal to “server”, because it seems to describe the technical origin. It is wrong: the field describes where the PERSON acted, and they acted on the site. We have written about what that does to attribution — it is one of the most common mistakes we see in audits.
The cookie that is not there: first-party fbc and fbp
A good share of leads arrive without Meta’s cookies, because a blocker stopped the pixel script or the browser limited the third-party cookie. There is no way to invent the fbc — but you can build it from the fbclid in the URL and persist it for 90 days, on your own domain. The fbp can also be born on your side, in the same format Meta’s script would use. We did exactly that and reported the before and after: fbp coverage went from 44% to close to 100% of events.
The right question is not “did Meta receive the Lead?”. It is “did Meta receive the Lead with what my form knew about the person?”.
Dedup: the Lead that arrives twice
If the browser pixel keeps firing Lead and the server sends it too, Meta needs to know they are the same event. The event_id solves the simple case. The remaining cases — the same form submitted three times by a nervous click, or the same e-mail in two forms on the same page — are the ones we describe in deduplication beyond event_id. In a real form we audited, one submission generated three Lead events, and Meta counted three.
Where the Lead should be born
There are three places to build the server event: a custom script in the site backend, a server-side tag container, or a CDP that already receives the form and already knows who the person is. The first is cheap to start and expensive to maintain. The second solves transport but not identity. The third is what turns the difference above into routine: the event leaves the same place where the lead was resolved, with e-mail, phone, cookies and the person’s stable id. It is the difference we detail in CDP, server-side GTM and pixel: who does what.
In CrazyLeads the Lead goes out like this by default: the pixel captures the form, the identity resolver ties the person to their history, and the Meta delivery builds the event with the fields in the table above, deduplicated, with a website action_source and the same delivery queue Purchase uses.