If you run lead-gen ads on Facebook or Instagram, the same problem exists there as on Google Ads: Meta's algorithm only ever sees the form fill, never the sale. The Conversions API — Meta's server-to-server alternative to the browser pixel — is how you close that gap for the Meta side of your account. This covers what it actually is, why the pixel alone isn't enough anymore, and the practical steps to get real conversion data flowing back.
Why the pixel alone stopped being reliable
The original Facebook pixel tracks events entirely in the visitor's browser — it fires when a page loads or a form submits, and reports that event back to Meta client-side. Two things have eroded how much of that data actually arrives: browser privacy features that block third-party tracking scripts, and ad blockers that strip pixel calls out entirely before they ever fire. Neither of those things touch a server-to-server API call, which is the core reason the Conversions API exists.
What the Conversions API actually is
Instead of the visitor's browser reporting an event to Meta, your own server does — using the same event data, sent directly from your backend or CRM. This has two real advantages for a lead-gen business specifically:
- It isn't blocked by browser privacy settings or ad blockers, because it never runs in the visitor's browser at all.
- It can report events that happen well after the page visit — a lead becoming "qualified" three days later, or "won" three weeks later — which a browser-based pixel was never designed to do, since the visitor is long gone by then.
That second point is the one that matters most for lead generation. The pixel can tell Meta someone filled in a form. Only the Conversions API, fed from your CRM, can tell Meta that person later paid you money.
The event chain for a lead-gen business
Most lead-gen advertisers should be sending at least three distinct events, not one:
- Lead — fired the moment the form is submitted. This can still come from the pixel; it's immediate and browser-side is fine for it.
- Qualified Lead / Contact — fired from your CRM once a real person confirms the lead is genuine, not a bot or a wrong number. This has to come through the Conversions API, since it happens after the page visit.
- Purchase / Won — fired from your CRM with the actual deal value, whenever the lead becomes a paying customer. Also Conversions API only, and the event Meta's bidding cares about most once it's flowing consistently.
Send a value with the Purchase event, not just the event name. Meta's value-based optimisation needs a number to bid toward. A rough average deal value reported consistently beats an exact value reported inconsistently — consistency is what the algorithm actually learns from.
What you need to identify the right person
Because the Conversions API fires from your server rather than the visitor's browser, Meta needs
something to match the later event back to the original ad interaction. In practice this means
sending hashed customer information — email, phone number — alongside each event, plus, where
available, the fbclid click identifier captured from the landing page URL at the moment
of the original click, the same way a gclid works for Google Ads. Capture it the same way: a hidden
form field populated from the URL parameter on page load, stored against the lead permanently.
If you're already capturing gclid for Google Ads, add fbclid to the same capture script —
it's the same mechanism, just a different parameter name, and doing both at once avoids maintaining
two separate tracking scripts on the same landing page.
Setting it up
- In Meta Events Manager, open your pixel and go to Settings → Conversions API.
- Generate an access token, or connect a partner integration if your CRM supports one directly — this avoids building the API calls yourself.
- Map your CRM's lead stages to Meta's standard events (
Lead,Contact,Purchase) so Meta recognises what each one means. - Send a test event and confirm it appears in the Test Events tab before relying on it — this is the step most setups skip, and where most silent failures are caught.
- Use Meta's Event Match Quality score to check how well your hashed customer data is matching real Meta accounts. A low score usually means missing or incorrectly formatted email/phone data, not a broken integration.
What "good" event match quality actually looks like
Meta scores every Conversions API integration on Event Match Quality, shown as a number out of 10 in
Events Manager, and it's worth knowing roughly what to expect rather than chasing a perfect score. A
score in the 6–8 range with consistent email and phone hashing is a genuinely healthy setup for most
lead-gen businesses; scoring below 4 usually means something structural is missing, most often the
fbclid or a consistently formatted phone number field. A perfect 10 is rare and not
actually necessary — Meta's own guidance treats anything reasonably above the middle of the range as
workable, and diminishing effort spent chasing the last point or two is rarely worth it compared to
simply getting more volume of events flowing consistently.
Format matters more than most people expect when hashing customer data. Emails should be lowercased and trimmed of whitespace before hashing; phone numbers should include the country code with no spaces, dashes or parentheses. A perfectly valid-looking phone number formatted with dashes will hash to a value that never matches a real Meta account, which silently drags down match quality without producing any visible error.
The mistake specific to Conversions API setups
Running both the browser pixel and the Conversions API for the same event without deduplication tells
Meta a single lead converted twice — once from each source — which inflates your reported conversion
count and quietly misleads the bidding algorithm about how well a campaign is actually performing.
Meta supports deduplication via a shared event_id sent from both the pixel and the
server for the same event; set this up from day one, not after you notice numbers look inflated.
How this differs from what Google Ads needs
If you're already set up for Google Ads offline conversion tracking, most of the underlying work transfers — the same lead record, the same "qualified" and "won" stages, the same discipline of storing a real deal value. The click identifier is the one piece that doesn't: Google Ads needs a gclid, Meta needs an fbclid, and a visitor arriving from a Meta ad won't carry a gclid at all. Capture both parameters on every landing page regardless of which platform you expect the click to come from — UTM tagging alone won't tell you which one applies, and a landing page that only checks for gclid will silently fail to attribute any Meta traffic that lands on it.
What this fixes, and what it doesn't
Done properly, this gives Meta's bidding algorithm the same thing offline conversion tracking gives Google Ads: a real signal about which leads became customers, so it optimises toward people who buy rather than people who merely fill in forms. It will not fix a weak offer or a sales team that doesn't follow up quickly — attribution reports the truth about a campaign, it doesn't improve it.
Doing this without building it yourself
Claudphic Ads sends the Conversions API events automatically as a lead moves through your pipeline, alongside the equivalent Google Ads offline conversion upload, from one place. See WhatsApp lead tracking if most of your Meta leads actually convert to a WhatsApp conversation rather than a form, which changes what you're capturing at the first step. Pricing is on the pricing page.