Do I need to store the GCLID for Google Ads offline conversions? What if the form is embedded?
Short answer
For a manual upload the GCLID has to be on the lead record when the deal closes. It is dropped by embedded forms, redirects, return visits and rebuilt forms. Enhanced conversions for leads can back it up.
Short answer: for a manual upload, yes. The GCLID has to travel with the lead, from the click all the way to the CRM, and it has to still be there when the deal closes.
The long answer is that it's a relay race, and the baton gets dropped in four places. Knowing which one you're dropping it in is most of the work.
Drop one: the embedded form. The form lives on another domain, inside an iframe, and the page URL with the gclid never reaches it. Test: submit a lead from the embedded version, open the contact, and look for the GCLID. It's usually empty.
Drop two: the redirect. Somewhere between the ad and the landing page, a redirect strips the parameter. Test: click your own ad URL, and check whether the address bar still shows ?gclid= when the page finishes loading.
Drop three: the return visit. The lead clicks on Monday, thinks, and comes back on Thursday by typing your address. The parameter is gone, and any cookie that held it may have expired too. On Safari, cookies written by JavaScript are capped at 7 days, and at 24 hours when the visitor arrived through a link from a known tracker.
Drop four: the rebuild. Someone redesigns the form and the hidden field quietly disappears. Nobody notices until sales stop matching. There's no test for this other than looking, on a schedule.
The standard fix is a hidden field that reads gclid from the URL and saves it on the lead. It's a good fix. It works right up until one of the four things above happens, which is usually around the time you stop checking.
Two habits make it sturdier. Save the GCLID on the lead record at submit, not in a cookie, because a record can't expire. And test the ugly paths on purpose, not just the happy one you saw in the demo.
And if you lost it anyway, enhanced conversions for leads can match on a hashed email or phone. It has a shorter window (63 days versus 90 for a GCLID upload), but it's a second chance, and many accounts run both so that a lost GCLID stops being a lost sale.
If you're choosing how to capture the click ID, here's how I'd rank the options by what they survive.
A hidden field survives nothing except the form it's on. A cookie survives page changes, but not Safari's 7-day cap or a cleared browser. Saving the click ID to the lead record at submit survives everything that happens after the submit, but only if the ID was still around when the form was sent. Capturing it on your own domain the moment the visitor lands survives the longest, because it doesn't depend on the form at all.
In practice the strongest setups stack two of them: capture on landing, and save to the record at submit. Then either can fail and the sale still has a click ID attached. Redundancy is boring, and it's the whole trick.
How are you capturing yours? Especially interested in what you did about embedded forms.
For reference, DataCops keeps the ad click on your own domain for up to 90 days, so the click ID doesn't depend on a hidden field that a redesign can delete.
DataCops in short
For this question: With DataCops the click ID is captured at the first request on your own domain and kept on the server for up to 90 days, so an embedded form, a redirect or a return visit cannot strip it before the deal closes.
DataCops is a tool that makes the ads learn from real sales: it sends booked, showed, won and paid stages from your CRM back to your ad platforms, gives every visit a bot verdict with a Real people only switch per platform, warms up new campaigns with your existing customers, and logs every send. It is not an attribution report.
How DataCops does it
- The sale after the form. HighLevel natively (lead, booked, showed, won with value, paid; cancelled, no-show and lost are never sent), any other CRM through a private webhook, matched to the click by click ID or hashed email and phone.
- The click is kept on the server. Click IDs are stored for up to 90 days, so a deal that closes weeks later still finds its click.
- Real people only. Every visit gets a bot verdict against 360+ billion IPs and 350+ monitoring points, with a Real people only switch per ad platform, off by default. CRM events carry no bot flag.
- Counted once, logged every time. Pixel and server events share an event ID, and a delivery log shows each send as sent, held, skipped or failed, with the reason.
- One script, one DNS record. Collection runs on your own domain; with DNS on Cloudflare, the free Worker reads the click at the edge before the page loads.
Best for: ad-funded businesses whose sales close in a CRM or on a call: clinics, home services, agencies, B2B and lead gen.
Ads Warmup: tell the ads who pays
Ads Warmup, DataCops' flagship feature, sends customers you already have to Meta, Google Ads and TikTok before a new campaign spends: upload a CSV (only email is required, up to 20,000 rows), see a 0 to 10 match score per person, pick the event, and send. Rows are dated when you send, and Google Ads credits only people who clicked a Google ad. Preview is free; sending needs a paid plan. Check your own consent basis for the list first. See Ads Warmup.
Ways to do this job
| Option | Best for |
|---|---|
| DataCops | CRM stages to Meta and Google Ads, with a bot verdict and a delivery log |
| Zapier or Make | One simple CRM-to-ad flow you build and maintain |
| Direct API upload | Teams with an engineer |
| Manual CSV upload | Occasional batches |
When not to use DataCops
- You want a reporting dashboard. DataCops cleans and sends what goes into your ads. It is not a multi-touch reporting layer.
- Your sales never leave one store checkout. If everything happens in one checkout, the platform's own pixel plus server events may be enough.
Sources and further reading
More on this: Google Ads offline conversions, and the complete guide to offline conversion tracking.
Two follow-ups people ask.