Event deduplication, explained
This guide explains how Facebook deduplicates, what you need to send for it to work, and how to check it is working on your own account. It is the detail behind the “run both together” advice in our Meta Conversions API guide, and it is the reason running both is safe rather than double-counting.
Emmett Cooke
Founder, PixelFlow.so
Last updated 22 July 2026
7 min read
What is "event deduplication"?
When you run the Facebook pixel and the Conversions API together, both report the same actions. Someone buys, the browser pixel sends a Purchase, and your server sends a Purchase too. Without a way to tell those two reports are the same sale, Facebook would count it twice. Deduplication is the mechanism that stops that, keeping one and discarding the copy.
Why running both creates duplicates
You should run the pixel and CAPI together. The pixel catches browser-side signals, and CAPI catches everything the browser blocks or loses. That overlap is deliberate, and it is covered in full in Facebook Pixel vs Conversions API.
But overlap means the same conversion often gets reported twice, once from each source. If Facebook treated those as two separate purchases, your reporting would inflate, your costs per result would look artificially low, and the algorithm would optimise on a doubled, distorted picture. Deduplication is what makes running both give you completeness without double-counting.
Event deduplication
Counted once
Purchase
ID: evt_a1b2
Browser
Purchase
ID: evt_a1b2
Server
Same ID + same name
Deduplicated
Reported conversions
1, not 2
How events pair up
Reliable
event_id + event_name
Primary
_fbp cookie + event_name
Fallback
Arrive within the window
Paired
Duplicate copy
Dropped
How Facebook deduplicates
Facebook uses two methods, in order of preference.
Primary: event_id plus event_name. Every event can carry a unique event ID. When the browser pixel and the server send the same conversion, they attach the same event ID and the same event name (for example, “Purchase”). Facebook sees two events sharing an ID and a name, recognises them as one action, keeps a single copy, and drops the other. This is the reliable method and the one you want.
Fallback: fbp plus event_name. If no event ID is present, Facebook falls back to matching on the _fbp browser cookie and the event name within a time window. This is weaker. It can miss genuine duplicates and, in rare cases, merge events that were not actually the same. Rely on the primary method and treat this only as a safety net.
The takeaway: deduplication lives or dies on a shared, matching event ID. Get that right and the rest takes care of itself.
The deduplication window
Facebook only looks for duplicates within a time window. If the browser event and the server event arrive close together, which they normally do, they deduplicate cleanly. The window is generous enough that ordinary delays between a pixel firing and a server sending are not a problem, so you do not need the two to arrive at the exact same moment. What matters is that both carry the same ID and name, not that they land simultaneously.
What you need to get right
For deduplication to work, three things have to line up between the browser event and the server event:
Must match
Browser pixel
Server (CAPI)
Event ID
evt_a1b2
evt_a1b2
Event name
Purchase
Purchase
Both fire
Yes
Yes
The same event ID on both. The pixel event and the CAPI event for one conversion must share one identical event ID. If each side generates its own separate ID, Facebook cannot tell they are the same, and you double-count.
The same event name on both. “Purchase” on the browser and “Purchase” on the server. A mismatch (say one side sends a custom name) breaks the pairing.
Both sides actually fire. Deduplication assumes two copies exist. That is fine. The failure case is subtler: if only one side fires for some conversions, you are not double-counting, you are under-counting, which is its own problem.
What commonly goes wrong
Mismatched or missing event IDs. The single most common cause. One side sends an ID, the other does not, or they send different ones. Result: duplicates counted as separate conversions.
Different event names. A standard “Purchase” on the pixel and a differently named event on the server will not pair up.
Only one source firing. If the pixel is blocked and only CAPI fires, that event is fine and counts once. But if your setup relies on the pixel to generate the shared ID and the pixel is blocked, the server event can lose its pairing anchor. Your setup needs to handle the ID independently of whether the browser cooperates.
Timing far outside the window. Rare, but batching server events with a long delay can push them past the dedup window. Send promptly.
How to check it is working
Open Events Manager and look at your events. Facebook shows when it is receiving events from both the browser and the server, and flags events it has deduplicated. If you see your Purchase count roughly matching real orders rather than double, and Events Manager reports the server and browser events as deduplicated rather than separate, you are in good shape. If your reported conversions are running at close to twice your real numbers, deduplication is almost certainly failing on a mismatched or missing event ID.
Why it matters
Deduplication is quiet infrastructure, but the cost of getting it wrong is real. Double-counted conversions make your ads look better than they are, which leads you to trust and scale campaigns on inflated numbers. Worse, the algorithm optimises on that distorted data, so it learns from a false picture of what is working. Clean deduplication keeps your reporting honest and your optimisation grounded in what actually happened.
Where PixelFlow fits
Setting deduplication up by hand means generating one shared event ID, passing it to both the browser pixel and your server, keeping the event names aligned, and making sure the server event still carries the right ID even when the browser is blocked. On a no-code platform without a developer, that is not realistic to do yourself.
PixelFlow handles all of it. It fires the pixel and the Conversions API for every event, generates and shares a single event ID across both, keeps the event names matched, and anchors the ID server-side so pairing holds even when the browser pixel is blocked. On Webflow, Framer, Squarespace, and WordPress, deduplication is handled for you, with no code and nothing to configure.
Frequently asked questions
Do I need deduplication if I run the pixel and CAPI?
Yes. Running both means the same conversion is reported twice, once from the browser and once from the server. Deduplication is what tells Facebook those two reports are the same action so it counts them once. Without it, you double-count.
How does Facebook know two events are the same?
Primarily by matching a shared event ID and event name. When the browser event and the server event carry the same ID and the same name, Facebook recognises them as one action and keeps a single copy. If no ID is present, it falls back to the _fbp cookie and event name, which is less reliable.
Will running the pixel and CAPI together double-count my conversions?
Not if deduplication is set up correctly. With a matching event ID on both sources, Facebook keeps one and drops the duplicate. Double-counting only happens when the event IDs are missing or do not match.
What is an event ID?
A unique identifier attached to a single conversion. The browser pixel and the server both send it with their copy of that conversion, and the shared value is what lets Facebook pair the two and deduplicate them.
How do I check deduplication is working?
In Events Manager, confirm your reported conversions roughly match your real order or lead numbers rather than running at nearly double, and that events show as deduplicated across browser and server. Conversions at close to twice your real count are the classic sign that deduplication is failing.
Smarter, server-side tracking
Start sending accurate conversions today - no tag manager, no code, no developer required.
Compatible with
