How dedup keeps one action one event

Why doubles happen#

Doubles happen because redundancy is the design: the Pixel fires from the browser in milliseconds while the server confirms minutes later with better data. Both copies are wanted, because either stream alone misses actions the other catches. Without a shared key, Meta sees two purchases for one order and bids accordingly.

The cost lands everywhere: inflated ROAS flatters reports, learning trains on fiction, and budgets scale into phantom demand. Dedup is therefore not hygiene but honesty, and it belongs in every dual-stream setup from day one. How the streams pair is introduced in CAPI setup.

The event ID contract#

One action, one event ID: generate the key at the source of truth, the order confirmation or the validated form handler, then pass the identical value to Pixel and CAPI. The ID must be unique per action, stable across streams, and resolvable months later when finance asks what a spike was. Order IDs plus timestamps make natural keys for shops; validated submit IDs serve lead sites.

Never let each stream mint its own key; per-stream random IDs are unmatchable by construction and guarantee double counting. Document the key scheme beside standard events notes so future developers inherit the contract. Developer key rules are at dedup parameters.

Names must match exactly#

The event name is the second half of the key: Purchase pairs with Purchase, Lead with Lead, character for character. A browser Purchase beside a server purchase_complete is two events, not one merged pair, and naming drift usually enters through separate teams owning separate streams. One shared event map, reviewed quarterly, prevents the drift.

Parameters should agree too: value, currency and content IDs consistent across copies give the merge clean material and reconciliation a legible trail. Where streams disagree on value, investigate before spending; the gap usually names a discount, refund or currency fault. Pixel setup sets the browser half.

Testing the merge#

Test with both streams live in Test Events mode: trigger a real action, then confirm the browser and server fires arrive with identical IDs and collapse to one counted event. Confirm the unhappy paths as well: failed payments and bounced forms must produce zero counted events, not one, and refunds must adjust value rather than duplicating. Meta own Test Events guidance walks the tooling.

Repeat the test after every checkout, form or tag-server release; dedup breaks silently inside successful deploys. Keep a dated test log with order IDs used, so audits can trace any historical spike to its cause. Attribution windows then decide how the single counted event is credited.

Faults we see most#

Three faults dominate our audits: random IDs minted per stream, names that drifted between teams, and Purchase fired on the button click instead of the confirmed order. Each inflates counts by a different multiple, and each hides inside healthy-looking ROAS until finance reconciles. Start every audit at the key, then the name, then the trigger point.

Fixes follow the same order: one key minted at the source of truth, one shared event map, triggers on confirmation only. Shops with feeds should also confirm catalogue ID alignment via catalogue setup. Start at the Meta Ads hub for the family view.

Dedup beyond the website#

Offline and store sales re-enter through uploads matched on customer data, and the same uniqueness discipline applies: one order ID, one counted event, no re-uploads of the same period without replacing the prior file. Phone and store closes attributed to ad clicks need click IDs captured at enquiry time, or matching leans on weaker fields.

Map every source, browser, server and offline, into one event ledger with owners and key schemes. Offline conversions covers the upload path, and our team audits ledgers when counts drift.

Frequently asked questions#