Diagnostics
Guide
How to validate Meta Pixel and Conversions API deduplication
Deduplication either works or it does not, and Events Manager will not tell you plainly which one is true unless you know where to look.
The short answer
Meta deduplicates a browser and a server event when both carry the same event_name and the same event_id within a 48-hour window. To validate it, send a test purchase through both channels, confirm in Events Manager that the event shows both Browser and Server as connections, and check that the processed count is roughly one event rather than two. A deduplication rate near zero with both channels active means your event_id values are not matching.
Key takeaways
Deduplication requires matching event_name and event_id across both channels within 48 hours.
The most common failure is generating the event_id separately in the browser and on the server, so the two never match.
Duplicate purchases inflate reported conversions and quietly corrupt bid optimisation.
A deduplication rate at or near zero while both connections are active is the clearest signal of an ID mismatch.
Validate with a real test order, not with the payload preview, because the preview does not exercise your ID generation.
How Meta deduplication actually works
When you send the same conversion from both the browser pixel and the Conversions API, Meta needs a way to recognise that the two payloads describe one event. It does that on two keys: the event name, and a shared identifier you supply as event_id in the browser call and as event_id in the server payload.
If both keys match and the events arrive within 48 hours of each other, Meta keeps one and discards the other, preferring the server event because it usually carries richer matching data. If either key differs, Meta has no basis to connect them and treats them as two separate conversions.
The subtlety is that nothing errors when this goes wrong. Both events are valid. Both are accepted. You simply end up counting every purchase twice.
The three failure modes
Independently generated identifiers
By far the most common problem. The browser generates a random UUID, the server generates its own random UUID, and the two have no relationship. The fix is to derive the identifier from something both sides already know, which for e-commerce is almost always the order ID.
Mismatched event names
A browser event named Purchase and a server event named purchase are not the same event to Meta. Casing matters. This tends to appear when the browser event comes from a platform integration and the server event was written by hand.
Events outside the window
A server event queued and retried the following day can fall outside the 48-hour window. This is rare but shows up in setups that batch server events rather than sending them in near real time.
A validation procedure
Do this against a live environment with a real order. Test payload tools bypass the code path that generates your identifiers, which is exactly the code path you are trying to verify.
Place a genuine test order through normal checkout, and note the order ID.
In Events Manager, open the Test Events tab before placing the order so both events are captured as they arrive.
Confirm you see a Purchase event listing both Browser and Server under connection method, rather than two separate Purchase rows.
Open the event detail and compare the event_id on the browser event against the event_id on the server event. They must be byte-identical.
Wait for processing, then check the Overview tab for that event and read the deduplication rate.
Reading the numbers in Events Manager
The deduplication figure is easy to misread, so it helps to know what each pattern implies.
What you see | What it means | Action |
|---|---|---|
Both connections listed, dedup rate 40 to 90 percent | Working as intended | None |
Both connections listed, dedup rate near zero | IDs are not matching | Compare event_id generation on both sides |
Server only | Browser pixel not firing on the purchase step | Check pixel installation and consent gating |
Browser only | Server events not arriving | Check webhook delivery and access token validity |
Dedup rate near 100 percent | Browser events may be entirely redundant | Verify the browser event is adding matching data |
A rate in the middle band is normal and healthy. It is not supposed to be 100 percent, because some sessions will only ever produce a server event: consent-blocked visitors, ad-blocked browsers, and customers who close the tab before the pixel fires.
Keeping it working
Deduplication is not a one-time configuration. It breaks when someone changes the checkout, reinstalls a pixel through an app, or migrates the server container. The cheapest safeguard is a standing weekly comparison: purchases in your store platform for the period, against purchases reported by Meta for the same period.
A ratio close to one means deduplication is holding. A ratio approaching two means it has stopped, and it has probably been broken since the last deployment rather than since today.
Frequently asked questions
What should I use as the event ID?
For e-commerce, the order ID is almost always the right choice. Both the browser and the server already know it, it is unique per purchase, and it stays stable across retries.
What is a healthy deduplication rate?
Somewhere between 40 and 90 percent. It should not reach 100 percent, because consent-blocked and ad-blocked sessions will only ever produce a server event.
Why not just send the server event and skip the browser pixel?
The browser event often carries matching signals the server cannot see, including the click identifier and browser cookies. Running both and deduplicating gives better match quality than either alone.
Sources
Measurement Architect, Avinian
Christoffer builds and defends the measurement layer underneath paid media for established e-commerce brands. His work focuses on server-side collection, consent-aware event design, and proving that what a platform receives matches what actually happened in the store.
Server-side GTM, Shopify checkout instrumentation, Meta CAPI and GA4 validation