In short
Two different reasons, and they need different responses. The first is attribution: Meta credits a purchase to the day someone saw or clicked an advertisement, within a window that includes views as well as clicks, so the totals sit on different dates and include orders your store would credit elsewhere. The second is duplication: browser and server events that are not deduplicated, two datasets on one site, or a purchase event that fires again when a confirmation page is reloaded. Attribution is expected. Duplication is a fault worth fixing this week.
Attribution puts the order on the ad's date, not the order's date
The reported figure answers the question of how many purchases followed an interaction with an advertisement inside a set window. Your store answers a different question: how many orders were placed today. Those two counts will not line up on any given day, and lining them up on a calendar month is only slightly better.
The window is the part people underestimate. A default that includes clicks over several days and views over a shorter period means a purchase can be credited to an advertisement seen days before, and to more than one platform at once if the buyer also clicked a search ad.
View-based credit is the largest single contributor in most accounts. Somebody scrolled past a product, did not click, searched for the brand later and bought. Meta records that as a purchase following an impression, and your store records an order from search. Both descriptions are accurate.
Compare a long enough period to smooth the date shift, and split the reported figure by whether the credit came from a click or a view before drawing any conclusion. The click-based subset is much closer to what your store would recognise.
Duplicate events are the part that is genuinely wrong
Look here when the surplus is large, when it appeared suddenly, or when the ratio is close to double. The most common cause is a browser event and a server event describing the same order without a shared event identifier, so each is counted separately.
Deduplication depends on both copies carrying the same identifier and the same event name. If a developer added the server integration without matching the identifier the browser sends, the setup looks correct in the interface and counts every order twice. The events tooling reports on deduplication and will show it.
The second cause is more than one dataset on the site. A pixel installed by a previous agency in the theme, plus one installed by the sales channel, produces two records of every purchase. Search the theme, the checkout customisations and the app list for extras.
The third is the confirmation page. Where the purchase event is tied to a page view rather than to the order itself, refreshing that page or returning to it from an email fires the event again. On modern Shopify checkouts the supported route is a customer event tied to the order, which avoids this.
Definition differences account for the rest
Check what your purchase event actually sends before assuming anything is broken. If the value includes tax and shipping while your store report shows product revenue, the totals will differ even when the counts match perfectly.
Subscription renewals are a frequent surprise. A store using a subscription app may fire a purchase event on each renewal, which is correct behaviour and will not match a report of new orders. The same applies to draft orders, exchanges processed as new orders, and point-of-sale transactions that reach the same tag.
Currency handling matters for cross-border stores. Events sent in the shopper's currency and reported after conversion will not equal a store report in your home currency, and the difference moves with exchange rates rather than with anything you did.
Cancellations and refunds are the last piece. Your store nets them out; the ad platform generally does not unless refunds are sent back to it. In a category with a high return rate this alone can explain a persistent gap between platform revenue and money you actually kept.
A reconciliation worth running monthly
Pick a full month and compare on comparable terms. Pull the ad platform's purchases restricted to click-based attribution, pull your store's orders for the same month, and note that a date shift of a few days remains at the edges.
Then split the difference into three buckets. Orders your store has that no advertisement preceded, which is the baseline the store produces on its own. Purchases the platform reports that no order matches, which points at duplication. And value differences on the orders that do match, which points at definition.
Each bucket has its own fix, and looking only at the headline totals tells you which month was worse without telling you why. Once you know the shape of your own gap, write it down and treat a change in that shape as the alert rather than the gap itself.
Use your store as the source of truth for revenue and profit, and use the platform's numbers for what they are built for: deciding which creative and which campaign to fund next.
Splitting one month's gap
- Purchases reported by the platform
- 1,240
- Restricted to click-based credit
- 890
- Store orders in the month
- 1,010
- Store orders with no ad interaction
- About 210, from search and email
- Duplicated by an undeduplicated server event
- Zero once event identifiers matched
- Remaining difference
- View-based credit and the date shift
Illustrative figures showing how a single gap separates into causes. Each line points at a different action, which is the reason for splitting it rather than reporting one number.
Related questions
Should I switch off view-based attribution?
You can change the attribution setting used in reporting, and doing so gives you a figure closer to what your store recognises. Keep both views available rather than choosing one permanently, since the click-based figure is better for reconciliation and the broader figure is closer to how delivery is optimising.
How do I know whether deduplication is working?
The events diagnostics report on it directly, showing how many events arrived from both sources and how many were recognised as duplicates. If the tooling shows no deduplication happening while both a browser and a server integration are live, every order is being counted twice.
Can two ad platforms both claim the same order?
Yes, and they routinely do. Each platform reports on interactions with its own advertising and has no knowledge of the other. Summing reported revenue across platforms will exceed your actual revenue, which is why total spend against total store revenue is the only figure that stays honest.