Conversion Deduplication

Conversion deduplication is the process of recognising that two reported conversion events describe the same real action, and counting them once. It exists because most modern tracking setups deliberately send the same purchase twice, once from the browser and once from a server, so that one can cover what the other loses. Without a shared identifier on both sends, the platform counts two sales where one happened.

Why Duplicate Conversions Happen

Duplicates come from three distinct situations, and only two of them are a deduplication problem.

1. Two sources, one platform. A Meta Pixel fires in the browser and the Conversions API posts the same purchase from your server. This redundancy is intentional. Ad blockers and Safari’s cookie limits kill browser events, so the server send is the safety net.
2. One source, fired twice. A customer refreshes the thank-you page, a single-page app re-renders the confirmation route, a tag is installed twice, or a queued request retries after a timeout. Each of these fires a second identical event.
3. Two platforms, one order. Meta claims the sale and Google Ads claims the same sale. Both are reporting honestly under their own attribution rules.

Cases 1 and 2 are solved with an identifier. Case 3 cannot be, which is the distinction most teams miss.

How Conversion Deduplication Works

The platform compares an identifier on incoming events and discards the second match. You generate that identifier once per user action and attach the identical value to every send describing it.

For Meta, the browser event and the server event must carry the same event_id and the same event name. Note the casing difference, which is a frequent cause of silent failure: the Pixel expects eventID while the Conversions API expects event_id.

// Browser: Meta Pixel
fbq('track', 'Purchase',
  { value: 89.00, currency: 'USD' },
  { eventID: 'order-10482' }
);

// Server: Meta Conversions API
{
  "event_name": "Purchase",
  "event_id": "order-10482",
  "event_time": 1757808000
}

The value itself is arbitrary. An order ID works well because it already exists, is unique per transaction, and is available to both the browser and the server. A timestamp or a random value generated separately at each send will never match, so nothing deduplicates.

Deduplication Keys and Windows by Platform

Each platform uses its own key and its own window. Getting the key right is the whole job.

Platform	Deduplication key	Window
Meta	event_id plus event_name, both must match	48 hours
TikTok	event_id plus the event name	48 hours
Snapchat	client_dedup_id	48 hours
Google Ads	Transaction ID, also called order ID	Not documented
GA4	transaction_id	Not documented

Two documented limits are worth knowing. Google caps the Google Ads transaction ID at 64 characters and prohibits any customer-identifying data in it, so no email addresses, phone numbers, URLs, or prices. Google also states that GA4’s transaction_id deduplication applies to web streams only, not app streams.

Meta’s 48-hour window is generous but not unlimited. Server events that sit in a batch queue or a nightly export can land outside it, and a late event is counted in full rather than merged. When deduplication succeeds, Meta’s Events Manager reports the action as one event from two sources.

What Deduplication Cannot Fix

No identifier resolves conversions claimed by two different ad platforms. Meta and Google Ads each maintain separate systems, apply separate attribution models, and never see each other’s data. A single order touched by both channels appears in both accounts, and summing the two totals overstates real revenue.

This is an attribution problem, not a deduplication problem, and it needs a single source of truth rather than a shared ID. The same logic explains why platform totals never reconcile to your order data, covered in data discrepancy.

Deduplication is also not retroactive. It happens when events are received, so a missing or mismatched event_id cannot be repaired after the fact. Historical duplicates stay in the reports permanently.

Common Deduplication Mistakes

• Turning off the Pixel to avoid duplicates. Redundancy is the design. Removing the browser event loses the data that server-side tracking cannot reconstruct, and removing the server event reinstates the loss from ad blockers and cookie limits.
• Generating the ID separately on each side. The browser and server must read the same stored value. Two independent calls produce two different IDs and zero deduplication.
• Sending an empty transaction ID. Google warns that GA4 deduplicates every purchase carrying transaction_id=" into a single event, which silently erases nearly all revenue.
• Reusing one transaction ID across orders. This is the inverse failure. Google states it causes significant undercounting, because genuinely separate conversions are merged.
• Mismatching event names. Meta requires both the name and the ID to match. A browser Purchase and a server purchase are two different events.
• Assuming deduplication handles cross-platform totals. It never has.

Frequently Asked Questions

What is deduplication in tracking?

Deduplication is the process of identifying two reported events that describe the same real action and counting them once. It is necessary because tracking setups intentionally send events through two paths, a browser pixel and a server API, so that one covers the failures of the other. The platform matches an identifier shared by both sends, keeps one event, and discards the duplicate.

How does event ID deduplication work?

You generate one identifier per user action, usually the order ID, and attach the identical value to both the browser event and the server event. When the platform receives the second event and finds a matching ID within its window, it discards it rather than counting it. For Meta, the event name must also match, and the window is 48 hours.

How do I deduplicate Meta Pixel and Conversions API events?

Send the same event_id and the same event name from both. The Pixel takes it as eventID in the third argument of fbq('track', ...), while the Conversions API takes it as event_id in the event payload. Confirm it is working in Events Manager, where a correctly deduplicated action is reported as one event from two sources rather than two events.

Why are my conversions still duplicated?

The usual causes are a mismatched or absent event ID, different event names on the two sends, a server event arriving outside the 48-hour window, or the same tag installed twice on the page. A thank-you page that a customer can refresh or bookmark will also fire repeatedly unless the event carries a transaction ID.

Can you deduplicate conversions across platforms?

No. Meta, Google Ads, and every other ad platform count independently and cannot see each other’s conversions, so a shared ID does nothing across accounts. Reducing that overlap requires picking one system as the source of truth, or measuring against order data in your own database.

Untagged campaign links are a common reason conversions land in the wrong place before deduplication ever applies, so validate your links with the free UTM checker at linkutm.