Glossary
Deduplication
Recognising that two records describe one event, so a purchase sent by both the browser pixel and the server counts once. A shared event ID links them.
Also called: dedupe, event deduplication
Send the same purchase from the browser and from your server — a common and sensible setup, because each path catches what the other misses — and the platform receives two events describing one sale. Without deduplication it counts both, and every number downstream is inflated.
The fix is an identifier both copies carry. Each sender stamps the same event ID, and the receiver treats two events with matching IDs inside a window as one event. That is the whole mechanism, and almost every failure is a variation on the ID not matching.
Where it goes wrong.
- The two senders generate their own IDs. They must share one, derived from the order, not created independently at each end.
- The IDs match but the event names do not. Most platforms match on both. A
Purchaseand apurchaseare two events. - The second copy arrives after the window closes. Server-side events that queue or retry can land outside it and get counted fresh.
- A retry sends a new ID. Now the retry is a second sale.
The one that cannot be fixed by configuration: deduplication only works inside a single receiving system. Two different vendors each receiving the same conversion will both count it, and no event ID makes them agree — they never see each other. Totals that exceed real revenue across tools are usually this, not a tracking bug.
Do not confuse with
Close enough to get mixed up, different enough that the mix-up costs something.
- Server-side tagging Sending marketing and analytics events from your own server instead of the visitor's browser, so requests that browser blockers stop can reach the platform.
- Modeled conversions Conversions a platform estimates with statistical models where consent choices, tracking prevention or privacy limits stop it from observing them directly.