Problem
Meta ads purchases not matching store orders: how to fix it
Meta and your store are answering two different questions. Meta reports purchases it believes its ads influenced, dated to the ad interaction and shaped by an attribution setting you chose. The store reports orders it received, dated to the order. Expecting those to agree is the first mistake. Once you accept that, the useful work is separating the differences that are by design from the ones caused by duplicate or missing events.
By CartKernel · Last reviewed 2026-09-07
Does this look familiar?
- Reported purchases are consistently higher than the orders the store can attribute to the channel
- Purchase counts look right but the reported value is far above or below the order totals
- The same order appears to be counted twice on days with high traffic
- Reported purchases fell sharply after a checkout or theme change while orders held
- Daily figures never line up although weekly totals are close
- Some orders carry no purchase event at all, particularly from wallet payments
Causes, ranked
Why it happens, most common first
Check them in this order. The first two account for most cases we open.
- most common
The attribution setting credits interactions your store does not
The default setting credits purchases that follow a click within a week or a view within a day, and dates them to the ad interaction rather than the purchase. Your store, using last click, credits a different channel entirely for many of those orders. Both numbers can be correct at once.
- most common
Browser and server events are not being deduplicated
Running the browser pixel and the server side connection together is the recommended setup, but each purchase must carry the same event name and the same event identifier from both sources so they are recognised as one. Without matching identifiers, every order is reported twice.
- common
More than one pixel fires on the same page
An app installed at one point, a manual snippet added later, and a channel integration can all send purchases. Each sends its own event, and the totals inflate. This is common on stores that have changed agency, theme or app stack over time.
- common
The purchase event carries the wrong value
A value that includes shipping and tax when the store reports on subtotal, a value sent as a string with a currency symbol, or a missing currency parameter all distort reported revenue while purchase counts stay correct. Multi currency stores are especially prone to this.
- common
Time zones differ between the ad account and the store
The ad account has its own time zone and the store has another. Orders near midnight land on different days in each system, so daily comparisons never agree while weekly totals are close. Nothing is broken; the reports are cut differently.
- occasional
Some orders never produce a browser event
Wallet payments, deferred payment providers, subscription renewals, phone orders and app created orders can complete without the customer landing on a page that fires the pixel. Those orders exist in the store and are invisible to browser based measurement.
- occasional
Reported figures include modelled and estimated results
Where signal is limited by privacy settings, platforms estimate some outcomes rather than observing each one. Those estimates appear in reporting alongside observed conversions, which means an exact reconciliation to individual orders is not possible by design.
The fix
In this order
Each step is something you can do today. Do them in sequence; skipping ahead is how a review fails twice.
Prevent it next time
- Keep exactly one purchase event source per pixel and document who owns it
- Include event deduplication in the test plan for any checkout or app change
- Review event diagnostics monthly rather than waiting for a reporting argument
- Report paid performance on blended acquisition cost alongside platform reported results
Set both systems to the same window before comparing
In the ads reporting, switch the comparison view so purchases are reported by the day the conversion happened rather than by the ad interaction date, and pick one attribution setting. Then compare against the same calendar days in the store.
Inventory every source sending purchase events
List the platform channel integration, any marketing app, any manual snippet in the theme, and any tag manager container. Confirm which pixel identifiers each uses. Keep one source per identifier and remove the rest before doing anything else.
Implement deduplication properly
Ensure the browser event and the server event for the same order share an identical event identifier, usually derived from the order number, and use the same event name. Verify in the event testing tools that the pair is recognised as one purchase rather than two.
Standardise the value and currency
Decide whether the reported value is subtotal or order total, send it as a plain number, and always include a three letter currency code. Apply the same definition in every source so browser and server events cannot disagree with each other.
Check event quality and match rates
Open the events diagnostics for the pixel and read the event match quality and any warnings about missing parameters. Adding hashed customer information from the order improves matching for orders that would otherwise go unattributed.
Move purchase collection into the checkout mechanism the platform supports
On platforms with a controlled checkout, use the customer events or pixel sandbox rather than theme edits so the event survives upgrades and fires for every payment method. Test with each wallet the store accepts.
Align the time zone or stop comparing days
Either set the ad account time zone to match the store's reporting time zone, which is a permanent decision, or agree to reconcile on weekly totals only. Comparing single days across mismatched time zones will always produce noise.
Judge the channel on incrementality, not reconciliation
Once the events are clean, stop trying to make the two totals equal. Use a holdout or a geographic split to estimate what the channel adds, and use blended acquisition cost across all channels as the number the business steers on.
When to get help
Bring in help when platform reported results are driving budget decisions and nobody can say how much of that revenue is incremental. The work involves setting up a clean server side connection, agreeing one reporting definition across channels, and running a holdout that is large enough to read. It is also worth help when several channels each claim the same orders, because the answer is a blended measurement model rather than a fix inside any one platform.
Free. We reply within one business day.
Should I run the browser pixel and the server connection together?
Yes, that pairing is the recommended setup because each covers gaps in the other. The condition is deduplication: both must send the same event name and the same event identifier for a given order. Without that, the pairing doubles your reported purchases instead of improving coverage.
Why does the platform report purchases on days I had no orders?
By default, results are dated to the day of the ad interaction rather than the day of the purchase. An order placed today from a click three days ago is reported against that earlier day. Switching the reporting view to conversion time removes most of this effect.
Does a one day view window count people who never clicked?
Yes, that is what it means. It credits purchases from people who saw the ad and bought within a day without clicking. Whether that credit is fair is a judgement call, and it is the single setting that most inflates apparent performance for stores with strong existing demand.
Can I make the platform report only orders my store agrees with?
Not exactly, and it is not a useful goal. You can align the attribution setting, the reporting date basis and the value definition so the two are comparable. Beyond that, modelled results and view based credit mean the platform will always describe influence rather than record orders.
Services that fix it for good
Related problems, answers and terms
Stop the leak.
A free Growth Analysis finds what is broken and ranks it by the revenue it costs you.