You've seen it. Somebody clicks your ad, lands on your page, and the address bar reads ?gclid=Cj0KCQjw... plus fifty characters of nonsense. That unreadable string carries more weight than anything else in your account.
What is a gclid, exactly?
It's an opaque token Google generates at the moment of the click and hands to your site in the URL. Opaque means you can't decode it. No campaign name inside, no keyword to parse out. It's a receipt number: Google holds the ledger, the gclid points at one row.
It's per click, not per user — the same person clicking twice gets two gclids. It's generated by Google, which is why it carries detail your own tagging never sees. And it's useless unless you store it.
How does the gclid get onto your URL?
Auto-tagging puts it there. In Google Ads: Admin, then Account settings, confirm Auto-tagging is enabled. While it's on, Google appends gclid to every final URL at click time. Switch it off and no gclid ever arrives, whatever you build in GTM. You can pass a copy through a tracking template with the ValueTrack parameter {gclid}, but auto-tagging is the source.
- Ad click — Auto-tagging appends ?gclid= at click time
- Landing page URL — The only tie to that specific auction
- Two places to store — _gcl_aw cookie and a hidden form field
- CRM lead record — Survives long after the cookie is gone
- Offline import — Closed deal uploaded within 90 days
Where does the gclid go after the page loads?
Two places, and you want both. A first-party cookie on your domain: GTM's Conversion Linker tag (or gtag.js alone) reads the gclid out of the URL and writes it into _gcl_aw, 90-day default lifetime. On conversion, the tag reads it back and credits the original click.
And your own database. On a lead-gen site you capture the gclid into a hidden form field and write it onto the lead record. That copy is what lets you upload a closed deal weeks later, once cookies are gone.
What can a gclid do that UTMs can't?
UTMs describe the campaign you labeled. The gclid identifies the click Google recorded.
| UTMs | gclid | |
|---|---|---|
| Who creates it | You | Google, at click time |
| Keyword-level detail | Only if you built it in | Yes, tied to the real auction |
| Device, time, network | No | Yes, held by Google |
| Offline conversion import | Not accepted | Required |
That offline import row pays for itself. If you sell anything that closes on a call, the gclid is the only way to send that deal back to Google Ads and let Smart Bidding optimize on revenue instead of form fills.
| gclid | gbraid | wbraid |
|---|---|---|
| One click by one user | App-to-web iOS clicks | Web-to-app iOS clicks |
| Keyword, device and time behind it | Identifies a group of clicks | Identifies a group of clicks |
| Offline imports accepted | No user-level identity, by design | No user-level identity, by design |
| Enhanced conversions data allowed | Attribution leans on modeling | No user data rides on the upload |
What are gbraid and wbraid?
Privacy-safe click IDs Google introduced for iOS traffic after Apple's App Tracking Transparency changed what could be tracked between apps and the web. They land in the URL where a gclid would, and a click carries one of the three, never two.
- gbraid — app-to-web. Someone taps your ad inside an iOS app, like the YouTube app, and lands on your site.
- wbraid — web-to-app. Someone taps your ad on the mobile web and ends up in an app.
The difference that matters: a gclid identifies one click by one user, while gbraid and wbraid identify a group of clicks. No user-level identity, by design. That's why conversions attributed through them lean on Google's modeling, and why enhanced conversions user data can't ride along on those uploads.
What about msclkid, fbclid and ttclid?
Same idea, different platform. Microsoft Advertising uses msclkid, and also needs auto-tagging on before offline imports work. Meta uses fbclid, which the pixel turns into the _fbc cookie and you send back as fbc on Conversions API events. TikTok uses ttclid. Build the capture once, generically, and adding a channel costs nothing.
- Auto-tagging off — No gclid arrives, whatever GTM does
- Redirect strips it — Query string gone before the page loads
- URL rewritten first — Consent banner or SPA beats your tag
- Hidden field empty — The form never wrote it to the lead
- Server captures it — Reads the URL before any script runs
How long does a gclid last, and why does it vanish?
The _gcl_aw cookie defaults to 90 days, and Google accepts offline conversion uploads within 90 days of the click. Design around that number. It's why a slow sales cycle needs the gclid in your CRM, never in a cookie alone.
Browsers shorten it anyway. Safari's Intelligent Tracking Prevention caps cookies written by JavaScript at 7 days, and links arriving decorated with tracking parameters can be capped harder still. A gclid landing page is exactly that. On Safari, a click-ID cookie set client-side can be gone before your first follow-up email.
Then the structural causes: auto-tagging off, a redirect dropping the query string, a consent banner or single-page app rewriting the URL first, a form that never wrote the hidden field. Each one, and how to test for it, is in the gclid missing rescue guide.
Why does first-party server-side tracking keep the gclid alive?
Plain-language version first, since most people have never heard the phrase. Normally your tracking runs entirely in the visitor's browser: scripts from Google and Meta load on your page, set cookies with JavaScript, fire requests straight to the ad platforms. Browsers and ad blockers are hostile to all three steps now. Server-side tracking moves the work to a server you control on your own subdomain, something like data.yoursite.com, so data reaches you first.
For click IDs that changes three things. The cookie holding your gclid gets set by your server in an HTTP response instead of by JavaScript, which takes it out of the 7-day script-written cookie cap ITP applies in Safari. The capture happens on the server that served the landing page, so a blocked script or slow consent banner can't beat it to the URL. And the gclid lands in storage you own at first touch, so it's still there 60 days later when the deal closes — with every other click ID for that visitor beside it, per consent.
Frequently asked questions
What does gclid stand for, and can I decode one?
Google Click Identifier, and no, you can't decode it. It's an opaque token; the campaign, ad group and keyword behind it live in Google's systems. You get that detail from Google Ads reporting, not by parsing the string.
Do I still need auto-tagging if I use UTMs?
Yes. Offline conversion imports, enhanced conversions for leads and keyword-level accuracy all depend on the gclid. UTMs can't substitute for it.
What's the difference between gbraid and wbraid?
gbraid covers app-to-web clicks and wbraid covers web-to-app clicks. Both identify a group of clicks rather than an individual user.
Should I store the gclid in my CRM?
Yes, it's the highest-value habit in lead-gen tracking. Capture it into a hidden field at first touch so months later you can upload the closed deal.
Does capturing a gclid need consent?
Treat it like any advertising identifier: in the EEA it falls under Consent Mode v2 and ad_storage, so capture and use follow the visitor's choice.
- gclid
- glossary
- attribution
- google ads

