Every serious measurement setup today collects the same event twice. Browser pixel plus server API. That redundancy is deliberate – and it manufactures the exact problem deduplication exists to fix.
PPC Land has published a deep explainer on how deduplication actually works across conversions, audiences and the bidstream. If you run paid media, this is the plumbing under every number in your dashboard.
What deduplication actually is
It’s the process of recognising that two or more records describe the same underlying thing – a conversion, a person, or an ad impression put up for auction – and merging them into one count.
Why the duplicates exist: browser tags leak events to ad blockers, tracking prevention and consent refusals. Server feeds leak events that never reach the backend. Running both recovers more of the truth. It also means the same purchase can be counted twice.
Three components, one key
Every dedupe rule needs the same three parts: an identifier both records carry, a matching rule, and a time window.
- Meta: the pixel sends eventID, the Conversions API sends event_id. Where those values and event names agree, they resolve to one event. Meta’s docs say a match within 48 hours resolves to whichever arrived first, and when server and browser events land within roughly five minutes, the browser or app event wins. Meta recommends an order or transaction ID as the key.
- Google Ads: uses transaction ID / order ID. Imported identifiers must match the tag-captured transaction_id exactly – stray whitespace, prefixes or suffixes break it. Optional for offline conversion import, required for supplementary sources via Data Manager.
- OpenAI: ChatGPT ads conversion tracking already reproduces the pattern – shared event_id across pixel and Conversions API, matched on pixel ID, event name and event_id.
The scary part: failure at this layer is silent. Nothing throws an error. The count simply doubles.
Where implementations break
Mundane stuff. Reloading an order confirmation page fires the tag again – the original reason transaction IDs exist. Two GA4 and server-side Tag Manager defects documented in September 2025 inflated event counts through duplicate hits, one traced to service worker communication, with a workaround limited to removing an iframe.
Platform integrations import the problem wholesale. Google’s server-to-server route for Shopify orders deduplicates purchases by transaction ID – but only for events from the Google and YouTube app, not a third-party server feed running alongside. When four more shopping events joined the mapping on 17 August 2026 – view_item_list, remove_from_cart, view_cart, add_shipping_info – none carry a transaction identifier. Merchants who already fire those in their own containers get the same interaction recorded twice.
One structural limit is easy to miss: transaction ID dedupe works inside a single conversion action. Two separate conversion actions describing one sale – common when an Analytics-derived action sits next to a native one – are never reconciled by any shared key.
The bidstream version
Header bidding created the auction-side problem: one page runs one auction, fans the impression to several exchanges, all forwarding to the same DSPs. Without a shared marker, a buyer sees five opportunities where one exists – and bids against itself.
OpenRTB 2.5 introduced the Source object with a tid field, drafted November 2016 with comment closing 16 December, explicitly motivated by header bidding. A June 2022 community extension extended it to per-impression identifiers.
Then on 27 August 2025, a Prebid.js change generated bidder-specific values, so each demand partner got a different ID for the identical opportunity. IAB Tech Lab called it a material violation the same day, with CEO Anthony Katsur saying the approach “risks undermining the integrity and consistency of open technical standards”. Publishers had argued the shared ID let buyers stitch requests across sellers and expose relationships they wanted kept private.
Reach dedupe is a different animal
Net unduplicated reach needs a link between identifiers belonging to one person – a device graph, whose accuracy caps any deduplicated reach figure.
Google shipped Cross-Media Reach measurement in June 2024; DV360’s Unique Reach Overlap reports had pre-filtering rebuilt on 8 July 2025 and gained campaign- and placement-level dimensions on 10 April 2026. Amazon added cross-order reach and frequency in December 2024 – its docs cite a CPG advertiser finding 34% reach overlap across orders from three brands in one business line, plus an average 6% unique reach lift from Frequency Groups (Amazon’s own internal September 2023 data). Cross-account reporting followed in April 2026.
Where it stops working
Coverage ends at the ecosystem boundary. Amazon dedupes Amazon. Google dedupes Google. No shared key crosses between them. That’s why de-duplicated Meta measurement inside the LiveRamp clean room, announced August 2026, was treated as a gap being closed rather than routine reporting.
The IAB Tech Lab’s ECAPI 1.0, published May 2026, tries to standardise the conversion side – marking event id as strongly recommended and instructing that where an identifier can’t be shared, the event should be submitted from a single channel only.
Your action list
Audit before you optimise. Use order or transaction IDs as your dedupe key everywhere. Check that imported IDs match tag-captured ones character for character. Look for duplicate conversion actions describing the same sale – no key fixes that. And remember errors run both ways: no dedupe overstates reach and conversions, aggressive dedupe discards a genuine second order or collapses a household into one viewer.
Deduplication decides whether there was one conversion or two. Attribution can’t allocate credit until that question is settled.
Source: PPC Land
