What "missing purchase events" actually means
When merchants say purchase events are missing, they mean one of two things — and the fix depends entirely on which.
The first is a tracking gap: a real order happened in Shopify, but the Purchase event never reached Meta's Events Manager. The pixel didn't fire, the shopper blocked it, or the tab closed before the thank-you page loaded. This is genuine data loss, and better plumbing narrows it.
The second is a methodology gap: Meta did record the sale, but its number doesn't line up with Shopify because the two systems measure different things. This gap can't be "fixed" — only understood. Confusing the two is the single most common reason merchants waste hours on the wrong repair.
If the Purchase shows in Events Manager but not in Ads Manager, you have an attribution question, not a tracking one. If it's absent from Events Manager entirely, you have a real tracking break.
Step one: is your gap even a problem?
Never compare a single day. Meta reports a conversion on the date of the ad click or view that earned credit, not the purchase date — so a Monday click that converts Thursday lands on Monday in Meta and Thursday in Shopify. Always compare on a trailing seven-to-fourteen-day window.
On the default seven-day-click, one-day-view attribution window, a twenty to thirty-five percent gap between Meta-reported purchases and Shopify orders is normal, according to Vaizle and TrackBee. Most of that excess is view-through and modeled conversions — Meta counting sales it influenced, not sales that Shopify missed.
Here's the counterintuitive part: on that default window, Meta usually reports more purchases than Shopify, not fewer. So if your Meta number is genuinely lower than your order count, that's the signal something broke. Understanding both directions of the gap is the heart of reconciling your ecommerce data across every tool you run.
Why purchase events go missing (the tracking side)
Purchase shows the largest client-side gap of any pixel event, because it fires last — on the one page most likely to never load. Four mechanisms cause the real losses.
Ad blockers and browser tracking prevention. Browser blockers and Safari or Firefox tracking prevention stop client-side pixels from firing entirely. Field estimates put affected traffic at ten to twenty-five percent of users. Shopify still records those orders server-side; Meta simply never sees them.
Cookie-consent declines. A shopper who rejects marketing cookies still checks out. Shopify logs the order; the browser pixel sees nothing unless a server-side setup with consent modeling fills the gap.
iOS App Tracking Transparency. Since iOS 14.5, shoppers who decline tracking strip the click ID and limit the pixel. Meta backfills these with modeled estimates rather than counted events, which shifts your reported number toward statistics and away from observed reality.
Lost tail events. The shopper closes the tab before the confirmation page loads, or the script fails on a slow connection. The pixel event never sends, even though the order is complete in Shopify.
The methodology gap (why "fixing" tracking won't close it)
Even with flawless tracking, Meta and Shopify will not match — because they answer different questions.
Shopify uses last-click attribution: one hundred percent of an order's credit goes to the last channel clicked. Meta credits itself for any purchase inside its attribution window after a click or a view. With the default seven-day-click, one-day-view window (Jon Loomer), Meta claims a sale made within a day of merely seeing an ad — a "view-through" conversion Shopify has no concept of.
Meta also reports modeled conversions: statistical estimates of real-but-unobservable sales from iOS opt-outs and blocked pixels. Shopify never models — it reports only completed orders.
This is why a popular myth misleads so many merchants: "set up the Conversions API and the numbers will match." They won't. The Conversions API recovers lost events, but it does nothing about view-through, modeling, or last-click-versus-window. A structural gap survives no matter how clean your setup is.
The over-counting trap: duplicate events
Sometimes the problem is the opposite of missing — it's doubling. Best-practice setup sends the same Purchase from both the browser pixel and server-side CAPI, so blocked-browser events get recovered by the server. Meta then has to collapse the two copies into one.
If both copies lack a shared deduplication key, Meta counts the order twice. A store showing Meta purchases at roughly twice its Shopify orders almost always has a dedup misconfiguration, not real inflation.
Meta's official dedup rules match on an identical event_id plus event_name on both copies, within a forty-eight-hour window, keeping whichever event arrives first. If you added CAPI and your count jumped, that's a dedup bug — walk through duplicate purchase events on the Shopify pixel before assuming your ads suddenly got better.
A worked example: one week, four different numbers
Say you run a print-on-demand store and drive Meta ads for a week. Ground truth: 100 real orders. Each order is 40 dollars in product, 5 dollars shipping, 4 dollars tax — 49 dollars total. Of the 100 buyers, 55 clicked a Meta ad within 7 days, 15 only saw one within a day, 10 clicked Google last, and 20 came from organic or direct. Eight later refund.
Meta reports about 78 purchases. That's 55 click-through plus 15 view-through (70 by window), plus roughly 8 modeled conversions recovering blocked buyers. It reports revenue on the subtotal the pixel passes: 78 × 40 = 3,120 dollars. It does not subtract the 8 refunds.
Shopify reports 100 orders. After the 8 refunds at 49 dollars each, total sales land near 4,508 dollars. The 15 view-through buyers are filed under their real last referrer, not Facebook — because they clicked nothing.
Your bank payout is a third number again. Shopify Payments deducts processing fees and refunds before depositing. On the Basic plan, US online fees run about 2.9 percent plus 30 cents per transaction. Walking the arithmetic: 100 × 49 = 4,900 dollars captured, minus fees of (4,900 × 0.029) + (100 × 0.30) = 142.10 + 30.00 = 172.10 dollars, minus 392 dollars in refunds (8 × 49), minus one 15-dollar chargeback fee, leaves 4,320.90 dollars deposited.
None of these numbers is wrong. Meta answers "how many sales did my ads plausibly influence?" Shopify answers "how many sales happened and for how much?" The payout answers "how much cash hit the bank?" Expecting them to agree is the mistake.
The profit angle everyone skips
Here's what the top-ranking troubleshooting guides never say: chasing a matched purchase count is the wrong goal. You are not trying to make three dashboards agree. You are trying to know whether each order made money.
A missing purchase event costs you twice. First, Meta's optimization algorithm learns from fewer conversions, so it targets worse. Second — and bigger — you can't tell your profitable ad sets from your losing ones. If Meta undercounts a winning campaign and overcounts a view-through-heavy one, you scale the wrong spend. The real cost of a tracking gap isn't a wrong number; it's a wrong decision about where the next dollar goes.
That's the number that actually matters: not "did the counts match," but "what did this order net after product cost, fees, shipping, and the ad spend that earned it?"
Where PodVector fits
PodVector connects Shopify, Meta Ads, Google Ads, Printify, and Printful, then computes your true per-order profit — the figure that survives whichever way your purchase events drift. It doesn't try to force Meta and Shopify to report the same count; it reads both and tells you what each order actually earned.
Victor, its AI employee, analyzes that live data and proposes moves you approve — the writes he executes are Shopify-side. Victor does not touch your ad account; he reads Meta's numbers and flags where your reported conversions and real profit diverge, so a tracking gap stops quietly draining margin. You can start with PodVector here.
FAQs
Why does Facebook show fewer purchases than Shopify?
On the default attribution window, Meta usually shows more purchases than Shopify because of view-through and modeled conversions — a twenty to thirty-five percent gap the other way is normal. If Meta is genuinely showing fewer, that's a real tracking break: ad blockers, consent declines, iOS opt-outs, or a pixel that isn't firing on the confirmation page. Check whether the Purchase appears in Events Manager at all.
Will the Conversions API fix my missing purchase events?
Partly. The Conversions API sends purchases server-side, recovering events that browser blockers, closed tabs, and consent declines lose. But it can't close the methodology gap — view-through credit, modeled conversions, and last-click-versus-window differences all survive a perfect CAPI setup. Expect CAPI to shrink the tracking gap, not eliminate the mismatch.
My Meta purchases roughly doubled — is that good?
Almost never. A count near twice your Shopify orders is the classic signature of a deduplication misconfiguration: the browser pixel and CAPI are both sending Purchase without a shared event_id, so Meta counts each order twice. Correct redundant setup keeps your count stable while recovering blocked events — it should not inflate it.
Should I compare Meta and Shopify on a single day?
No. Meta reports conversions on the click or view date, not the purchase date, so daily comparisons desync even when the totals eventually agree. Always compare on a trailing seven-to-fourteen-day window, and treat a stable ratio — not an exact match — as the sign of a healthy setup.
Do refunds explain part of my gap?
Yes. Shopify reduces net and total sales when an order is refunded, but Meta generally does not retroactively remove the original conversion. So after a wave of refunds, Meta's totals stay high while Shopify's drop — widening the gap for reasons that have nothing to do with tracking. This same refund asymmetry shows up when you migrate a catalog from Etsy to Shopify and start reconciling fresh.
How do I test whether my pixel fires without placing a real order?
Use Meta's Test Events tool or the Pixel Helper extension to trigger a Purchase in a controlled way, rather than buying and refunding. There's a clean method for firing a test purchase event without a real order so you can confirm the event and its parameters arrive before trusting live numbers.