Most founders set up the Pixel, fire a test event, and consider tracking done. That's the wrong finish line.
Since iOS 14 rewrote how iPhones handle app tracking — and Safari has blocked third-party cookies for years — browser-based tracking loses signal every month. Your Pixel fires through the customer's browser. If that browser blocks scripts, the customer taps "Ask App Not to Track," or an ad blocker intercepts the call, the signal disappears. Meta doesn't know the sale happened. The result: Ads Manager shows 20 purchases. Your Shopify dashboard shows 34. That gap isn't a reporting quirk — it's your algorithm training on the wrong data.
What Pixel and CAPI actually do
Pixel is a JavaScript snippet that runs in the customer's browser when they visit your site. It fires events — PageView, AddToCart, Purchase — and sends them to Meta in real time.
The problem: it depends entirely on the browser cooperating. Ad blockers, Safari's ITP (Intelligent Tracking Prevention), and iOS permission prompts can all kill the signal before it reaches Meta.
Conversions API (CAPI) sends event data directly from your server to Meta — bypassing the browser entirely. The customer's cookie settings, their browser version, whether they're on iPhone or VPN — none of that matters. Your server knows a purchase happened, and it tells Meta through a direct, server-to-server connection.
Why Event Match Quality is your tracking canary
Meta scores how well your event data matches actual Facebook accounts using Event Match Quality (EMQ). Higher EMQ means better optimization signal — which means lower cost per result.
| EMQ Score | What it means |
|---|---|
| 6–7 (green) | Strong — algorithm has clean signal to work with |
| 4–5 (yellow) | Passable — add email + phone to your CAPI payload |
| 1–3 (red) | Broken — conversion optimization is running blind |
CAPI consistently produces higher EMQ than Pixel alone because server-side data can include customer identifiers — email, phone number, country — that browsers often strip or block before Pixel can capture them.
What you're actually losing without CAPI
Accounts that switched from Pixel-only to Pixel + CAPI typically find they were undercounting conversions by 20–40%, according to Meta's own audit benchmarks.
The downstream problems are worse than the raw number gap:
- The algorithm builds lookalikes from incomplete data — it's learning from half your buyers, so it finds the wrong next audience
- Late-window conversions disappear — a customer who converted 3 days after seeing your ad often won't be attributed if iOS removed the cookie in the meantime
- Your reported ROAS is lower than actual — which can make you pause campaigns that were genuinely working
The trap that bites after you add CAPI
Here's the one nobody mentions until you've already done it wrong.
When you run both Pixel and CAPI simultaneously, Meta receives the same event twice — once from the browser, once from the server. Without deduplication, Meta counts that as two separate conversions. Your ROAS jumps 40–60% overnight. You feel great. But you're not selling more — you're just counting the same sales twice.
The fix: pass the same Event ID in both the Pixel fbq() call and the CAPI payload for every event. Meta uses that ID to deduplicate automatically. Matching IDs = one conversion. Missing or mismatched IDs = double-counted ROAS that will mislead every campaign decision you make.
Quick reference
| Your platform | CAPI setup path |
|---|---|
| Shopify | Enable via the Meta channel app — takes about 5 minutes |
| WooCommerce | PixelYourSite Pro + CAPI addon |
| Custom website | Server-side integration via Meta's Conversions API gateway |
| Not sure if CAPI is running | Events Manager → check if events show "Server" source alongside "Browser" |
What to do next
Open Events Manager and look at your active events. If you only see "Browser" as the data source — you're on Pixel-only and losing signal right now. If you see both "Browser" and "Server" — check that the event volumes are close but not doubled (doubled volume means deduplication isn't configured correctly).
AdBlueprint reads your Event Match Quality score and event volume directly from Events Manager and flags tracking gaps before they drain your ad spend silently. Fix the foundation, then scale — not the other way around.