Processed vs Deduplicated in Meta Events Manager

“Deduplicated” is not an error. When Meta labels your server event deduplicated, it is telling you it already received a matching browser event carrying the same event ID and has folded the two into one conversion. That label is the closest thing Events Manager will ever give you to a receipt for successful pairing — and most people who see it think something has gone wrong.

Here is what the labels mean, why a server-only row is usually not what it looks like, and how to tell the difference between a display artifact and a real deduplication fault.

Why there are two copies in the first place

Server-side tracking does not replace the browser pixel. It runs alongside it. The same conversion is sent twice on purpose: once from the visitor’s browser, once from your server straight to the platform’s API. The browser copy carries the visitor’s cookies and click IDs; the server copy survives ad blockers, closed tabs and gateway redirects.

That only works if the platform can tell the two copies are the same event. Meta merges them on the combination of event name and event ID. One shared ID on both halves, and two sends become one conversion. Different IDs, and you have just doubled your numbers with no error anywhere.

The two labels

A healthy event shows up as one row, sourced from two places:

Source	Label	What it means
Browser	Processed	This copy was counted.
Server	Deduplicated	This copy matched the browser one and was folded into it.

Events Manager summarises that as Processed from 2 sources. Which half gets counted and which gets deduplicated is Meta’s business, not yours. What matters is that both arrived carrying one ID.

What the labels do not tell you

They do not tell you that the IDs matched. Meta’s deduplication has a fallback: where it cannot match on event ID, it will still pair a browser and a server copy on event name and fbp — the browser cookie that identifies the visitor. So a “Deduplicated” label can appear on a setup where the two event IDs never matched at all.

The labels only say which copy Meta kept. Matched IDs are the only proof of pairing, and unlike the labels they are readable directly on the wire — which is what the rest of this article is about.

The row that looks broken and isn’t

The most common report goes like this: one event row appears, sourced Server. After a few seconds it changes to “deduplicated”. A browser source never appears at all. It looks exactly like a dead browser pixel.

Read that sequence again, though. Meta cannot deduplicate an event against nothing. If the server copy is being marked deduplicated, a browser event reached Meta and was matched against it — on the event ID, or on the fallback above. What is missing is the display of the browser half, not the browser event itself.

The usual cause is that Test Events is scoped to a browser session. The tab only shows browser events from the session that has it open. Browse your store in an incognito window while watching Test Events in your normal profile and you will reproduce this symptom exactly, every time, on a completely healthy setup.

Two other things produce the same false alarm:

• Administrator exclusion. If “Don’t track administrators” is on — and it usually is — nothing fires for you at all. No browser event, no server event, no log row. Test logged out.
• An ad blocker in your testing browser. It kills the browser request while the server copy arrives untouched, because that one never goes near the visitor’s browser. That asymmetry is not a bug; it is the entire point of sending server-side. But it does mean your own blocker can show you a server-only picture.

Proving it, rather than inferring it

Browse and watch in the same browser profile, logged out, and the second source appears. If you want to settle it directly instead:

1. Open your browser’s network tab and find the request to facebook.com/tr.
2. Read its eid parameter. That is the event ID the browser sent.
3. Find the event ID recorded in the plugin’s log for that same page load.
4. Compare them.

Identical means pairing works and you were looking at a display artifact. Different means a real deduplication fault, and every event on your site is being counted twice.

This comparison is what Dedup Doctor does for every event automatically, rather than one page load at a time. A healthy funnel reads like this — the same ID on both sides, all the way down:

PageView          fdf4dd5f-9c31-4e02-9a8d-1c7b2f0e0476  browser  sent
PageView          fdf4dd5f-9c31-4e02-9a8d-1c7b2f0e0476  server   sent   fbtrace_id …
ViewContent       0f2a91c4-77bd-4c19-9f0a-3b6d5e2c8e11  browser  sent
ViewContent       0f2a91c4-77bd-4c19-9f0a-3b6d5e2c8e11  server   sent   fbtrace_id …
AddToCart         7c19bb02-4a61-4f5e-8b90-2d4c6a1e4d3f  browser  sent
AddToCart         7c19bb02-4a61-4f5e-8b90-2d4c6a1e4d3f  server   sent   fbtrace_id …

That trailing trace ID is Meta’s own reference for that specific send. A matched pair with a trace ID beside it is the strongest evidence available from outside Meta’s systems.

Why “deduplication is enabled” proves nothing

Every plugin in this category has a deduplication setting, and every one will happily report that it is switched on. A setting describes an intention. The event IDs on the wire describe what actually happened.

They are not the same claim, and only one of them can be checked. That gap is the whole reason this product exists — and it is why the full walkthrough lives in Processed vs Deduplicated in the docs.

One thing you can check right now

None of the above requires installing anything. The free tracking checker reads your public pages the way a visitor does and reports which pixels are there and whether the same account ID is being initialised more than once — which is the other, cruder way to end up double counting.

It will not tell you whether your server-side events arrived. Nothing outside your own server can. But it will tell you in about ten seconds whether you have two plugins fighting over the same pixel.