---
title: "Facebook Pixel not tracking all purchases? Why Meta shows fewer sales than your shop"
description: "Your shop shows 200 orders, Meta shows 140 purchases. Which part of the gap is normal, which is a tracking problem, and how to find and fix it."
author: "IsPixelWorking team"
published: "2026-10-12"
url: "https://ispixelworking.com/blog/events-manager-fewer-events"
---

# Facebook Pixel not tracking all purchases? Why Meta shows fewer sales than your shop

IsPixelWorking team · published 2026-10-12

Sooner or later every ecommerce store owner puts the numbers side by side. The Shopify store, WooCommerce shop or analytics tool says 200 orders last month. Meta says 140 purchases. Is that fine?

Nobody can give you a universal answer, because part of the gap is built into how consent, browsers and Meta's reporting work, and part is a broken setup that quietly costs you money. This post goes through both, covers the case where the pixel tracks page views but no purchases at all, and ends with a way to measure your own gap.

## First: which Meta number are you looking at?

Meta counts conversions in two places, and they count different things.

- **Events Manager** shows events Meta received from your pixel and from the Conversions API: from ad visitors, organic visitors and everyone else. Meta says the total there is not deduplicated, and if you use both pixel and server, the "events received" figure is the sum of the two.
- **Ads Manager** shows conversions attributed to your ads: people who saw or clicked an ad and then converted within your attribution setting, after Meta discards duplicates.

So Ads Manager is almost always lower than Events Manager, and that difference is attribution, not lost tracking. Meta explains this in [differences between Ads Manager and Events Manager](https://www.facebook.com/business/help/337196340694086).

Your shop's count has quirks too. Phone and manual orders, in-store sales, subscription renewals and test orders are all orders, but none of them happen on your website's thank-you page.

## How to see the purchases your pixel tracked

- **Events Manager:** open your pixel (dataset), find `Purchase` on the **Overview** tab and click **View details**. The **Event overview** tab shows browser (pixel) and server (Conversions API) events separately.
- **Ads Manager:** open **Columns**, then **Customize columns**, and add the purchases metrics, such as purchases and purchase conversion value. These are attributed purchases only.
- **Live, one order at a time:** the **Test events** tab in Events Manager, described in the last section.

## Why purchases never reach Meta

**Visitors who reject cookies.** If your pixel waits for consent, buyers who reject or ignore the banner are not tracked by the pixel. That part of the gap is the consent setup working. Loading the pixel earlier is not the fix: it creates a different problem (see [the pixel fires before consent](https://ispixelworking.com/guides/meta.fires_before_consent/generic)).

**The pixel fires late, or not at all.** These are the fixable ones:

- The consent tool never releases the pixel after a visitor accepts. Then you lose almost everyone, not just the people who reject. See [the pixel does not fire after consent](https://ispixelworking.com/guides/meta.not_firing_after_consent/generic).
- The `Purchase` event only fires on the thank-you page, and some buyers never see it: they pay on an external payment page and do not come back, or close the tab once payment is confirmed.
- A theme, checkout or app change removed the purchase event for one payment method or one checkout flow.

**Orders that never touch a browser.** The pixel cannot see phone orders, manual orders or renewals. If you want Meta to learn from them, they have to be sent with the Conversions API.

## Can ad blockers, browser privacy or iOS affect purchase tracking?

Yes, each in its own way.

**Ad blockers.** Meta's own help center says the pixel [may not fire for people using an ad blocker](https://www.facebook.com/business/help/147965221941551), which makes Meta report fewer conversions than your internal data. Shopify says the same about its pixel-only data sharing level, and notes that server-to-server data sent through the Conversions API cannot be blocked by browser-based ad blockers.

**Browser limits.** These mostly hurt attribution rather than raw counts. Safari, for example, limits how long cookies written by scripts survive, so a buyer who returns a week after clicking your ad may no longer carry the click ID. The purchase still arrives, but Meta has less to link it to the ad. Our post on [fbclid and the _fbc cookie](https://ispixelworking.com/blog/fbclid-fbc-cookie-explained) covers this in detail.

**iOS and App Tracking Transparency.** Since iOS 14.5, apps must ask iPhone users for permission to track them across other companies' apps and websites. When someone declines in the Facebook or Instagram app and later buys on your site, Events Manager may still receive the purchase, but Meta has less data to tie it to the ad. Meta says it uses statistical modeling for some of these conversions, and that modeled conversions can be reported up to three days late.

## Your pixel tracks page views and add to cart, but not purchases

If `PageView` arrives but `Purchase` never does, the problem is almost always on the order confirmation step. Meta's base code sends `PageView` by itself. A `Purchase` event has to be added separately, by your platform's integration or by code.

- **No purchase event on the confirmation page.** Place a test order and look for a `Purchase` request on the confirmation page (Network tab, filter `facebook.com/tr`). If there is none, the event was never set up for that page.
- **Shopify: old Thank you page scripts.** Shopify upgraded the Thank you and Order status pages; the final deadline was August 26, 2026, and stores that had not upgraded were upgraded automatically. Scripts pasted into the old **Additional scripts** box, or added as script tags, no longer run there. Use Meta's **Facebook & Instagram** app, which tracks `Purchase` itself, or rebuild the event as a custom pixel under **Settings > Customer events**, not both. Shopify's `checkout_completed` event, which custom pixels use for purchases, fires once per checkout, usually on the Thank you page, or on the first upsell page if you use post-purchase offers.
- **Checkout or payment on another domain.** If orders complete on a hosted checkout on a different domain, the pixel has to run there as well, or the buyer has to come back to a confirmation page on your site that sends `Purchase`.
- **Traffic permissions.** If your pixel has an allow list (Events Manager, your pixel, **Settings**, **Traffic permissions**) and the checkout domain is not on it, its events are blocked. Meta says events lost while a domain was blocked cannot be recovered.
- **A custom name instead of `Purchase`.** A self-made event such as `order_completed` is a custom event. Ads Manager does not report it as a purchase unless you build a custom conversion from it.
- **A Tag Manager trigger that no longer matches**, for example a data layer event or a confirmation URL that changed with a new checkout.

## Can duplicate pixels or wrong event settings break purchase tracking?

Yes, in both directions. When Meta receives the same event more than once, it keeps one. That is correct for a reloaded thank-you page, or for a browser and a server copy of the same purchase with the same event ID. Several things can go wrong around it:

- **A pixel installed twice** sends every event twice. Your numbers look healthier than they are and can hide a real loss elsewhere. See [duplicate Meta Pixel events](https://ispixelworking.com/guides/meta.duplicate_pixel/generic).
- **An event ID that never changes** makes Meta treat real purchases as copies of the first one and discard them. See [Meta Pixel events have no event ID](https://ispixelworking.com/guides/meta.missing_event_id/generic).
- **The wrong pixel.** A plugin, app or tag sends purchases to a different pixel than the one your ad sets use. Compare the `id` in the pixel's requests with the pixel selected in your ad sets.
- **Missing `value` or `currency`.** Meta lists both as required for `Purchase`. Without them, Meta cannot report purchase value or return on ad spend correctly. Even with them, values differ from your shop's reports: on Shopify, the Facebook & Instagram app sends the order's total price including duties, taxes and discounts, which is not your net sales.

## Can the Conversions API fix missing purchase data?

For the browser part of the gap, largely yes. A server event is sent when the order is created, so ad blockers, closed tabs and a broken thank-you page do not stop it. On Shopify, the **Enhanced** and **Maximum** data sharing levels of the Facebook & Instagram app add the Conversions API. Elsewhere, our [Conversions API setup guide](https://ispixelworking.com/guides/general.server_side_not_detected/generic) compares the options.

Three conditions apply. Each order needs one event ID shared by the browser and server copies, or you swap missing purchases for doubled ones (our post on [event IDs](https://ispixelworking.com/blog/pixel-and-conversions-api-event-ids) explains how). Server events should carry matching data such as the `_fbc` click ID and a hashed email, or Meta receives the purchase but cannot link it to the ad. And the Conversions API does not change which consent you need: Meta says it is not designed to bypass privacy rules such as the ePrivacy Directive.

## Why Meta counts fewer even when events arrive

**Attribution windows.** In Ads Manager, the standard attribution setting [counts conversions](https://www.facebook.com/business/help/460276478298895) within 1 or 7 days of a link click, and within 1 day of an ad view or another engagement. A buyer who clicked an ad two weeks ago, or never saw one, is a real order but not an attributed conversion.

**Timing.** Events sent late land on a later day. Compare whole days that ended at least a couple of days ago, and check that the shop report and Meta use the same time zone and date range.

## What is normal and what is a fixable gap

Usually normal, though you can reduce some of it:

- buyers who reject cookies;
- ad blockers and browser restrictions (server events recover part of this);
- orders outside the attribution window, or not driven by ads (Ads Manager only);
- offline orders you never send to Meta.

Usually a fixable problem:

- a gap far larger than your consent rejections explain;
- page views arriving but no purchases at all;
- days with no purchases in Events Manager while the shop kept selling;
- purchases missing for one payment method, one device type or one checkout flow;
- two pixel IDs, or two `Purchase` events per order;
- no server events at all.

## How to check purchase tracking and measure your gap

1. **Pick a period.** Fourteen full days, ending at least two days ago.
2. **Count website orders** in your shop for those days. Leave out phone, manual, in-store and test orders.
3. **Count Meta's purchases by source.** In Events Manager, open your pixel (dataset), find `Purchase` and click **View details**. The **Event overview** tab shows browser (pixel) and server (Conversions API) events separately. Use those two numbers, not the total, which adds them up without deduplication.
4. **Work out two ratios:** browser purchases divided by website orders, and, if you send server events, server purchases divided by website orders.
5. **Compare the browser ratio with your consent rate.** Your consent tool can usually tell you what share of visitors accept marketing cookies. If 70% accept and browser purchases are 60% of orders, the pixel is doing roughly what it can. If they are 25%, something besides consent is losing events. Treat this as a rough check: buyers may accept at a different rate than all visitors, and ad blockers take their own share.
6. **Check the server ratio.** A server setup that sends every order should come close to all of them, apart from any visitors you deliberately exclude, such as people who rejected cookies. The **Event coverage** tab shows server events as a share of browser events; Meta suggests [at least 75%](https://www.facebook.com/business/help/308855623839366).
7. **Test each path live.** Open **Test events**, click **Open website**, and place a real order with each payment method you offer. Each order should show exactly one browser `Purchase`, with `value` and `currency`. Server events sent by a plugin or app usually do not appear in Test events, so check the event overview for them about 20 minutes later.

The browser-side causes above (firing before or after consent, duplicate pixels, lost click IDs, missing event IDs) are what the free IsPixelWorking check looks for. It never places orders, so it cannot test `Purchase` itself: step 7 is still yours.