Event deduplication: how to stop double-counting purchases

The moment you add server-side tracking on top of your existing client-side tags, you create a new risk: counting the same purchase twice. It is the natural side effect of sending one sale down two paths, and if you do not handle it deliberately, your revenue numbers inflate and your bidding algorithms learn the wrong lesson.

The good news is that deduplication is a solved problem with a clean, deterministic answer. This article explains why double-counts happen in the first place, why naive fixes fail, and how a shared event_id derived from the order reference makes one sale count exactly once — across GA4, Meta, and Google Ads alike.

Why double-counts happen

There are two common sources of duplicate conversions, and most stores eventually hit both.

The first is hybrid setups. To recover conversions that ad-blockers and ITP hide, the recommended approach sends each purchase from both the browser (the pixel or client-side tag) and the server (the Conversions API or server-side tag). That redundancy is intentional and good — but without deduplication, the analytics platform receives two events and credits two sales.

The second is page reloads and retries. A confirmation page that the shopper refreshes, navigates back to, or that retries a failed beacon can fire the purchase event again. If each fire uses a fresh random identifier, every reload looks like a brand-new order. Stack the two causes together and a single sale can be counted three or four times.

Why random IDs make it worse

The instinct is to give each event a unique ID so you can tell them apart. For deduplication, that is exactly backwards. A random event_id guarantees that the browser event and the server event for the same sale carry different IDs — so the platform sees two distinct conversions and counts both.

The same flaw breaks reload handling. If the confirmation page generates a new random ID every time it loads, a refresh produces a second "unique" purchase that nothing recognises as a duplicate.

Deduplication needs the opposite property: the same logical sale must always produce the same ID, no matter how many times or from how many places the event fires. Uniqueness per fire is the enemy; consistency per sale is the goal.

The deterministic event_id

The robust solution is a deterministic event_id derived from something that is already stable and unique per sale: the PrestaShop order reference. Because the order reference does not change, every path and every reload can compute the identical event_id independently — without coordinating with each other.

When the pixel and the Conversions API both send a purchase with the same event_id, Meta recognises them as one sale and counts it once. GA4 deduplicates the same way using a deterministic transaction_id from the order reference, and Google Ads conversions collapse cleanly too.

This is the core design decision behind a clean hybrid setup: identity comes from the order, not from a random number generated at fire time. Reloads, back-button clicks, and dual-path delivery all resolve to one canonical conversion.

How hybrid setups deduplicate end to end

In a properly built hybrid pipeline, deduplication is not a single switch but a consistent principle applied everywhere. The browser-side tag and the server-side tag for a given sale share one deterministic event_id. The platforms — Meta for CAPI, GA4 for analytics, Google Ads for conversions — each use that shared identity to merge the duplicate into one.

The payoff is that you get the reliability of server-side delivery and the behavioural richness of client-side tracking, with none of the inflation that would otherwise come from sending everything twice. The redundancy protects you against loss; the deduplication protects you against double-counting.

PrestaSignal implements exactly this: one deterministic event_id per order, reused across Meta CAPI, GA4 tracking, and Google Ads tracking, so a single sale is counted once everywhere.

How to tell if you have a problem

Suspect double-counting when GA4 or Meta report more conversions or revenue than your PrestaShop back office, especially after adding a server-side or pixel-plus-CAPI setup. A revenue figure that runs consistently above your actual takings is the clearest tell.

Another symptom is erratic bidding behaviour: if Smart Bidding or Meta optimisation suddenly overspends, it may have learned that certain clicks are worth twice what they really are, because duplicates taught it inflated values. Duplicate conversions distort optimisation just as badly as missing ones.

If any of this sounds familiar, the diagnosis is usually a missing or non-deterministic event_id. To have your setup checked against your real orders, book a teardown and we will identify exactly where the duplicates are coming from.