
Offline conversions are CRM events, such as a lead qualifying or a deal closing, sent back to the ad platform that produced the click, so its bidding learns from revenue instead of form fills. In practice you capture click IDs and contact details when the form is submitted, store them on the CRM record, and when the deal moves stage, send the event and its value to Google Ads (offline conversion import and enhanced conversions for leads) and to Meta (the Conversions API). GA4’s Measurement Protocol is useful for reporting, but it is not the main route for training ad bidding.
This is the core of how we run paid advertising at Goodish, a senior team in Novo mesto and Maribor working mostly with US fintech, SaaS and franchise companies. Below is the method as we build it in HubSpot, Pipedrive and Zoho.
Why do ad platforms optimize for the wrong event?
Because they learn from whatever you count as a conversion. If that is a form fill, Google’s Smart Bidding and Meta’s delivery system find more form-fillers, including students, competitors and people who never answer the phone. In B2B, where a bad lead wastes a salesperson’s afternoon, that is expensive.
The browser-side signal has also been getting weaker for years. The iOS 14 era was the turning point: from iOS 14.5, apps had to ask permission before tracking people across other companies’ apps and websites, and Meta responded by limiting how many conversion events each website domain could prioritize for a time. Safari shortens the life of script-set cookies, ad blockers stop known tracking domains, and cookie banners leave some visitors unmeasured. The pixel still matters, but it sees less.
The platforms’ own answer is first-party data sent from your server: what happened in your CRM, matched to the ad click.
Which CRM stages should you send?
Send one early stage that happens often enough for bidding to learn from, and closed-won with its real value. Skip the stages that only add noise.
| Stage | HubSpot | Pipedrive | Zoho CRM | Send it? |
|---|---|---|---|---|
| Form submitted | Contact created | Lead or person created | Lead created | Already tracked on the website; no need to resend |
| Qualified | Lifecycle stage MQL or SQL | Lead converted to a deal | Lead converted, or a qualification field set | Yes, as the main bidding signal for long sales cycles |
| Closed-won | Deal stage “Closed won” | Deal marked won | Deal stage “Closed Won” | Yes, with the real deal value |
| Disqualified or lost | Lead status or “Closed lost” | Deal marked lost | Deal stage “Closed Lost” | Not as a conversion |
Two rules make this work. Agree on what “qualified” means with sales and make it a field, not a judgment call; if the definition drifts, the bidding drifts with it. And keep primary conversion actions few, because each extra one dilutes what bidding optimizes for.
What do you need to capture at the form?
A platform can only credit a deal to an ad if you tell it which click or which person it was, so capture identifiers on the first visit and carry them through to the deal.
| Identifier | Platform | Where it comes from |
|---|---|---|
gclid |
Google Ads | Added to the landing-page URL by auto-tagging |
gbraid / wbraid |
Google Ads | Used on some iOS traffic in place of gclid |
fbclid, stored as fbc |
Meta | Added to the URL on ad clicks; kept in the _fbc cookie |
fbp |
Meta | The Meta pixel’s browser ID cookie (_fbp) |
| Email and phone, hashed | Google Ads and Meta | The form itself, normalized and hashed with SHA-256 before sending |
| CRM record ID | Meta (external_id) and your own matching |
The CRM |
GA4 client_id |
GA4 only | The _ga cookie |
In practice:
- Persist the IDs. Visitors rarely convert on the landing page, so store click IDs in a first-party cookie on arrival and read them into hidden form fields.
- Copy them to the deal. The click ID usually lands on the contact or lead, but the stage change happens on the deal, so copy the fields across when the deal is created.
- Normalize before hashing. Trim spaces and lowercase emails; format phone numbers with the country code. A wrongly normalized hash simply fails to match.
Server-side tagging makes capture more reliable; see our server-side Google Tag Manager guide.
How do you send conversions to Google Ads?
Google offers two matching methods, and we usually use both:
- Offline conversion import matches on the click ID: you upload the
gclid(orgbraid/wbraid), the conversion action, the time and the value. - Enhanced conversions for leads matches on hashed email or phone captured when the form was submitted, so a conversion can still be credited when no click ID was stored.
Google has been steering advertisers toward treating these as one setup, with the click ID and hashed contact details in the same upload. How the data gets there depends on the CRM: HubSpot’s ad integrations can sync lifecycle-stage changes to Google Ads, Zoho CRM has its own Google Ads integration, and for Pipedrive, or wherever the native option is too blunt, we build the upload in n8n or a small script against the Google Ads API.
Settings that matter on the conversion action:
- Count one conversion per click for lead stages, and every conversion for closed-won only if repeat purchases are real.
- Set the click-through window to match your sales cycle, up to Google’s maximum of 90 days.
- Mark the stage you want bidding to target as primary; keep the others as secondary, for reporting.
- If you advertise to people in the EU or UK, send consent status with the upload.
How do you send conversions to Meta?
Through the Conversions API, which receives events from your server instead of the browser. Meta has retired its separate Offline Conversions API, so CRM events now go the same way as server-side website events.
Each event carries its name and time, its source (your CRM), the matching data (hashed email and phone, fbc, fbp, external_id) and the value. For leads from Meta’s instant forms, Meta’s lead ID is the strongest match, and conversion leads optimization can then deliver toward the leads that move furthest through your CRM.
Three things to get right:
- Speed. Meta accepts events only within a short look-back period; send stage changes within hours, not in a monthly batch.
- Deduplication. When the pixel and the server both report the same website event, give them the same event ID so Meta counts it once.
- Match quality. Events Manager scores each event’s match quality; more correctly hashed identifiers mean more conversions credited.
HubSpot’s ads tool can also sync lifecycle stages to Meta; for Pipedrive and Zoho it is typically a server-side integration, part of our CRM and workflow work.
Where does GA4’s Measurement Protocol fit?
It sends events from your server into GA4, so offline milestones such as “deal won” can sit in the same reports as website sessions. It is a reporting tool, not a way to train Google Ads or Meta.
Where it fits: reporting closed deals and qualified leads alongside web behavior, joined to the visitor’s history through the stored client_id, or across devices through a user_id (a non-personal internal ID, such as the CRM record ID). Events can be backdated only briefly (Google currently allows about three days), so it suits stages that happen soon after the visit.
Where it doesn’t: it does not carry the ad click, so it is a weak path for crediting a deal to a Google Ads click weeks later; use Google Ads’ own imports for that. It sends nothing to Meta. And Google describes it as a way to augment browser data, not replace it: without a valid client_id or user_id, events arrive orphaned.
The client_id is per browser and disappears with the cookie; the user_id lasts as long as your system recognizes the person. Our post on cross-device identity in GA4 goes deeper on user_id.
How quickly do conversions need to arrive?
Faster than most CRM exports run:
| Destination | Timing constraint | What we do |
|---|---|---|
| Google Ads | The conversion must fall inside the conversion action’s click-through window (90 days at most) | Upload daily; use an early stage as the primary signal when deals take longer than the window |
| Meta Conversions API | Short look-back period for events | Send on the stage change, within hours |
| GA4 Measurement Protocol | Backdating limited to a few days | Use for stages that happen soon after the visit, or for reporting only |
The window is why early stages matter. If deals close four months after the first click, a closed-won upload to Google Ads arrives too late to count; sending “qualified” within days gives bidding something to learn from.
What value should each conversion carry?
Closed-won carries the real deal value (contract value or first-year revenue, applied consistently, in the right currency). Earlier stages carry an expected value: average deal value multiplied by the share of that stage that eventually closes, taken from your CRM history.
Never send pipeline value as if it were revenue; inflated values teach bidding to chase deals that never close. For the arithmetic, see our post on what a good cost per lead is.
How do you check that it works?
Offline conversion setups tend to break quietly: a form gets redesigned, a CRM field is renamed, and uploads stop matching. Our QA list:
- Capture rate. The share of paid leads in the CRM with a click ID or email stored. A low share means the form or cookie is losing them.
- Diagnostics. Rejected and unmatched uploads in Google Ads, and Event Match Quality in Meta’s Events Manager; read them weekly at first.
- Deduplication. Platform totals that suddenly double usually mean the pixel and the server are both counting.
- A test lead, pushed through the whole journey to closed-won, before launch and after every CRM change.
- Monthly reconciliation. Closed-won deals from paid traffic in the CRM against what each platform reports, with a written reason for any gap.
- Loud failures. If an upload fails, an alert goes to a channel with an owner, rather than the data quietly stopping.
We report platform numbers beside CRM revenue, never instead of it; our analytics work is built around that.
What did this change for iSoftpull?
iSoftpull, a US B2B credit-data company, is the clearest example. We run their CRM end to end, along with their API integrations, and we connected Meta and Google Ads to product-usage data, so the algorithms learned from people who used the software rather than people who only filled in a form. We also cut spend on low-intent audiences.
Comparing late 2024 to early 2026, cost per qualified lead fell from $205.41 to $25.84, an 87% drop, with 88 qualified leads in January. The iSoftpull case study has the full story; our Google Ads and Meta Ads pages cover each channel.
FAQ
Can we send offline conversions without a gclid?
Yes. Enhanced conversions for leads matches on hashed email or phone, so Google Ads can still credit a conversion when no click ID was stored. Meta’s Conversions API also matches on hashed contact details. Click IDs improve match rates, so capture them when you can.
Is sending CRM data to ad platforms allowed under privacy rules?
It can be, with the right legal basis and consent. Contact details are hashed before they leave your server, consent status should travel with uploads for EU and UK users, and your privacy policy should say you do this. Check specifics with your legal adviser.
How many conversions a month do we need?
Enough for the bidding to see a pattern, which is why we often optimize on qualified leads when closes are rare. With only a handful a month at any stage, start with tracking and search before scaling automated bidding. Keep form fills as secondary conversions for diagnosis. If you want us to look at your setup, the ads audit is free: get in touch.


