Meta Conversions API for lead forms: a practical guide

If you run a lead form and you're feeding Meta only Pixel data, you are probably undercounting your own conversions. By how much depends on your audience and devices, but it is the reason Meta built a second way to send the same event. This is a practical guide to what the Conversions API is, why it exists alongside the Pixel rather than instead of it, how the Lead event and deduplication actually work, what "event match quality" means and how to improve it, the consent question you can't skip, and how to check the whole thing is actually doing what you think. There's a short section at the end on how Formglide sends it: the mechanics before that apply to any form or website, on any platform.

What the Conversions API actually is

The Meta Pixel is browser-side: a script that runs in the visitor's browser and reports events (a page view, a completed form) back to Meta over the network, from the visitor's device. The Conversions API (CAPI) is the same idea from the other direction: your server sends the event directly to Meta, without going through the visitor's browser at all.

They're designed to run together, not as alternatives. Meta's own guidance is to use the Conversions API in addition to the Pixel, not instead of it, specifically to help maximise the accuracy of the website events you're already sending (Meta Business Help Center: About Conversions API). The reason that matters is the subject of the next section.

Why Pixel-only tracking undercounts your leads

A browser-based script only fires if the browser lets it run, and increasingly, browsers don't.

Meta's own help centre states plainly that data sent through the Conversions API is less affected than Pixel data by browser loading errors, connectivity issues, and ad blockers (Meta Business Help Center: About Conversions API), because a server-to-server call doesn't depend on a script executing in someone's browser at all.

Two specific mechanisms explain why the Pixel alone loses events:

• Ad blockers. Browser extensions and built-in blockers are explicitly designed to stop third-party tracking scripts, including the Pixel, from loading. If the script never runs, the event never fires: there's nothing for the Pixel to report, because it was blocked before it could.
• Browser privacy features. Safari's Intelligent Tracking Prevention restricts how long client-side identifiers can persist and how cross-site tracking scripts are treated, by design: Apple's own WebKit team documents this as a deliberate limit on cross-site tracking capability, applied automatically and by default (WebKit: Tracking Prevention). Other privacy-focused browsers apply similar restrictions. None of this is a bug; it's the intended behaviour of the browser doing what it's supposed to do for its user.

A server-side event sent via CAPI isn't subject to either of those, because it never touches the visitor's browser in the first place. That's the whole rationale for running both: the Pixel catches what it can, and CAPI catches the completions that the Pixel structurally cannot see.

The Lead event and how deduplication works

For a lead form, the event that matters is Lead: fired once per completed submission. Sent from the browser alone, or from the server alone, you'd be missing whichever side didn't manage to fire. Sent from both, without care, you'd double-count every real completion. The fix Meta built for this is deduplication by event_id.

The mechanism, straight from Meta's own documentation: you attach the same event_id (and the same event name) to the Pixel's browser-side event and the server-side CAPI event for the same completion. Meta then matches events on those two fields and treats them as one; if server and browser events for the same event_id don't differ meaningfully in content, Meta generally prefers whichever it received first, and the whole match only applies within a 48-hour window of the first event's arrival (Meta for Developers: Deduplicate Pixel and server events). Get the event_id wrong, or send it from only one side, and you'll either double-count completions or lose the safety net entirely.

Event match quality: the customer information parameters

A Lead event landing at Meta is only useful if Meta can match it to a real ad account audience member. That match quality depends on how much verifiable customer information you attach to the server event: sent as hashed or plain parameters in the user_data block, per Meta's documentation (Meta for Developers: Customer information parameters):

The general pattern: hashed personal identifiers (email, phone) plus browser-linkage identifiers (fbp, fbc) plus connection metadata (IP, user agent) together let Meta match a server event to a real, ad-attributable person with much more confidence than any single field alone. Sending only an IP and user agent, with no email or phone, will match far fewer events than sending all of it.

Consent and privacy: get this right before you optimise anything else

Everything above assumes you're allowed to collect and send this data in the first place, and in the UK and EU, that's a real legal question, not a formality.

Under UK PECR guidance (the UK's implementation of the ePrivacy rules, enforced by the ICO), non-essential cookies and similar technologies (which explicitly includes tracking pixels) require clear, specific, unambiguous consent, confirmed by a genuine positive action such as ticking a box, before you set them; a "strictly necessary" exemption exists, but it's narrow and doesn't cover advertising or behavioural tracking (ICO: Guide to PECR: cookies and similar technologies). The same logic extends to sending personal data like an email address to an ad platform for matching: that's a data-processing activity under GDPR with its own legal-basis requirement, separate from the cookie-consent question.

This is genuinely a "get proper advice" area rather than a "read one blog post and copy it" one: the right consent mechanism depends on your specific setup, your audience's location, and how you've configured your ad account's data processing settings. Treat this section as a flag to raise with someone qualified before you scale a form that hashes and forwards personal data, not as the advice itself.

How to check it's actually working

Once it's live, don't assume: verify:

• Events Manager overview. Meta's Events Manager shows events arriving from both the Pixel and CAPI for the same pixel/dataset, broken out by source, so you can see whether server events are actually landing.
• Test event code. Meta's Conversions API documentation describes a test_event_code field: generate a code in Events Manager's Test Events tool, include it in your server payload, and matching events appear in the Test Events view within moments. Be aware that the events are not quarantined: Meta states that events sent with test_event_code are not dropped and are used for targeting and ads measurement like any others, so only test with real-looking events you are happy to have counted, and remove the code before sending production traffic (Meta for Developers: Using the API).
• Deduplication check. With both Pixel and CAPI sending the same completions, check that your reported Lead volume in Events Manager roughly matches your actual form completions, not double, not half. A count near double usually means the event_ids don't match between the two sides; a count well under your real completions usually means one side isn't firing at all.
• Match-quality feedback. Events Manager surfaces match-quality diagnostics for the parameters covered above; if it's consistently low, that's a sign you're missing hashed email or phone on a meaningful share of events, not a sign to ignore.

Common mistakes

• Different event_id values on the Pixel and server events for the same completion. This is the single most common way deduplication silently fails: check both sides generate or receive the identical string.
• Sending plain-text email or phone instead of hashed values. Meta's parameters expect SHA-256 hashes for em and ph; sending them raw isn't just wrong formatting, it's a data-handling problem.
• Phone numbers without a country code. A number hashed as 07700900123 will not match anyone on Meta's side, because Meta expects the country code (447700900123) and no leading zero. If your form collects phone numbers, ask for them in international format.
• Leaving test_event_code in the production payload. Meta says the field is for testing only and should be removed for production. Because test events still count, the damage is not lost data but confusion: your Test Events view fills with live traffic and you can no longer tell a test from a real lead. The opposite mistake is never setting a test code at all, and so never verifying the integration before spending on ads.
• Sending CAPI events with no fbp/fbc and no hashed email or phone: technically "working" in the sense that an event arrives, but with match quality too poor to be useful for optimisation.
• Treating consent as someone else's problem: shipping the integration before confirming your consent banner actually covers this kind of data sharing.

How Formglide sends it

This is what Formglide's Meta integration does today (Meta Pixel and Conversions API are on the Pro plan and above), including the limits.

Browser Pixel. When a form has a Pixel integration, the Pixel loads with the form and fires PageView and ViewContent, then Lead when the respondent completes it. Add the Pixel integration as well as the Conversions API one: with only the Conversions API, no Pixel loads, so there's no browser Lead to deduplicate against and no fbp or fbc to send. By default that is all: per-question events are optional and off by default (a checkbox on each integration, which adds a FormStepCompleted custom event for each completed question, with no answer values).

Server-side Conversions API. With the Conversions API integration added (your Pixel ID and a Conversions API access token, plus an optional test event code), Formglide sends one Lead event to Meta from its server for every completed submission. The event's event_id is the submission's own ID, and the browser Lead uses the same ID as its eventID, so the two deduplicate. Partial, abandoned submissions do not send a Lead.

What goes in user_data. The email answer is trimmed and lowercased, the phone answer is stripped to digits, and both are SHA-256 hashed before sending. By default Formglide uses the first email block and the first phone block in the form; you can override either with a block key in the integration settings. It also sends fbp and fbc (read from the respondent's browser cookies when the form loads, so they are only present if the Pixel had already set them), the visitor's user agent, and the page URL as event_source_url.

Known limits you should plan around.

• Phone numbers are reduced to digits but Formglide does not add a country code or strip leading zeros. If you want phone numbers to contribute to match quality, ask for international format in the question text.
• The Lead event does not include the visitor's IP address: Formglide stores only a hash of it, so there is no raw IP to forward. Matching on that event relies on hashed email and phone, fbp/fbc and the user agent.
• Formglide does not include a consent banner or gate the Pixel behind consent. The Pixel loads when the form loads. If you need consent before tracking in your jurisdiction, that is something you handle outside the form (for example, only sending traffic to the form after consent has been collected on your own page), and you should take advice on it.
• By default the server sends a single Lead per submission. The only extra is the optional per-question FormStepCompleted server event (a checkbox, off by default, sent without email or phone and matched on browser ID and IP). If you need a richer event set (purchase, qualified lead, offline stages), that is outside what the integration does.

Other tracking on the same completion. GA4 gets a generate_lead event on completion, sent from the browser and via the Measurement Protocol, which is Google's recommended pattern for lead forms (Google Analytics: Recommended events). UTM parameters and hidden fields are captured on each submission, which lets you tie a Lead event, and the CRM record it becomes, back to the campaign and creative that produced it. That is the same tracing this article recommends for judging lead quality, not just lead volume.

None of this is exclusive to Formglide, and it is not the only form tool with server-side Meta tracking: Heyflow, for example, says it supports the Conversions API natively (we checked in September 2026). As of 27 September 2026 we found no native server-side Conversions API on any Typeform plan. Whatever tool you use, run the checks in the section above before you trust the numbers.