Move Offline Conversions to Data Manager API Without Losing the Audit Trail

The migration decision is not “Can we get an HTTP 200 from a new endpoint?” It is “Can we move a business-approved offline conversion from CRM evidence to the correct Google Ads conversion action, preserve a defensible audit trail, understand what the destination accepted or ignored, and then reconcile that evidence with advertising reporting without overstating what the upload proved?”

That distinction matters in September 2026. Google’s developer blog announcement (published May 15, 2026) restricted new adopters of Google Ads API offline conversion imports from June 15 while allowing established adopters to continue during migration. Google’s later deprecations table uses a more precise historical activity window than the announcement.

Separately, Google sunset developer tokens as the Google Ads API access mechanism on September 9, 2026 and moved access levels to Google Cloud projects. That is an access-management transition, not the same change as offline-conversion transport migration.

This guide is for paid-search leads, marketing analysts, CRM owners and integration engineers. It follows one synthetic CRM-qualified sale through destination mapping, identifier transformation, submission, asynchronous diagnostics and reporting reconciliation. The practical goal is a controlled pass, hold or escalate decision. Nothing in an accepted request, a Data Manager SUCCESS status or a received record count, by itself, proves that a conversion was attributed, reported, or used to improve bidding. Google’s own migration steps explicitly separate Data Manager diagnostics from Google Ads performance reporting.

Scope the migration without inventing a universal shutdown

Treat three dated facts as separate entries in the migration register. Google’s May announcement said developers without adoption or offline imports “between December 2025 and May 2026” would be affected from June 15, 2026. The Google Ads API deprecations page (updated September 10, 2026) later specifies December 17, 2025 through June 15, 2026 for the historical activity test. The sources therefore differ in precision; do not silently collapse them into one date range.

The same deprecations page says the historical restriction remains in effect even though developer tokens have since been deprecated. The developer token sunset guide (updated September 11, 2026) says developer tokens were sunset September 9 and Google Ads API access levels are now determined by the Cloud project that owns the OAuth credentials.

One current documentation conflict also deserves explicit treatment. The Data Manager upgrade comparison (updated September 15, 2026) still contains a comparison row saying a developer token is “Required” for the Google Ads API, while the dedicated Google Ads access guide says tokens were already sunset and are ignored when sent. For current Google Ads API access, use the dedicated access-management guide; record the comparison row as stale or unresolved context, not as an instruction to obtain a token.

Define the five states of a conversion record

A migration is easier to control when every team uses the same evidence vocabulary. The following five states are a proposed operating model, not five Data Manager API enums. Data Manager has its own destination statuses: PROCESSING, SUCCESS, FAILURE and PARTIAL_SUCCESS. Those should remain vendor states in the ledger.

“Partially ignored” is best treated as a processing-quality condition, not a sixth lifecycle state. Google documents a warning as a case where the record is not rejected but some portion of its data is ignored. A SUCCESS destination status therefore still requires warning review.

Business eligibility versus transport acceptance

The business definition must exist before serialization. For the worked example, use a wholly synthetic event: CRM-SYN-SALE-00017, hypothetically approved as a “Qualified sale” when a signed order reaches the CRM’s booked state. Its hypothetical value is USD 1,250 and event time is 2026-09-14T16:20:00+03:00. Those identifiers, values and dates are invented for this article; no upload was executed.

At transport time, Data Manager’s successful ingestion response contains an auto-generated requestId; optional invalid fields can also produce fieldWarnings. Google says diagnostics are available only for successful requests that were not validateOnly=true. A request receipt is therefore a traceable transport event, not certification of the sale, the match, or the reporting effect.

A useful rule is: business eligibility is decided upstream; transport acceptance is observed downstream. Never substitute one for the other.

Destination processing versus attribution and reporting

Data Manager processing is asynchronous. Google tells clients to retrieve status per destination until it reaches SUCCESS, PARTIAL_SUCCESS or FAILURE. SUCCESS means processing completed without errors, but warnings still need review; PARTIAL_SUCCESS means some records succeeded and others failed.

Attribution and reporting sit beyond that boundary. Google’s Data Manager upgrade steps (updated September 15, 2026) explicitly instruct implementers to verify results with both Data Manager diagnostics and performance reports in the Google Ads UI or API.

That creates a useful evidence question at every handoff:

•        Received? Show the successful response and requestId.

• Processed? Show destination status and diagnostics.

•       Partially ignored? Show warning reasons/counts and their business relevance.

•        Attributed? Show the agreed Google Ads conversion metric and action.

•        Reported/reconciled? Show the cohort definition, time window, value rules and discrepancy disposition.

Freeze conversion definitions before moving the transport

Do not use a transport migration as an excuse to redefine the conversion. Changing the CRM milestone, value rule, conversion action, goal configuration and API route together makes a discrepancy impossible to localize. Keep SEO and SEA measurement foundations as background; this migration ledger should instead preserve the exact business event that the existing pipeline meant to send.

For each conversion action, approve a compact “conversion contract” before code changes begin. Data Manager maps the old Google Ads conversion_date_time to event_timestamp; JSON uses RFC 3339. It maps conversion_value directly to conversionValue as a currency value, not micros, and currency_code to currency.

Proposed control: freeze this contract for the pilot and cutover window. Any intentional business-definition change should get a different contract version and an explicit evaluation plan. That is a local governance rule, not a Google product requirement.

For the synthetic sale, the payload boundary begins only after the CRM has asserted eligibility under the frozen contract. The integration may then transform identifiers and map the event, but it must not silently recalculate whether the sale “counts.” This keeps marketing’s conversion meaning visible while engineering changes the transport.

Map accounts, projects and destination identifiers

The most expensive mapping error is often not a malformed email; it is a perfectly formatted event sent toward the wrong account or conversion action. Google’s Data Manager send-events guide (updated September 15, 2026) states that for Google Ads offline conversions the operatingAccount must be the Google Ads account that owns the conversion action. The productDestinationId must be the ID of a conversion action whose type is UPLOAD_CLICKS; the UI source is “Website (Import from clicks).”

Build a source-to-destination ledger before making a production request.

The Data Manager field mappings guide (updated September 15, 2026) is particularly important for legacy migrations: the old customer_id maps to the destination operating_account, but the required account may differ from the customer ID used in legacy Google Ads API requests. The conversion action maps to a numeric product_destination_id.

Operating account, login account and conversion action

Do not assume the account running the campaign owns the action. Data Manager explicitly removed one legacy convenience: the Google Ads API could accept a parent or descendant account around the conversion customer in some cases, while Data Manager requires the conversion customer itself as operating_account.

For a direct advertiser using manager credentials, Google’s destination documentation shows the child/client as operating_account and the manager as login_account. For a data partner, the send-events guide defines a distinct DATA_PARTNER login path and may require linkedAccount when the partner link is through a parent. Keep those two architectures separate.

Proposed negative test: in a nonproduction/approved test, create a validation-only variant with an intentionally wrong owner mapping. The goal is to prove that your test harness can distinguish mapping failure from the correct path without executing a conversion. Do not assert a specific error code unless your authorized environment actually returns it; validateOnly=true validates but does not execute, and it produces no later diagnostics.

Historical allowlists versus current API access

Preserve three separate pieces of access evidence: legacy offline-import eligibility, current Google Ads Cloud-project access, and Data Manager authentication/destination access.

Google’s historical UploadClickConversions restriction is still listed, even after developer-token sunset. Current Google Ads API access levels belong to the Cloud project used for OAuth credentials. Data Manager, meanwhile, requires its API to be enabled in a Cloud project and uses the Data Manager OAuth scope; API keys are not an authentication option.

The Data Manager API access setup guide (accessed September 16, 2026) says user-account and service-account authentication are supported and identifies https://www.googleapis.com/auth/datamanager as the relevant scope. A new integrator should therefore not be told to obtain a legacy developer token.

Escalate when the same payload works under one authorized project/account path but not another. That pattern points first to access or destination context, not to normalization.

Normalize identifiers without corrupting the matching inputs

Offline conversion normalization is field-specific. Google’s user-data formatting guide (updated September 15, 2026) separates formatting, whitespace handling, SHA-256 hashing and encoding. Gmail/Googlemail addresses have rules that do not apply to other domains: remove dots before @ and strip the plus suffix for Gmail/Googlemail; for other domains, preserve dots and plus signs while lowercasing.

The phone rule requires E.164 formatting with +, country code and digits; JSON timestamp fields use RFC 3339 and accept offsets. Hex output is case-insensitive while Base64 is case-sensitive.

This is where general backend API integration foundations help with deterministic transforms and tests, but the Google field rules must remain the source of truth.

Proposed control: test the pre-hash normalized value in disposable fixtures, then assert only the digest/encoding shape in production telemetry. Never print real customer identifiers or production hashes merely to debug the migration. Hashing is a transformation required for specified user identifiers; it is not, by itself, evidence of consent, anonymization, lawful use or permission to retain data. Those are separate governance questions.

Also resist “hash everything.” Google explicitly documents fields that are not hashed, including IP data in its relevant structure, and the event timestamp is a timestamp, not an identifier to hash. Apply only the transformation required for each field.

Design a privacy-conscious conversion evidence ledger

A useful CRM conversion audit trail should let an authorized reviewer reconstruct what was intended, what representation was sent, where it was sent, what Google reported about processing, and what later reporting showed, without turning operational logs into a duplicate customer database.

The ledger below is a proposed local design, not a Data Manager schema.

Google’s REST ingestion response exposes the request identifier as requestId and row-level fieldWarnings; the diagnostics documentation and proto-style mappings render the same correlation concept as request_id. Later diagnostics are queried by that request ID and return status separately for each destination. Those documented identifiers make a correlation ledger possible, but Google does not define your retention period or access model for the CRM side.

Proposed privacy control: keep customer-source records in the CRM under its existing retention/access regime; keep integration telemetry in a narrower operations store with only the evidence required for replay, diagnostics and audit. Give production support access to the evidence ledger, not blanket access to raw customer profiles.

A hash should not become a retention loophole. The fact that Google requires SHA-256 for email and phone formatting does not establish that a hashed value is non-personal for your jurisdiction, risk model or contract. Record the privacy reviewer’s decision and minimize what the integration needs.

For the synthetic sale, the ledger would contain CRM-SYN-SALE-00017, the hypothetical action and owner IDs, and a payload-version digest. A real implementation would add the returned requestId only after a non-validation request. This article invents no production requestId and reports no executed test.

Submit a bounded pilot with explicit replay ownership

Data Manager uses a different request and error model from legacy UploadClickConversions. Google’s migration guide says Data Manager is fast-fail: if any field in an IngestEventsRequest fails validation, the whole request is rejected, rather than using the Google Ads API’s partial-failure model. The events.ingest REST reference (accessed September 16, 2026) allows at most 2,000 Event resources in one request.

That does not mean “send 2,000 every time.” Batch size is an operational choice within the documented limit. For a migration pilot, choose bounded cohorts that can be traced and repaired.

A robust pilot sequence is:

1.       Proposed: select synthetic records or an explicitly approved, minimized test cohort under the frozen conversion contract.

2.       Run validateOnly=true to catch request validation problems without executing the events. Google says validation-only requests are validated but not executed and only errors are returned.

3.       Obtain human approval to switch to a real submission for the bounded cohort.

4.       Have one accountable sender write the source watermark and local batch ID before sending.

5.       Persist the successful response requestId and any immediate fieldWarnings.

6.       Hand the request ID to the diagnostics process rather than re-sending because “nothing appeared yet.”

For broader patterns around integrating external APIs reliably, retries and failure isolation matter, but this pipeline needs conversion-specific replay controls.

The following is pseudocode for local correlation only. It is not a Data Manager request schema and it does not claim vendor idempotency:

# PSEUDOCODE: local state only; does not call or change Google services.
batch = reserve_batch(source_watermark, contract_version)

for event in approved_events:
    assert event.source_id not in local_completed_events
    batch.add(event.source_id, payload_digest(event))

response = data_manager_submit(reviewed_payload)   # actual API call implemented from current docs
record(batch.id, response.request_id, response.field_warnings)
mark(batch.id, "submitted_not_yet_reconciled")

Google documents transactionId as an optional unique identifier for the event in the generic reference, and the offline-conversion send-events table marks it optional for this use case. The sources inspected here do not establish a general idempotency guarantee for replaying the same offline event. Therefore, offline conversion replay controls should be local and conservative unless separate, current product documentation verifies deduplication behavior for the exact use case.

Avoid uncontrolled dual production uploads. A “backup sender” that posts the same source event through a second path can create an ambiguity you may not be able to unwind safely.

Read asynchronous diagnostics as an operating process

A successful submission is the start of asynchronous reconciliation, not the end. Google’s Data Manager diagnostics guide (updated September 15, 2026) says a successful request has status code 0/OK/HTTP 200, returns a request ID, and becomes eligible for diagnostics only when it was not validation-only. Google recommends waiting 30 minutes before the first status retrieval.

Processing can take up to 24 hours, although some requests may complete in as little as 30 minutes. Google gives an example backoff configuration that starts at 30 minutes, multiplies delay by 1.3, caps the delay at 60 minutes, and uses a 24-hour maximum total time, with jitter recommended. These are vendor polling guidelines, not an attribution service-level agreement.

Google reports status per destination. Persist one row per request-destination pair. A single green request-level dashboard that hides a second destination’s partial failure is an operational anti-pattern.

When to poll and what terminal status proves

Keep ingestion transport retries and status polling as different state machines.

A failed HTTP submission is a transport/request problem: inspect the returned error and decide whether it is safe to retry. A successful submission with PROCESSING is not a reason to submit the conversions again; it is a reason to poll the existing request_id. Google specifically says to send a separate status request for each successful request ID and poll until every destination is terminal.

Proposed local escalation rule: use Google’s 24-hour maximum processing guidance as the outer diagnostic window, then escalate any request that still lacks a documented terminal destination state rather than silently extending polling or replaying. The 24-hour figure is documented; “escalate rather than replay” is the local control.

Validation-only requests sit outside that process. Because Google says diagnostics can only be retrieved for successful requests that do not have validate_only=true, do not create an operations ticket expecting a later destination status for validation-only testing.

Warnings, partial failure and misleading record counts

Consider a hypothetical two-destination test; these counts and outcomes are invented and are not observations from a real execution.

The last caution matters because Google documents warning/error information as lists of reason/count objects. It does not state in the diagnostics guide that all reason buckets are mutually exclusive at record level. Proposed safe accounting rule: never add reason counts to derive a unique-person failure count unless the API response or another current reference explicitly establishes that exclusivity.

For event ingestion, the documented record_count includes both successful and failed records. Match-rate fields described elsewhere on the diagnostics page belong to audience-member diagnostics, not event-ingestion status. Do not transplant audience match-rate concepts into Google Ads offline event diagnostics.

Repair rejected inputs without replaying every success

Repair starts by classifying the failure layer. Do not respond to every anomaly with “resend the batch.” Data Manager’s fast-fail validation model, asynchronous destination processing and absence of a verified general replay-idempotency guarantee require more disciplined recovery.

Google defines a warning as data being partially ignored without rejecting the record and an error as the record being completely rejected. The diagnostics guide documents aggregate reason and record counts; it does not document a per-record rejected customer identity list in that destination-status section.

That limitation changes recovery. If your local batch ledger can deterministically isolate records from immediate field-path warnings or from pre-submit validation, repair those records. If asynchronous processing gives only aggregate error counts and you cannot identify the specific rejected source rows, say so. Narrow the next approved repair batch using the strongest available partitioning evidence; do not invent a rejected person.

A proposed remediation ledger should record original local batch ID, source-event IDs included, failure layer, vendor reason, mapping/config version, repair change, approver, new submission ID and whether prior records were known successful, known failed or unknown. “Unknown” is a legitimate state and is safer than pretending diagnostic detail exists.

Reconcile with Google Ads without promising exact parity

Google Ads conversion upload reconciliation must compare like with like. The ingestion pipeline asks whether Data Manager accepted and processed the event. Google Ads reporting asks whether conversions appear under a specific conversion action, metric definition and reporting window. Those are related but different systems.

Google’s conversion reporting guide (accessed September 16, 2026) says conversion-action metadata can be queried from the conversion_action resource, and conversion metrics can be segmented by conversion_action. It also warns that conversion performance data is not available instantly and that all-zero rows may not be returned.

For teams already reasoning about Performance Max reporting boundaries, keep channel/campaign interpretation separate from source-event ingestion health.

A current, documented Google Ads Query Language example for a read-only campaign-level reconciliation is:

SELECT
  campaign.name,
  segments.conversion_action,
  metrics.conversions,
  metrics.conversions_value
FROM campaign

Prerequisites: authorized Google Ads API reporting access and an explicitly chosen date scope in the surrounding request/reporting process. This query changes no advertising state. Google publishes this field combination in its current conversion-reporting documentation.

Do not treat the query as a row-level receipt for each CRM sale. It returns aggregated performance metrics. Build the reconciliation around definitions:

A mismatch is not automatically “attribution latency,” and processing latency is not a universal excuse for report differences. First establish that both sides use the same conversion contract, action, window and value definition. Then classify the residual.

Work a 1,000-record hypothetical pilot

This 1,000-record exercise is invented to demonstrate bookkeeping. It is not a test that was run, not a match-rate benchmark and not evidence of expected performance.

Assume 1,000 synthetic or otherwise approved source events enter the migration review. The local ledger deliberately uses mutually exclusive states:

The arithmetic 900 / 1,000 = 90% is a hypothetical local evidence-completion measure. It says only that 900 source records reached the locally defined “cleared” state. It says nothing by itself about Google match rate, attribution rate, incremental revenue, bidding improvement or return on investment.

Within the documented Data Manager request limit, 1,000 events could fit in one request because the REST reference currently permits at most 2,000 events per request. That is not a recommendation to use a 1,000-event batch. Smaller local batches may improve fault isolation under a fast-fail validation model.

Follow one synthetic record, CRM-SYN-SALE-00017, end to end: business-approved under contract v1; identifiers normalized with the applicable field rules; mapped to the verified conversion-action owner; included in an approved batch; successful submission correlated by the returned request ID; per-destination diagnostics reviewed; and only later compared with the chosen Google Ads conversion report. At every stage, the evidence stops where the next system begins.

Pilot decision: PASS only when the cleared cohort is understood and the remaining 100 records have explicit quarantine, waiting or repair ownership. HOLD if unknown replay exposure remains. ESCALATE when account/project access or undocumented product behavior blocks a safe decision.

Cut over with a reconciliation window and stop rules

Cutover is a routing change, not a celebration of a green API call. The aim is to move one source of truth from the legacy sender to Data Manager while preserving enough overlap evidence to prove that source coverage was neither dropped nor unintentionally duplicated.

A proposed staged plan is:

1.       Freeze conversion-contract version and source watermark.

2.       Complete the bounded pilot and close access/mapping issues.

3.       Define a cutover watermark such as “events committed after source sequence X go only to Data Manager.”

4.       Disable or drain the legacy production sender according to that watermark.

5.       Audit any intentional overlap cohort by source event ID.

6.       Reconcile Data Manager destination evidence and Google Ads reporting on an agreed schedule.

7.       Keep a bounded repair path with one replay approver.

Rollback must be described precisely. In this operating model, rollback means reviewed routing of future eligible events back to an approved sender, if that sender remains authorized. It does not mean that previously imported conversions are automatically deleted or reversed.

Do not assume legacy conversion-adjustment, retraction or deduplication methods have direct Data Manager equivalents. The sources used for this migration procedure establish sending, mapping and diagnostics, but not a blanket feature-parity promise for reversal. Before modifying previously imported data, obtain current, use-case-specific Google guidance and document the action separately. That unresolved boundary is safer than inventing an adjustment command.

Assign business and engineering ownership

A conversion pipeline fails organizationally when everyone can send and nobody owns the meaning. The responsibility model should put the business definition, CRM truth, API transport and privacy decision in different reviewable hands. For a broader discussion of marketing and analytics responsibilities, keep this table as the migration-specific operating split.

Proposed control: no role can unilaterally declare the migration complete. The campaign owner can validate business meaning, but cannot turn HTTP 200 into attribution evidence. The engineer can prove destination processing, but cannot redefine the sale. The analyst can reconcile reports, but cannot infer that a hashed identifier settles privacy obligations.

To strengthen the paid-search and measurement foundations beneath this specialist integration, review Refonte Learning’s SEO & SEA Mastery Program, which lists Google Advertising Fundamentals and Analytics and Performance Tracking in a three-month curriculum requiring 12–14 hours per week.

The program page also says no prior experience is required while separately listing an admission prerequisite of working toward a bachelor’s or higher-level degree; those statements should remain distinct rather than being flattened into “open to everyone.” It states that successful completion offers a Training Certificate and Certificate of Internship.

Approve the migration only when the evidence is complete

A migration should end in an explicit decision record, not an impression. The minimum pass condition is that business meaning, account/action mapping, transformation, submission correlation, destination diagnostics, replay exposure and reporting reconciliation are each evidenced at the level they actually prove.

The checklist before PASS should answer: Is the operatingAccount the actual conversion-action owner? Is the action UPLOAD_CLICKS for this offline-click use case? Are login/partner relationships mapped to the correct path? Are email/phone normalization tests field-specific? Is validation-only evidence separated from real submission evidence? Is every real request ID linked to per-destination diagnostics? Are warnings reviewed even on SUCCESS? Is reporting evidence kept separate from ingestion evidence?

Use this proposed 30-day follow-through schedule after cutover: days 1–3 review every migration batch and destination; day 7 sign the first cohort reconciliation; day 14 review repair/replay exceptions and access changes; day 21 sample ledger-to-CRM traceability; day 30 obtain campaign-owner, CRM, engineering and privacy sign-off or reopen the migration. These are local control points, not Google-prescribed timings.

Did June 15 stop all imports? No. Google’s May 15 announcement said new adopters would be blocked from June 15 while established adopters could continue during migration. The September deprecations table narrows the historical activity test to December 17, 2025 through June 15, 2026 and says the restriction remains effective. Because the two sources express the historical window differently, verify the specific integration’s authorized behavior rather than calling June 15 a universal end-of-service date.

Does a request ID prove attribution? No. Data Manager returns requestId after a successful ingestion request and uses it to retrieve diagnostics. Google’s migration steps separately require performance-report verification. The request ID proves correlation to an accepted ingestion request, not that the event was attributed or appeared in a Google Ads metric.

Do warnings matter on SUCCESS? Yes. Google defines SUCCESS as destination processing completed without errors and explicitly says to check warnings. A warning means the record was not rejected, but part of its data was ignored. Whether that ignored part matters to your business acceptance rule requires review.

Is a second sender a safe fallback? Not by default. The current sources inspected here do not establish a blanket idempotency or cross-sender deduplication guarantee for replaying Google Ads offline events through Data Manager. Treat dual sending as duplicate-risk until the exact behavior is verified for the use case. A safe fallback is a reviewed routing decision with source watermarks, one replay owner and documented overlap, not an automatic second POST.

The migration is approved when the organization can show where each conversion record is in the evidence chain and where its knowledge stops. That is the standard that prevents three costly category errors: calling receipt “processing,” calling processing “attribution,” and calling attribution “business impact.” A Data Manager API offline conversion migration is controlled when those boundaries remain visible after the last legacy sender is turned off.