What Is GCLID? How Google Ads Click Tracking Really Works

If you have ever clicked a Google ad and glanced at the address bar, you have seen it: a long, opaque gclid parameter tacked onto the landing page URL. Most people ignore it. Some people — usually the ones writing redirect rules or CDN configs — delete it. That second group is quietly destroying their company’s ad attribution, and often nobody notices for weeks.

gclid stands for Google Click Identifier. It is the thread that connects a single ad click to everything Google Ads knows about that click: the campaign, the ad group, the keyword, the device, the auction. It is also the join key for offline conversion imports — the mechanism that lets you tell Google Ads “that click from three weeks ago turned into a paying customer,” so its bidding algorithms can optimize for revenue instead of form fills.

By the end of this post you will know where gclid comes from, how it flows through Google Ads and GA4, how offline conversion imports use it, how it relates to UTM parameters, and — most practically — which redirect and URL-rewriting mistakes silently strip it, and how to make sure yours don’t.

What gclid actually is

A gclid is an opaque token that Google Ads generates for each individual ad click and appends to your final URL as a query parameter. A landing page URL after an ad click looks something like this:

https://www.example.com/pricing
  ?gclid=EAIaIQobChMIabc123XYZExampleToken

Three properties matter:

• It identifies one click, not one user. Two clicks from the same person get two different values.
• It is opaque by design. The format is undocumented and can change. You cannot decode a campaign name out of it, and you should never parse it — only store and forward it.
• The data lives on Google’s side. The token itself carries nothing. It is a lookup key into click metadata that Google holds: campaign, ad group, keyword, match type, ad creative, device, and so on.

That last point is why gclid is so compact compared to a fully manually tagged URL. Instead of encoding five UTM values into the query string, Google encodes one key and keeps the values server-side.

Auto-tagging: where the parameter comes from

Google Ads appends gclid through a feature called auto-tagging, an account-level setting that is enabled by default in new accounts. With auto-tagging on, you don’t change your ad URLs at all — at click time, Google adds the parameter to whatever final URL you configured.

This has one operational consequence people trip over: your landing pages must tolerate arbitrary query parameters. If your server returns an error for unknown parameters, canonicalizes them away with a redirect, or serves a cached page keyed on the exact URL, auto-tagged traffic will behave differently from your own test visits. Google’s ad review systems check for exactly this failure mode, and ads can be disapproved when the tagged URL breaks.

Auto-tagging is also a prerequisite for most of what makes gclid useful downstream: GA4 session attribution for Google Ads traffic, and offline conversion imports, both described below.

How gclid connects a click to reports in Google Ads and GA4

When a visitor lands with a gclid in the URL, the Google tag on your page picks it up and stores it in a first-party cookie (you will see it as _gcl_aw if you inspect your cookies). That is how a conversion fired three pages later — or on a return visit within the attribution window — still gets credited to the original ad click: the tag sends the stored click ID along with the conversion event, and Google matches it to the click record.

If your Google Ads and GA4 accounts are linked, GA4 uses the same identifier to attribute the session. GA4 doesn’t need UTM parameters on Google Ads traffic; it resolves the gclid against Google Ads and populates its Google Ads dimensions — campaign, ad group, keyword — with more detail than you could reasonably stuff into manual tags. This is why an auto-tagged account shows google / cpc traffic with full campaign detail even though the URLs contain no utm_source at all.

The failure mode is symmetric: if the gclid never reaches the page where the tag runs, the click still cost you money, but the session shows up as organic or direct, and any conversion it produces is invisible to Google Ads.

Offline conversion imports: gclid as the join key

This is where gclid stops being an analytics detail and starts being a revenue lever. Plenty of businesses don’t convert on the website: the ad click produces a lead, and the actual sale closes days or weeks later in a CRM, over the phone, or in person. Offline conversion imports let you feed those outcomes back into Google Ads, and the join key is the gclid.

The workflow looks like this:

1. A prospect clicks your ad and lands with a gclid in the URL.
2. Your landing page captures the parameter and stores it alongside the lead — typically in a hidden form field that flows into your CRM.
3. When the lead becomes revenue, you upload a record to Google Ads: the stored gclid, a conversion action name, a timestamp, and optionally a value and currency.
4. Google Ads matches the ID back to the original click and credits the conversion to that campaign, keyword, and auction — which is what value-based Smart Bidding then learns from.

Capturing the parameter is a few lines of JavaScript using URLSearchParams. Persisting it matters because the lead form is often not on the first page the visitor sees:

// Capture gclid on landing and persist it for the lead form.
const params = new URLSearchParams(window.location.search);
const gclid = params.get("gclid");
if (gclid) {
  window.localStorage.setItem("gclid", gclid);
}

// Later, when the lead form renders:
const field = document.querySelector('input[name="gclid"]');
const stored = window.localStorage.getItem("gclid");
if (field && stored) {
  field.value = stored;
}

Uploads can go in through a spreadsheet in the Google Ads UI or, at any real volume, through the Google Ads API’s click conversion upload. A spreadsheet upload is conceptually just rows like:

Google Click ID,Conversion Name,Conversion Time,Conversion Value,Currency
EAIaIQobChMIabc123XYZ...,qualified-lead,2026-07-21 14:32:00,150,USD

Two constraints to design around: clicks expire — you can only import conversions for clicks within the conversion action’s lookback window, so upload regularly rather than in quarterly batches — and the match is exact, so any system between the ad click and your CRM that truncates, rewrites, or drops the ID breaks the entire loop. Google also offers enhanced conversions for leads, which match on hashed contact details instead of the click ID, but gclid remains the most direct and precise key when you can capture it.

Auto-tagging vs. manual UTM tagging

People often frame gclid and UTM parameters as competitors. They are complementary tools with different scopes:

In practice, most serious setups use both: auto-tagging on for the rich Google-side data and offline imports, plus UTM parameters so that non-Google tools — your data warehouse, a CRM attribution field, a third-party analytics product — can classify the traffic too. The two can coexist on the same URL without conflict; just keep your manual values consistent with reality, because conflicting manual tags on auto-tagged traffic is a classic source of confusing reports. If your UTM conventions are shaky, fix that first — I wrote a practical guide to UTM parameters that covers naming schemes and the mistakes that fragment your data.

How redirects and query stripping break attribution

Everything above depends on one fragile assumption: the gclid that Google appends actually arrives at the page where your tag runs. Every hop between the ad click and that page is a chance to lose it. The usual suspects:

• Redirects that don’t forward the query string. A rule like “redirect /promo to /pricing” written against a fixed target URL discards everything after the question mark. The status code doesn’t save you — a 301 and a 302 both lose the parameters if the rule doesn’t explicitly carry them over. (If you’re unsure which code you even want, see 301 vs 302 redirects.)
• URL shorteners and vanity domains. Ads pointing at a shortener, or a QR code on print material that goes through one, add a redirect hop you don’t control unless you built it.
• CDN and cache “normalization” rules. Stripping unknown query parameters to improve cache hit rates is a common optimization — and it deletes gclid before your origin ever sees it.
• Client-side cleanup. SPAs and consent tools that rewrite location to a “clean” URL before the Google tag has read the parameter.
• Protocol and host canonicalization chains. Each hop — http to https, apex to www — is usually fine individually, but every link in the chain must preserve the query string, and the one someone hand-wrote in an nginx config often doesn’t.

The insidious part is that nothing visibly errors. The page loads, the visitor converts, revenue arrives. What breaks is the feedback loop: conversions detach from clicks, Smart Bidding starves, and reported ROAS drifts away from reality. The fix is boring and absolute: every redirect in the path must append the incoming query string to the destination, or at minimum must pass through the ad click identifiers.

How the shortlinks on this site handle it

This site runs its own link shortener (the build is written up in Build a URL Shortener with Next.js and Supabase), and this exact problem shaped its redirect logic. Each shortlink has a per-link setting for whether to forward incoming query parameters to the destination — but even when forwarding is turned off, the redirect code special-cases the ad click IDs:

// Even if forward_query is false, preserve ad-tracking IDs
// so conversions can still be attributed on the destination.
for (const key of ["gclid", "wbraid", "gbraid"]) {
  const v = incoming.get(key);
  if (v && !target.searchParams.has(key)) {
    target.searchParams.set(key, v);
  }
}

In other words: “don’t forward my query params” is treated as a preference about noise, not permission to break someone’s ad attribution. If you operate any kind of redirect layer — shortener, marketing vanity domains, a legacy-URL mapper — I’d encourage the same default.

wbraid and gbraid: gclid’s iOS-era cousins

If you inspect ad-click URLs from iOS devices, you may see wbraid or gbraid instead of gclid. Google introduced these for traffic affected by Apple’s App Tracking Transparency rules, where the classic per-click identifier isn’t available: wbraid appears on web-to-web flows and gbraid on web-to-app flows. They are privacy-conscious identifiers rather than drop-in replacements — they support more aggregated measurement, and conversion upload endpoints accept them alongside gclid.

For an engineer, the operational takeaway is simple even if the measurement details are Google’s problem: treat all three parameters identically in your infrastructure. Capture them, store them with leads, and preserve them through every redirect — which is exactly why the snippet above forwards all three, not just gclid.

Bottom line

• gclid is a per-click, opaque identifier that Google Ads auto-tagging appends to your landing page URLs. It is a lookup key; the campaign and keyword data live on Google’s side.
• Leave auto-tagging on. It powers GA4 attribution for Google Ads traffic and is the prerequisite for offline conversion imports.
• If sales close off-site, capture gclid into your CRM at lead time and upload conversions regularly — that closed loop is what lets bidding optimize for actual revenue.
• Use UTM parameters alongside auto-tagging for non-Google tools, not instead of it.
• Audit every redirect, shortener, and CDN rule between ad and landing page: each one must preserve the query string, or at least gclid, wbraid, and gbraid. Stripping them costs nothing visibly and everything in attribution.