Google Ads Offline Conversion Upload template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

This is the file that closes the loop between Google Ads and your CRM: offline conversion uploads that tell Google which clicks became SQLs and closed-won revenue — not just which clicks filled a form. Once Google's bidding sees real outcomes, it optimizes toward customers instead of toward whoever loves submitting forms.

The format follows Google's documented click-conversion import as of July 2026, including its one structural quirk: the first line is a Parameters row declaring your timezone, and the real column headers sit on the second line. The example rows model the two uploads that matter most — a closed-won deal with revenue, and a zero-value SQL event for mid-funnel signal.

How to use it, step by step

1. Capture GCLIDs into your CRM first. Every ad click carries a gclid URL parameter. Your forms must write it to a hidden field so each lead record stores the click that created it — no GCLID, no upload. (Our UTM and attribution setup guides cover the wiring.)
2. Create the conversion actions in Google Ads. Under Goals → Conversions, create import-type conversion actions whose names exactly match your Conversion Name values ('Closed Won - CRM', 'SQL Created - CRM'). The name match is exact and case-sensitive.
3. Keep the Parameters timezone row intact. The first line declares the timezone all conversion times are interpreted in. Edit the value to your timezone; delete the row and the upload fails or shifts every timestamp.
4. Export outcomes from the CRM on a schedule. Weekly works for most sales cycles: every new SQL and closed-won with its GCLID, conversion time (after the click, in the declared timezone), and value for revenue events.
5. Upload and read the diagnostics. Goals → Conversions → Uploads takes the file directly, or schedule it from cloud storage. The results report lists rejected rows and why — expired clicks and name mismatches are the usual rejects.
6. Give bidding time, then judge. Value-based bidding needs conversion volume to learn. Judge the shift over weeks of consistent uploads, not days — and reconcile in our attribution reconciliation template monthly.

What each column means

Common mistakes to avoid

• Never capturing GCLIDs in the first place — the upload is only possible if lead records carry the click ID from day one.
• Deleting the Parameters:TimeZone row because it looks like a mistake — it's required syntax, not clutter.
• Conversion names that almost match the conversion action ('Closed Won CRM' vs 'Closed Won - CRM') — rows silently reject.
• Uploading conversions timestamped before the click or past the click's expiry window — both reject; export conversion time, not record-created time.
• Uploading once, seeing no immediate change, and abandoning the practice — the value is cumulative signal, not a one-shot boost.

Questions, answered

Why upload offline conversions at all?

Because form fills lie. Google optimizes toward whatever conversion it can see — feed it SQLs and revenue instead of raw leads, and smart bidding starts buying the clicks that become customers. It's the single highest-leverage attribution practice for lead-gen advertisers.

What if we use enhanced conversions for leads instead?

Enhanced conversions for leads matches on hashed email instead of GCLID and solves similar problems where click IDs are hard to carry. As of July 2026 both paths are supported; GCLID uploads remain the most direct where your CRM captures them. Many teams run both.

How far back can we upload conversions?

Within the click's conversion window (set on the conversion action — commonly up to 90 days). Beyond that window, uploads reject, which is why a weekly schedule beats a quarterly catch-up.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.