Offline conversion tracking: sending CRM outcomes back to Google Ads

Offline conversion tracking is the layer that connects what happens in your CRM back to the Google Ads clicks that created those leads. It sits on top of your web tracking foundation (see Google Ads conversion tracking) and turns anonymous form fills into revenue signals the bidding system can use.

Why sending CRM outcomes back changes bidding behavior

When Google Ads only sees form submissions, automated bidding learns to maximize cheap form fills, not qualified pipeline. Per Google’s offline conversion import documentation, the platform can instead optimize toward later-stage conversions such as qualified leads, opportunities, or closed deals when those events are imported.

For Temper And Forge’s B2B clients, the campaign-level kill decision runs on ROAS from conversion volume, and for a lead business, that ROAS does not exist until CRM outcomes flow back into the platform. A form fill is not revenue; qualified leads, opportunities, and closed deals are. The offline layer is what lets Temper And Forge structure B2B accounts around acquisition strategy and intent verticals and then see which verticals pay; without it, bidding optimizes toward whoever fills forms, and the weekly ROAS read is fiction. Temper And Forge treats this as part of the tracking-before-spend requirement, with the same conservative posture, build the feedback loop first, then scale what the loop proves.

Google’s help content states that advertisers using first-party data alongside GCLIDs saw a median 10% increase in conversions versus standard offline imports, based on Google data. That uplift comes from giving the system more accurate, richer signals about which clicks drive valuable outcomes, not just raw volume.

A common misconception is that offline conversions show up on the day you upload them. Per Google’s reporting docs, imported conversions report by click or impression time, so a correctly working import looks like history rewriting itself as past days gain more conversions.

How GCLID-based offline conversion tracking works

GCLID is a URL parameter that Google Ads appends to ad click URLs when auto-tagging is enabled, and it identifies the campaign and click attributes for that visit. Google’s documentation states that GCLID is required for website conversion tracking and for GCLID-based offline conversion tracking, and it is case sensitive.

The standard capture pattern has 3 parts. First, a script on every page reads the GCLID from the URL and stores it, with Google’s sample using localStorage with a 90-day expiry. Second, every lead form includes a hidden GCLID field. Third, when the form submits, that hidden field value is stored with the lead in your CRM or lead database.

This hidden-field pattern ensures that the click identifier survives beyond the browser session and is available when the lead later becomes a qualified opportunity or a closed deal. Google’s help pages specify that they keep the GCLID for 90 days, so your storage and upload design must respect that window.

A frequent misconception is that you can upload conversions whenever the deal closes. In reality, Google’s documentation states that conversions after 90 days need an earlier conversion event uploaded within the window, and uploads older than the conversion window error, so you must plan your event definitions and upload cadence around that 90-day retention.

At a high level, the GCLID-based flow is:

For platform-specific field mapping and Data Manager configuration in Salesforce, see the Salesforce-focused guide. The same architecture applies to other CRMs that can store a GCLID field.

Enhanced conversions for leads and when to favor it

Enhanced conversions for leads is Google’s upgraded version of offline conversion import that uses user-provided data, such as email or phone, to supplement or replace the GCLID. Per Google’s help pages, the hashed email or phone is matched to website lead data and signed-in Google accounts, and Google recommends including GCLIDs whenever possible.

This path is useful when your existing CRM schema does not store GCLIDs, or when leads convert through channels where GCLID is not reliably present but you do have email or phone. A misconception is that offline tracking requires storing GCLIDs in the CRM; enhanced conversions for leads can match on hashed email or phone alone, so you can implement without CRM changes to store GCLIDs, although including them improves match quality.

Google’s documentation notes that using first-party data alongside GCLIDs produced a median 10% increase in conversions compared with standard offline imports, based on Google data. That is why the recommended configuration is hybrid: capture and store GCLID where possible, and also capture the user-provided identifiers needed for enhanced conversions for leads.

From April 2026, Google’s help content states that user-provided data flows through one unified enhanced-conversions setting across tags, Data Manager, and the API. That unification means you define your hashing and user data handling once, then reuse it across your offline and online lead flows.

Upload methods and how to choose among them

Google lists several import methods for offline conversions: Google Ads Data Manager, the Google Ads API, Zapier, and UI-based uploads from file, Google Sheets, or transfer over HTTPS or SFTP, with scheduled imports available. All of these methods must send the same core fields: a click identifier (GCLID or hashed user data), conversion name, conversion time, and optional value and currency.

Data Manager is Google’s connection layer for recurring imports from systems like Google Cloud Storage, Amazon S3, HTTP endpoints, SFTP servers, and Google Sheets. Per Google’s documentation, these connections import conversions from 90 days back on every run, and Salesforce and HubSpot direct connections import the last 14 days. For HubSpot-specific steps, see the HubSpot implementation guide.

The Google Ads API path uses the ConversionUploadService.UploadClickConversions method, which requires an enabled UPLOAD_CLICKS conversion action. Developers.google.com states that click-conversion user identifiers support hashed email and hashed phone only; address_info is not accepted and will error.

Zapier is a documented third-party integration that can send conversions and values in real time, supporting GCLID or hashed first-party data, and it requires a paid Zapier account. Google’s file import docs describe UI uploads from CSV or Google Sheets, as well as scheduled imports over HTTPS or SFTP, which are useful when you can generate a daily export from your CRM but do not want to build against an API.

Choice of method is primarily about engineering ownership and latency. If you have developers working in Google Ads integrations, the API or, from 2026, the Data Manager API is the most controllable. If you rely on marketing ops and CRM exports, scheduled file or Sheets imports through Data Manager are usually simpler. Zapier is suitable when your CRM has strong Zapier support and you want near real-time uploads without writing code.

Timing rules that cause upload failures

Google’s help pages document several timing rules that commonly break offline conversion imports. First, clicks less than 6 hours old will error with a “click too recent” message, so you must delay uploads for at least 6 hours after the click.

Second, a conversion cannot happen before the ad click, so you need to ensure your conversion time is not earlier than the recorded click time. Google recommends adding 1–2 days to the conversion time in some troubleshooting scenarios to avoid ordering issues, and they also advise waiting 4–6 hours after creating a conversion action before uploading to it.

Third, Google keeps the GCLID for 90 days, and their docs state that conversions after 90 days require an earlier conversion event uploaded within that window, while uploads older than the conversion window error. This is why the misconception that you can upload conversions whenever the deal closes is incorrect; you must design your event stages and upload cadence to fit within the 90-day GCLID retention.

Finally, processing is not instantaneous. Google’s documentation states that data can take 24–48 hours to fully process, with typical processing under 12 hours, and up to 72 hours for conversions keyed on GBRAID or WBRAID. Combined with the reporting-by-click-time behavior, this means you will see past days’ conversion counts change for 1–3 days after each upload.

Data Manager API migration and 2026 changes

Google’s enhanced conversions for leads documentation states that starting June 15, 2026, offline conversion imports and enhanced-conversions-for-leads uploads migrate to the Data Manager API and are blocked in the Google Ads API. This directly contradicts the misconception that the Google Ads API is the long-term home for these uploads.

The same documentation notes that from April 2026, user-provided data flows through one unified enhanced-conversions setting across tags, Data Manager, and the API. For implementers, this means new builds should plan around Data Manager as the long-term interface for offline conversions and enhanced conversions for leads, even if you are still using the Google Ads API in the interim.

Hashing and formatting rules for offline uploads

Google’s upload specs require a specific hashing and formatting process for user-provided data. The sequence is: normalize the input, UTF-8 encode it, hash with SHA-256, and send the result as lowercase hexadecimal with 64 characters.

For email, Google’s docs state that you must trim whitespace, lowercase the address, and for Gmail or Googlemail addresses, remove periods and plus-suffixes before hashing. For phone numbers, you must format them in E.164 before hashing. Country, state, city, and ZIP must not be hashed.

Scheduled uploads must pre-hash user-provided data, while manual one-time uploads through the UI can send unhashed data for Google to hash. This is why you need consistent normalization logic in your CRM export or middleware when you automate imports.

File imports also have strict format rules. Google’s documentation specifies a timezone parameter row, with ID form recommended to avoid daylight-savings errors, and the conversion name must match the conversion action’s spelling and capitalization exactly. Currency codes must use ISO 4217 format.

Google’s docs clarify that duplicate uploads with the same conversion action, time, and identifier are rejected, not double-counted, which corrects the misconception that duplicates double-count conversions. Combined with the reporting rule that conversions are attributed to the click time, not upload date, this means you can safely re-upload a batch if a previous import failed, without inflating metrics.

Temper And Forge’s practice for B2B clients is to treat this offline conversion layer as part of the tracking-before-spend requirement. The firm structures accounts around acquisition strategy and intent verticals, then uses CRM-fed ROAS from qualified leads, opportunities, and closed deals to decide which verticals to scale or kill, since form fills alone do not represent revenue.