Detection: Browser pixel and CAPI events are double-counting

Key: pixel_capi_deduplication_broken Severity: Medium–Critical (scales with rate) Confidence: 95% Shipped: v1.2, May 2026 Runtime: Requires Meta OAuth (the dedup_rate field is Meta-API-only).

What this detection looks for

We fire one account-level finding when:

1. A Purchase pixel event exists with both is_browser=True AND is_capi=True
2. The event's dedup_rate is populated AND below 0.85

Severity scales with how broken the dedup is:

Why this matters

When browser pixel and CAPI both fire for the same Purchase but their event_id deduplication keys don't match, Meta counts the conversion twice. Reported Purchases inflate by 30–80%, the ROAS dashboard becomes a lie, and downstream optimization decisions get made on phantom conversions.

This rule is independent of EMQ (event match quality) and presence checks:

• capi_missing_or_weak answers "is CAPI even firing?"
• capi_event_match_quality_low answers "is CAPI matching to a person?"
• pixel_capi_deduplication_broken answers "are CAPI + pixel double-counting the same purchase?"

Pilothouse's Q1 2026 technical review lists broken dedup as one of the most common — and most expensive — tracking failures because every other finding's dollar impact gets miscalculated when the conversion count is inflated.

How we estimate the recoverable dollars

deficit_tenths = (0.85 − dedup_rate) × 10
impact_share = deficit_tenths × 0.05
monthly_impact = account_ad_spend × impact_share × 30 / audit_days

Each tenth below the 0.85 floor contributes ~5% to the impact share. At a 0.50 dedup rate (35% below floor = 3.5 tenths), the impact is ~17% of account spend optimizing against double-counted events.

What would change our mind

• Single-channel accounts. If you only fire the browser pixel OR only CAPI (not both), there's nothing to dedupe. The rule withholds in that case.
• Recent dedup-key change. If you changed the event_id parameter in the last 14 days, the rate is in transition. Re-audit after 2 weeks.
• Different event-id semantics. Some platforms (Shopify's CAPI integration, GTM server-side) generate event_ids with subtle timing differences that can degrade match without functionally breaking dedup. Verify in Events Manager that the SAME purchase shows up as ONE event after dedupe.

What to do about it

1. Verify the event_id parameter is identical on browser pixel + CAPI for the same Purchase. The most common cause: server-side fires a new UUID per request; the browser fires a different identifier. They must match exactly.
2. Set up the Events Manager dedup audit. Meta has a built-in tool that shows which events are deduping. Use it to confirm the fix.
3. After fixing, every other finding's dollar estimate needs re-reading. The audit you ran during broken dedup overstated all the per-finding losses. Re-run the audit after the fix lands.

References

• Pilothouse Q1 2026 Technical Review (dedup section)
• Meta Business Help Center: Deduplicating browser + CAPI events