- Browser pixels die to iOS ATT, ad blockers, Safari/Firefox tracking prevention — and in India, to the checkout redirect through Razorpay/PayU-style gateways.
- CAPI sends conversions server-to-server, deduplicated against the pixel via a shared event_id. Better match quality → better bidding → measurably lower CPA.
- CAPI fixes signal loss, not attribution inflation. Meta hears about more of your real orders — it still claims credit its own way. Reconciliation remains your job.
Somewhere between a fifth and two-fifths of your real conversions never reach Meta's pixel. Each miss hurts twice: reporting undercounts (you kill working ads), and the bidding algorithm learns from a biased sample (it optimises toward users whose browsers happen to be trackable). The Conversions API is the fix — and it's now table stakes, not an optimisation.
How the signal actually dies
| Killer | Mechanism | Who it hits |
|---|---|---|
| iOS ATT (2021→) | Opt-outs strip identifiers; Meta models the gap | All iOS traffic |
| Safari ITP / Firefox ETP | Cookies capped or partitioned; pixel loses continuity | ~15–25% of Indian D2C traffic, more for premium audiences |
| Ad blockers | Pixel script never loads | 5–15%, skews to high-income users |
| Payment-gateway redirects | Checkout hops to Razorpay/PayU/bank OTP page and back; the purchase event fires on a page the pixel never sees — or never fires | Chronically underrated in India — hits COD-verification and UPI flows too |
What CAPI is (one paragraph, no mystique)
Instead of the customer's browser telling Meta "purchase happened," your server does — an HTTP call from your backend (or Shopify's) carrying the event plus hashed identifiers (email, phone). No browser, so nothing to block, expire or lose in a redirect. The order confirmed in your system is the event Meta hears about, including COD orders confirmed after the browser session ended.
The rule that makes or breaks it: deduplication
Run pixel and CAPI together (redundancy is the design), but every event needs one shared event_id. Broken dedup silently inflates results and mis-trains bidding — the failure mode where "CAPI made our ROAS better" actually means "we started counting everything twice."
Setup options for a Shopify brand
| Option | Effort | What you get | Watch out |
|---|---|---|---|
| Shopify's native Meta integration (Max level) | Hours | Pixel + CAPI + dedup handled for standard events | Custom events limited; verify it's set to server-side max, not pixel-only |
| Tag-manager server container (sGTM) | Days–weeks | Full control, one server pipe feeding Meta + Google + others | Needs someone to own the container; misconfig = silent double-counting |
| Specialist tools (Elevar-class) | Days | Server-side + persisted UTMs/click IDs into order attributes — the attribution join for free | Subscription cost; audit what they enrich |
How to verify it's actually working
- Events Manager → your pixel → Overview: purchase events should show "Browser · Server" with a healthy dedup rate — server-only or browser-only rows are the tell that one leg is down.
- Event Match Quality (EMQ): aim 6+ on purchases. In phone-first India, hashed phone numbers move EMQ more than email — send both.
- The reconciliation check: Meta-reported purchases for a week vs Shopify orders for the same week. CAPI done right narrows the count gap (signal recovered); the revenue-credit gap will remain — that's attribution, not plumbing.