Conversion Adjustments in Google Ads 2026: Refunds, Cancellations and Retracting Junk Leads

A store reports 400 purchases for the month. Three weeks later 70 of them are returned and another 20 were cancelled before shipping. Google Ads still shows 400 conversions and the full revenue figure, because nobody uploaded conversion adjustments — and Smart Bidding is dutifully hunting for more people who look like the ones who sent the parcels back.

Lead generation has the same disease in a different shirt. Out of 300 form fills, 90 are junk: bots, fat-fingered phone numbers, people who wanted a price list. To the bidding algorithm all 300 are identical successes. Until the outcome flows back into the platform, you are paying to train a model on your own losses.

The mechanism that fixes this is conversion adjustments. This guide covers the two types, what has to be in place before your first upload, the timing windows that quietly kill adjustments, how bidding reacts, and the mistakes that turn the whole exercise into rejected rows nobody notices.

What conversion adjustments are — and what they are not

An adjustment tells Google that a conversion it already recorded has changed after the fact. Two types do the heavy lifting:

Type	Effect	Changes count	Changes value	Typical trigger
Restate	Updates the conversion’s value	No	Yes	Partial refund, upsell, discount, corrected margin
Retract	Removes the conversion, value to zero	Yes	Yes (to 0)	Full refund, cancellation, junk lead, fraud

A third mechanism, enhancement, attaches hashed customer data to a conversion. That solves a different problem — matching, not outcome — and lives in enhanced conversions territory, covered in our guide to enhanced conversions and first-party signal.

Adjustments are not:

• A way to tidy up reports for a client deck. The data feeds bid strategies; lying in either direction shows up in your CPAs a fortnight later.
• Deduplication. If one purchase fires twice because two tags are live, fix the tagging — see duplicate conversions and overcounting.
• A replacement for offline conversion import. Import adds events; adjustments change existing ones. Most mature setups run both — the import side is in offline conversion import for Smart Bidding.

Prerequisites: almost all the pain is upstream

1. A transaction (order) ID captured at conversion time. Online conversions are adjustable only if a unique transaction ID was sent with the original event. No ID, no adjustment — the system cannot tell which of a thousand purchases you mean.
2. Or GCLID plus exact conversion time when no order ID exists. Workable, but brittle: the timestamp has to be right, and some click environments will not have a usable identifier at all.
3. The exact conversion action name, character for character as it appears in the account.
4. An eligible conversion action. Not every action type accepts adjustments; purchases and order-ID-bearing lead actions are the straightforward cases.

If you are not sending an order ID with purchase conversions today, that is the whole project. Everything downstream is blocked until it exists, and there is no clever workaround.

Where the ID comes from in practice

• Ecommerce: the order number from your platform, passed as transaction_id on the purchase tag. Most carts support this natively.
• Lead gen: generate your own submission ID (a UUID works) on the site and write the same value into both the tag and the CRM record.
• Calls: the call ID from your call tracking provider — the plumbing is described in call tracking and call campaigns.

Timing: why “we’ll do it quarterly” fails

Adjustments live inside a window with a floor and a ceiling:

• The floor. Do not upload an adjustment minutes after the conversion — the original event needs time to land. Waiting a few hours is workable; next-day is safer.
• The ceiling. Conversions age out. As a working reference, standard actions accept adjustments for roughly two to three months after the conversion, and some campaign types are notably shorter.

The operational consequence: your refund cycle has to fit inside the adjustment window. If you accept returns for 90 days and adjustments expire earlier, some refunds can never be reflected. The fix is process, not technology — adjust daily as refunds are processed in the CRM rather than batching at the end of the return period.

Retractions are one-way

A retracted conversion cannot be restored by another adjustment. The only path back is uploading it again as a new event with a different unique ID. That is why automatic retraction on a weak signal — “no answer within 24 hours” — is a bad idea: a good share of those leads call back on day three.

Three ways to upload

Method	What it looks like	Best fit
Manual file upload	Goals → Uploads → adjustments template, CSV or Sheets	Up to a few hundred rows a week; first implementation
Scheduled Sheets / HTTPS source	Same template, refreshed on a schedule	Mid volume with someone maintaining a CRM export
Google Ads API / Data Manager	uploadConversionAdjustments or a data connector	Continuous flow, CRM or ERP integration

Start with the template even if you plan to automate. It shows exactly which columns the system expects — identifier, conversion action name, conversion time, adjustment time, adjustment type, new value and currency — and once manual uploads run clean, the same schema moves into a pipeline. For the infrastructure side of connecting sources without building three parallel pipelines, see Google Ads Data Manager and first-party data.

A minimal ecommerce flow

1. Order placed → purchase tag fires with transaction_id and a value based on revenue or margin.
2. Order cancelled before dispatch → next day’s export writes a retract row for that ID.
3. Partial refund → a restate row carrying the remaining value.
4. The file uploads on schedule; the results report is checked for rejected rows.
5. Weekly reconciliation: adjustments uploaded versus refunds recorded in the back office.

What happens to your bidding

• Retractions affect both tCPA and tROAS. The conversion leaves the history, so the model’s estimate for that segment changes too.
• Restatements affect value-based strategies only — tROAS and maximise conversion value. For tCPA, changing value is neutral.
• History is rewritten. Yesterday’s ROAS will not match what you saw yesterday, because adjustments apply to the original conversion date. Same family of effect as described in conversion windows and conversion lag.
• A giant one-off backfill is a shock. Dumping three months of retractions in a single day hands the algorithm a sudden re-rating of its own history. Split the backfill across several days and leave targets alone for a week afterwards.

Adjustments versus the other ways to send quality

Tool	Best when	Limitation
Adjustments (retract / restate)	The event already counted and then changed: refund, cancellation, fraud	Needs an order ID and has to land inside the window
Separate conversion actions per stage	You have clean stages: lead → qualified → closed	Requires CRM discipline and correct primary/secondary setup
Conversion value rules	Value is predictable up front by geo, device or audience	Does not reflect the actual outcome of a specific deal
Offline conversion import	The real sale happens later and off-site	Requires stored GCLIDs and a working CRM link

Healthy accounts combine them: primary and secondary conversions decide what the strategy optimises toward, conversion value rules shape the economics by segment, and adjustments close the last mile with what actually happened.

Seven mistakes that neutralise the whole effort

1. No order ID. The most common failure by a wide margin: the project is approved, the tag never changes.
2. Conversion time in the wrong timezone. Rows fail to match and the report says the conversion was not found.
3. A mistyped conversion action name. Copy it from the interface; never retype it from memory.
4. Uploading minutes after the conversion. The original event has not landed yet, so the adjustment bounces.
5. Auto-retracting on weak signals. “Did not pick up the first call” is not junk. Retract only what is confirmed.
6. Different IDs in tag and CRM. Cart order number in the tag, internal deal ID in the export — they must be identical strings.
7. Nobody reads the results report. The file uploaded, half the rows were rejected, and everyone assumes the data is in.

Verifying it actually worked

• The uploads report (Goals → Uploads) should show an acceptance rate close to 100%, with every rejection explained.
• Historic conversion columns must move after an upload. If past-period numbers are frozen, nothing was applied.
• Reconcile counts: retractions uploaded this week against refunds and cancellations in the back office. A gap beyond 5–10% means a matching problem.
• If conversions behave strangely in general, start with the basics instead of adjustments — the sequence is in a 30-minute conversion tracking diagnosis.

The upload template: columns and how to fill them

The schema is strict, and most rejected rows fail at the column level rather than on logic. The minimum set:

Column	What goes in it	Common mistake
Order ID / GCLID	The identifier from the original conversion	CRM deal ID used instead of the cart order ID sent by the tag
Conversion Name	The exact conversion action name	Trailing space, or a name from a neighbouring account
Conversion Time	Original conversion time with timezone	Local time with no offset, or export timezone ≠ account timezone
Adjustment Time	When the adjustment was created	Set earlier than the conversion time, which rejects the row
Adjustment Type	RESTATEMENT or RETRACTION	Free text or a localised label
Adjusted Value	New value, restatements only	Populated on a retraction, or stated in a different currency
Currency	ISO currency code	Differs from account currency with no code supplied

Process tip: generate the export from a single source — a SQL query or a saved CRM report — rather than assembling it by hand. Manual assembly reliably produces date-format drift between weeks.

Reporting ROAS once refunds are in the data

After adjustments go live, the numbers in the interface will not match what everyone was used to. That is the point, but it needs explaining to the team and the client before it happens, not after. A workable framework:

• Gross ROAS — what the interface used to show: all recorded revenue over spend. Overstated by exactly your refund rate.
• Net ROAS — after adjustments: refunds deducted, cancellations zeroed.
• Margin ROAS — if you send margin rather than revenue as conversion value. The most decision-ready of the three.

Worked example. Spend $10,000, recorded revenue $40,000 — gross ROAS 4.0. Refunds run at 18%: net revenue $32,800, net ROAS 3.28. Average margin 35%: margin value $11,480, margin ROAS 1.15. Same month, three different pictures — and “scale or cut” has a different answer in each.

If your target ROAS was set against gross numbers and you now feed net values, the strategy will throttle spend hard. Reset the target onto the new base in the same change window as the adjustments rollout.

The operational layer: who does it and how often

Technically this is one file a day. It breaks on the human layer, so pin down three things:

1. An owner. One named person is accountable for the file going out and being accepted — not “the marketing team”.
2. Cadence. Daily beats weekly: it keeps you far from the upper edge of the adjustment window and keeps each batch small.
3. Quality control. Weekly, reconcile row counts against refunds and cancellations in the back office; monthly, confirm the rejection rate is near zero.

Agree the retraction rule for leads explicitly. A good criterion is checkable and binary: invalid number after three call attempts, duplicate of an existing customer, explicit refusal, confirmed fraud. Anything softer is not grounds for zeroing a conversion.

Automating through the API: what to brief the developer on

Once volume outgrows spreadsheets, adjustments move to the Google Ads API (uploadConversionAdjustments) or a data connector. Four things are worth stating explicitly, because they are easy to miss in the docs:

• Partial success is normal. A batch is not rejected as a whole — some rows apply, others return errors. Parse the response row by row, or you will never learn that 12% of your adjustments never landed.
• Re-sending is not always idempotent. Retracting an already-retracted conversion simply errors, which is safe. A series of restatements with different values, however, will end at whichever value arrived last — so ordering matters.
• Batch size. A few thousand rows per call is a sensible ceiling; oversized batches are slower and much harder to debug when something fails.
• Log everything you send. Keep your own record of payloads and API responses. Without it, “why does the 14 March conversion look like that?” has no answer.

One sequencing rule saves weeks: get the same dataset uploading cleanly by hand first, then automate. An integration written before the format has been eyeballed usually just automates the mistake.

Explaining the numbers to a client

To a stakeholder, switching on adjustments looks like performance getting worse: conversions drop, ROAS falls, CPA rises. Nothing actually got worse — only the honesty of the measurement changed. Three points that defuse the conversation before it starts:

1. Sales did not change, only which of them count. Reconcile against finance: net revenue will match.
2. Decisions get cheaper. Budget was flowing to segments with high refund rates precisely because reporting flattered them. Now that is visible.
3. Targets need rebasing. The old tROAS was set on inflated data; the new one must come down by roughly the refund rate, or the strategy will choke spend.

Who gains the most

The value of adjustments scales with the gap between “recorded” and “collected”. It is largest in cash-on-delivery models, apparel and footwear with structurally high return rates, expensive lead-gen niches where a third of forms are noise, and subscription products with heavy first-month churn. In those verticals, an account without adjustments is optimising toward losses — which is one reason a dashboard ROAS can look healthy while the unit economics of the media buy refuse to add up.

If you run several accounts, standardise the ID format and the export schema once and reuse them everywhere — it is the same category of infrastructure hygiene as running on stable agency ad accounts with clean access structure. Related pieces published this week: Google Ads billing thresholds and invoicing, and, for showing returning users the product they abandoned, dynamic remarketing with business data feeds.

FAQ

What is the difference between retract and restate?

Retract removes the conversion entirely: the count drops and the value goes to zero. Restate keeps the conversion but changes its value, leaving the count untouched.

Can I adjust conversions without an order ID?

Only through GCLID plus the exact conversion timestamp, which is less reliable. For ongoing work, pass a unique transaction ID with the conversion itself.

How long after a conversion can I upload an adjustment?

Not immediately — let the original event land first. A few hours is usually enough; next-day uploads are safest.

How old can a conversion be and still be adjustable?

There is a ceiling. As a working reference it is roughly two to three months for standard actions, shorter for some campaign types. Confirm the current limit for your conversion type before designing the process.

Can I undo a retraction I made by mistake?

No. A retracted conversion cannot be restored by adjustment. You would have to upload it again as a fresh conversion with a different unique identifier.

Do adjustments disturb Smart Bidding?

They change what it learns from, which is the point. Retractions influence tCPA and tROAS; restatements influence value-based strategies. A large historical backfill in one day can visibly shake a strategy.

Why did last week’s numbers change after I uploaded?

Adjustments apply to the date of the original conversion, not the upload date, so historic rows are recalculated. That is expected behaviour.

Should I retract every unqualified lead?

No — only confirmed junk: invalid contacts, fraud, duplicates, explicit refusals. Retracting on soft signals throws away valid training data.

What if refunds arrive after the adjustment window closes?

Adjust when the refund is processed rather than at the end of the return period, and cover the residual by baking an average return rate into the value you send at conversion time.

Do I still need adjustments if I already import offline conversions?

Yes. Import adds new events; adjustments modify events that already counted. Refund-heavy businesses need both.

How do I confirm adjustments were applied?

Check the acceptance rate in the uploads report and watch historic conversion columns recalculate, then reconcile counts against your back office.

Do adjustments fix duplicate conversions?

No. Duplicates are a tagging problem and must be fixed at the tag or deduplication level, not patched retroactively.