Key takeaways
- Import a small set of well-defined business outcomes instead of mirroring the CRM.
- Preserve identifiers and consent state lawfully from capture through upload.
- Use event IDs, timestamps, action definitions, and adjustment rules to prevent duplicates and contradictions.
- Monitor upload diagnostics and reconcile accepted events to the CRM source cohort.
01
Choose the event that deserves to influence delivery
A form submit is fast but often weak. Closed revenue is valuable but may arrive too late or too sparsely for campaign optimization. Map the funnel and choose separate conversion actions for materially different stages such as qualified lead and won customer. Google’s implementation checklist likewise recommends unique actions for distinct offline events.
Write an event contract: qualifying rule, owner, source object, event time, value, currency, revision behavior, and exclusions. “Qualified” cannot mean one thing in sales reporting and another in the upload job.
Swipe to compare every column
| Field | Operational rule | Why it matters |
|---|---|---|
| Event ID | Stable across retries | Supports deduplication and reconciliation |
| Event time | Actual business event with timezone | Prevents upload time from replacing outcome time |
| Value | Documented revenue or expected-value logic | Avoids training toward arbitrary scores |
| Consent | Captured and propagated for the intended use | Keeps processing aligned with the person’s choice |
02
Carry only the identifiers the integration needs
Preserve eligible click identifiers when available. For enhanced conversions for leads, Google documents normalized and hashed user-provided data as an additional matching input. Hashing is a transport requirement, not permission: the business still needs a lawful basis, appropriate notice, access controls, and retention rules.
Minimize the payload. An advertising endpoint does not need sales notes, free-text call summaries, or every CRM property. Map the smallest supported set required for matching, event definition, value, and diagnostics.
03
Design retries before the first failed row
Use idempotent event identifiers, bounded retry logic, partial-failure handling, and a dead-letter queue or review table. Store the request job, source record, response status, error reason, and retry count without logging raw personal data.
Decide how cancellations, refunds, stage reversals, and value corrections propagate. A pipeline that only adds positive events slowly teaches the platform an account history that the CRM itself no longer believes.
04
Reconcile cohorts, not dashboard totals from different clocks
Google notes that imported conversions can report against the original interaction date and take time to appear. A CRM may group the same event by close date. Compare a fixed source cohort through capture, eligibility, upload, acceptance, and reporting rather than expecting daily totals to match immediately.
Track matchable share, upload delay, accepted share, duplicate rate, correction rate, and value reconciliation. A rising conversion count is not proof the feedback loop is healthy if the accepted events are late, duplicated, or commercially weak.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
- Google Ads API: Manage offline conversions
- Google Ads: Enhanced conversions for leads implementation checklist
- Google Ads API: Monitor offline data diagnostics
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
