What Is GCLID? The Google Click ID Explained, With Setup Steps

GCLID is the string Google Ads adds to your landing page URL when someone clicks one of your ads. It's how Google Ads knows a form fill, a call or a purchase came from a specific ad, not just from "Google search" in general. This guide covers what it looks like, how long you have to use it, what gbraid and wbraid are for on iOS, and how to get it off the URL and into a form or a CRM without losing it on the way.

The short answer

What a GCLID actually is

GCLID stands for Google Click Identifier. When auto-tagging is switched on in your Google Ads account, which it is by default for new accounts, Google appends a gclid parameter to the final URL of your ad the moment someone clicks it. Google's own example is simple: a click on an ad for example.com becomes example.com/?gclid=123xyz.

In practice the value isn't three characters. A real GCLID is a long, opaque, base64-style string, usually somewhere in the range of 60 to 100 characters, often starting with Cj0. It isn't meant to be read, only matched. Treat it as a token, not as data you decode: don't lowercase it, don't trim it, don't try to parse anything out of it. Any change to the string breaks the match.

The reason Google Ads wants this parameter on the URL is that it's the mechanism behind almost everything in conversion reporting: website conversion actions, imported Google Analytics conversions, and offline conversion import. Without a GCLID (or one of its iOS equivalents, below), Google Ads has to guess which click led to a conversion, or it can't attribute it at all.

Auto-tagging: how it's switched on and off

Auto-tagging lives in Google Ads account settings, under "Tag the URL that people click through from my ad." It's enabled by default. If it's off, either because someone turned it off or because a third-party tracking template overwrote the final URL without it, no GCLID gets added, and anything downstream that depends on it (offline conversion import, some auto-tagged GA4 reporting) has nothing to work with. Turning it on only affects clicks from that point forward. It does nothing for traffic that already happened.

gbraid and wbraid: the iOS versions

Apple's App Tracking Transparency rules in iOS 14.5 and later limit how ad platforms can track individual clicks. Google Ads responded with two parameters that stand in for GCLID in those cases:

• gbraid: used for web-to-app measurement, added to URLs when auto-tagging is on and a click came from Search, Shopping, Display or Performance Max on iOS 14.5+.
• wbraid: used for app-to-web measurement, when a click starts inside an iOS app and leads to a web conversion.

Neither is a straightforward one-to-one swap for GCLID. They support modelled and aggregated measurement rather than a clean per-click identifier, because that's what Apple's rules allow. For offline conversion import, Google accepts gclid, gbraid or wbraid, but exactly one of the three should be present per row, and Google says conversions keyed by gbraid or wbraid can take longer to process (Google quotes up to 72 hours, against the usual under-12-hours for GCLID). If your forms or CRM only ever capture gclid from the URL and ignore gbraid/wbraid, you will quietly lose iOS attribution and most dashboards won't tell you why.

How long a GCLID is valid

For offline conversion import specifically, Google's own documentation is direct about this: GCLIDs are retained for 90 days. Upload a conversion tied to a GCLID older than that and it will fail to import, usually surfacing as an expired or unparseable event rather than a clear "too old" message. The clock starts from the click, not from when you first saved the GCLID.

Two related limits worth knowing if you're setting up offline imports:

• Enhanced conversions for leads, which matches on hashed personal details (email, phone) rather than a click ID, has its own separate retention: Google allows up to 63 days for that matching data.
• A conversion can't be dated before its click. If your conversion timestamp lands even slightly earlier than the click timestamp, due to time zone handling, Google will reject the row. Google's own guidance is to build in a day or two of buffer and double check time zones before uploading.

There's also a minimum: a conversion uploaded less than 6 hours after its click can be rejected as too recent, since Google hasn't finished processing the click yet. In practice, this mostly matters for near-real-time integrations, not for a nightly or weekly offline upload job.

How to capture the GCLID into a form

A GCLID only survives if something saves it before the visitor leaves the page it landed on, and before the form is submitted. The common pattern:

1. Read it from the URL on page load, with a small script that checks window.location.search for gclid (and gbraid/wbraid for iOS traffic).
2. Store it somewhere that survives navigation, typically a cookie or sessionStorage, since a visitor might browse several pages before filling in a form.
3. Write it into a hidden input on every form on the page, so it's part of the submitted payload, not something you have to go fetch separately.
4. Save it against the lead record in your CRM or database when the form is processed, alongside the other UTM and click data, so it's available later for an offline conversion upload or a report.
5. Don't rely on the GCLID still being in the URL by the time someone submits a form on a different page. Capture it once, early, and carry it forward yourself.

This is also where redirects quietly break things. A redirect chain, a tracking template pointing at a different domain, or a "www" versus non-www bounce, can all strip query parameters if they're not explicitly passed through. If GCLID is missing on forms further into a journey but present on the landing page itself, check every redirect and link in between before assuming the capture script is broken.

The _gcl_aw cookie and the Conversion Linker tag

Google's Conversion Linker tag, available in Google Tag Manager, is the standard way to turn a GCLID in a URL into a first-party cookie that other tags can read later. It automatically looks for ad click parameters in the landing page URL and stores them in cookies prefixed _gcl_, with _gcl_aw holding Google Ads click data specifically (_gcl_gs is used for Google Search). These cookies are set on the top-level domain so other tags on the same site, and across subdomains, can read them.

If you're not using Tag Manager, the equivalent manual step is the same idea: read the URL parameter once and write your own first-party cookie or storage entry, so later pages (and later form submissions) still have access to it even without the parameter still sitting in the address bar.

Cross-domain setups, for example a landing page on one domain and a checkout or booking form on another, need the Conversion Linker's cross-domain linking option, or an equivalent manual pass-through, or the GCLID won't survive the domain change at all.

Using GCLID for offline conversion import and enhanced conversions for leads

Offline conversion import is how you tell Google Ads about something that happened away from your website: a sales call that converted three days after the click, a quote accepted a week later, a deal closed in a CRM. You upload rows with a GCLID (or gbraid/wbraid), a conversion name, a timestamp and a value, matched against a conversion action set up with the source "Import from clicks."

Two things decide whether this works at all:

• You actually captured the GCLID on the lead, using the method above, at the point the form or call came in. If it isn't there, there's nothing to upload.
• The conversion action exists and matches what you're importing against, and the account you're uploading to is the same one the GCLID's click belongs to. A GCLID from one Google Ads account can't be matched in another.

Enhanced conversions for leads is a related but separate feature: instead of (or alongside) the GCLID, you send hashed email and phone number from your CRM when a lead becomes a qualified opportunity or a sale, so Google can match on identity rather than click ID alone. It's worth running both where you can, since a GCLID can expire or go unmatched while the person's details usually don't change. The detail of setting that up is covered in Google Ads enhanced conversions for leads.

GA4 and GCLID

Google Analytics 4 uses the same gclid parameter when it's present in the URL, and if your GA4 property is linked to your Google Ads account, GA4 conversions can be imported back into Google Ads using that same click data, no separate manual upload needed. This only works while Google Ads auto-tagging is switched on and your GA4 property is actually linked under Admin, Google Ads Links. Turning off auto-tagging, or relying only on UTM parameters, breaks this path even if everything else in GA4 looks fine.

Common problems and causes

1. Auto-tagging is off. No GCLID is added to any URL at all. Check Google Ads account settings first; it's the most basic cause and the easiest to miss.
2. Redirects strip the parameter. A tracking template, a URL shortener, an http-to-https bounce, or a CMS redirect rule can drop query parameters unless they're explicitly preserved.
3. GCLID was never captured before the form was submitted on a later page. The visitor landed with it, browsed, and it was gone by the time they filled in a form two pages later.
4. The value was altered. Lowercased, trimmed, URL-decoded twice, or partially copied. Any change breaks the match. Treat it as an opaque string, never reformat it.
5. It's older than 90 days by the time it's uploaded for offline conversion import.
6. The conversion is dated before the click, often from a time zone mismatch rather than a real sequencing problem.
7. It belongs to a different Google Ads account than the one receiving the upload, or to a client account that doesn't have access to the conversion action.
8. iOS traffic only ever sends gbraid or wbraid, and the capture script only looks for gclid, so iOS clicks silently stop being tracked.
9. Ad storage consent was denied, so the _gcl_* cookies were never set, and anything depending on reading that cookie later in the journey comes up empty. The parameter in the URL on the landing page itself is still usually accessible, which is why capturing it immediately, before any cookie decision affects later pages, matters.

Running this through Inflowave

Inflowave's hosted website builder captures gclid (along with UTM parameters and Meta's fbclid) from the URL on page load, stores it in a first-party _gcl cookie, and writes it into a hidden field on every form on the page at the moment it's submitted, so it travels with the form data rather than being read from the URL separately.

When the form is submitted, the UTM parameters and fbclid are saved on the lead record and used in attribution reporting. GCLID isn't stored on the lead yet, and Inflowave doesn't upload offline conversions to Google Ads, so if you import offline conversions today, capture the gclid field in your own integration.

Related guides: Google Ads enhanced conversions for leads, Event Match Quality, Lead scoring.

Questions people ask

What is GCLID used for?

It links a website conversion, a phone call, or an offline sale back to the exact ad click that caused it: which campaign, ad group, keyword and ad. Without it, Google Ads can't connect what happened later to the click that started it.

How do I find my GCLID?

Look at the URL of the page someone landed on after clicking your ad. If auto-tagging is on, it'll be in the query string as gclid=. You can also see GCLIDs tied to specific clicks in Google Ads reporting tools that reference click data.

What does a GCLID look like?

A long opaque string, typically 60 to 100 characters, often starting with Cj0. It isn't readable text and shouldn't be edited, reformatted or shortened.

How long does a GCLID last?

For offline conversion import, Google retains a GCLID for 90 days from the click. After that, a conversion tied to it won't import.

What's the difference between GCLID, gbraid and wbraid?

GCLID is the standard click ID used across most traffic. gbraid and wbraid are iOS-specific alternatives introduced after Apple's App Tracking Transparency rules limited individual click tracking: gbraid for web-to-app, wbraid for app-to-web.

Why don't I see a GCLID on my form submissions?

Most often because auto-tagging is off, a redirect stripped the parameter before the form page loaded, or the capture script only grabs the parameter from the exact landing page and the visitor filled in the form somewhere else on the site.

Is GCLID the same as a UTM parameter?

No. You choose and set UTM parameters yourself to label traffic sources. GCLID is generated by Google Ads and added automatically through auto-tagging; you don't set its value.

What is the _gcl_aw cookie?

A first-party cookie, usually set by Google's Conversion Linker tag, that stores Google Ads click data (including the GCLID) so it's available to other tags on later pageviews, not just the one the visitor landed on.

Why does my offline conversion upload say the GCLID isn't recognised?

Usually one of: the GCLID was never actually captured, it's older than 90 days, it was altered somewhere in the chain, the conversion's timestamp is before the click's, or it belongs to a Google Ads account that doesn't have access to the conversion action you're uploading against.

Does consent mode affect GCLID?

If a visitor denies ad storage consent, Google won't set or read the _gcl_* cookies, so anything relying on that cookie later in the journey won't have the value. The GCLID on the landing page URL itself can still be read by your own code at that moment, before any cookie is involved.

Can I use GCLID for enhanced conversions for leads?

Enhanced conversions for leads primarily matches on hashed email and phone, not GCLID, though you can send both. It's a useful backup when a GCLID has expired or a lead converts well outside the 90-day window, since personal details don't expire the same way.

Will a VPN or ad blocker remove the GCLID from a URL?

No, since it's part of the URL Google Ads built. An ad blocker or strict privacy setting can prevent the cookie that would otherwise store it for later pages, which is why capturing it on landing matters more than relying on the cookie.