Why Your GCLID Disappears Before the Form (And How To Check If Yours Does)

The gclid lives in the URL of exactly one pageview. If a visitor browses before they convert, your hidden field saves blank and your offline conversion imports have been running on nothing. Here is the five-minute test.

The gclid only exists in the URL of the page your ad click landed on, so any navigation, redirect, subdomain hop, or full-page cache between that landing and your form leaves the hidden field blank without producing any visible error. The form still submits, the lead still lands in your CRM, and your on-site Google Ads conversion still fires, so the failure only surfaces months later when an offline conversion import returns a near-zero match rate on clicks that have already aged past the 90-day window. Test it by appending a test gclid to your landing page URL, navigating to the form the way a real visitor would rather than loading it directly, submitting, and checking the field on the resulting lead record. The Conversion Linker does not cover this, because the cookie it writes is for Google's own on-site attribution and is not in a form you can hand to a CRM. The fix is a tag on all pages that reads the gclid, gbraid, and wbraid out of the URL and writes them to your own first-party cookie with a 90-day expiry and the domain attribute set to your root with a leading dot, then reading that cookie at form submission rather than at page load.

Key takeaways

Quick Answer: The gclid only exists in the URL of the page your ad click landed on. If the visitor browses to another page before reaching your form, or the form sits on a subdomain, that parameter is gone and your hidden field saves blank. Add &gclid=test to your landing page URL, click through to the form the way a real visitor would, submit, then open the record in your CRM. A blank field means your offline conversion imports have been running on nothing.


The failure that never throws an error

This one is nasty because everything downstream keeps working. The form submits. The lead lands in HubSpot or Pipedrive or whatever you use. Your Google Ads conversion still fires. Nothing turns red anywhere.

Then three months later you close a deal, run your first offline conversion import, and the match rate comes back near zero. Now you are debugging a pipeline that has been quietly broken since the day you built it, with no way to recover the clicks you already paid for.

The 90-day gclid window makes this worse. By the time the upload fails, a chunk of your click IDs have expired anyway. You cannot backfill your way out of it.

Where the click ID actually goes

Google appends the gclid to your final URL through auto-tagging. It lives in the address bar of exactly one pageview. That is it.

Anything that changes the URL after that drops it. A visitor reading your services page before hitting the contact page. A single-page app swapping routes. An HTTP to HTTPS redirect in nginx rewriting the request. A quote form hosted at quote.yourdomain.com instead of yourdomain.com. Full-page caching at Cloudflare serving a version of the page with no query string on it at all.

If your landing page is anything other than a single page with the form on it, assume the parameter is gone by the time someone converts.

What the Conversion Linker actually covers

Here is where most setups go wrong, and it is an honest mistake.

The Conversion Linker tag does store the gclid in a first-party cookie. That is real. But it stores it for Google's own use, so that your on-site conversion tag can still attribute a purchase or form fill that happens two pages later. Google writes that cookie, Google reads that cookie, and the value inside is not in a shape you can hand to your CRM.

Your offline pipeline is a completely separate road. You need the raw click ID sitting in a field on the lead record, ready to be uploaded when the deal closes. The Conversion Linker never puts it there.

So people install the Linker, watch their on-site conversions record correctly, and reasonably conclude the click ID is handled. On-site tracking working while offline tracking is dead is a normal state for an account to be in, and the Google Ads interface does nothing to tell you which one you are looking at.

How to fix it

Run these in order. The first takes five minutes and tells you whether the other two are necessary at all.

Step 1: Prove whether you are broken

Take your landing page URL and stick &gclid=test123 on the end of it. Use ?gclid=test123 if there is no query string already.

Now behave like a visitor instead of a tester. Do not go straight to the form. Click through your nav the way someone reading your site would, land on the form page, fill it out, submit.

Open that lead record in your CRM and look at the field that should hold the click ID. If it says test123, your capture survives navigation and you can stop reading. If it is empty, you found it.

Do a second pass on mobile if you serve a different mobile experience, since that is a separate code path and it fails independently.

Then check your history. Pull the last 90 days of leads and count what fraction have any value in that field at all. That number is roughly the ceiling on how much of your spend you can currently connect to revenue.

Step 2: Capture on the first pageview and scope the cookie correctly

You want a tag firing on all pages that reads the gclid out of the URL and writes it to your own first-party cookie. Set a 90-day expiry to match Google's window.

The part that gets missed is the domain attribute. A cookie written without one is scoped to the exact hostname it was set on. Write it on www.yourdomain.com and it will not be readable from quote.yourdomain.com. Set the domain to your root with a leading dot and it becomes readable across every subdomain you own. This single attribute is the whole fix for anyone whose form lives on a hosted CRM subdomain.

Capture gbraid and wbraid in the same tag. Those come back on some iOS traffic in place of the gclid, and if you only look for one parameter you will drop a slice of iPhone leads without noticing.

Step 3: Read the cookie at submit, not at page load

If your form is on a single-page app, populating the hidden field when the page first renders will fail, because the form often does not exist yet at that moment. Pull the value from the cookie at the point of submission instead.

Then repeat Step 1 exactly as written. Do not verify by loading the form page directly with the parameter attached, because that path was never the broken one. The whole failure lives in the navigation between landing and converting, so your test has to include that walk.

One more thing worth checking if you have referral exclusions configured in Analytics. That list changes cookie handoff behavior across your own domains, and it is a common reason a setup that used to work suddenly stopped. Make sure both your root and www versions are on it, since the www version counts as one too.

If you want the whole offline pipeline mapped out in order, from click ID capture through to the upload itself, that is what the OCT Setup Checklist covers. It is free, and it exists because this exact gap is the most common place lead gen accounts lose their attribution.

Full disclosure, we also built FormTrackr, which handles the capture and the upload for you. The manual version above works fine too.

FAQs

How do I know if my gclid problem is capture or upload?

Look at where the value stops. If the field on the lead record is blank, capture is broken and there is nothing to upload. If the field has a value but Google reports unmatched rows, the click is older than 90 days, the conversion action is set up wrong, or the timestamp format in your upload file is off.

Does enhanced conversions for leads solve this instead?

It solves a different version of it. Enhanced conversions match on hashed email or phone rather than the click ID, which is useful when you cannot reliably capture a gclid at all. It is a genuine alternative, not a backup, and running both without understanding the difference is how accounts end up double counting.

My form is hosted by a third party and I cannot add code to it. Now what?

Check whether the tool has a redirect setting that sends people to a thank-you page on your own domain after submission. Many hosted form products do, and it lets you fire your own tag on a page you control. If not, an iframe embed keeps the visitor on your site so your cookie is readable.

Will fixing this improve performance right away?

No. It gets you a clean signal starting from the day you fix it, and Smart Bidding needs volume in that signal before behavior changes. What it does immediately is let you see which campaigns produce revenue instead of which ones produce form fills.

Free checklist

OCT Setup Checklist — every step from GCLID capture to upload verification.

Free with a Freak.Marketing account. Know your offline conversion tracking is actually working.

Get the free checklist