The Duplicate Count: Auditing a CAPI + Pixel Event Log
Objective: Given a raw exported event log containing both browser-pixel and Conversions API (CAPI) events, identify which conversions are being double-counted because they lack a shared event ID for deduplication.
You're the growth marketer at Duolingo checking why last week's Meta Ads Manager purchase count for the Plus subscription campaign looks 40% higher than the number in the billing system.
Pull the raw event export, match pixel and CAPI rows by event ID and timestamp, and flag every purchase that was logged twice.
Before you start
What you'll need
Free path (everything below is enough to finish)
Free, no account access needed, handles a few thousand rows easily
The process
1 step
Step 01 of 01
The lesson's Mistake 2 explains that running the browser pixel and CAPI together without a shared event ID makes Meta log the same purchase twice, inflating conversion counts by 30-60%.
This export has 50 purchase rows, 18 of them share an identical event_id value across a pixel row and a CAPI row. How many real purchases actually happened?
Procedure
- Import capi-pixel-events.csv and freeze row 1
- Sort by event_id, then by source (pixel vs capi)
- Use COUNTIF on event_id to flag any value appearing more than once
- Subtract the flagged duplicate count from the total row count to get real purchases
event_id source value timestamp evt_2291a pixel 12.99 14:02:03 evt_2291a capi 12.99 14:02:05 evt_2295b capi 12.99 14:05:11 evt_2299c pixel 12.99 14:07:44 COUNTIF(event_id) > 1: 18 rows (9 duplicate pairs) Raw row count: 50 | Deduplicated purchase count: 41
Healthy
Every duplicate pair shares one event_id across pixel and CAPI; the dashboard total is corrected down to the deduplicated count before anyone reports ROAS.
Unhealthy
Reporting the raw 50-purchase count as 'conversions' when 9 of those purchases were logged twice, inflating ROAS by roughly 22%.
What this means
A shared event_id is the only thing that tells Meta two rows are one event, not two; without it, every dual-tracked purchase counts twice.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| Ads Manager purchase count is meaningfully higher than the billing system's real order count | Pull the raw event export and COUNTIF the event_id column before trusting the dashboard number | 5 min |
| No event_id column exists in the export at all | Flag to the developer that CAPI events are firing without a matching pixel event_id parameter, this is a required fix, not optional | dev ticket |
Final deliverable
A corrected purchase count with every duplicate pair flagged, plus a one-line note on the true ROAS versus the dashboard's inflated number.
See a reference example
Wise, Meta Ads purchase export audit (excerpt) Raw dashboard count: 112 purchases Duplicate pairs found (matching event_id, pixel + capi): 21 Corrected purchase count: 91 Dashboard ROAS: 4.8x -> Corrected ROAS: 3.9x
Success criteria
You're done when you can:
- Correctly identifies every duplicate event_id pair in the export
- Produces a deduplicated purchase count that matches the billing system
- States the corrected ROAS, not just the raw dashboard number