Offline Conversion Tracking Explained (Click → CRM → Sale)

For anything with a sales cycle (B2B, high-ticket, lead gen), the conversion that matters doesn't happen on the website. It happens weeks later, on a call or in your CRM. Offline conversion tracking closes that loop: it ties the closed-won deal back to the ad click that started it, so Google Ads can optimize toward revenue instead of raw form fills. The whole technique rests on one thing, capturing a durable identifier at the moment of the click and keeping it attached to the lead until the deal is done.

What offline conversion tracking is

The idea is simple even if the plumbing isn't: when someone lands from an ad, capture an identifier that can later be matched back to that click, carry it with the lead into your CRM, and when the deal closes, send that outcome back to the ad platform keyed on the same identifier. The platform reconnects the sale to the campaign, keyword and creative that earned it.

There are two primary types of identifier, and a complete setup captures both. The first is a click id (Google's gclid), read straight from the landing URL. The second is enhanced conversion data: the email or phone number the lead typed into your form, hashed before it leaves the browser. The click id is precise while it lasts; the hashed email is what keeps matching after the click id is gone.

Identifiers are the key

Every offline match comes down to one question: what identifier links this sale back to the click? Get the identifier right and everything downstream works. Lose it and the conversion is invisible, no matter how good your campaigns are. There are two families of identifier, and a resilient setup uses both.

Click IDs

Every paid click can carry an id in the landing URL. Google's gclid (plus gbraid / wbraid for iOS web and app traffic), Microsoft's msclkid, Meta's fbclid. It's precise, it points at the exact click. But it lives in a cookie, and that's its weakness.

https://example.com/landing?gclid=Cj0KCQ...AB

Enhanced conversion data

The second identifier is the first-party contact data the lead already gave you: their email, and optionally phone, name and address. Hashed with SHA-256 in the browser so the raw value never leaves the device, it becomes a privacy-safe key the platform can match against the account behind the click. It doesn't expire, it doesn't depend on a cookie surviving, and it's collected with consent. This is the identifier built for a cookieless world.

Why the click ID alone isn't enough anymore

It helps to be precise about what is actually breaking, because "cookieless future" gets thrown around loosely. Three separate forces shorten the life of a stored click id:

• Cookie lifetime caps. The gclid is persisted in a first-party cookie (_gcl_aw, written by the Conversion Linker). Safari's ITP caps script-set first-party cookies at 7 days, and in some cases 24 hours. A lead that converts a month later has no gclid left to match.
• Consent rejection. Under Consent Mode v2, if a visitor denies ad_storage you never write the gclid cookie at all. For those users the click id simply doesn't exist, so the only identifier you can still capture is the data they type into the form.
• Third-party cookie deprecation and signal loss. The broader move away from cross-site cookies, plus ad blockers and privacy browsers, means click-id coverage keeps shrinking. Planning around it now is cheaper than rebuilding later.

None of this breaks enhanced conversion data, because a hashed email isn't a cookie. It's captured at submit time, lives in your CRM record, and matches months later. That asymmetry is the whole argument: build on the identifier that lasts.

Importing conversions back

When a deal closes, the stored identifier goes back to the ad platform with the conversion name, time and value. You can key the import on the gclid (a standard offline conversion import) or on the hashed email (Enhanced Conversions for Leads). Same pipeline, different key, and the email-keyed path keeps working when the click id has expired.

• Manual upload: a CSV of identifier + conversion name + time + value.
• Scheduled import: from Google Sheets or your CRM on a recurring basis.
• Automated: a direct CRM integration (e.g. HubSpot or Salesforce → Google Ads), or the Google Ads API.

# gclid-keyed (classic offline import)
Google Click ID, Conversion Name, Conversion Time, Conversion Value
Cj0KCQ...AB, Qualified Lead, 2026-06-01 14:05:00, 500

# email-keyed (Enhanced Conversions for Leads, survives a lost gclid)
Email, Conversion Name, Conversion Time, Conversion Value
9b2c1f...e7a, Qualified Lead, 2026-06-01 14:05:00, 500

Measuring and reconciling

Offline conversions arrive late, so reports lag, a deal that closes in week six shows up against the click from week one. Expect the delay, and reconcile uploaded conversions against your CRM's closed-won count so you trust the numbers driving your bids.

Watch your match rate, the share of uploaded conversions the platform can tie back to a click. A low match rate almost always means a lost identifier: an expired gclid with no email to fall back on, or a hashed email that wasn't normalized the same way on both sides. It's the clearest signal that you need the durable identifier doing the heavy lifting.

Putting it together

A setup that survives the cookieless future captures both identifiers on every lead, stores both on the CRM record, and imports on whichever one still matches when the deal closes. Thegclid gives you precision while it lasts. The hashed email gives you durability for everything after. Lean on the second, treat the first as a bonus, and your offline conversions keep flowing no matter what the browsers do to cookies next.