PPC Rebels 2026 cover: GCLID, GBRAID and WBRAID click identifiers in Google Ads

GCLID, GBRAID and WBRAID: keeping the click identifier alive from ad to CRM

A familiar scene: sales closes a $12,000 deal, you try to attribute it to a campaign, and the CRM source field is empty. The cause is almost always the same — the click identifier never survived the journey from the ad to the enquiry form. It was dropped on a redirect, stripped by the CMS, overwritten by a second session, or it never arrived because auto-tagging was switched off.

This guide covers how click tagging works in Google Ads in 2026: why there are now three identifiers instead of one, how a tracking template differs from a final URL, which ValueTrack parameters are actually worth carrying, and how to build a chain where the identifier reaches the CRM and comes back as an offline conversion.

Three click identifiers instead of one

There used to be one: GCLID, the Google Click Identifier, a unique string appended to the landing page URL on click. It linked click, session and conversion.

Then cross-site tracking restrictions in browsers and on iOS broke parts of that chain. Google added two identifiers that work in aggregate — they do not identify an individual user, but they still let a conversion be attributed to a campaign:

Identifier When it appears What it enables
GCLID A standard web click on an ad Full click → session → conversion chain, offline conversion import
GBRAID App-to-web traffic under tracking restrictions (iOS) Aggregated app-to-web attribution
WBRAID Web traffic where GCLID is unavailable Aggregated web-to-web attribution

The practical conclusion for implementation: capture and store all three. Any handler reading only gclid loses traffic — and loses it unevenly. The loss concentrates in iOS users, who are frequently the more valuable half of the audience.

If your form only writes gclid to the CRM, you are systematically undervaluing every campaign that produces mobile and in-app traffic. That is not measurement error, it is a structural bias.

Auto-tagging: is it really on?

Auto-tagging is the mechanism that appends the identifier automatically. Without it, none of GCLID, GBRAID or WBRAID exist, and offline conversion import cannot function.

The check takes a minute: Account Settings → Tracking → Auto-tagging. It should be on. Then a practical test: take any ad’s final URL, append ?gclid=test123 manually and load it. The page should render normally. If the site returns a 404, redirects to the homepage, or strips the parameter, you have found your leak.

Five places the parameter dies

  1. Redirects. http to https, www to non-www, trailing slash to no slash — each hop can drop the query string. Test with a redirect chain that preserves parameters.
  2. URL canonicalisation in the CMS. Some platforms “clean” unknown parameters. Fixed by whitelisting them.
  3. Single-page applications. Client-side navigation frequently rewrites the URL and erases parameters. The fix is capturing the identifier in the first moments after load.
  4. Caching and CDN. Aggressive caching either serves the page without the parameter or, worse, caches a page carrying someone else’s identifier.
  5. The second session. A user arrives from an ad, leaves, comes back directly and then submits. If the identifier was never stored, attribution is gone.

Number five is the most common and the most underestimated. It is not fixed in Google Ads settings but on your own side: store the identifier in a 90-day cookie on first visit and inject it into hidden fields on every form. A more robust variant moves the identifier server-side so it does not depend on browser restrictions — that architecture is described in our guide to server-side tagging with sGTM.

Tracking template, final URL and suffix: who does what

Three fields that get confused constantly:

Field Purpose Relevant to review
Final URL Where the user actually lands Yes — the domain is checked
Tracking template How the resulting URL is assembled, including third-party redirects No, as long as the domain matches
Final URL suffix Parameters appended to the destination address No

The choice is simple. If you only need to append parameters — UTM tags, your own identifiers — use the final URL suffix. It is more robust: no redirect involved, and nothing breaks when a tracker is unreachable. A tracking template is only needed when traffic genuinely passes through an external redirect.

Levels and precedence

Templates and suffixes can be set at four levels: account, campaign, ad group, and ad or keyword. The lowest level that has a value wins. That produces a classic failure: a template is set at account level, one campaign has its own outdated version, parameters diverge and nobody knows why. The remedy is to keep tagging at a single level — usually the account — and override deliberately, not accidentally.

ValueTrack: which parameters actually matter

ValueTrack is a set of placeholders Google replaces with real values at click time. There are dozens; the working set is small. A solid baseline for the final URL suffix:

utm_source=google&utm_medium=cpc&utm_campaign={campaignid}&utm_content={creative}&utm_term={keyword}&mt={matchtype}&net={network}&dev={device}

What each one buys you:

  • {campaignid}, {adgroupid}, {creative}, {targetid} — numeric IDs. Unreadable by humans, but they never break when something is renamed. More reliable than names for long-term analysis.
  • {keyword} — the keyword that triggered the impression on Search. Empty on Display.
  • {matchtype} — e (exact), p (phrase), b (broad). Useful for isolating broad match in reporting.
  • {network} — g (Google Search), s (search partners), d (Display), u (YouTube search). A separate column for search partners often reveals uncomfortable truths about traffic quality.
  • {device} — m (mobile), t (tablet), c (computer).
  • {lpurl} — the final URL itself. Mandatory inside a tracking template when a redirect is involved.
  • {gclid} — can be passed explicitly, which helps when a receiving system expects a specific parameter name.

What not to do

  1. Do not carry campaign names via {campaignname}. Rename the campaign once and your analytics history splits into two unrelated sources.
  2. Do not hand-set utm_source while auto-tagging feeds GA4. Manual tags can override the automatic link and corrupt Google Ads reporting.
  3. Do not build a kilometre-long URL. Every extra parameter is another failure point and another invitation for a CMS to “tidy” the address.
  4. Do not skip encoding. Values containing spaces or non-Latin characters must be encoded or some systems will truncate the string.

A chain that survives to the CRM

The sequence worth implementing end to end:

Step 1. Enable auto-tagging and prove the parameter survives

Auto-tagging on, a test URL with a parameter loading correctly, redirects preserving the query string. Test every landing type: homepage, category, product page, standalone landing page.

Step 2. Capture all three identifiers

A script on load reads the query string looking for gclid, gbraid and wbraid. The first one found is written to a 90-day cookie together with which type it is and the click timestamp. Overwrite the cookie only on a new paid visit, not on any visit at all.

Step 3. Inject it into forms

Every form on the site gets hidden fields: the identifier, its type, the click timestamp, and where possible the UTM set. The critical detail is that those fields must be populated from the cookie rather than from the current URL — otherwise a second session wipes attribution.

Step 4. Store it in dedicated CRM fields

The deal record gets its own fields for the identifier and its type. Dumping everything into a single free-text “source” field guarantees that in six months nobody will be able to parse it.

Step 5. Send conversions back to Google Ads

When the deal changes status, the value goes back as an offline conversion — identifier, conversion time, action name and amount. This is where the loop closes: the ad platform learns which clicks produced money and optimises accordingly. Format requirements and common failures are in our guide to offline conversion import. If the deal amount is known, always pass it — value-based strategies do not work without it, as covered in conversion value and value rules.

Step 6. Add enhanced conversions as a safety net

Where the identifier is lost anyway, enhanced conversions for leads help: matching runs on hashed email or phone. It is not a replacement for the identifier but a second layer, and it noticeably improves data completeness. The mechanics are in enhanced conversions.

Calls, messengers and offline: where the click identifier is lost by design

A web form is the easy case: it has hidden fields and you can put anything in them. The difficulty starts wherever the enquiry does not come through a form.

Phone calls

A visitor sees a number on the page and dials it — the browser session has no connection to the CRM at all. There is one solution: dynamic number insertion. Each visitor is shown a number from a pool, and a call from that number links back to the session and therefore to the stored identifier. Pool size follows “peak concurrent visitors × session lifetime”; economising on numbers means one number gets shown to two people and attribution becomes a coin flip. The mechanics are covered in our piece on call tracking and call campaigns.

Messengers

Moving into a messenger takes the person out of the browser, and no cookie follows them. The working technique is a parameterised link: a short token tied on your side to the stored identifier is embedded in the deep link. The user’s first message carries the token automatically, the bot reads it and binds the conversation to the ad click. Without a token the entire thread lands in the CRM as direct traffic.

Offline locations and call centres

When the deal closes in a showroom or on site, the only carrier of the connection is what the person told you: a phone number or an email. Enhanced conversions for leads cover this case — you send Google a hashed contact and it finds the matching click. Accuracy is lower than with a direct identifier, but it is the only mechanism that works at all.

Coverage summary

Enquiry channel Linking method Expected coverage
Web form Identifier from cookie in a hidden field 75–90%
Call from the website Dynamic number insertion 60–80%
Call from the ad’s number Google Ads call reporting Campaign-level attribution
Messenger Token in a parameterised deep link 50–70%
Offline / call centre Enhanced conversions via hashed contact 30–50%

Those numbers are benchmarks for a healthy setup, not guarantees. The point is different: coverage will never be 100%, and that is fine. The goal is not perfect completeness but the absence of systematic bias, where one channel is fully visible and another is invisible entirely.

Diagnostics: finding the leak in 20 minutes

Symptom Likely cause How to check
Most CRM records have no identifier Form reads the URL instead of the cookie Walk the path: click → leave → return directly → submit
Only mobile records are empty Handler captures gclid but ignores gbraid Verify all three parameter names in the handler
Parameter disappears immediately on entry Redirect or canonicalisation Trace the redirect chain preserving the query string
Offline conversion upload rejected Expired window or wrong time format Check the upload window and the account time zone
Google Ads and GA4 differ by multiples Manual UTMs overriding auto-tagging Remove duplicate utm_source / utm_medium
Conversions arrive with zero value Amount not included in the upload Verify the value and currency columns in the export

One more layer of investigation: reconcile against the attribution model. If the identifier does arrive but the distribution across campaigns still looks odd, the issue may not be tagging but how credit is assigned across touchpoints — a separate topic covered in GA4 attribution for media buyers.

The organisational half: who keeps this alive

Tagging does not break at setup. It breaks three months later, when a developer ships a new form, a marketer launches a landing page on a subdomain, and an agency adds a redirect. So the implementation needs a maintenance routine:

  • Monthly — an end-to-end test: click an ad, submit an enquiry, confirm the identifier reached the CRM.
  • On every new landing page — verify parameter persistence before release, not after.
  • Quarterly — measure the share of enquiries carrying a non-empty identifier. A healthy benchmark is 75–90% for web forms; anything under 60% needs investigation.
  • On any CMS or CDN migration — a full re-check. This is the single most common cause of sudden tagging loss.

Correct tagging is not about tidy dashboards. It is about the bidding automation receiving an honest signal. The algorithm optimises toward what it can see; if half your deals are invisible to it, it will faithfully optimise toward the visible half and push budget in the wrong direction. Two adjacent settings worth fixing in the same pass: customer types and lifecycle goals and the general account audit checklist.

If the blocker is not analytics but account access and category limits, start with the foundation: see how Google Ads agency accounts work and what a managed PPC setup covers.

FAQ

What is the difference between GBRAID and WBRAID in plain terms?

GBRAID appears when a user moves from an app to the web under tracking restrictions; WBRAID when the journey stayed within the web but a standard GCLID was unavailable. Both work in aggregate: they cannot identify a person, but they can attribute a campaign.

Should I disable auto-tagging if I use UTM parameters?

No. Auto-tagging and manual tags coexist. Turning auto-tagging off is nearly always a mistake: offline conversion import and the analytics linkage both stop working without it.

Tracking template or final URL suffix?

Suffix, if you only need to append parameters. A template only when traffic genuinely routes through an external redirect. The suffix is more robust and adds no extra failure point.

How long is a GCLID valid for offline conversion import?

Uploads are accepted within a limited window after the click, and that window relates to your account’s attribution settings. The practical advice is to export deals to Google Ads on a regular cadence rather than quarterly — the closer to the click date, the lower the risk of rejection.

Can attribution be reconstructed retroactively if identifiers were never stored?

Not fully. Enhanced conversions for leads recover part of it through hashed contact matching, but only from the moment of implementation. Historic data does not come back.

The identifier reaches the CRM but the conversion still does not import. Why?

Usually the conversion time format, the wrong time zone, or a mismatch in the conversion action name. Confirm the action was created as an Import type and that its name matches your file character for character.

How do I handle this on a heavily cached site?

Exclude ad parameters from the cache key, or process the identifier client-side before the cached page is served. Caching a page together with someone else’s identifier is never acceptable.

Do I need to pass every ValueTrack parameter?

No. More parameters means more failure points. The working minimum is source, medium, campaign ID, creative, keyword, match type, network and device. Add anything else only for a specific need.

What share of enquiries carrying an identifier is normal?

For web forms, 75–90%. Below 60% almost always indicates a technical loss rather than user behaviour. For phone calls the share is lower and requires call tracking with dynamic number insertion.

Does a tracking template affect ad approval?

Not by itself, provided the final domain matches the displayed one and the redirect does not lead elsewhere. Problems begin when the redirect chain takes the user to a domain other than the one declared.

What if the site is on a website builder and I cannot add scripts?

At minimum, use a final URL suffix with UTM parameters and a hidden form field if the builder allows one. Many platforms can populate form fields from the query string natively, and the CRM link is then made through a prebuilt integration.

Is all this necessary for an ecommerce store with online checkout?

Less than in lead generation, but still yes: returns, cancellations and offline sales all require data corrections. A stored identifier also settles the awkward cases where a purchase happens weeks after the click.

Similar Posts