> ## Documentation Index
> Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Offline conversions

> Report leads back to Google Ads from the rows that captured a gclid, so conversion-based bidding learns which clicks became customers — and understand what Google's acknowledgement does and does not promise.

# Offline conversions

A landing page that carries no conversion tag still produces leads, and the
bidding strategy paying for its clicks learns nothing from any of them. It keeps
buying whatever it was buying, because as far as Google can tell nothing has
happened since the click. Offline conversion upload closes that loop: the lead
rows that captured a `gclid` are reported back to Google Ads from your data, so
`MAXIMIZE_CONVERSIONS` and `TARGET_CPA` find out which clicks became customers
and start bidding towards more of them.

Ask an agent for it in the words you'd use anyway — "report last week's leads to
Google Ads as conversions" — and it reads the lead rows, matches them to the
conversion action, and files an [approval](/approvals) before anything reaches
your account. Every upload is a write to a live ad account, so it is gated the
same way a budget change is.

## Reconnect Google Ads once

Google has moved offline conversion upload onto a separate API with a permission
of its own, and a connection made before that change does not carry it. **If your
Google Ads connection predates it, the first upload will stop and ask you to
reconnect** — it will not try the call and fail halfway.

Reconnecting takes one pass through Google's consent screen from
**Settings → Integrations**, and Google will ask for the additional permission
while you're there. Nothing else about the connection changes: your account and
campaign selections stay as they are, your synced data keeps flowing, and every
other Google Ads capability keeps working before, during, and after. Only the
conversion upload waits on it.

## What "submitted" means

Google acknowledges an upload immediately and processes it later, so the result
you get back is honest about which one it is:

> Submitted 412 click conversions to Google (processing asynchronously)

That is an acknowledgement that Google **accepted the batch**, not a report that
412 conversions were recorded. The real processing finishes some time in the next
30 minutes to 24 hours, and Google's acknowledgement carries no per-row outcome
at all — so Erdo reports the number submitted and the request id, and never a
number of conversions "recorded", because that number does not exist yet.

To find out what actually happened, ask the agent to check the upload's status
using the request id from the result. It answers with one of:

| Status            | What it means                                                                                     |
| ----------------- | ------------------------------------------------------------------------------------------------- |
| `PROCESSING`      | Google has the batch and is working through it. Expected for the first half hour — not a problem. |
| `SUCCESS`         | Every conversion in the batch was processed.                                                      |
| `PARTIAL_SUCCESS` | Processed, with some records rejected.                                                            |
| `FAILED`          | Google rejected the batch's records.                                                              |

Where records were rejected, Google reports **how many** for each reason — twelve
duplicates, say — but not which rows they were. Erdo reports what Google reports,
so nobody acts on a row-level detail that was never sent.

## Rejections are all-or-nothing

If anything in an upload fails Google's validation, the **whole batch is
rejected** and none of it is processed. There is no partial acceptance to sift
through: correct what the error names and resubmit the batch. Erdo's result says
so explicitly, so an agent retrying on your behalf resubmits everything rather
than a subset that was never the problem.

## Only the click id is sent

A conversion is matched to a click by its `gclid` and nothing else. Erdo does not
send customer email addresses, phone numbers, or any other personal identifier to
Google — not hashed, not encrypted — even though Google's API would accept them.
If a lead row you're uploading from carries contact details, those fields are
ignored rather than forwarded.

## Retracting a conversion you already reported

Some reported leads turn out not to be leads — spam, a duplicate, a test
submission. Left alone, the optimizer keeps bidding towards whatever produced
them and your reported cost per lead stays wrong in the flattering direction.
Ask the agent to retract them, and it reports the correction to Google against
the same conversion action. Restating a conversion's value works the same way,
for when what a lead was actually worth becomes known later.

Retraction is unaffected by the reconnect above — it travels a different route
and works on connections old and new alike.

## Related

* [Ad accounts](/ad-accounts) — finding the account id an upload reports into
* [Approvals](/approvals) — the gate every ad-account write passes through
* [Dataset row actions](/dataset-row-actions) — the standing way to report new leads as they arrive, rather than uploading by hand each time
* [Integrations](/integrations) — connecting and reconnecting Google Ads