Meta Pixel and CAPI: Event Deduplication Diagnostic

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 until you approve a change, then executes the approved change on Meta; connected Google Ads data is used for intelligence only. 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 it does not generate your creative.

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.