Every Order Is Worth Exactly $1, and Your ROAS Is Fiction

Value-based bidding is the default recommendation for anything with revenue attached, and it rests entirely on an assumption nobody checks: that the numbers flowing into the platform are the real ones. A conversion action can be active, firing, verified and reporting a healthy return on ad spend while every single order it records is worth the same invented amount. Nothing about the account looks wrong. The ROAS column is populated. It is simply describing a different business from the one you are running.

This matters more than a reporting inaccuracy, because Google’s own documentation is explicit that automated bid strategies use the conversion values you set up to set bids. Target ROAS aims at a return figure computed from those values. Maximise conversion value maximises the total of them. If the values are flat, the algorithm cannot tell your best customer from your worst, and it will spend your budget as though they are identical, because as far as it can see they are.

The five ways values go wrong

1. Everything reports the default

A Google Ads conversion action is configured either to use the same value for every conversion or to use different values for each one. Google frames the trade-off plainly: the same value is easier to set up but less representative, while different values are more representative and require more work. Plenty of accounts pick the easy option during setup, intending to come back to it, and never do.

To report real transaction values, two things must both be true. The conversion action has to be set to use different values for each conversion, and the tag on the site has to actually send the amount. Google’s guidance on transaction-specific values is specific about the first half: you need to have selected that option during setup, and you set a default value for the conversions that do not pass one.

That default is where this hides. If the action is set to accept dynamic values but the site never sends any, every conversion silently falls back to the default, and you get a perfectly consistent revenue line that is a single number multiplied by order count.

2. The value arrives as zero or not at all

The tag is configured to pass a value and the variable it reads is empty. This happens constantly after a theme change, a checkout update, or a platform migration, because the data layer key the tag was built against no longer exists or has been renamed.

The signature is a conversion count that looks right and a value that is zero or blank. On Meta, the Pixel reference marks currency and value as required for the Purchase event, so a Purchase without them is not a well-formed Purchase, whatever the browser console reports.

3. The value is a string the platform cannot read

A value of $1,299.00 is not a number. Currency symbols, thousands separators and trailing text can cause the value to be rejected or truncated, and the failure is not uniform: a small order of 99.00 might pass while a four-figure order containing a comma does not. That produces the nastiest version of this bug, where your reported revenue is systematically missing your largest transactions, and average order value drifts down for reasons nobody can trace.

If you only test with a cheap order, you will never see it. Test with an amount above a thousand.

4. Tax and shipping are baked in

An order total of 120 might be 100 of product, 12 of tax and 8 of shipping. Whether you include those is a business decision rather than a technical one, and either answer can be defended, but it has to be a decision and it has to be consistent.

Two failures follow from not deciding. The first is comparison: the ad platform reports gross totals while the client’s own reporting counts net revenue, and the permanent gap gets blamed on tracking accuracy rather than on definitions. The second is bidding: if shipping is free above a threshold and included in the value, the algorithm sees extra value on small orders that carry shipping and slightly undervalues the larger ones, which is exactly backwards.

For a target ROAS strategy that is supposed to represent profitability, the most useful value is usually net of tax and shipping, and for merchants with thin margins, net of cost of goods. The point is to pick one definition, write it down, and make both sides use it.

5. The currency is missing or wrong

This is the one that produces unbelievable numbers. If the value is sent without a currency, the platform has to assume one, and the assumption is usually the account’s currency. A store selling in one currency into an account denominated in another will report revenue inflated or deflated by the exchange rate, permanently, with no error anywhere.

On a multi-currency store this gets worse, because the error is not a constant factor. Orders in the home currency are right and everything else is wrong by a different amount, so the distortion follows your geographic mix and moves when you change targeting. Meta’s Pixel reference describes currency as the currency for the value specified, and expects an ISO code such as USD. Send it explicitly on every event, per order, rather than hardcoding one in the tag.

How to tell in fifteen minutes

1. Divide value by conversions. Add the conversion value and conversions columns and compute value per conversion. If it is exactly 1.00, or exactly the same number to the cent across months, the values are static. This single check resolves most cases.
2. Read the conversion action setting. Open each conversion action and look at whether it uses one value or different values. Do it per action, because accounts routinely contain a correctly configured purchase action alongside a lead action that was duplicated from it.
3. Place a test order with an unusual amount. Not 10.00. Something like 1,347.62, which is large, contains a separator and has cents. Then confirm the platform recorded 1347.62, not 1, not 1347, not 1.347 and not zero.
4. Compare a full month against the client’s own numbers. Pull reported ad platform revenue and the actual revenue from the same period and look at the ratio. A stable ratio like 1.2 points at tax and shipping. A ratio near an exchange rate points at currency. A wild ratio points at double counting or a static value.
5. Check the currency on the event itself, not in the platform interface. The interface shows you what it decided to assume, which is not evidence about what you sent.

Fixing it without wrecking your bidding

Correcting values is a bigger intervention than it feels like, because you are changing the signal a learning system has been trained on. The fix itself is usually small; the rollout deserves care.

• Fix the data before you change the strategy.Get real values flowing and verify a few days of them against the client’s orders. Switching to target ROAS on top of values you have not verified is how an account gets throttled.
• Expect reported revenue to move, and say so first. If every order has been counting as 1.00, your revenue line is about to change by orders of magnitude. Pre-announce it with the explanation, or you will spend the next client call defending a graph.
• Give the strategy time to relearn. The historical values are not restated. The algorithm needs a run of accurate data before its targets mean anything, so resist retuning the target in the same week.
• Pass a transaction identifier. It lets you correct or retract a specific conversion later, which matters for refunds and cancellations, and it is the identifier the platform uses to recognise an adjustment to an order it has already recorded.
• Write the definition down. One line in the client file saying what the value includes. It takes thirty seconds and it ends the recurring argument about why two reports disagree.

Lead generation has the same problem in a different shape

Lead gen accounts often set no values at all, which is defensible, and then run a strategy that needs them, which is not. If every lead counts as one conversion, a tyre-kicker and a six-figure enquiry are equivalent, and the algorithm will buy whichever is cheaper. It is cheaper to buy tyre-kickers.

The practical fix is not to invent a precise value per lead but to separate tiers: a quote request is worth more than a newsletter signup, and a booked call is worth more than a form fill. Even rough, consistent relative values beat flat ones, because the signal the algorithm needs is which leads are worth more, not what they are worth to the penny.

Why this survives every audit

Because the usual checks all pass. The tag fires. The conversion action records. The value column is populated with a plausible number. Tag Assistant is satisfied. Nothing in any interface flags a value as suspicious, because the platform has no way to know what your orders are actually worth. The only thing that exposes it is arithmetic against a source of truth, and most accounts never run it.

If you want to see the mechanical half quickly, our free tracking scan reads the public source and the published container in about thirty seconds and shows what is installed and what it sends. The honest limit is that it reads configuration rather than your orders, so the value-per-conversion arithmetic and the test order above are still how you confirm the numbers are real.

Values also break later, with no warning, because they depend on a data layer key that a theme update can rename. Taglert rechecks every connected account every thirty minutes and emails you when conversion tracking changes, so revenue that has quietly gone to zero gets noticed the same day instead of at month end.

Values that quietly fall to zero are the case for conversion tracking monitoring, which watches the conversion action rather than the order book.