Meta Conversions API in 2024: Closing the Post-iOS 14.5 Signal Gap

Your ad account reports one number of purchases. Your payment processor reports a bigger one.

If you have ever had a version of that conversation, you have met the signal gap. The ad platform is making budget decisions from a partial view of what happened, and the missing part is usually the part that matters most: who actually bought. In the five-part revenue system, this is the signal leak.

The single most common fixable problem I see in ad accounts is not the creative or the audience. It is thin conversion data. This piece lays out the baseline for fixing it using Meta's public documentation: server events, deduplication and the customer information that makes a match possible.

Why does a browser pixel alone underreport results?

Because it depends on the browser, the device and the user all cooperating.

Apple's App Tracking Transparency, required since iOS 14.5, means that apps need a user's permission to track them across other companies' apps and websites for advertising or measurement.¹ That rule is about apps, but it changed expectations across the whole ecosystem, and browsers and devices have kept adding privacy controls since. In my experience, a setup that relies only on a browser pixel sees less than it used to, and the gap is biggest on exactly the events you care about, the ones that happen late in the journey.

Where the gap hurts

The ad platform optimizes toward the events it can see. If purchases are underreported, it has less to learn from, and your cost per result tends to drift up. Reporting and optimization both suffer, which is why this is a performance problem and not only an accounting problem.

What is the Conversions API, in plain English?

It is a direct line from your server to Meta.

Meta describes the Conversions API as a connection between an advertiser's marketing data, such as website events, app events and offline conversions, sent from the advertiser's server, website platform, app or CRM, to Meta systems that optimize ad targeting, decrease cost per result and measure outcomes.⁴ Server events are linked to a dataset and processed like events sent with the Meta Pixel.⁴

Pixel and server are partners

The pixel runs in the visitor's browser and captures what happens on the page. The server sends events from your own systems, like a completed purchase confirmed by your payment processor. Run together, each can catch events the other missed. That only works if Meta can tell when two reports describe the same event.

How does deduplication with event_id work?

You give the same event a shared name and a shared ID from both sources.

Per Meta's documentation, an event is deduplicated only if the pixel's eventID matches the Conversions API's event_id and the pixel's event matches the API's event_name.² A later event is discarded only if the matching pair arrives at the same pixel ID within 48 hours of the first one.²

That quote tells you what happens when the browser and the server both report the same event and the details do not meaningfully differ: Meta usually keeps whichever arrived first.²

The fallback, and its limits

If you cannot send an event ID, Meta can try matching on event name plus fbp and/or external ID. The documentation lists clear limits: it generally works only when the browser event arrives first, a server event is not discarded if no browser event was received in the previous 48 hours, and it does not deduplicate within one source, so two identical server events in a row are both kept.² Treat the fallback as a safety net, not a design.

Which customer information parameters make matches possible?

The more accurate parameters you send, the more likely Meta can match the event to a person.

The ones you hash

Email, phone, first name and last name must be hashed, and each has a normalization rule you apply first.³ Trim spaces and lowercase an email. For a phone number, remove symbols, letters and leading zeros and include the country code. For names, use lowercase with no punctuation.³ The external ID, any unique ID you assign, is recommended to be hashed.³

The ones you never hash

The client IP address must never be hashed, and the client user agent is sent as is. The fbc and fbp values, which come from Meta's cookies, also go unhashed.³ Meta notes that events sent from the browser include IP address and user agent automatically, but for server events you have to configure them yourself.³

Order matters

Normalize first, then hash. Hash a messy email and you get a perfectly valid hash of the wrong string, which will never match anything. This is the most common silent failure I see.

How do you verify the setup?

Check, do not assume. Meta's own overview recommends a verification step where you confirm Meta received your events and that they are deduplicated and matched correctly.⁴

A five-minute check

• Open Events Manager and look for both browser and server sources on the same event.
• Confirm the event shows as deduplicated, not doubled. If your purchase count is suddenly twice what your processor says, deduplication is broken.
• Look at the match quality for each event and note which parameters are missing.
• Place a test purchase and follow it end to end.

What goes wrong most often?

• Missing event IDs, so every event is counted twice.
• Mismatched event names, such as "Purchase" from one side and "purchase" from the other.
• Hashing before normalizing, or hashing the IP address.
• Server events with no user data, which Meta cannot match to anyone.
• Sending data you should not, which is a legal problem before it is a technical one.

Get the basics right and you will have a cleaner foundation than most accounts I see. The data you feed the platform becomes the quality of its decisions. The same logic shows up in my mid-2024 read of Meta's earnings: first-party data sent from your own systems is the durable input. If you want help auditing your own setup, you can find me at ekaistone.com.

Keep building.Ekai