Why Events Manager shows fewer purchases than Shopify
Shopify books every order; Meta credits a purchase only inside the ad set's window. Work out whether your gap is attribution or events that never arrived.
Shopify and Events Manager are not disagreeing about what happened — they are answering different questions. Shopify books every order the moment it is placed, with no window and no opinion about where the customer came from. Meta credits a purchase only when it arrives as a Purchase event and falls inside the ad set's attribution window, which for new ad sets defaults to a 7-day click lookback plus a 1-day view lookback. Part of the gap is arithmetic, not loss: the same store can show 40 orders in Shopify and 26 purchases in Events Manager with nothing broken at all.
The useful question is which half you are looking at. If the purchase events Meta received are close to your order count but the reported purchases are lower, your tracking works and the window is doing the counting. If the received count is low as well, events are being lost before attribution ever sees them — and that half is fixable.
7-day click, 1-day view — Meta Business Help Center
webgrab harvest 2026-09-27, n=263
same harvest, n=263
Two numbers, two questions
The reason the two dashboards can never simply match: one records a transaction, the other assigns credit for it. Shopify's order list has no window, no click ID requirement and no view-through concept — an order exists on the date it exists. Meta's purchase column is the output of a credit rule applied to events it received, on an ad set you configured, for people it could identify.
| Check | Attribution gap | Delivery gap |
|---|---|---|
| Purchase events received vs Shopify orders | Roughly equal | Lower too |
| Changing the attribution window | Moves the number | Does not move it |
| Test Events tool on a live checkout | Event arrives | Event missing or incomplete |
| Where the fix lives | Reporting settings | Tracking stack |
That table is the whole diagnostic. Run the top row first — it costs two minutes and tells you whether to keep reading this post or to go read the 12-cause pixel checklist instead.
The window does most of the work
Meta's help centre describes the default for new ad sets as 7-day click or 1-day view, and most accounts still display it as "7-day click, 1-day view". Practically that means a purchase is credited if the buyer clicked your ad in the previous 7 days or merely saw it in the previous day. Everything outside that — an order from email, from a Google search, from a customer who bought two weeks after the click — is Shopify's, not Meta's.
Three consequences worth internalising:
- Credit date ≠ order date. Meta writes the purchase back to the day of the ad interaction that earned it. Shopify books it on the day it happened. Two correct reports, two different calendars.
- Any period whose window is still open under-reports. Clicks from the last few days have purchases still to come, and Meta will write them backwards into days you already counted. Compare against a window that closed at least 7 days ago, in the same time zone, before you conclude anything.
- The label itself has been moving. Third parties report Meta retired the 7-day and 28-day view-through windows in January 2026 and split engagement from link clicks in March 2026, and Meta's own documentation varies by product page. Read the attribution setting on your own ad set — Ad set → Optimization & delivery → Attribution setting — rather than trusting any article, this one included.
Meta's reported purchases can also include modeled conversions: purchases it could not directly observe, estimated from similar users. That pushes in the opposite direction of your complaint, which is exactly why the received-event count is the honest baseline.
When the gap is real: purchases that never arrived
If Overview shows fewer Purchase events than orders, attribution is not the problem — the events died on the way. In the order we see them:
Ad blockers and Safari ITP. Blockers remove the pixel entirely for a slice of visitors, and ITP expires cookies after 7 days (24 hours for known trackers), so a late conversion never links back to the click. This is structural loss, not a misconfiguration — the pixel checklist covers the full range.
Consent gating. A consent platform set to hold all tags until acceptance means every visitor who never clicks accept never fires anything. On EU mobile traffic that can zero out a store's events while the dashboard still looks healthy.
Checkout extensibility and accelerated buttons. Stores migrated off the old checkout lose custom pixels that hooked it, and Shop Pay, PayPal and wallet buttons bypass the theme's standard purchase listener — the event goes quiet exactly where it matters. Purchase capture belongs on the server, from Shopify's order webhooks.
Incomplete purchase parameters. The event arrives without value, currency or content_id, or with identifiers Meta cannot match to a person. It is counted somewhere, but it cannot be credited properly and match quality stays low.
Data restrictions. Events arrive and are then filtered — excluded URL patterns, a wrong domain, a filtering rule someone set a year ago. The pixel works; the report is empty.
Data table
| Category | Value |
|---|---|
| No attribution tool | 59.3 |
| Has attribution tool | 40.7 |
Source: webgrab harvest, 2026-09-27 — 263 Shopify stores actively running Meta ads
Data table
| Category | Value |
|---|---|
| No Google Tag Manager | 52.1 |
| Has Google Tag Manager | 47.9 |
Source: webgrab harvest, 2026-09-27 — 263 Shopify stores actively running Meta ads
Those two numbers are the backdrop for why this complaint is so common: in most ad-running stores nothing independent is watching the path, so a delivery gap and a healthy store with a wide attribution window produce the same Events Manager screen. The 2026 state of Meta tracking report walks through the full sample.
The fix for the delivery half
Once capture moves to the server, blockers cannot touch what never ran in the page, and server events carry first-party identifiers a browser cannot keep — with the event_id reused from the browser copy so the two are merged instead of double-counted (the deduplication rules are shorter than they sound). That is what Headless does: server-side delivery, first-party enrichment and 39 revenue and engagement metrics in one place, from $0 to $49 a month.
Work the diagnostic top-down — received events against orders first, window second, stack third — and don't compare two reports again until you know which one of them you were actually reading.
Frequently asked questions
Why did my purchase count in Events Manager drop?
Usually a reporting change, not a performance change: a different attribution setting on the ad set, a date range whose window is still open, or a removal of an older view-through option Meta used to offer. Compare the same closed period under the same attribution setting before treating it as a loss.
Does a gap between Shopify and Meta mean my pixel is broken?
Not on its own. Open Events Manager → Data sources → Overview and read the number of Purchase events Meta actually received for a closed period. If that is close to your Shopify order count, delivery is fine and attribution is doing the arithmetic. If it is low too, events are being lost before attribution sees them.
Which number should I trust for revenue?
Shopify, every time — it books real orders with payment behind them. Meta's purchase count is an in-platform optimisation input: it is shaped by the attribution window and can include modeled conversions for users who opted out of tracking. Use it to steer campaigns, not to close the books.
How do I see how many purchase events Meta actually received?
Events Manager → Data sources → your dataset → Overview shows the raw event counts separate from attribution. The Test Events tool shows a single checkout live, including whether value, currency and content_id arrived with it.