TL;DR
Shopify counts an order on the day it was placed. Meta credits a purchase back to the ad interaction that earned it, inside whatever attribution setting the ad set uses, and the default is 7-day click and 1-day view [1][2]. So a slice of the gap is arithmetic, not loss. Under that layer sit two real failures worth your time: events Meta received but could not match to a person, which show up as a low event match quality score [3], and events that never left the browser at all. Estimates that fill Meta's iOS blind spot make up the rest, and no configuration change touches them [4]. The order to work in is delivery, then matching, then the settings that govern counting.
Key Takeaways
- Compare a window that closed at least 7 days ago, in the same time zone, with the same attribution setting the ad set is optimizing against. Meta's default is 7-day click and 1-day view [1][2].
- Meta scores event match quality only for Conversions API website events, on a 0 to 10 scale, calculated on the last 48 hours of data [3]. A pixel-only purchase gets no score at all.
- A purchase event carrying nothing but a browser cookie and a user agent is a purchase Meta may never attribute, even though Events Manager confirms it arrived.
- Aggregated Event Measurement limits how many events per domain Meta measures for iOS traffic and delays their reporting [4], and no tag work turns an estimate into an observed conversion.
- If your reported purchases fell right after you added deduplication, the previous number was inflated by double counting, and the lower number is the un-inflated one.
- Server-side purchase delivery from the Shopify order webhook carries the hashed customer record, so the match problem and the delivery problem get solved by the same change.
- Meta tracking sits on the WeltPixel Conversion Tracking Plus plan at $39/mo; the free plan is GA4 only [5].
Start by comparing two numbers that mean the same thing
Most gaps shrink before anyone touches a pixel, because the first comparison was never valid. Three settings decide what each system prints.
| Setting | What Meta does | What Shopify does |
|---|---|---|
| Date basis | Credits the purchase back to the day of the ad interaction that earned it, inside the attribution setting [1] | Books the order on the day the order was placed |
| Window | 7-day click and 1-day view is the current default, changeable per ad set [1][2] | No window. An order counts once, on its date |
| Time zone | The ad account time zone, set when the ad account is created and not editable afterwards | The store time zone, set in Shopify Admin |
Start with the attribution setting rather than the date range, because it lives on the ad set and it carries a view-through leg that search platforms have no equivalent for. An ad set optimizing on 7-day click and 1-day view credits purchases from people who saw the ad and never clicked it, and a report pulled on a click-only setting simply does not contain those. A good share of "Meta is under-reporting" investigations end right here, with two people comparing two different settings.
Once the setting matches, pull a 30-day window that ended at least 7 days ago. A window that ends yesterday is guaranteed to under-report, because clicks and views from the last few days have purchases still to come, and Meta will write those purchases backwards into days you already counted. Then check that the two time zones agree. An account on Pacific time compared against a store on Central European time moves nine hours of orders into the wrong day at every boundary, which is invisible in a monthly total and glaring in a daily one. The reporting-lag mechanics that apply across every platform are in attribution windows and reporting delays.
One more thing to settle before you debug: Ads Manager shows purchases attributed to ads, and your Shopify order count includes every sale, including organic, email, direct, and returning customers who came back on their own. Those two numbers were never supposed to be equal. The question is whether the ratio moved.
Why doesn't Meta match every purchase it receives?
Because receiving an event and identifying the buyer are separate steps, and Events Manager confirms only the first one.
Meta grades the second step with event match quality. Two details of that metric change how you read it. It is available only for website events sent through the Conversions API with the action source set to Website, so a purchase that exists only as a browser pixel hit gets no score at all. And it runs on a 0 to 10 scale, calculated on the last 48 hours of data [3]. A number you looked at on Monday describes Saturday and Sunday, not the month.
The practical failure looks like this. A browser-side purchase event fires with a Facebook browser cookie, a click cookie if one exists, and a user agent. A server-side purchase event built from the order carries the hashed customer record on top of those. The first can be matched when the shopper is a recent, logged-in, single-device Facebook user. The second can be matched in most other cases too. Nothing about the first event is broken, and it will still show as delivered.
Two articles cover the remediation properly and there is no point restating them here: how to get event match quality to 8 or higher for the parameter work, and why funnel events score lower than purchase for why your add-to-cart score will never look like your purchase score, no matter what you do.
How many purchase events never reach Meta at all?
More than most operators assume, and this is the one cause you can size without guessing.
Run the arithmetic on an illustrative store: 1,000 Shopify orders in a month, 640 purchases reported in Ads Manager. Before you ask where the other 360 went, ask the narrower question first. How many purchase events did Meta receive at all? If a slice of your traffic runs a content blocker or never finishes loading the page, a browser-only setup loses those events at the source. They are not late, not modeled, and not mis-attributed. They were never sent.
The measurement is simple: compare the count of purchase events Meta received against your Shopify order count for the same period, before you look at attribution at all. Channel mix does not enter this comparison; the pixel or server path fires on every order. If Meta received 700 events for 1,000 orders, you have a 300-event delivery gap and a separate matching question underneath it. If Meta received 985, delivery is healthy and everything left is matching and counting rules. What ad blockers do to conversion tracking has the full picture on the blocking side.
Consent belongs in this section with a precise boundary. Browser events respect Shopify's Customer Privacy API signals. What that means for your reporting is that the browser cannot be your only path to Meta if you want delivery to survive blockers and crashed sessions.
The deduplication fix that makes your numbers go down
This one surprises people, so it deserves the emphasis: if your reported purchases dropped the week you fixed deduplication, you did not break anything. You removed an inflation you had been optimizing against.
Double counting happens when two paths describe the same purchase without a shared identifier. On Shopify the common pair is the native Facebook and Instagram sales channel plus a tracking app, or a pixel firing in the theme alongside a server-side event. Meta deduplicates on event name plus event ID, so the fix is a shared ID rather than turning a path off. How event_id prevents double counting covers the mechanism in detail.
The reason it matters for this article: a store with an inflated purchase count has an inflated ROAS, and every budget decision made on it was made on a number that was too high. The corrected, lower figure is the one your accountant would recognize. Take the drop.
Modeling and the floor you cannot fix
Some share of your Meta purchases is estimated rather than observed. Aggregated Event Measurement limits how many events per domain Meta measures for iOS traffic and delays the reporting of them [4]. Meta fills the resulting observable gap with estimates.
That has two consequences worth internalizing. Small slices, single ad sets over three days, are the least reliable cuts you can read, because estimation behaves badly at low volume. And no server-side change converts an estimated conversion into an observed one. The recovery framing that applies here is the one in what iOS 14 changed and the server-side fix: you are not restoring 2019 visibility, you are raising the share of events that arrive with something Meta can match.
Fix the two causes you control
Work these in order on your own store.
- In Events Manager, open Data sources → your dataset → Overview and note the purchase event count for a closed 30-day window. Compare it against your Shopify order count for the same window and time zone. That single ratio separates a delivery problem from an attribution one.
- In the same dataset, open Overview and read the Event match quality score on the Purchase row. As a working rule, a Purchase score below 6 usually means the events arrive with too little customer information. Meta publishes no official threshold, so treat it as a signal to do the parameter work in the two match quality articles linked above.
- In Test events, place a live test order with your Meta test event code applied, and confirm the purchase arrives once, with a deduplication status that shows the browser and server copies collapsing into a single event.
- In Ads Manager, set the attribution setting on your comparison report to match what the ad set optimizes against, then re-pull the same closed window.
FAQ
Why does Meta show fewer purchases than Shopify?
Partly by design and partly by loss. Meta credits purchases back to the ad interaction date inside the ad set's attribution setting, usually 7-day click and 1-day view, while Shopify books orders on the order date [1][2]. On top of that, events Meta cannot match to a person are not attributed, and events blocked at the browser never arrive.
What is a normal gap between Meta and Shopify?
There is no published benchmark, and any specific percentage you see quoted is practitioner lore rather than a Meta figure. What you can judge is stability. A gap that holds steady month over month is structural. A gap that widened on a specific date is an incident, and the date usually points at a theme change, an app change, or a consent banner change.
Does the Conversions API fix the under-count?
It fixes the delivery half and improves the matching half. Server-side purchase events arrive regardless of browser conditions, and they carry the hashed customer record that event match quality scores [3]. Attribution-window and modeling differences are unaffected, because those are counting rules rather than data loss.
Why did my purchase count fall after I set up deduplication?
Because two paths were reporting the same sale as two sales. Meta deduplicates on event name plus event ID, so once both copies carry the same ID they collapse into one event, and the count returns to one event per sale. It will still sit below your Shopify order total for the reasons above.
WeltPixel Conversion Tracking sends the Meta purchase from the Shopify order webhook rather than the browser, so a blocked script or a closed tab does not remove the sale from Meta's view. That event carries the hashed customer record, which is what the match quality score reads, and it reuses Shopify's own event ID so it deduplicates against the native Facebook and Instagram channel instead of double counting alongside it. Each order is recorded as sent, so webhook retries do not resend it. If you want that on your store, install WeltPixel Conversion Tracking.
Sources
- Meta Business Help Center, "About Facebook's attribution system", facebook.com/business/help/458681590974355, accessed August 26, 2026
- Meta Business Help Center, "Compare attribution settings in Meta Ads Manager", facebook.com/business/help/854500742637772, accessed August 26, 2026
- Meta Business Help Center, "About event match quality", facebook.com/business/help/765081237991954, accessed August 26, 2026
- Meta Business Help Center, "About Meta Aggregated Event Measurement", facebook.com/business/help/721422165168355, accessed August 26, 2026
- WeltPixel Conversion Tracking, Shopify App Store listing, apps.shopify.com/weltpixel-conversion-tracking, accessed August 26, 2026