A quick primer
The first, basic checkpoint is whether dynamic values are used at all. When setting up a conversion, you need to select "Use different values" for each conversion. Without that selection, the system uses one fixed value for every conversion regardless of the real order amount, and correctness around discounts or shipping doesn't matter at that point, since the value isn't tied to the transaction to begin with.
For cases where the order amount changes after the conversion has already been recorded (a partial refund, a cancellation, a later upsell), the official mechanism is conversion adjustments. You can restate or retract after the fact using a transaction ID to match it to the original record. One key technical requirement: you can only adjust online conversions with a transaction ID. Without one, there's no way to match an adjustment back to the original entry.
What to check before you touch anything
- Is "Use different values for each conversion" selected for every relevant conversion action, or is a fixed value in use.
- Is a transaction ID (order ID) passed with every conversion. Without it, precise segmentation and later return adjustments aren't possible.
- What exactly is included in the passed value: the gross product total, or an amount that already accounts for shipping and discounts. Compare this against how the business's own accounting works, so the numbers are comparable.
- Is there a regular process for sending conversion adjustments on returns or cancellations, ideally on a schedule, rather than a manual one-off task.
- Does the currency used for the passed value match the account's billing currency. A mismatch will skew ROAS without an obvious cause.
Possible approaches
- If a fixed value is in use, switch to passing the actual transaction amount dynamically as a first, mandatory step, before worrying about discounts or shipping separately.
- If shipping and discounts are handled inconsistently (sometimes included, sometimes not), standardize the logic and document it, to avoid discrepancies during an audit or a developer handoff.
- If returns and cancellations happen regularly and conversion adjustments aren't set up, implement a regular (for example, daily) restate or retract upload based on transaction ID, so ROAS reflects actual, not just initially recorded, amounts.
- If no transaction ID is passed at all, add it first. Without it, neither order-level segmentation nor later adjustments are possible.
- Periodically spot-check a sample of specific orders manually (the amount in your CRM or accounting versus the value recorded in Google Ads). This surfaces a systemic value-passing error faster than waiting for it to show up as an aggregate ROAS gap.