Offline Conversion Tracking Playbook
Return qualified leads, customers and authoritative revenue to Google and Meta without duplicating events or teaching bidding systems from the wrong source.
Choose the business system of record first, then define one stable event contract and one deduplication key. A platform-accepted upload is a delivery result—not proof that attribution, consent or bidding quality is correct.
Use this resource when
1. Choose the authoritative business record
Start with the system that confirms the commercial outcome. For lead generation, that is usually the CRM stage-change record. For ecommerce, it is usually the order or commerce backend after cancellations, refunds and value are known. Do not use a second analytics export as the authority when it can inherit the same signal loss or duplication as the advertising tag.
- Lead generation: valid lead → qualified lead → opportunity → customer
- Ecommerce: order created → paid → fulfilled → adjusted or refunded
- Record the owner, source table, timezone and definition for every imported outcome
2. Select the 2026 Google ingestion path
Google now combines enhanced conversions for web and leads under one setting and can accept user-provided data from website tags, Data Manager and API connections. Google's May 2026 developer update makes Data Manager API the primary path for new offline-conversion imports. Audit an existing feed before migrating it; feature availability, account access and legacy eligibility can differ.
- Document the current connection and owner
- Confirm the destination conversion action
- Preserve click IDs where available
- Plan a rollback and overlap window without double counting
3. Build one event and consent contract
For each event define the business trigger, timestamp, value, currency, attribution identifiers, consent fields, destination action and retry behaviour. Google recommends continuing to include GCLID, GBRAID or WBRAID where available, alongside consented first-party identifiers. The applicable consent and privacy basis must be decided for the business and market; this playbook is not legal advice.
4. Make deduplication deterministic
Use a stable transaction or event ID that survives retries. Google's multi-source conversion guidance requires the same transaction ID when an additional source should update or deduplicate a conversion recorded by the website tag. For Meta browser-and-server events, use the same event name and event ID for the same business action. Never generate a fresh ID on every retry.
5. Validate delivery before changing bidding
Send a controlled, consented set from a non-production or approved test process where available. Record accepted, rejected, duplicate and unmatched outcomes, then reconcile them with the authoritative system by event ID and date. Processing success, match diagnostics and attributed conversions answer different questions; report them separately.
6. Reconcile lead generation and ecommerce differently
Lead-generation reconciliation follows stage timing, sales acceptance and eventual revenue. Ecommerce reconciliation follows order status, value, currency, refunds and customer type. Do not force the same delay, value rule or optimisation event onto both tracks.
- Lead generation: compare CRM events, upload status and platform attribution by cohort
- Ecommerce: compare backend orders, tag events, imported adjustments and platform values
- Explain expected attribution-window differences instead of forcing exact report equality
7. Monitor the production feed
Assign owners for zero-event days, stale timestamps, rejected rows, duplicate IDs, schema changes and unexpected value shifts. Google recommends timely uploads and identifies the business backend or CRM as the authoritative additional source. Review the contract whenever sales stages, checkout logic, consent handling or order adjustments change.
Apply this resource
Turn the event contract into a bounded implementation
Use the playbook to write the contract before commissioning an integration. The first question is which business outcome is authoritative, not which connector can send the most events.
Prepare a useful handover
- Bring the CRM or commerce stage definition, current event map and destination action.
- Separate website collection repairs from a new CRM, CAPI or server-side integration.
- Agree evidence for accepted, rejected, duplicate and awaiting-reporting records, plus a maintenance owner.
Continue with the resource: Reconcile analytics and order revenue.

Practical questions
Questions that change the decision
Should I import revenue or qualified leads?
Use both as observation when they are reliable, but optimise toward the deepest event that is defined consistently, arrives within a useful delay and occurs often enough for the chosen bid strategy. Lead-generation and ecommerce accounts can require different primary events.
Do I still need GCLID with enhanced conversions for leads?
Google recommends continuing to include GCLID, GBRAID or WBRAID where available. Consented first-party data can strengthen matching, but it does not make click identifiers irrelevant.
Does an accepted upload prove tracking is correct?
No. Acceptance proves the destination processed the row. You still need to reconcile event definition, identifiers, duplicates, value, consent and attribution against the authoritative business record.
When should I switch bidding to the offline event?
Only after the event arrives consistently through a normal business cycle, retries do not duplicate it, owners can resolve failures and the volume and delay suit the chosen strategy.
What changed in Google Ads during 2026?
Google unified enhanced-conversion settings and shifted new offline-import integrations toward Data Manager API. Existing implementations should be audited against the account's current settings and migration eligibility before changes are made.
Sources and platform documentation
Platform features change. These links point to the primary documentation used for the implementation details above.
