Offline Conversion Import

Offline conversion import, defined

Google Ads describes offline conversion import as a way to measure what happens away from the advertising surface after an ad produces a click or call ^{[google_ads_offline_imports]}. A downstream event is sent back through a supported import method and associated with the earlier interaction when the required matching data is available. The documented capability is the import path; the source does not establish that any specific business has implemented it or that every submitted event will match.

The important systems distinction is between the event the platform observed first and the event the business confirmed later. A form submission, connected call, or lead record can occur near the ad interaction. A qualified stage, signed agreement, completed job, paid invoice, or other downstream state may be written later in another system. The tracking and attribution systems owner explains why those levels of evidence must stay separate ^{[fp_tracking_attribution_owner]}.

What must exist before an import is meaningful

Current Google Ads guidance also points new implementations toward enhanced conversions for leads and describes the use of hashed user-provided data alongside offline conversion data ^{[google_ads_offline_imports]}. That is current vendor guidance, not a universal architecture requirement. The appropriate method depends on the platform, the event, available matching data, permission boundaries, and the systems that hold the first-party record.

The identifier has to survive the path

An import cannot repair an identity chain that never existed. Where an earlier interaction and a later record need to be associated, a supported key or matching input has to be captured, retained through the intervening handoffs, and available when the downstream event is sent. If the key disappears between the website, intake, CRM, delivery system, and ledger, the import has no deterministic join to recover from the outside.

That makes offline conversion import adjacent to a tracking gap but not identical to one. The gap is the missing or inconsistent evidence boundary. The import is one possible platform return path after the internal event and matching data have been verified. A cross-system identity join is the broader internal data operation that may be required before any platform upload is considered.

Imported, observed, and modeled records are different evidence classes

An observed platform event records an interaction the platform could link directly. An imported event is supplied later from another system. A modeled conversion is estimated where the platform does not have an observable link ^{[google_ads_conversion_modeling]}. A combined report may be useful operationally, but its rows do not all have the same provenance, so a financial or causal conclusion still requires the first-party source and operator review.

A bounded implementation review

1. Name one downstream event and the system that authoritatively records it.
2. Write the event definition and its allowed state transitions before choosing an import method.
3. List the matching data available at the original interaction and confirm how it survives each handoff.
4. Review permission, retention, suppression, and data-handling requirements with the accountable owners.
5. Test a bounded cohort and reconcile accepted, rejected, unmatched, duplicated, adjusted, and late records.
6. Keep the first-party reconciliation beside the platform report and state what remains unknown.

What an offline conversion import does not prove

• It does not prove that advertising caused the downstream event.
• It does not guarantee complete matching, accurate attribution, or identical totals across systems.
• It does not establish that a submitted value is final, realized, or financially reconciled.
• It does not establish a lead, conversion, revenue, ROI, ROAS, traffic, ranking, or AI-visibility result for any business.
• It does not replace account access, internal verification, operator review, or applicable privacy and consent decisions.

Where to continue

Use the Tracking, Attribution & Measurement Systems domain for portfolio context, the canonical tracking and attribution guide for the measurement model, tracking gap for the evidence break, and modeled conversion for the estimation boundary. A Revenue Scan can frame public-surface questions; it cannot inspect or authorize an account import ^{[fp_revenue_scan_boundary]}.