What is a GCLID and why does it keep going missing?
A GCLID is the click identifier Google appends to your ad's landing page URL. It is how a lead sitting in your CRM can be matched back to the exact ad click that produced it. It goes missing when a redirect strips query parameters, when the form does not capture it, when the visitor returns days later by another route, or when consent tooling blocks the script that stores it.
What it is and where it must end up
When someone clicks a Google ad, the destination URL arrives with a long value attached to a gclid parameter. That string identifies the click. If it reaches your CRM alongside the lead, you can later tell Google which clicks turned into jobs. If it does not, that lead is permanently unmatchable to a specific click.
The single most important implementation detail is when you capture it. Read the parameter on the very first page view, write it to a first-party cookie, and populate a hidden form field from that cookie at submit time. Reading it only at form submit fails for anyone who browses two pages first.
The common ways it evaporates
- Redirects that drop query strings. A non-www to www rule, an http to https rule, or a legacy URL redirect written without parameter passthrough will silently remove it.
- Forms hosted on another domain. An embedded scheduler or third-party form on a different origin cannot read your cookie unless you pass the value explicitly.
- Consent gating. If your consent banner blocks the tag that stores the value, visitors who never accept produce leads with no click ID.
- Delayed return visits. Someone clicks the ad Monday and calls Thursday from a bookmark. The cookie may still hold the value, or may not, depending on lifetime and browser.
- Phone calls. A call is not a form submit. Tying a call to a click requires call tracking that carries the session identifier, not the GCLID by itself.
Related identifiers you will run into
Google also issues alternative click parameters for cases where the standard identifier cannot be set, typically involving app-to-web journeys on privacy-restricted browsers. Your capture code should store whichever parameter is present rather than looking only for the one you know. Other platforms have their own equivalents, and a robust capture routine treats them as a list to sweep rather than a single field.
The same applies to your own UTM values. Store them next to the click ID at first touch, because they answer different questions and one can survive when the other does not.
How to verify it in ten minutes
Click one of your own ads, land on the site, navigate to two other pages, then submit a test form. Look at the resulting CRM record. If the click ID is there, your capture survives navigation. Repeat from a phone, and repeat from an ad pointing at a URL that redirects. Those three tests catch most breakage.
Then make the check recurring. Track the share of paid leads arriving with a click ID as a standing number in your reporting, and treat a sudden drop as a site change to investigate. This kind of quiet decay is exactly what marketing intelligence monitoring exists to catch.
Topics: GCLID · click ID · tracking · offline conversions
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.