Meta Pixel and CAPI: Event Deduplication Diagnostic
How do I diagnose duplicate events between pixel and CAPI?
Build a ledger keyed on event name and event identifier, then classify each record as the first valid occurrence, a browser and server twin, or an idempotent retry. A duplicate rate calculated without that classification counts legitimate retries as faults and misdirects the repair.
For the surrounding account decisions, compare Meta Ads Reporting vs Execution Tools and use Meta Pixel and CAPI: Event Collection Architecture as the next diagnostic.
In short
This guide owns one decision artifact: the filled, auditable structure below. Reader-supplied thresholds stay explicit; missing evidence stays missing.
Deduplication diagnostic
Use the following as the operator’s occurrence ledger. Meta’s current deduplication documentation discusses browser/server event-name and event-ID matching; accessed 2026-08-27, re-check before release.
| Occurrence ID | Browser/server source | event_name |
event_id |
Occurrence ts | Receipt ts | Retry attempt | Order ID | Duplicate classification |
|---|---|---|---|---|---|---|---|---|
| Cart mutation key | Browser | AddToCart |
Stable cart-mutation ID | Client action time | Collector receipt time | 0 | None | First valid browser record |
| Same cart mutation key | Server | AddToCart |
Same stable cart-mutation ID | Accepted mutation time | Collector receipt time | 0 | None | Browser/server pair for one logical event |
| Order transition key | Server | Purchase |
Immutable order-event ID | Authorized-order time | First receipt time | 0 | Commerce order ID | First valid purchase record |
| Same order transition key | Server | Purchase |
Same immutable order-event ID | Same authorized-order time | Later receipt time | 1+ | Same order ID | Retry; duplicate if first record was accepted |
| Different key, same order | Browser or server | Purchase |
Conflicting ID | Any | Any | Any | Same order ID | Suspected double fire; inspect trigger and state transition |
Duplicate rate = (event records classified as duplicates after the first valid record per logical occurrence) ÷ (eligible event records received in the diagnostic window). Source/window: immutable raw collector log plus commerce order transitions. Limitation: define eligibility and the logical key before counting; a duplicate rate does not assess payload accuracy.
Interpretation boundary
Use the logical-occurrence dedup ledger only for its stated decision. Classify the first valid record, browser/server twin, idempotent retry, and suspected double fire using immutable raw receipts. Do not calculate duplicate rate until event eligibility and the event_name plus event_id logical key are frozen. Reader-supplied thresholds remain inputs, not universal standards.
Where implementation depends on Meta behavior, re-check Meta’s current Business Tools Terms and linked product documentation before release; accessed 2026-08-27. The tables below are operator contracts unless a primary Meta source is linked.
Can software help?
Bach.ai audits your connected Meta account against 100+ checks, ranks what it finds by estimated impact, and proposes specific fixes. It stays read-only by default, then executes the approved change on Meta; connected Google Ads accounts work the same way, on a narrower set of actions. Think of it as an automated audit layer that surfaces issues and proposed fixes for your review — not a replacement for your team’s judgment, and creative production is not its core job, though the Pro and Agency plans can generate a limited number of variants.
FAQ
How do you classify Pixel and CAPI records for deduplication?
Classify the first valid record, browser/server twin, idempotent retry, and suspected double fire using immutable raw receipts.
What must be fixed before calculating a duplicate-event rate?
Do not calculate duplicate rate until event eligibility and the event_name plus event_id logical key are frozen.
Can a deduplication ledger prove why campaign performance changed?
It isolates competing explanations through the logical-occurrence dedup ledger. The resulting branch is a diagnostic decision, not proof that one candidate caused the observed change.
Method and sources
“Build a ledger keyed on event name and event identifier, then classify each record as the first valid occurrence, a browser and server twin, or an idempotent retry.”
Source: Where this guide describes platform behaviour, it follows Meta’s published advertising and Marketing API documentation, which changes without notice — verify anything load-bearing against the current version before you act on it. Every threshold the guide asks you to supply is first-party, drawn from your own account exports and commerce ledger, because no external benchmark can stand in for your own margin structure.