Why is my Meta purchase value wrong?
A wrong Meta purchase value has four common causes, and they are worth separating because they need different fixes: the currency is missing or wrong so Meta interprets the number in the account's default, the value includes or excludes tax and shipping differently from what you are comparing against, the same purchase is counted twice because deduplication is broken, or the value is right and the disagreement is really about attribution windows rather than about the value at all. Check the currency first — it is the fastest to rule out and it produces the largest and strangest discrepancies.
Free30 minutesNo obligation
Meta purchase value wrong · what breaks
What this looks like when it's happening to you — Meta purchase value wrong
- 01
Meta revenue roughly double the store's
Almost always deduplication rather than valuation.
- 02
Meta revenue wildly out by a strange factor
A currency mismatch. The ratio often maps to an exchange rate.
- 03
Meta consistently off by a small, stable percentage
Tax or shipping included on one side and not the other.
- 04
Meta higher than the store with no obvious pattern
Frequently an attribution window question rather than a value problem.
Meta purchase value wrong · the fix
What changes once it's fixed — Meta purchase value wrong
Currency sent explicitly on every event
Never relying on an account default, especially with more than one selling currency.
An agreed definition of what the value means
Gross, net of tax, net of shipping — decided, documented, and used consistently on both sides of the comparison.
Deduplication confirmed working
Browser and server events paired on event_id, verified in Events Manager on a real purchase.
Refunds reversed
So the reported figure can go down as well as up.
Meta purchase value wrong · architecture
Why your conversion data was wrong in the first place
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to meta purchase value wrong, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
Meta purchase value wrong · normal or broken
Some of this is supposed to happen — Meta purchase value wrong
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
Working
Value and currency from the order record, deduplicated on event_id, refunds reversed, and both sides comparing the same defined number.
Broken
Revenue roughly double, or off by an exchange rate, and nobody able to say which figure to trust.
Broken but defensible-looking
A small stable gap that everyone has learned to mentally adjust for, which quietly discredits every other number in the account.
Actually broken
Currency missing or hardcoded
Meta applies the account default. On a multi-currency store this produces figures that look inexplicable until you spot the exchange rate.
Tax and shipping treated differently on each side
A stable percentage gap is the signature. Harmless in itself, corrosive to trust in every other number.
Broken deduplication
Pixel and Conversions API both firing without a matched event_id. Doubles revenue and inflates ROAS, which is why it survives so long.
Refunds never reversed
The gap grows with your return rate and never self-corrects.
Attribution window mismatch
Meta's reporting window and your store's date range are not the same thing, and comparing them is comparing two different questions.
Meta purchase value wrong · diagnose
How we find out why is my meta purchase value wrong
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Divide Meta's revenue by the store's for the same window
Close to two means deduplication. An exchange rate means currency. A small stable percentage means tax or shipping. No pattern means look at windows.
- 02
Open a real purchase in Events Manager
Read the value, the currency, and the deduplication indicator on that single event. One event answers most of this.
- 03
Confirm the currency parameter is present
Present and correct per order, not assumed from the account setting.
- 04
Check whether both pixel and Conversions API are sending
And whether their event_ids match. Both sending with matched IDs is correct; both sending without is the doubling.
- 05
Agree the value definition with whoever is comparing
Write it down. This step resolves more disputes than any technical change.
- 06
Match the attribution window to the comparison you are making
A 7-day click window against a calendar month is not a like-for-like comparison and never will be.
Meta purchase value wrong · prove
How we prove it's actually fixed — Meta purchase value wrong
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your store's order records for the same window, at an agreed and written-down definition of value
- One real purchase opened in Events Manager, with its value, currency and deduplication state read directly.
- Meta revenue reconciled per order against the store over a closed window, at the agreed value definition.
- Reconciled against your store's order records for the same window, at an agreed and written-down definition of value for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
Meta purchase value wrong · free audit
What we check in the free audit
- Divide Meta's revenue by the store's for the same window
- Open a real purchase in Events Manager
- Confirm the currency parameter is present
- Check whether both pixel and Conversions API are sending
- Agree the value definition with whoever is comparing
- Match the attribution window to the comparison you are making
Checked against
Your store's order records for the same window, at an agreed and written-down definition of value
Free30 minutesNo obligation
Meta purchase value wrong · when not to buy
When you don't need us for this — Meta purchase value wrong
Most of these you can do yourself, and we would rather you did.
- Divide Meta's reported revenue by your store's for the same week. The ratio usually names the cause on its own.
- Open one purchase event in Events Manager and read the currency field. Missing or wrong is a five-minute finding.
- Ask whoever is comparing the numbers whether they mean gross or net. A surprising share of these disputes end there.
Meta purchase value wrong · what we deliver
What we do about it — Meta purchase value wrong
Send the currency parameter explicitly
Per event, from the order record. Multi-currency stores cannot rely on the account default and neither can single-currency ones after they expand.
Pin the value definition and apply it consistently
Most Meta-versus-store arguments turn out to be two people comparing two different numbers.
Fix event_id pairing
The browser pixel and the Conversions API event must carry the same event_id for the same purchase, or every order counts twice.
Wire the refund reversal
Available and almost never implemented, which means reported revenue drifts upward by your refund rate.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
Meta purchase value wrong questions, answered
There is no universally right answer, only a consistent one. Most advertisers use the order total because it is what the store reports by default and it is the easiest to reconcile. What matters is that both sides of every comparison use the same definition and that it is written down somewhere.
Three usual reasons: double counting from broken deduplication, refunds that were never reversed, or an attribution window that credits purchases your date range excludes. Check them in that order — the first is a bug, the second is an omission, the third is not an error at all.
Yes. It costs nothing, it removes a dependency on an account setting somebody else can change, and it means nothing breaks the day you add a second currency.
Send a refund event referencing the original purchase, from your store's refund webhook. Confirm the current event name and required fields against Meta's own documentation before building — this is an area where guidance has changed.
Free · 30 min
Get meta purchase value wrong diagnosed properly
WhatsAppFree30 minutesNo obligation
