Most CAPI problems aren't build problems, they're testing problems. The setup looked fine, nobody checked, and a month later the numbers are doubled or the match rate is on the floor.
Here's how to test CAPI events so those surprises stop happening to you.
Start with the platform's test tool
Meta's Test Events tab, and the equivalent on every other platform, exists for exactly this. Add the test_event_code to your server payload, fire a real event, and watch it land in the test view in real time.
If it doesn't appear there, nothing downstream matters yet, so fix that before anything else.
What to actually check
- The event is received from both the pixel and the server.
- It's marked deduplicated, not counted twice.
- The event_id matches on both sides.
- Value and currency are correct and tie out to the order.
- user_data is present and properly hashed.
- action_source is right, website for web, something else for offline.
Test the real flow, not a synthetic one
Fire the event through the actual checkout, not a simulator or a standalone test page. Then test the awkward cases that break in production:
- A refund, so you know the reversal sends back.
- A post-purchase upsell, which loves to fire a second Purchase.
- A cached confirmation page, where the pixel often misbehaves.
Check match quality, not just receipt
An event can arrive and still be nearly useless if the platform can't match it to a person. Read the Event Match Quality score, and treat a low score as a real defect, because it caps how much of your data actually optimizes anything.
Make it ongoing, not a launch step
- Re-test after every tag, plugin, or theme change, since those are what break dedup.
- Watch the deduplication rate in diagnostics weekly, not once at launch.
- Set an alert on a sudden jump in conversion counts, your early warning for a broken event_id.
Build a repeatable test checklist
Testing sticks when it's a list someone can run without thinking, not tribal knowledge in one person's head. Write down the exact events to fire, the values to expect, and the screens to check, so anyone can validate a change.
A good checklist turns "I think it's fine" into "I ran the ten steps and it passed," which is the difference between a setup you trust and one you hope about.
Watch it in production, not just in test
The test tool proves an event can fire correctly. It doesn't prove your real traffic does. Keep an eye on the live diagnostics: the deduplication rate, the match-quality trend, and the raw conversion count against your store.
Sudden divergence between the platform's numbers and your backend is the earliest sign something broke, usually right after a change nobody flagged as risky.
What good looks like
Every key event fires once through the real flow, arrives from both sources, deduplicates, and matches well, and the live dedup rate holds steady week over week. Hit that and you've moved testing from a launch-day scramble to a quiet, boring habit, which is exactly where you want it.
The teams that never get burned aren't the ones with the cleverest setup. They're the ones who test the same boring way after every change, so a broken event_id surfaces in an afternoon instead of at the end of a quarter. Boring, repeatable testing wins here every time.
Most CAPI problems are testing problems, so make testing the habit, not the launch step. Fire a real event, confirm it arrives once, deduplicated and well matched, and re-check after every change, and the doubled-count surprises stop happening to you.
Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.
