Why does the Meta Pixel miss restaurant orders?
The Meta Pixel misses orders because it runs in the browser: ad blockers, cookie restrictions, page loading errors and iPhone users declining tracking (App Tracking Transparency) stop events from reaching Meta. Meta’s own recommendation is to run the Pixel together with the Conversions API, which sends events from the server, with deduplication so nothing is counted twice.
If your campaign dashboard looks "a little off", with orders you know happened not showing up, or cost per result rising for no clear reason, the problem may not be the campaign. Your Pixel may simply not be seeing everything that happens on your ordering page.
Why this happens
The traditional Pixel runs in the visitor’s browser. That means it depends on things outside your control: if the person uses an ad blocker, if the browser restricts third-party cookies or if the page fails to load before the script fires, the event never reaches Meta.
On iOS the problem is more explicit. Apple requires apps to ask permission to track people across apps and websites through the App Tracking Transparency framework. Many iPhone users decline, and each decline is a person whose post-click behavior becomes invisible to traditional tracking.
What Meta did about it
Meta’s answer was Aggregated Event Measurement (AEM): a method that measures events from iOS 14.5+ devices in aggregate, without individual data, even when the person declined tracking. Campaigns can keep optimizing and reporting, but at a coarser level.
The piece that closes the gap: the Conversions API
Meta describes the Conversions API (CAPI) as a direct connection between the marketing data on your server, website or CRM and Meta, without depending on the browser. According to the documentation, data sent through the Conversions API is less affected by browser loading errors, connectivity issues and ad blockers than Pixel data.
That is why the recommendation, and it is Meta’s own recommendation, is not to choose between Pixel and CAPI. It is to run both together, with event deduplication, so each one covers what the other misses. An event the browser could not send, the server can.
It also opens the door to optimizing for actions that happen later, such as a catering order confirmed by phone or an order placed through your POS: events only your own system knows happened.
The real impact, without the jargon
Think of it this way: every order Meta does not see is an order that, for the algorithm, never happened. That pushes the campaign to keep looking for the "wrong" kind of customer, because the system has no way to know that a certain profile actually ordered. The result is a higher cost per order and slower optimization, with no visible problem in the campaign itself.
Pixel vs. Conversions API
| Criteria | Pixel | Conversions API |
|---|---|---|
| Where it runs | In the visitor’s browser | On your server, ordering system or CRM |
| Affected by ad blockers | Yes | Much less |
| Offline events (phone, POS) | No | Yes |
| Meta’s recommendation | Use both together | Use both together, with deduplication |
Frequently asked questions
Based on the official Meta Business Help Center documentation on the Conversions API and Aggregated Event Measurement.
How much order data is your account losing?
We check your Pixel and Conversions API before any campaign changes.
Check my tracking →