GCLID

A GCLID (Google Click Identifier) is a URL parameter that Google Ads appends to your landing page address every time someone clicks a paid ad. It carries the campaign, ad group, keyword and other click attributes back to your site, which is what lets Google Ads match a later purchase or lead to the exact click that produced it. Google’s own definition calls it “a URL parameter passed with ad clicks” that “identifies the campaign along with other attributes of the click,” and it is required for Google Ads website conversion tracking. This entry covers what the parameter looks like, how auto-tagging generates it, how it differs from UTM tags, the iOS-era replacements wbraid and gbraid, and the site problems that silently destroy it.

What Is a GCLID?

The GCLID is an opaque identifier — a string of letters, numbers, dashes and underscores that means nothing on its own. It is a lookup key. When a visitor lands on your page with a GCLID attached, that key points to a record inside Google Ads holding everything about the click: which campaign, which ad group, which keyword matched, which device, what time, and what the click cost.

Your website never decodes it. The tag on your page stores the value, and when a conversion fires later, that value travels back to Google Ads, which does the matching on its side. This is why a GCLID is far richer than anything you could tag manually: you cannot write “which keyword triggered this ad” into a URL by hand, because you do not know it at the time the ad is served.

What a GCLID Looks Like in a URL

A tagged landing page URL takes this shape:

https://example.com/pricing?gclid=Cj0KCQjw1dGnBhD7ARIsAHjdMDkX...

The parameter always arrives as gclid= followed by a long encoded value. It is generated fresh for every single click, so two people clicking the same ad one second apart receive different identifiers. That per-click uniqueness is what makes click-level attribution possible — and also what makes a cached page or a stripped query string so damaging.

How Auto-Tagging Creates the Parameter

The GCLID does not appear because you added anything to your final URL. It appears because auto-tagging is switched on in the Google Ads account, under Admin → Account settings. Google states that GCLID functionality is “activated by turning on the auto-tagging setting.”

With auto-tagging enabled, Google Ads rewrites the destination URL at click time and appends the parameter. Nothing on your side needs to change. When it is disabled, no GCLID is generated at all, and Google Ads falls back to whatever manual tagging you supplied — which means conversion tracking and the Google Ads ↔ Analytics link both lose their most precise signal.

Once the visitor lands, the Google tag reads the parameter and writes it into a first-party cookie so that a conversion happening several pages — or several days — later can still be attributed to that click. If the visitor blocks cookies or the storage is cleared, the link between click and conversion breaks even though the GCLID arrived correctly.

GCLID vs UTM Parameters: Different Jobs

Both are URL parameters, both relate to campaign tracking, and they are constantly confused. They do different work:

Running both together is normal and usually correct: the GCLID feeds Google Ads reporting and bidding, while UTMs make the same traffic legible to any second analytics platform. The one rule that matters is never to overwrite source with something other than google on Google Ads traffic — a contradiction between the two tagging systems produces double-counted or misattributed sessions.

wbraid and gbraid: the iOS Parameters

Apple’s App Tracking Transparency rules made the classic GCLID unusable in parts of the iOS ecosystem, so Google introduced two replacements that appear in its place:

• wbraid — introduced in March 2021 for web conversions on iOS. It supports attribution back to campaigns in aggregate rather than per user, working alongside conversion modeling.
• gbraid — introduced in May 2021 for app deep-link conversions on iOS. Google describes it as added to landing page URLs when auto-tagging is enabled for iOS 14.5+ clicks.

If you inspect real traffic today you will find all three in circulation. Any system that looks only for gclid= — a homegrown lead form, a CRM import script, an offline conversion pipeline — will silently drop the iOS share of your paid traffic. Check that your capture logic reads all three parameter names.

Where the GCLID Shows Up

The parameter itself is rarely displayed as a dimension in the GA4 interface; its effect shows up as properly attributed Google Ads campaigns once the accounts are linked. Where you do encounter raw values:

• Lead forms and CRMs — a hidden field capturing the GCLID at form submission, so the sales outcome can be sent back to Google Ads later.
• BigQuery exports — the value can be present in the event parameters of a GA4 export, useful for click-level joins.
• Server logs — the query string is recorded like any other, which makes logs a decent audit trail when attribution disputes arise.

Offline Conversion Import

The most valuable use of a captured GCLID is closing the loop on sales that finish away from the website. A visitor clicks an ad, submits a form, and signs a contract three weeks later by phone. Storing the GCLID with the lead record lets you upload that contract back to Google Ads as an offline conversion, attributed to the original click. Google documents GCLID use with offline conversion tracking for exactly this pattern.

Without the stored identifier, the sale is invisible to the ad platform, and bidding optimises toward form fills rather than revenue — the classic case of a channel that looks expensive because the money it produced was never reported back.

What Breaks a GCLID

The parameter is fragile in specific, recurring ways:

• Redirects that drop the query string. A rule that sends /pricing to /plans without preserving parameters deletes the GCLID before any tag reads it. This is the single most common cause of unattributed paid traffic.
• Aggressive page caching. A CDN that serves one cached copy per path can strip or ignore query strings; the page loads fine and the identifier is gone.
• Landing pages behind a consent wall. If the tag is blocked until consent is granted and the visitor navigates before answering, nothing captures the value.
• Auto-tagging switched off. Often disabled years ago by someone worried it would “break the URLs,” and never revisited.
• Capture logic that only knows gclid. As above, iOS traffic arrives as wbraid or gbraid.

The test takes a minute: click one of your own live ads, then check the address bar on the landing page after it fully settles. If the parameter is missing there, no reporting fix downstream will help.

Frequently Asked Questions

Related Terms

• UTM — the manual tagging system GCLID complements
• Conversion — the outcome a GCLID is matched to
• CPC — the cost attached to each recorded click
• Attribution — how credit is assigned across touchpoints
• Client ID — the Analytics-side visitor identifier
• First-party cookie — where the captured value is stored