Your Meta Pixel is almost certainly under-reporting. It runs in the browser, and browsers now block a meaningful share of what it tries to send — iOS tracking prompts, Safari and Firefox protections, ad blockers and cookie-consent refusals all remove events before Meta ever sees them. The Conversions API sends the same events server-side, where none of that applies. Run both together with a shared event ID so Meta deduplicates, and your optimisation improves because the algorithm finally sees the conversions it was already causing.
If your Meta account shows fewer conversions than your own records do, nothing is broken. That gap is the normal state of browser-based tracking in 2026, and the businesses that do not know it exists end up switching off campaigns that were actually working.
This is the technical piece behind a lot of "my ads stopped working" conversations we have across the 25+ ad accounts SSM manages. It is worth understanding before you touch a budget.
What does the Meta Pixel actually miss?
The Pixel is a piece of JavaScript running in your visitor's browser. Every time someone views a product, submits a form or completes a purchase, it fires an event from that browser to Meta. Which means anything that interferes with the browser interferes with your data.
- iOS app tracking prompts. When someone declines tracking, Meta's ability to tie that person's later action back to the ad they saw is severely limited.
- Browser tracking prevention. Safari and Firefox restrict third-party cookies and shorten the life of first-party ones, so return visits often look like new strangers.
- Ad blockers. A straightforward block of the Pixel script. No script, no event, no record that the conversion happened.
- Cookie consent. If your site asks for consent and the visitor declines, a correctly implemented Pixel does not fire at all.
- Connection drops. Mobile data, a fast tab close, a slow page — the event never completes its round trip.
None of that means fewer customers. It means fewer recorded customers, which is a very different problem — and a more dangerous one, because it makes a profitable campaign look unprofitable.
What does the Conversions API fix?
The Conversions API — CAPI — sends the same events to Meta from a server instead of a browser. Your website or store tells Meta directly: this person just bought, here is what they bought, here is the hashed contact information that identifies them.
Because that request never travels through the visitor's browser, ad blockers, tracking prevention and dropped connections do not touch it. Two things follow, and only one of them is about reporting:
- Reporting gets more complete. You see conversions that were always happening but were invisible.
- Optimisation gets better. This is the part that actually matters. Meta's delivery algorithm learns from the events it receives. Feed it 40% more conversion signal and it finds more of the right people — which is also why a starved event feed is a common reason campaigns sit in a stuck learning phase.
CAPI is not a workaround for a broken Pixel. Meta's own guidance is to run both, and the combination is what produces a complete picture.
What are the setup paths?
Four routes, in increasing order of effort. Pick the least technical one that fits your stack.
| Path | Best for | Effort |
|---|---|---|
| Native platform integration | Shopify, WooCommerce, WordPress | Low — connect the account, enable CAPI |
| Partner / CRM integration | Zapier, HubSpot, Zoho and similar | Low to medium |
| Conversions API Gateway | Custom sites with no dev team | Medium — Meta hosts the server side |
| Direct / server-side GTM | Custom builds needing full control | High — developer required |
For a Shopify store this is close to a switch you flip. On the NK Creation account — a jewellery brand whose store SSM rebuilt through the Shopify Admin GraphQL API, with 34 products and 12 collections — the event data is what made the diagnosis possible when one campaign brought traffic but no sales. Reading the funnel rather than the ad report is what pointed at the storefront: a countdown timer that had broken, and trust badges too thin for a first-time buyer. After those page fixes, a later paid test produced 21 add-to-carts in four hours on ₹193 of spend. Those add-to-carts are events. Without event tracking, that signal does not exist and you are guessing.
How do you stop double counting?
This is the step most self-installed setups skip, and it produces the opposite problem: purchases counted twice, ROAS that looks great and a budget decision built on fiction.
When the Pixel and CAPI both report the same action, Meta needs to know they are the same action. That is what deduplication does, and it needs two things sent with both copies of the event:
- The same
event_name— both must sayPurchase, not onePurchaseand onepurchase_complete. - The same
event_id— a unique identifier for that specific action, generated once and attached to both the browser event and the server event.
Native integrations handle this for you. Custom implementations frequently do not, and the symptom is a suspiciously round doubling of your conversion count on the day CAPI went live.
How do you verify it is actually working?
Everything below lives in Meta Events Manager. Check in this order:
- Test Events. Open the tab, perform the action on your own site, and watch the event arrive in real time. If nothing appears, nothing is working — stop here.
- Event deduplication status. Meta tells you plainly whether it is receiving matched pairs from browser and server. "Not deduplicated" means you are double counting.
- Event Match Quality. Scored out of ten per event, this reflects how much customer information you send — hashed email, phone, name, city, IP, user agent. A low score means your server events arrive but cannot be matched to a real person, which makes them nearly useless for attribution. Sending hashed email and phone typically moves this more than anything else.
- Diagnostics. Meta flags missing parameters and malformed events here. It is unglamorous and it is usually where the real bug is.
If events are firing and your leads still are not appearing where you expect, the problem has moved downstream — the same territory as ads that spend money but bring no leads.
How should you read attribution after all this?
Honestly, and with lower expectations than the dashboards invite.
Meta, GA4 and your store will never agree. They use different attribution windows and different rules — Meta defaults to a 7-day-click, 1-day-view window and credits the ad; GA4 uses its own model and often credits the last non-direct source. Both are internally consistent and neither is lying. Trying to reconcile them monthly is wasted effort.
Some of what Meta reports is modelled. Where direct observation is blocked, Meta estimates. That is a reasonable statistical practice, and it is also a reason to treat small differences between two campaigns as noise.
Pick one source of truth for money decisions. For most of the businesses we work with across 10 industries, that is their own record of closed customers, not any platform. Platform numbers steer the campaign; your own numbers decide the budget.
And if all of this sounds like a lot of engineering for a small local business — it is, which is precisely why so many Rajkot accounts run click-to-WhatsApp campaigns instead. A conversation happens inside Meta's own ecosystem, so there is no browser, no pixel and no attribution gap to argue about. It is a smaller measurement problem by design.
Key Takeaways
- The Pixel is browser-side, so anything that blocks browser tracking silently removes conversions from your reporting.
- The Conversions API sends the same events from a server, which browsers cannot block.
- Run both, not one. Deduplication via a shared event ID is what stops double counting.
- Event Match Quality in Events Manager is the number that decides how many server events Meta can actually attribute.
- Click-to-WhatsApp campaigns sidestep the whole problem, which is one reason so many local accounts run them.
- Expect Meta, GA4 and your store to disagree permanently. Pick one as the source of truth for budget decisions and stop reconciling.
Before You Ask
Why are my Facebook leads not showing up in the Pixel?
Because the Pixel runs in the visitor browser, and a meaningful share of browser events never reach Meta. iOS tracking prompts, Safari and Firefox tracking prevention, ad blockers, declined cookie consent and dropped mobile connections all remove events before they are recorded. Your leads are real; the recording is incomplete. The fix is to add the Conversions API so the same events are also sent server-side, where none of those blockers apply, and to deduplicate the two using a shared event ID.
Do I need both the Meta Pixel and the Conversions API?
Yes. Meta recommends running both rather than replacing one with the other. The Pixel captures rich browser context, the Conversions API guarantees delivery of the events the browser blocks, and together they give the delivery algorithm a fuller signal to optimise against. The requirement is that both copies of an event share the same event name and the same unique event ID, otherwise Meta counts the action twice and your conversion numbers become unusable.
What is Event Match Quality and why does it matter?
Event Match Quality is a score out of ten shown in Meta Events Manager for each event, reflecting how much customer information you send with server-side events — hashed email, phone number, name, city, IP address and user agent. It matters because a server event that cannot be matched to a real person contributes very little to attribution or optimisation. Sending both a hashed email and a hashed phone number typically improves the score more than any other single change.
Platform behaviour described here reflects Meta Events Manager and Conversions API documentation as of September 2026; Meta changes these systems regularly, so verify current requirements before implementing. NK Creation figures are add-to-carts and spend from that client account — not revenue.