Your fulfilment partner confirms a return. Your finance team approves the refund. Who confirms that the original advertising conversion now reflects the revised order value?
For an overseas brand working with Chinese suppliers, that question can cross several teams and systems. A connected purchase tracker is not evidence of a connected refund workflow. AnyTrack, for example, states in its current documentation that it does not process post-sale refunds or send conversion adjustments to advertising platforms. That is a boundary of one service—not a verdict on the tracking market.
ONCE recommends buying an auditable revision process, not merely a successful upload. The practical deliverable is a record of what was originally reported, what the business now believes, and what the platform has accepted. This can improve the inputs to creative decisions; it does not establish profitability or incremental sales.
Restate the remaining value, not the refund delta
Google distinguishes a restatement, which changes conversion value without changing its count, from a retraction, which removes the conversion and its value. Its API defines adjusted_value as the new value after restatement. These are adjustments to an existing conversion, not a new purchase with a negative amount. [1][2]
Consider a hypothetical order reported at USD 120. A confirmed partial refund of USD 30 leaves USD 90. A later refund of USD 20 leaves USD 70. Assuming both refunds relate entirely to the value originally reported, the two restatements are 90 and 70—not −30 and −20. Nor should the second operation subtract the cumulative refund of 50 from the already reduced value of 90.
A different second restatement also needs a later adjustment occurrence time to avoid being ignored as a duplicate. [2] Our implementation recommendation is to preserve business events and their resulting target values, so retrying delivery does not repeat the commercial subtraction.
Before commissioning an integration, agree what that original 120 included. A refund may contain shipping or tax that was never included in the advertising value. The commerce owner should approve the value convention and currency treatment; the developer should not silently invent them.
The ONCE three-state order audit
This is our proposed acceptance method, not a Google product. Keep three views of the same order, with explicit ownership.
| View | Minimum evidence | Question it resolves |
|---|---|---|
| Originally tracked | Account, conversion action, original order identifier, value, currency and value definition | What did advertising receive? |
| Business-confirmed | Confirmed refund events, their times, current target value and internal version | What should remain now? |
| Platform-confirmed | Submitted version, individual result or error, unresolved difference and owner | Which change has actually been accepted? |
Check identity before buying automation. Google's API requires order_id for website-type conversions and when the original conversion included it; adjustment support is limited to specified action types. [3] Ask the provider to document the actual conversion source and account configuration. A GA4 connection or a website purchase does not, by itself, establish eligibility for this route.
Obtain a redacted mapping example between the commerce record and the identifier originally sent. Where historical identity is missing, repair future collection and document the gap. Creating a convenient new identifier does not prove a match to an old conversion.
The three views may legitimately disagree for a while. A confirmed refund awaiting platform acceptance is an open reconciliation item. It is neither “no refund” nor a completed job.
Require four failure cases in acceptance testing
Google's API upload guidance requires partial_failure and provides for valid and failed operations within a request. [3] A transport-level success is therefore an inadequate acceptance criterion. Request a controlled demonstration of four cases, without contaminating live campaigns with invented purchases:
- Two partial refunds. The 120→90→70 example must retain the correct target value and event order. Re-delivery of the same business event must not deduct it again internally.
- An unmatched conversion. The integration should expose the mismatch for investigation—account, action, identifier or missing original event—not disguise the refund as a new purchase.
- A refund still under review. Keep it pending in the business record. Do not use zero to mean “unknown”: Google says a retracted or zero-restated conversion cannot receive further adjustments, and later attempts may be ignored without an error. [1]
- A partially successful batch. Show the individual outcomes, exception queue and accountable owner. Retry delivery for a repairable error while retaining the business event identity; create a new business version only for a genuinely new change.
An accidental retraction requires source-specific recovery review, not a routine instruction to invent a new order ID. The provider must also document applicable adjustment deadlines, reporting latency and bidding-use restrictions. Acceptance into a report does not demonstrate that every late change will influence bidding. Retain genuinely late refunds in the internal ledger and disclose the platform difference; never alter event times to evade eligibility limits.
Reconciliation completes the test. Google's Conversion adjustment reporting segment separates original metrics from adjustment changes. [4] Compare aggregates using aligned accounts, actions, dates and currencies, with attribution and timing differences explained. This supports—but does not replace—the individual upload outcome record.
Give the creative team usable feedback, not raw orders
When a China-based production partner proposes the next product demonstration, it needs verified product questions and comparable results. It usually does not need customer names, contact details or transaction-level exports.
Send aggregated feedback by agreed market, SKU and creative family, alongside observation period, matching coverage and unresolved refunds. Otherwise the group with the most complete refund capture can look worse than a poorly measured group.
Suppose, hypothetically, a demonstration is associated with more “size was unexpected” complaints. That can justify testing a clearer scale reference or usage limitation in the next film. It does not prove the video caused the returns: product mix, market and observation conditions still need checking. For teams planning product films and other video production, this is a briefing input, not a promise that a reshoot will improve profit.
Start small when refund volume is modest: a reviewed sample and explicit reconciliation may be more useful than a large integration. Where volume warrants automation, price exception handling, version history and ongoing reconciliation as separate deliverables. In both cases, ask the provider to explain one order all the way from 120 to 70—and identify every system that has not caught up.
Sources and scope
Checked on 14 October 2026. This is an evergreen analysis of documented mechanisms, not a claim that conversion adjustments have just launched. The audit method and procurement recommendations are ONCE's analysis; all numerical examples are hypothetical.
- Google Ads Help, About conversion adjustments. No publication date displayed.
- Google Ads API, RestatementValue, v22 reference. Updated 23 February 2026. Cited for field semantics, not as a recommendation of an implementation version.
- Google Ads API, Import conversion adjustments. Updated 6 October 2026.
- Google Ads Help, Understand the impact of conversion adjustments. No publication date displayed.
- AnyTrack, Commission Reversals & Refunds. Page last-updated label: 28 July 2026. Used only for that vendor's stated service boundary.
