Event ID deduplication
When the same conversion is sent from both a browser and a server, the destination needs a way to recognize them as one event — that's what a shared event ID does. The rule is simple and the implementations fail anyway, because the two paths are usually built at different times by different people and each mints its own ID. The fix is to generate the ID once from something that already exists and is stable: for a purchase, that's the order number, which is identical on both sides by construction.
Free30 minutesNo obligation
Event ID deduplication · what breaks
Where teams get this wrong — Event ID deduplication
- 01
Each path generating its own ID
Both events are valid, both process successfully, and the destination has no way to relate them.
- 02
Using a timestamp or random value
It can't be reproduced by the other path. Deduplication needs the same value, not a similar one.
- 03
Assuming a platform integration handles it
A one-click integration mints its own ID with no knowledge of your container.
Event ID deduplication · the fix
What a correct implementation looks like — Event ID deduplication
One generation point
The ID is created once and both paths read it.
A stable business identifier
Order number for purchase, lead ID for a lead. Already unique, already on both sides.
Event names matching exactly
Most platforms deduplicate on name and ID together. Case matters.
Verified over a week
Not on the day of handover.
Event ID deduplication · architecture
How deduplication works, and what to use as the ID
The mechanics differ slightly per platform but the principle doesn't: the destination needs the same identifier from both paths within its window.
- 1
The matching rule
Most destinations match on event name plus event ID together. A mismatch in either means two events.
- 2
Best ID for purchase
Your order number. Stable, unique, and available identically to both the browser and the server without coordination.
- 3
Best ID for a lead
A lead ID generated at submission and written into both the browser event and the CRM record.
- 4
Where to generate it
Once, at the earliest point both paths can read it. Pushing it into the data layer is the usual pattern.
- 5
The deduplication window
Finite. A server event delayed well past the browser event may not deduplicate, which makes send latency worth checking.
Event ID deduplication · diagnose
Common mistakes and how to validate each — Event ID deduplication
Ordered by how often we find them. Each one has a specific check rather than a general instruction to be careful.
- 01
Two paths, two IDs
Capture both payloads from one real conversion and compare the IDs character by character.
- 02
Event name case mismatch
Purchase versus purchase. Read both payloads rather than both configurations.
- 03
More paths live than anyone realised
List every integration, app and container that could be sending. Count them; the number is usually a surprise.
- 04
Server event sent too late
Check the delay between the browser event and the server send. Long queues can exceed the window.
- 05
Indicator never checked
Meta exposes a Deduplicated indicator. Read it over seven days, not one session.
Event ID deduplication · prove
How to prove your implementation is right — Event ID deduplication
Against your own records and a live payload, not against a preview screen.
Source of truth
your backend records, matched on the business ID used as the event ID
- Identical event ID confirmed on both paths for one real conversion.
- Deduplicated indicator visible where the destination exposes one.
- Conversion count within a few percent of your own records for a closed week.
- No business ID appearing twice at any destination.
- Checked on a live conversion, not in preview mode.
- Reconciled over a fully closed window, matched per record.
- Re-checked 30 days later.
Event ID deduplication · free audit
What we check in the free audit
- Two paths, two IDs
- Event name case mismatch
- More paths live than anyone realised
- Server event sent too late
- Indicator never checked
Checked against
your backend records, matched on the business ID used as the event ID
Free30 minutesNo obligation
Event ID deduplication · when not to buy
What this reference deliberately leaves out — Event ID deduplication
Stated openly, because a reference that's silent about its own gaps is the dangerous kind.
- Deduplication behaviour differs by destination and each publishes its own rules. This page covers the shared principle rather than every platform's specifics.
- Deduplication window lengths aren't published consistently and we're not going to invent numbers. Keep server latency low and verify the indicator.
- Some destinations offer no deduplication at all. Where that's the case the answer is one path, not two.
- Vendor documentation is the authority, not this page. Where the two disagree, the vendor is right and we'd like to know so we can correct it.
- Parameter names and behaviour change. Anything here is accurate as we last verified it; verify against the current documentation before you rely on it for a build.
Event ID deduplication · what we deliver
The checklist — Event ID deduplication
The same event_id is present on both paths
Byte-identical, verified on one real conversion.
The ID comes from a business record
Not generated per path.
Event names match exactly between paths
Including case.
Server latency is inside the deduplication window
A long delay can push the server event outside it.
Only the intended paths are live
A partner integration plus an app plus a container is three paths for one order.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup against this reference, on a live conversion.
- Implementation checked against the spec
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, built to this specification.
- First-party server container on your own subdomain
- Events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, documented to this standard.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
Event ID deduplication questions, answered
A stable business identifier — the order number for a purchase, a lead ID for a lead. Both paths can produce it identically without coordinating.
Only if it's generated once and both paths read the same value. A random value generated separately per path defeats the whole mechanism.
Where the destination exposes an indicator, read it over a full week. Otherwise, count your conversions against your own records — roughly double is the tell.
Yes. Most destinations match on name and ID together, and a case mismatch is enough to produce two events.
Free · 30 min
Prove your deduplication actually works
WhatsAppFree30 minutesNo obligation
