Convwatch

Field test · Google Data Manager API · 3 October 2026

Google said 200 OK. An hour later it rejected all of them.

Viktor Shataev · developer · tested on a live Google Ads account, not a test account

Since 15 June 2026, offline click conversions go to Google Ads through the Data Manager API. I sent five conversions that should fail and watched what Google said, and when.

What I sent

One conversion action of type Import from clicks. Four upload requests, five events in total, each with a click ID that Google could not match to a real ad click: two well-formed fake GCLIDs, one plain junk string, one with a conversion value and currency, one dated 120 days back. A fifth request pointed at a conversion action that doesn't exist.

Timeline of one request

1. 13:49:45POST /v1/events:ingest → 200 {"requestId": "8edf4943-…"}. Nothing in the body hints at a problem.
2. 14:18:43First requestStatus:retrieve, 29 minutes later, as Google's guide suggests → PROCESSING.
3. 14:59:23Second check → FAILED, 2 of 2 events rejected, reason INVALID_GCLID.

The responses, verbatim

The accepted upload:

POST https://datamanager.googleapis.com/v1/events:ingest → 200
{"requestId": "8edf4943-0aa7-458e-aede-bc545357857f"}

The same request, an hour later:

GET /v1/requestStatus:retrieve?requestId=8edf4943-… → 200
{"requestStatusPerDestination": [{
  "destination": {"operatingAccount": {"accountType": "GOOGLE_ADS", "accountId": "…"},
                  "productDestinationId": "…"},
  "requestStatus": "FAILED",
  "errorInfo": {"errorCounts": [{"recordCount": "2",
                                 "reason": "PROCESSING_ERROR_REASON_INVALID_GCLID"}]},
  "eventsIngestionStatus": {"recordCount": "2"}
}]}

The one that failed fast, which carries a request ID you can't look up later:

POST /v1/events:ingest → 404
{"error": {"code": 404, "status": "NOT_FOUND",
  "message": "Conversion action ID is not valid.",
  "details": [
    {"@type": "…ErrorInfo", "reason": "INVALID_CONVERSION_ACTION_ID",
     "metadata": {"requestId": "t-cbb4c79b-…"}},
    {"@type": "…BadRequest", "fieldViolations": [{
       "field": "destinations[0].product_destination_id",
       "reason": "INVALID_CONVERSION_ACTION_ID"}]}]}}

Check your own uploads

If your backend uploads offline conversions, keep the requestId from every successful ingest and ask for its status from 30 minutes on. Google's guide suggests backing off ×1.3 up to an hour and giving up after 24 hours.

# token for the same account that uploaded, with the datamanager scope
curl -s "https://datamanager.googleapis.com/v1/requestStatus:retrieve?requestId=$REQUEST_ID" \
  -H "Authorization: Bearer $TOKEN" \
  -H "x-goog-user-project: $GCP_PROJECT"

Look at requestStatus per destination, then errorInfo.errorCounts for how many events were dropped and why. Status can't be retrieved for a request that failed outright or was sent with validateOnly.

Reasons worth alerting on

From Google's ProcessingErrorReason list, the ones that point at a problem on your side rather than a lead that never clicked an ad:

CLICK_NOT_FOUND on its own is often normal for leads that came from organic traffic. Watch its rate, not its presence.

One oddity

With validateOnly: true, a request carrying conversionValue and currency was refused with destination_references: Resource not found. The identical request without validateOnly returned 200. Dropping the value fields made validateOnly pass. I saw this on one account and don't know the cause; if you rely on validateOnly in CI, check it against a real upload.