Meta's Definition Has a Missing Word
Here is Meta's own description of the value parameter, from the Conversions API standard parameter reference, last updated 17 November 2025:
Required for purchase events or any events that utilize value optimization. A numeric value associated with the event. This must represent a monetary amount.
Read it twice. It constrains the amount to be monetary. It never says whose.
For every advertiser Meta designed that sentence for, the omission does not matter. A brand sells a $297 product, the customer pays $297, the brand receives $297, and $297 is the only candidate. The word "whose" would be redundant.
Now put an affiliate in that sentence. The customer paid $297. The affiliate received $89.10. Both are monetary amounts associated with the event. Both are true. Only one of them is the affiliate's.
Google's Target ROAS documentation has the same structure. It says the system "predicts future conversions and associated values using your reported conversion values, which you report through conversion tracking." Reported. By you. TikTok's Events API documentation describes its value parameter as the total purchase amount and lists it as required for ROAS and value-based optimisation.
Three platforms, three advertiser-supplied numbers, and none of the three has a concept of an intermediary.
Every reasonable-feeling step in the chain is correct on its own terms, and the sequence still ends somewhere you did not intend.
The Network Already Solved This and Nobody Noticed
The thing that makes this worth writing about is that the data is not missing. It is not hard to get. It is not behind a tier.
ClickBank's Instant Notification Service, on version 8 since June 2024, sends both figures in the same payload, already separated and already labelled:
| Parameter | ClickBank's definition |
|---|---|
totalOrderAmount |
"Total the customer was charged" |
totalAccountAmount |
"Total you received for the transaction in USD" |
accountAmount |
"Amount you received on this line item" |
affiliatePayout |
"The amount earned by the affiliate for the sale of the product" |
Four fields. Two different economies. One notification.
Somewhere between that payload arriving and a Purchase event leaving for Meta, a piece of software picks one number and moves on. If nobody made that choice deliberately, it was made by whichever field the integration author reached for first, and the field named "total order amount" reads like the obvious one.
I am going to call the wrong choice the seller's number, because that is exactly what it is. It is a real, correct, auditable figure. It is the merchant's revenue. And once it is in your value field, three ad platforms treat it as yours.
No system in this chain is broken. A field was chosen once, silently, and three ad platforms have been acting on it ever since.
The Math
The relationship between the two ROAS figures is not an estimate. It is division.
Your reported ROAS divided by your commission rate is your gross-value ROAS. That is the whole formula, and it means the error is not random noise you can average out over a big enough sample. It is a fixed multiplier sitting on top of every campaign you run at that commission rate, and it moves the moment you promote a different offer.
Which brings up the part that is worse than the reporting error.
If your commission rate were identical across every offer, tier and upsell path, the multiplier would be constant and you could mentally divide it out. Most affiliates do exactly that, and it half works. But the moment your rates differ, a $497 offer paying 20% and a $197 offer paying 60% both send the order total, and the bidder now believes the first is worth two and a half times the second. In your bank account the second one pays $118.20 and the first pays $99.40.
That inversion is where gross-value bidding stops being a reporting problem and becomes a spending problem. The system is working perfectly. It is maximising the number it was given, and steering budget toward the offer that pays you less.
You do not need a study to run this diagnostic. Open one purchase event and compare its value against the payout line for the same receipt.
Why This Matters Now Rather Than in 2019
Two things changed and they compounded.
The first is that manual bidding has quietly become a minority sport. Meta's broad campaign types and Google's Smart Bidding both now expect a value and will use it. Google's own description of Target ROAS is that it bids high on a search likely to produce a high-value conversion and low on one that is not. In 2019, sending a slightly wrong number meant a slightly wrong report. In 2026 it means the machine reallocating your money toward the wrong people, at auction speed, every hour, without asking.
The second is that server-side tracking became the default. When the value came off a pixel on a page you owned, you saw it. It was in your own template. Now it travels through a tracker, from a network notification, into a Conversions API call, and nobody looks at it after setup day. Server-side made the data better and made it invisible at the same time.
There is a third thing, less measurable, that I will state as opinion rather than fact. The whole attribution tooling category is built by and for people who own their checkout. Read the documentation of any of the big attribution platforms and the assumed reader is a brand. The affiliate is a rounding error in their product thinking, which means the question of whose revenue goes in the value field simply never came up in the design review.
What Good Looks Like
Nothing here requires new technology. It requires a decision that somebody makes on purpose.
The value field carries your payout. Not the order total, not the total including tax and shipping, not the merchant's revenue. The number that lands in your account.
The value is per-offer, not per-account. If you promote a 20% offer and a 60% offer, the events carry different values because they are worth different amounts to you. A single blended assumption puts the inversion straight back.
Reversals travel back out. A refund thirty days later is a correction to a number the ad platform is still training on. Correcting only your own dashboard corrects the smaller of the two systems that were learning.
Somebody has actually opened an event and checked. Not the integration docs. An event, in the events manager, matched against a payout line for the same receipt ID. I would put money on a meaningful share of setups failing that check, and I am not going to pretend I know the share, because nobody publishes it.
So What Do You Do About It
Go and look. Pull one purchase event from the last week, find the same receipt in your network's payout report, and see whether the two numbers match. That takes about ninety seconds and it is the only part of this article you cannot get from reading.
If they do not match, you now know your ROAS column has a fixed multiplier on it, you know what the multiplier is, and you know your bidding has been steering toward carts rather than commissions. That is a fixable configuration problem, not a strategic one.
For what it is worth, this is the sort of thing I built ClickerVolt to get right by default: its ClickBank receiver reads the field ClickBank defines as "total you received", not the one defined as "total the customer was charged", and its WarriorPlus receiver picks the affiliate earnings figure when the notification is an affiliate's. It does not yet populate Meta's net_revenue parameter separately, which is a gap I would like to close.
But the check above works no matter what you use, and if you find your value field is right, you have lost ninety seconds and gained a thing you no longer have to wonder about.
