Duplicate Conversions Tracker: Three Systems, Three Numbers

Underneath every duplicate conversions tracker investigation lies an uncomfortable truth: when the tracker says 80 conversions, the network balance says 74, and Ads Manager says 92, none of the three systems is broken. Every one of them counts by its own documented rules, over its own windows, from its own vantage point on the chain. Genuinely duplicated conversions hide inside that definitional noise - the same sale counted twice by the platform, or a postback re-registered after a status change - and finding them requires separating counting differences from real doubles. This guide does exactly that: what each system documents about deduplication, how duplicates actually arise across the chain, and a reconciliation procedure that ends with one of two answers - a defined difference, or the specific duplicate and its fix.

The complete affiliate tracking guide introduces the three-system picture; here it gets the forensic treatment.

First, Accept That the Three Books Disagree

Before hunting duplicates, account for the divergence that every system documents as intended behavior:

Only the last row is a duplicate at all. All the rest is reconciliation noise that mimics one, which is why "dedupe everything" is not a possible goal - the three books cannot agree because they are not counting the same thing.

What Deduplication Each System Actually Provides

Each layer has a documented mechanism, and they are not the same mechanism:

1. The platform dedups by event identity. Meta keeps the first received copy of an event with the same event_id and event_name arriving within a 48-hour window and discards later copies - and importantly, nothing deduplicates two events inside the same channel (deduplication documentation). Reddit pairs pixel and server events by conversion ID under its own rules (event deduplication). The event ID discipline is what makes any of this work: no shared identity, no dedup.
2. The tracker dedups by overwriting. Keitaro's postback contract: a new postback with the same subid and changed parameters overwrites the earlier conversion; an identical re-send does not re-fire the tracker's outgoing S2S queue, which also excludes duplicates (postback URL, S2S postbacks). Multi-action offers escape overwrite via the tid-style transaction parameter - "a unique value per postback records separate conversions."
3. The network dedups however its specification says - often not at all, which is why duplicate postbacks for the same subid arrive with different parameters and legitimately overwrite each other in the tracker while representing one real sale.

A trap sits between the layers: the tracker's overwrite consolidates one conversion row, but if the first version already went out to the platform, the platform keeps the first event - correction arrives late by design.

How Genuine Duplicates Arise Across the Chain

Genuine doubles come from a handful of patterns:

1. Identity drift. The same conversion forwarded twice with different event_id values - typically after a tracker re-import, a re-mapped postback, or a delivery retry that regenerated the ID. To the platform these are two distinct events; no dedup window will merge them.
2. Parallel delivery paths. The tracker integration sends the conversion and a script or CRM sends the same one - both with valid identities. Platform-side dedup only helps when the identity matches; two differently-built events about one sale both count.
3. Status-change resends. The network re-announces a conversion after hold resolution. Your tracker overwrites its row, but a delivery layer configured to fire on multiple statuses can send lead and purchase as if they were two sales. With distinct event names and IDs, both land.
4. Rebill confusion. Recurring payments sent as new conversions without transaction identity - correct for genuine rebills, catastrophic when the network re-reports the same first payment.

Notice what is absent from the list: the platform counting a properly-identified event twice. Documented windows do their job - duplicates happen upstream, in identity and wiring, not in the dedup logic itself.

The Reconciliation Procedure

Aggregate totals cannot localize a duplicate - one conversion can. The procedure:

1. Choose a suspicious interval and a sample - one conversion the tracker counts that you suspect doubled at the platform.
2. Follow its identity chain: tracker click record, network postback entries (Keitaro's postback and S2S logs show what arrived and what was sent (logs)), and the platform event ID it should carry.
3. Classify each gap. Postback arrived after the lead event was sent - defined behavior (your status policy). Two platform events with different event IDs for one sale - a genuine duplicate with identity drift. The same ID inside the window for a pixel-plus-server pair - not a duplicate; the platform already discarded one. Two server events sharing an ID are not merged, because cross-channel is the only dedup Meta documents.
4. Fix at the origin: one delivery path per conversion, stable event IDs derived from the conversion identity, and status routing that cannot double-fire - the wiring rules in the postback chain guide.
5. Re-run the sample monthly. The postback troubleshooting checklist covers the plumbing failures this procedure also flushes out.

When a Mismatch Is a Definition, Not a Bug

After reconciliation, most differences resolve into the documented buckets: events you chose to send that the network never confirmed, attribution windows that join clicks differently, holds that shrink the balance after the fact. The pixel-versus-CAPI variant for Meta specifically has its own deep dive in Facebook pixel and CAPI event deduplication, and the money-side view of the same divergence is in the tracker-versus-Ads-Manager discrepancy guide.

What remains in the bug bucket stays small and actionable: identity drift, parallel paths, and double-firing status routes - each fixed at its origin, not by "cleaning up" the platform side after the fact.

Duplicate Conversions: Frequently Asked Questions

Sources