A recorded conversion can later be refunded, canceled, duplicated, disqualified, or assigned a different value. Google Ads conversion adjustments let advertisers restate or retract eligible conversions rather than leaving bidding and reporting with a known wrong outcome. Google's help warns that retracting or restating to zero removes the conversion and later adjustments are ignored. This lesson builds a governed correction ledger before upload.

VISUAL LESSON

What you will learn

  1. 01Distinguish restatement from retraction.
  2. 02Prepare identifiers, times, and adjustment values safely.
  3. 03Reconcile uploaded adjustments with corrected business records.
A conversion ledger branches into restate and retract paths before reconciling with final business records
Restate changes an eligible conversion; retract removes it. Both need identifiers, timestamps, reasons, and a reversible audit trail.

ILLUSTRATIVE WORKED EXAMPLE

Correct an illustrative conversion batch

Original conversionsImported records
100
Value restatementsCorrect value retained
12
RetractionsCanceled or invalid
7
Corrected valid totalCount after removals
93
Illustrative example—not a benchmark. Replace every sample value with your own campaign, market, and measurement data.

PRACTICAL INTERFACE MAP

Move from business correction to verified adjustment

Classify01Choose restate or retract

Map refund, partial refund, duplicate, cancellation, qualification change, and attribution exception to approved actions.

Prepare02Match the original conversion

Use the required click or order identifiers, conversion action, original and adjustment times, value, currency, and reason.

Reconcile03Upload, review, and compare

Capture accepted and rejected rows, segment by adjustment, wait for processing, and tie totals to the corrected ledger.

Conceptual walkthrough. Labels, controls, and availability can vary by account, region, plan, and interface version; verify the current screen before acting.

STEP-BY-STEP LESSON

Business event change → action rule → upload → corrected reporting

ChangeRefund, cancel, qualify
AdjustRestate or retract
ReconcileGoogle and source ledger

THE LEAD ATLAS METHOD

Lead Atlas Data can research a custom contact list for the campaign's exact business categories, locations, and market, while the paid team keeps offline qualification and conversion corrections traceable.See how custom list research works ↗
01

Define correction policy before files

List business events that change a conversion: full or partial refund, cancellation, duplicate, chargeback, test order, later disqualification, corrected order value, currency error, or returned sale. Decide which source system owns the final status and who can authorize an adjustment.

Map each reason to restate, retract, no action, or manual review. A retraction removes the conversion; a restatement changes supported attributes such as value. Do not use platform corrections to hide poor campaign results or overwrite a business dispute without evidence.

02

Match the original conversion

Preserve the identifiers and conversion action needed to find the original event, such as the supported click identifier or order ID, plus the original conversion time. Record the adjustment time, reason, new value and currency for restatements, and source-record ID. Follow the current Google template or API requirements exactly.

Normalize time zones and formats without changing the actual event. Detect duplicate adjustment rows and confirm the original conversion has been processed. Keep personally identifying data out of the file unless the supported method requires it and governance permits it.

03

Treat zero and retraction as terminal

Google's help states that retracting a conversion or restating its value to zero removes it from reporting and that later adjustments to that conversion are ignored. Use zero only when the approved intent is equivalent to removal; do not use it as a placeholder while waiting for a final value.

Add a terminal-action check that requires reason, source evidence, reviewer, and confirmation that no later restatement is expected. When the business status is unresolved, hold the row outside the upload rather than making an irreversible correction prematurely.

04

Test and monitor processing

Upload a small known batch through the supported interface, template, API, or scheduled workflow. Capture file version, row count, uploader, date, accepted rows, errors, and diagnostics. Fix identifiers, formats, time windows, or action names from documented error messages; do not invent substitute events.

Segment reporting by conversion adjustment and review days to conversion or adjustment as Google recommends. Allow for processing delay and confirm that corrected counts and values appear in the intended date and conversion-action context.

05

Reconcile and retain the audit trail

Compare the business source ledger, original imports, restatements, retractions, accepted adjustments, platform report, and financial or CRM outcomes. Explain remaining differences using processing time, attribution, invalid identifiers, date scope, currency, or unsupported records.

Deliverable: correction policy, reason-to-action matrix, protected source ledger, identifier and time validation, terminal zero/retraction control, test upload, accepted-and-rejected log, segmented adjustment report, source-to-Google reconciliation, reviewer sign-off, and next scheduled run.

THE TAKEAWAY

Use a stable business reason and original identifiers, test a small batch, never use zero casually, record every accepted or rejected adjustment, and reconcile Google totals to the corrected source of truth.

OFFICIAL REFERENCES

Check the platform’s current instructions.

Platform labels, eligibility, and workflows can change. These official help pages were used to validate this lesson.