Skip to content
Adrythm

How-to

Fix offline conversion import errors in Google Ads

Updated October 11, 2026

30 minutes

Read the reason on each failed row before sending again. Too recent means not yet: wait six hours, or a day for a correction, then resend for two or three days at most. Too old or expired is final. A refused click ID, or refused email and phone, tells you which identifier to send instead.

Before you start

  • Access to the Google Ads account that owns the conversion action. Google matches an upload to an action of that exact name in the account you upload to.
  • The failed rows, from the upload's error file, the offline data diagnostics page, or the reply your CRM or developer received.
  • What each row carried: a click ID (GCLID, GBRAID or WBRAID), an email or phone number, or both, plus the conversion time.

Read the reason for each failed row

Start with the reason Google gave, because the same upload can fail for several reasons at once.

  1. For file uploads, open Goals, then Conversions, then Uploads. Find the file, then in the Actions column click Download errors. Each failed row has its reason in the Results column.
  2. If the whole file failed, read the first row of the error file (a .csv or .tsv) or the General Errors worksheet (Excel). That error stopped every row.
  3. For uploads through the API, Data Manager or a CRM connection, go to Goals, then Conversions, then Summary. In the Status column of the conversion action, hover over its offline data quality and click Go to diagnostics. Alerts are grouped by error type, with the type affecting the most data first.
  4. Sort every reason into one of three groups before you act: not yet, final, or a problem with what was sent. The next two parts cover each group.

Google says offline conversion uploads move to the Data Manager API from June 15, 2026, so newer API uploads usually report Data Manager reason names. This page gives both names where they differ.

Wait and resend when the answer means not yet

Some refusals only mean Google cannot act on the row yet, so the fix is to send the same row again later.

  1. Click too recent (TOO_RECENT_EVENT or TOO_RECENT_CLICK): the click happened too recently. Google's help page gives 6 hours, so send the row again after 6 hours.
  2. Conversion action too new (TOO_RECENT_CONVERSION_ACTION, or a destination created too recently): wait 6 hours after creating the action, then resend. Google's file guide says 4 to 6 hours, and the API's error says 6.
  3. For conversions within a day of their click, include the last day again in your next upload. Google says it may not be able to record those yet, and it does not count a true duplicate twice. Rows that were already recorded will come back as duplicates. That is expected.
  4. For a correction (a retraction or a new value), too recent means the conversion happened less than 24 hours ago. A correction sent soon after its upload can also come back not found, which may only mean the conversion has not reached the account yet. Check that the correction names the same conversion action and the same order ID (or click ID and conversion time) as the upload, then wait a day and send it once more before treating it as missing.

Resend a not-yet row a day apart, for two or three days at most. If it is still refused after that, treat the reason as real and move to the next part.

Change what you send, or stop

Every other reason means sending the identical row again will fail the same way.

  1. Final, stop sending: the identifier or event is too old (EVENT_TOO_OLD, EXPIRED_CLICK, EXPIRED_EVENT), the conversion fell outside the action's conversion window, or Conversion actions not active (no conversion action existed when the click happened). Google keeps the GCLID for 90 days, and a row matched by email or phone must be uploaded within 63 days of the click. Upload more often, or send an earlier step of the sale that happens inside that time. If the account has no Import from clicks action, create one so later clicks can count.
  2. Click ID refused (INVALID_GCLID, UNPARSEABLE_GCLID, or the GBRAID or WBRAID versions): if the lead also has an email or phone number and the account takes enhanced conversions for leads, send it by those instead. Then find where the stored ID was changed: Google says the GCLID is case sensitive.
  3. Click belongs to another account (INVALID_CUSTOMER_FOR_CLICK, or the Data Manager reason INVALID_OPERATING_ACCOUNT_FOR_CLICK): upload to the account that owns the conversion action. If the click came through a manager account, check that cross-account conversion tracking is on.
  4. Email or phone refused because the customer data terms are not accepted or enhanced conversions for leads is off: send the click ID alone, or accept the terms and turn the setting on in the account's conversion settings. If the hashing itself is refused, fix the formatting, then hash with SHA-256: lowercase emails with no spaces, phone numbers in E.164 format such as +16502531234.
  5. Conversion time before the click: check the time zone in the file or request. Google suggests checking the time zone or moving the conversion time 1 to 2 days later.
  6. Already recorded (CLICK_CONVERSION_ALREADY_EXISTS, ORDER_ID_ALREADY_IN_USE, DUPLICATE_GCLID, DUPLICATE_TRANSACTION_ID): Google has it, so stop sending that row. If it is really a separate event, give it its own conversion time or order ID.
  7. Duplicated inside one upload (DUPLICATE_ORDER_ID, DUPLICATE_CLICK_CONVERSION_IN_REQUEST): those rows were not processed. Remove the repeats and send one copy.
  8. Unknown clicks on uploads matched by email or phone: Google says this can generally be ignored, because only some of the people you upload came from a Google ad. Look into it only if every row gets it, or far fewer match than you expect.

Check it worked

After the next upload, open Uploads (for files) or the diagnostics page (for API and connector uploads) and compare the failed rows with the last run. Rows you resent after a not-yet reason should be gone, and duplicate errors on the repeated day are expected. Rows you marked final should no longer be sent at all.

The diagnostics page's Data quality reads Excellent when at least 90 percent of the offline data is well-formed and valid, and Good between 70 and 90 percent. Below 70 it reads Needs attention. The History panel shows the last 7 days by day or the last 7 uploads by job, so allow a week of uploads before judging the trend.

Why the identifier in a refusal matters

A refusal names one identifier, and the other one on the same lead may still be good. A lead that carries both a click ID and an email or phone number can usually be sent again with only the identifier Google did not refuse. A lead that carries only the refused identifier has nothing left to send, so stop rather than resending it.

Corrections Google refuses for good

Three correction reasons are final. CONVERSION_EXPIRED means the conversion happened more than 54 days ago. CONVERSION_ALREADY_RETRACTED means an earlier retraction already went through. CANNOT_RESTATE_CONVERSION_ACTION_THAT_ALWAYS_USES_DEFAULT_CONVERSION_VALUE means the action gives every conversion the same value, so check the action's value setting before sending new values to it.

Errors versus conversions that were accepted and never showed

This page covers rows Google refused. Rows that uploaded without an error but never appeared in the Conversions column are a different problem, usually the column, the date range, the action's count setting or processing time.

Still have a question this page did not answer?

Ask it on a call. Thirty minutes, a straight answer, and no follow-up sequence if you decide not to work with us.