Wrong Purchase Values Are Wrecking Your ROAS | Clikim
Home  /  Blog  /  Purchase Values
By Yael Rachmut · Pixel & CAPI clinic · Updated September 2026 · 7 min read

Wrong Purchase Values Are Silently Wrecking Your ROAS

A pixel that doesn't fire gets caught in a week. A pixel that fires with the wrong value runs for years — flattering ROAS by 15–25%, teaching the algorithm to love coupon hunters, and turning every year-over-year comparison into fiction. The audit takes 20 minutes.

Facebook purchase values wrong ROAS audit checklist
QUICK ANSWER

Wrong values never error — they redefine ROAS silently. The audit: pull 20 identical orders in your store admin and Events Manager and check five things — total vs subtotal, tax/shipping inclusion, discount handling, currency, and browser-vs-server value parity (dedup keeps ONE copy; if they differ, revenue depends on a race). The honest policy: value = post-discount product revenue excluding tax and shipping, first charge only for subscriptions, refunds handled knowingly either way, account currency on both channels, identical to the cent. Then re-audit every sale period and platform change — discount bugs only surface when discounts exist. Value-based bidding amplifies whatever you feed it: tax-inflated values literally optimize toward heavy carts in high-tax jurisdictions.

Key takeaways

• Wrong values don't error, don't warn, and don't look broken — they just quietly redefine ROAS while every dashboard renders normally. • The root cause is almost never code — it's the absence of a written value policy: tax in or out, discounts pre or post, refunds counted or not, on BOTH channels. • The honest defaults: value = post-discount product revenue, excluding tax and shipping, first charge only for subscriptions, account currency always. • Broken dedup is a value bug too: two copies with different values means your ROAS depends on which copy Meta keeps. • Run the 20-minute audit: 20 real orders, admin vs Events Manager, five checks. Most stores fail on the first discounted order. • Value optimization (highest-value bidding) amplifies whatever your values teach it — feed it tax-inflated numbers and it optimizes toward heavy, expensive-to-ship carts.

Why this bug survives for years

A pixel that doesn't fire gets noticed in a week — the numbers crater and someone panics productively. A pixel that fires with the wrong value can run for years, because nothing looks broken: conversions count correctly, campaigns "perform," and ROAS is a plausible number that happens to be a fiction. The store comparing this January to last January is comparing two different value definitions and calling the delta "performance." And it compounds: value-based bidding optimizes toward whatever you feed it — send tax-and-shipping-inflated values and Meta dutifully learns to prefer heavy carts shipping to high-tax jurisdictions, which is not a customer-acquisition strategy anyone chose on purpose. If your ROAS moved and nothing else did, the value pipeline belongs on the suspect list.

The 20-minute audit (do this before reading further)

Twenty orders, five checks — the audit that most stores running six figures have never done once.

Twenty orders, five checks — the audit that most stores running six figures have never done once.

Pull the same twenty orders in your store admin and in Events Manager (Test Events for a live one — Meta's event reference documents what value and currency should look like on the wire). You're answering five questions: does value match the order total, the subtotal, or something else? Does it move when tax and shipping move? What happens on a discounted order? Is currency the account's currency — every time? And do the browser and server copies of the same purchase carry the same number? That last one matters more than it looks: deduplication keeps one copy and discards the other, so if your plugin sends the total and your webhook sends the subtotal, your reported revenue depends on a race you've never watched.

The six-decision value policy

Decision
The honest recommendation
Why
Tax & shipping in value?
Exclude both — value = product revenue
You optimize toward margin-bearing revenue, not pass-through costs; ROAS stops being flattered by high-shipping orders
Pre- or post-discount?
Post-discount (what the customer paid)
Optimizing on pre-discount teaches Meta to love your coupon hunters at full-price valuations
Refunds & cancellations?
Pick a stance: ignore (simple) or send Meta's refund events (accurate)
Either is defensible; not knowing which one you do is not
Subscriptions: first charge or LTV?
First charge as value; LTV belongs in your bidding strategy, not the event
Inflated first-purchase values corrupt every cohort comparison
Currency?
The account currency, always, on both channels
Mixed currencies don't error — they silently mis-scale
Browser vs server value?
Identical, to the cent, same policy
Dedup keeps ONE copy — if they differ, your data depends on which one wins

Six decisions, one page of policy — the single highest-leverage document most ad accounts don't have.

One store, one month, five ROAS numbers — none of them lies, they just answer different questions. Pick ONE.

One store, one month, five ROAS numbers — none of them lies, they just answer different questions. Pick ONE.

Defending the recommendations

Tax and shipping out, because ROAS should measure revenue you keep a margin on — a $100 product shipped for $30 to a 25%-VAT country books $162.50 with them in, and that 62% flattery scales into real budget decisions. Post-discount, because the alternative teaches the algorithm that your 40%-off buyers are full-price customers — then the sale ends and your "performance" mysteriously collapses with it. Refunds: ignoring them is simple and fine at low refund rates; sending refund adjustments is accurate and worth it above ~5% — the only wrong answer is not knowing which one your stack does. Subscriptions at first-charge value, because stuffing projected LTV into the purchase event corrupts every cohort you'll ever compare — LTV belongs in your bidding strategy and margins math, not in the event stream. Account currency always: mixed currencies don't throw errors, they silently mis-scale — a EUR value on a USD account is just... a different number. Whatever you decide: one page, written down, enforced identically on browser and server. That document outperforms most tracking tools.

Sale-period sanity and the ongoing check

Two recurring moments deserve a calendar entry. Sale periods: discount handling bugs only surface when discounts exist, so audit five orders during every major sale — the "our ROAS crashed right after Black Friday" story is often just pre-discount values reverting to truth. Platform changes: checkout updates, new payment methods, and plugin versions all touch the value pipeline; re-run the 20-order audit after each. And keep perspective on which dashboard is for what: Meta's value data drives optimization, your store admin remains the revenue truth, and the two serve different jobs even when perfectly configured. The win isn't making Meta match your accountant — it's making Meta's number mean one consistent thing, so the machine optimizes toward money you actually keep.

Meta accepts whatever you send — the policy you never wrote is the bug you can't find.

Meta accepts whatever you send — the policy you never wrote is the bug you can't find.

Why media buyers run on Clikim
9,800+
accounts under management
$490M+
in ad spend processed
<3 min
average rep reply
0%
top-up & spend fees
Trusted by 1,200+ media buyers scaling 7–8 figures on whitelisted Meta & TikTok accounts.

Frequently asked questions

Should the Facebook purchase value include tax and shipping?+
The defensible default is no — value = post-discount product revenue. Tax and shipping are pass-through costs; including them flatters ROAS by 15–25% on typical stores and teaches value optimization to prefer heavy, high-tax orders. Whichever you choose, write it down and enforce it identically on browser and server.
Why is my Facebook ROAS higher than my actual revenue suggests?+
Usual suspects in order: values include tax/shipping (flattery), broken dedup doubling purchases (the classic 2x), pre-discount values during sale periods, or a currency mismatch mis-scaling everything. The 20-order audit against your store admin identifies which within minutes.
Should purchase value be before or after discounts?+
After — send what the customer actually paid. Pre-discount values teach Meta that your 40%-off buyers are full-price customers, so it optimizes toward coupon hunters, and 'performance' collapses the day the sale ends.
How do refunds affect Meta purchase values?+
By default they don't — Meta keeps the original value unless you act. Two defensible stances: ignore refunds (simple, fine under ~5% refund rate) or send refund adjustment events (accurate, worth it above). The only wrong stance is not knowing which one your stack takes.
What value should subscription businesses send?+
The first charge — not projected LTV. Stuffing LTV into the purchase event inflates every cohort comparison and makes creative tests unreadable. LTV belongs in your bid strategy and margin math, outside the event stream.
What happens if my pixel sends the wrong currency?+
No error — silent mis-scaling. A 100 EUR value on a USD account is simply treated as the account currency's units in reporting terms, corrupting ROAS in whichever direction the exchange rate points. Always send the account currency, from both channels.
Can broken deduplication cause wrong values?+
Two ways: unmerged duplicates double your revenue outright, and merged-but-mismatched copies (browser says total, server says subtotal) mean the kept value depends on which copy wins dedup. Browser and server must send identical values to the cent.
Does value optimization make wrong values worse?+
Dramatically — highest-value bidding steers spend toward whatever your values rank highest. Tax-inflated values steer toward high-tax jurisdictions; pre-discount values steer toward discount hunters. The bidding is fine; the diet is poisoned.
How often should I audit purchase values?+
Three triggers: once now (most stores never have), five orders during every major sale period (discount bugs only surface when discounts exist), and after any checkout/plugin/payment change. Twenty minutes each time.
My values look right in Test Events but ROAS still seems inflated?+
Test Events shows the wire, not the policy — check the cases the happy path skips: discounted orders, multi-currency buyers, subscription renewals, and refund handling. Then verify dedup: right values, counted twice, is still wrong revenue.
Should Meta's revenue number match my Shopify admin exactly?+
No — attribution windows and clock differences make Meta's view structurally different from your admin's. The goal is one consistent value definition so Meta's number means the same thing every month, not equality with your accountant.

Honest numbers, capable account

Whitelisted infrastructure — rails worthy of a value pipeline you can defend in any meeting.