How Do You Retract a Canceled Clinic Offline Conversion in Google Ads?

Use a RETRACTION conversion adjustment when a previously uploaded clinic conversion was canceled and should no longer count. A retraction removes the conversion count and sets its value to zero. Use RESTATEMENT only when the conversion remains valid but its value must change. Prefer the original order_id, submit the adjustment through the Google Ads account that manages the conversion action, and treat a retraction as final. The ability to send an API request does not make health-related data eligible for upload.

What a retraction changes in Google Ads

Google Ads supports two distinct conversion adjustment types. A retraction tells Google Ads that the original conversion should be removed. Google sets its value to zero and removes it from the conversion count. That change can affect reporting fields based on conversion count, conversion value, cost per acquisition, and return on ad spend.

A restatement keeps the conversion but replaces its value. It is appropriate when the business outcome still happened and only the reported value was wrong. It does not reduce the conversion count. Choosing between the two is therefore an accounting decision about the original event, not a cosmetic reporting preference.

For a canceled booking that was previously counted as a completed offline conversion, retraction is the matching operation if the clinic’s defined conversion no longer occurred. If the booking remained valid but its commercial value changed, restatement may be the matching operation. The conversion definition should be documented before either adjustment is sent.

Confirm that the cancellation is final before retracting

Google warns that a retracted conversion cannot later be adjusted. A conversion restated to zero is also closed to later adjustment. Subsequent attempts are ignored without an error, so an operator should not assume that a successful request means a second correction was applied.

Operational inference: retract only after the clinic’s source system has reached a final administrative state under its own documented rules. A temporary reschedule, pending review, duplicate flag, or payment dispute is not automatically the same as a final cancellation. The Ads operator should receive a simple approved status and an opaque event identifier, not clinical notes or other sensitive details used to reach that status.

Operational inference: keep the cancellation reason in the clinic’s internal record and send only the fields Google Ads needs to locate and adjust the original conversion. This separation supports reconciliation without expanding the advertising payload. For a durable implementation pattern, see the offline conversion outbox reporting guide.

Prefer the original order ID

The Google Ads API documentation recommends identifying the original conversion with order_id. It is more durable than matching a Google click identifier and conversion time. The order ID must be the same opaque identifier sent with the original conversion, not a newly generated ID for the cancellation.

If the original conversion did not contain an order ID, an eligible offline conversion can be matched with its GCLID and conversion time. GBRAID adjustments require an order ID, and the documented adjustment flow does not support WBRAID. For a WEBPAGE conversion action, an order ID is required. It is also required whenever the original conversion was uploaded with one.

Operational inference: use an opaque order ID that does not encode a person’s name, phone number, email address, diagnosis, treatment, appointment notes, or procedure. It should function only as a stable reconciliation key. If the original pipeline cannot produce that key reliably, fix the identifier contract before automating cancellations.

Submit through the account managing the conversion action

The adjustment must be uploaded by the Google Ads account that manages the conversion action. In cross-account conversion tracking, that may be a manager account rather than the individual clinic account. Sending through the wrong account can produce NO_CONVERSION_ACTION_FOUND even when the action is visible elsewhere in the account hierarchy.

The API documentation limits adjustments to conversion actions whose type is SALESFORCE, UPLOAD_CLICKS, or WEBPAGE. The conversion must already have been recorded. A newly created action can also need four to six hours before uploads are accepted. A CONVERSION_NOT_FOUND response can mean the original conversion was never imported, was discarded, or cannot be matched with the supplied identifier and time.

Operational inference: before changing the pipeline, compare the conversion action owner, action type, original identifier, and original upload result. The offline conversion diagnostics guide covers the account-boundary checks that commonly explain an empty client view.

A minimal retraction workflow

Operational inference: the following sequence turns the documented adjustment requirements into a reviewable clinic workflow.

1. Confirm that the original event appears as an accepted conversion and record the managing customer ID and conversion action.
2. Confirm that the cancellation is final according to the clinic’s approved administrative definition.
3. Retrieve the original opaque order_id. Use GCLID plus conversion time only where the documented rules permit that match.
4. Create a RETRACTION adjustment with the adjustment time and the original conversion reference.
5. Upload from the account managing the conversion action and keep partial failure enabled so individual row errors are returned.
6. Store the request result and reconcile the adjusted reporting after Google Ads processing time.

Operational inference: make the operation idempotent in the clinic’s outbox. One approved cancellation should create one adjustment attempt record, with retries tied to the same event and identifier. This reduces duplicate requests and preserves an audit trail without copying sensitive source-system fields into advertising logs.

Verify the adjustment instead of trusting the request alone

The API requires partial failure mode for these uploads.

Operational inference: inspect each returned result and error rather than treating the HTTP response as proof that every row succeeded. Keep the Google request ID, managing customer ID, conversion action reference, opaque order ID, adjustment type, adjustment time, and per-row outcome. Those fields are enough for most technical reconciliation and do not require clinical context.

Google says adjustment reporting generally appears on a timing similar to regular conversion data.

Operational inference: after processing, confirm that the specific conversion is no longer counted and that its value is zero. Then verify the expected effect in the reporting columns used by the campaign. If an event appears under All conversions but not Conversions, review action inclusion and goal configuration using the clinic conversion-column troubleshooting guide.

Operational inference: do not test a retraction against a real conversion that might need to be restored. Use a controlled eligible test event and document its expected lifecycle. Because retraction is effectively irreversible, a production proof should focus on the final accepted cancellation, request result, and reporting reconciliation.

Platform capability does not decide health-data eligibility

The Google Ads API documents how eligible conversions can be adjusted. That technical capability is not permission to upload health or medical information. Google’s Customer data policies prohibit conversion information related to sensitive categories, including health and medical information, for the products covered by that policy, such as enhanced conversions, store sales uploads, and Google-engaged audiences.

The mapped sources document conversion adjustment through Google Ads tools and the Google Ads API. They do not establish that Data Manager supports this adjustment operation, so this article does not recommend or claim a Data Manager adjustment path. It also does not conclude that every administrative clinic conversion is eligible. Eligibility depends on the exact product, event definition, data fields, consent and legal basis, account configuration, and current Google policy.

Operational inference: use a generic business event only after that separate review, and exclude medical details from identifiers, values, labels, logs, and upload payloads. Hashing does not change the nature of sensitive data. See how to audit enhanced conversions for leads without overclaiming proof for a related measurement boundary.

Common failure modes

• Wrong adjustment type: a restatement changes value but leaves the conversion count in place.
• Wrong account: the upload runs from a client account while a manager account controls the action.
• New identifier: the cancellation receives a different order ID and cannot match the original conversion.
• Missing original conversion: the source event was rejected, discarded, or never uploaded.
• Unsupported action type: the action is outside the API’s documented adjustment types.
• Premature retry: an operator retries before checking row-level errors and creates a misleading local state.
• Sensitive payload: an implementation copies clinical or identifying fields that are unnecessary for reconciliation.

Frequently asked questions

Can a retracted conversion be restored?

No documented adjustment restores it. Google says a retracted conversion cannot be adjusted further, and later attempts are ignored without an error. Treat approval of the retraction as a final control point.

Should a canceled booking be restated to zero?

Use retraction when the conversion should no longer count. Restatement changes value only. Google also says a conversion restated to zero cannot be adjusted again, so zero is not a reversible holding state.

Is order ID always required?

It is required for WEBPAGE actions, for GBRAID adjustments, and when the original conversion used an order ID. Some eligible offline conversions without an order ID can be matched by GCLID and conversion time.

Does a successful API call prove policy compliance?

No. It proves only that the request met the technical processing rules reported by the API. Product eligibility, sensitive-data restrictions, privacy duties, and the clinic’s own governance require separate review.

References

• Google Ads Help: About conversion adjustments, accessed August 16, 2026.
• Google Ads API: Upload conversion adjustments, accessed August 16, 2026.
• Google Ads policies: Customer data policies, accessed August 16, 2026.