Google Ads Offline Conversion Uploads Are Moving Toward Data Manager API: A B2B Migration Checklist

Google’s Data Manager API supports Google Ads offline-conversion and enhanced-conversion-for-leads events, and Google’s current Ads Help documentation says the Google Ads API upload path for those workflows was blocked starting June 15, 2026. Google says legacy access is limited to developer tokens allowlisted through prior request activity; don’t assume an account still has it. If your pipeline still uses the old API, confirm your token/account status immediately and plan the supported migration. This is a data-mapping and operations change—not an endpoint swap. Before production changes, map account ownership, conversion actions, identifiers and timestamps; validate the request; and plan for asynchronous processing and detailed diagnostics. Review Google’s offline conversion help notice, Data Manager offline conversions overview and upgrade guide.

This guide is for B2B marketing operations, analytics engineering and RevOps teams that send downstream CRM outcomes to Google Ads. The availability of any legacy exception is account-specific; confirm current status with Google Ads and the documented migration guidance before changing production.

What changes when an offline upload moves to Data Manager API?

The business purpose can remain the same—send a qualified lead, opportunity or other conversion event—while the request model and operational behavior change. Google’s field-mapping documentation compares the legacy UploadClickConversionsRequest with Data Manager’s IngestEventsRequest.

Area	What to check in the migration
Destination/account	Identify the Google Ads account that owns each conversion action. Data Manager’s operating_account must be the account that owns the conversion action; linked/partner destinations have separate configuration.
Request model	Map conversion objects to event objects and conversion actions to destination references. Confirm any multi-destination setup explicitly.
Authentication	Recheck the credential and API scope requirements; don’t assume request headers and account relationships map one-to-one.
Event data	Map required event_timestamp and event_source, one supported identifier path, plus optional value/currency/transaction ID and consent fields as applicable.
Validation	Use the non-applying validation option during development, then monitor processing diagnostics using the request ID.
Error behavior	Structural/required-field failures can reject the request; optional-field warnings and asynchronous per-record errors have separate handling.
Processing	A successful request acceptance is not identical to confirmed downstream processing; use diagnostics and reconciliation.

Google documents benefits such as a unified data model across advertising products and additional supported data sources. Those capabilities may matter for some architectures, but they don’t establish that a move will improve every advertiser’s measurement or campaign performance. Make the decision against your own requirements and implementation costs.

Decide whether the supported migration is required for your pipeline

Google says offline-conversion imports and enhanced-conversions-for-leads uploads were blocked in the Google Ads API starting June 15, 2026. It describes legacy access as limited to eligible developer tokens; this is not a blanket future migration date. If you have a legacy path, confirm current account/token eligibility and follow the Data Manager API migration guidance rather than assuming access continues. See Google’s offline conversion import notice and upgrade guide.

Before planning a cutover, answer a few practical questions:

1. What exactly do you upload today? Separate click-based offline conversions, enhanced conversions for leads, phone or sales-assisted outcomes, and any additional tag-sourced events. Keep a sample of real but sanitized payload shapes.
2. Which system owns each conversion action? A manager account, child account or partner link can change the required destination and authorization model. Write down the conversion-action owner for each event.
3. Which current API path can you use? The Google Ads API upload route for offline conversions and enhanced-conversions-for-leads has been blocked since June 15, 2026, subject to limited token-specific legacy access. Verify account eligibility and use the documented Data Manager API upgrade for new or migrating pipelines.
4. Can a controlled test avoid double counting? Before routing events from both systems to the same conversion action, isolate a test action or define a supported deduplication scheme. For offline-conversion events, Google documents transaction_id as optional and usable for deduplication; do not assume parallel uploads are automatically safe.

Treat this as an engineering change with a measurable acceptance test. Define the fields and events that must arrive, how long asynchronous processing may take, how duplicate events are prevented, and what constitutes a rollback before touching production.

Map the accounts and conversion actions before coding

A common migration failure is using the right event data with the wrong destination. Start with an inventory that ties every CRM stage to a Google Ads conversion action and its owning account.

Inventory field	Example of what to record
CRM event	Sales accepted, qualified opportunity, closed-won
Event definition	Explicit business rule for when the stage transition occurs
Google Ads conversion action	Exact current action and owning account
Destination account	Account that receives the event in the new request model
Event timestamp	Timestamp of the actual stage change, including source timezone and conversion to required format
Event value	Value and currency policy; whether fixed, estimated, or sourced from CRM
Matching identifiers	Click identifier, hashed first-party identifiers or other currently supported identifiers
Deduplication key	Stable event/conversion identity shared across retries and source systems
Consent handling	How the account’s documented consent state is represented in each event/request
Reconciliation source	CRM export or event ledger used to compare sent, accepted, processed and reported events

Use the API’s current schema and mapping guide for exact field names and types; the table above is an implementation inventory, not a JSON specification. In particular, don’t assume a similarly named field has identical semantics across both APIs.

Build a field-mapping worksheet

For each event type, take one real but sanitized example and map the existing fields to their new equivalents. Record the source system, transformation and validation rule for every field.

Event identity and timestamp

Use the CRM’s actual stage-transition timestamp where possible, rather than the time a nightly job happens to run. Store the source timezone and conversion rule so daylight-saving or delayed batches don’t silently shift events. Preserve the original CRM record ID and a stable event key in your internal ledger even if the destination API uses a different representation.

Conversion action and destination

Map the conversion action to the new destination as required by Google’s current docs. For multi-account or multi-action integrations, explicitly associate each event with the intended destination reference. Don’t infer account ownership from a login account alone; check the account that owns the conversion action.

Value and currency

Define what value means at each stage. A qualified opportunity value, closed-won revenue and a fixed score are not interchangeable. If value changes later, determine whether the event should be updated, retracted, or represented as a distinct event according to Google’s current API rules. Keep currency in a consistent, documented format and reconcile sample values against CRM records.

Identifiers and consent

Use only identifiers currently supported for the specific event and API use case. Google’s mapping guide lists identifiers unsupported in its offline and enhanced-conversion-for-leads contexts; don’t carry legacy fields forward just because the old upload accepted them. Follow Google’s requirements for formatting, hashing and consent, and never put raw personal data in public examples or diagnostic logs.

Design the validation and rollout plan

Google’s Data Manager event sending guide documents an event-ingestion workflow and a validation-only mode. Use it before applying events. Validation reduces avoidable mistakes, but it is not a substitute for proving production events reach the intended account, match the right conversions and reconcile with CRM outcomes.

Phase 1: Inventory and baseline

Export a time-bounded baseline from the old pipeline: event counts by stage, upload attempts, accepted/rejected results, conversion action, timestamp lag, match diagnostics where available, and CRM source counts. Keep the period long enough to include normal sales-cycle variation. Don’t use campaign-reported conversions as the only source of truth; compare with your CRM event ledger.

Phase 2: Map and validate

Build the destination and event mapping. In a non-production or validation-only request, test representative records for each event type: a normal record, missing optional data, a boundary timestamp, an unusual currency/value, and supported consent or identifier variations. Confirm the exact schema from current docs before sending.

Record the request ID and validation result. Fix errors at their origin—CRM extraction, transformation, destination mapping, or payload construction—rather than adding silent fallbacks that make invalid events look valid.

Phase 3: Controlled pilot

Choose one low-risk conversion action or a test account that cannot double count against the live production action. Compare the event ledger with the Data Manager diagnostics and Google Ads reporting after the documented processing interval. Test the round trip: CRM stage transition → event creation → ingestion request → processing diagnostics → conversion-action reporting.

Keep the legacy path available during the pilot if your architecture permits it, but don’t send duplicate production signals to the same action. If you can’t isolate a safe test, pause and design that isolation first.

Phase 4: Reconcile and expand

Set explicit acceptance criteria before the pilot. For example:

• Every eligible CRM event in the test cohort has one internal event-ledger record.
• The request is accepted and processing diagnostics show expected outcomes.
• No event is associated with the wrong account or conversion action.
• Duplicate retries don’t create additional counted conversions.
• Timestamp lag remains within your documented operational target.
• Differences between CRM events, API processing and Google Ads reporting are explainable and monitored.

Only expand when the evidence satisfies your criteria. “The API returned success” is not enough to declare the migration complete.

Failure modes worth testing deliberately

A common mistake is treating the Data Manager API’s validation-only request as proof that asynchronous processing works. Google says validation-only requests cannot be checked later through normal request diagnostics. After a production-eligible test request returns successfully, capture its request_id; Google recommends polling status with exponential backoff until each destination reaches a terminal state. Its diagnostics guide says processing can take up to 24 hours, sometimes as little as 30 minutes. Build this operational step into the pilot checklist so “request accepted” and “events processed” remain separate states.

Google’s error-handling guide distinguishes fast-fail structural or required-field errors from optional-field warnings and asynchronous processing errors. A required-field/structural problem can reject the whole request; other issues may appear as field_warnings or in per-destination diagnostics. If you batch events, test how your client reads each response and diagnostics, retries only suitable events, and alerts an operator. Avoid endless retries that resend a bad payload.

An accepted request is mistaken for processed conversions

Data Manager processing is asynchronous. Google’s diagnostics workflow says to capture the successful request ID and periodically retrieve status; processing may take up to 24 hours. Distinguish transport/request acceptance from processed events and from conversions that later appear in Google Ads reporting.

Destination ownership is wrong

A valid-looking event can still target an account that doesn’t own the conversion action. Verify ownership for each action and manager-account relationship before production. Make account mapping explicit in configuration rather than relying on a default.

Retried events are duplicated

Network timeouts can leave the sender unsure whether an event was accepted. Use an idempotent event ledger and the API’s supported deduplication fields and semantics. Reuse an event’s stable identity on retry; don’t generate a fresh ID just because the HTTP request is new.

CRM timestamps describe the batch, not the stage change

When offline events are uploaded in batches, the upload timestamp can differ substantially from the actual qualification or sale. Preserve the original stage-change time and document timezone conversion, delayed updates and backfills according to Google’s current limits.

Personal data leaks through logs

Request debugging can tempt teams to log full payloads. Redact or exclude personal identifiers, tokens and secrets; log request IDs, event IDs, field paths and non-sensitive status details instead. Restrict access and retention for any diagnostic store that legitimately contains sensitive information.

What B2B teams should monitor after migration

A lightweight operational dashboard should separate four layers:

1. CRM source: eligible stage transitions created and their timestamps.
2. Delivery: queued, sent, retried, rejected and accepted requests, with request IDs.
3. Processing: event diagnostics and processed/invalid counts after asynchronous processing.
4. Advertising outcome: conversion action totals and campaign reporting, with known reporting delays and attribution limits.

Track event lag by stage, not only an account-wide average. Raw lead events may be nearly immediate, while opportunity or closed-won stages naturally arrive later. A delay can be a sales-process property, a data-sync issue or a deliberate batch cadence; the dashboard should help you tell which.

Review a sample of records end-to-end weekly during rollout. Compare CRM stage, event timestamp, destination, value and matching data. If systems disagree, pause expansion until you identify whether the difference comes from eligibility rules, consent, mapping, deduplication, API validation, asynchronous processing or reporting latency.

Common migration mistakes

• Assuming Google Ads API uploads will keep working by default. Google says offline-conversion imports and enhanced-conversion-for-leads uploads were blocked in that API starting June 15, 2026; limited legacy allowlisting is token-specific. Check current access and follow the Data Manager API upgrade guide rather than planning around indefinite legacy access.
• Changing the upload path and conversion definitions at the same time. Keep the measurement question stable so you can attribute discrepancies to the migration.
• Testing only a happy-path record. Include edge cases and invalid payload behavior.
• Mixing processing layers. Structural/required-field errors can fast-fail ingestion, optional-field validation issues can appear in field_warnings, and asynchronous destination diagnostics can report processing outcomes. Inspect each rather than treating them all as “request rejected.”
• Counting API acceptance as conversion reporting. Follow processing diagnostics and reconcile the destination account’s reporting.
• Running both paths without deduplication. A parallel test can corrupt campaign signals if duplicate conversions reach the same action.
• Claiming transaction IDs always deduplicate the same way. Google documents them as optional for offline-conversion events and uses them for deduplication within a conversion action; some additional tag-conversion sources have a stricter requirement. Follow the exact workflow.
• Logging sensitive payloads to solve a temporary issue. Use redacted logs and controlled access.

The takeaway

Treat a Data Manager API transition as a measured system migration: inventory existing conversion actions, map every destination and field, test representative events with validation-only requests, verify asynchronous diagnostics, and reconcile processed events against the CRM before expanding. The goal isn’t simply to change APIs. It’s to preserve trustworthy B2B funnel signals—with fewer silent errors and a clear operator path when something goes wrong.