Skip to content
whitead

GCLID, GBRAID, and WBRAID

glossary google ads updated 2026.05.06 7 min read
// contents · 9 sections
  1. What the three click IDs are
  2. How each identifier flows through measurement
  3. What changed in 2025/26
  4. Common misconceptions
  5. Isn't GCLID enough if my campaigns aren't App campaigns?
  6. Should I de-duplicate GBRAID and WBRAID against GCLID?
  7. Does WBRAID modeling overlap with Consent Mode v2 modeling?
  8. Related concepts
  9. Sources

GCLID, GBRAID, and WBRAID are the three click-identifier strings Google appends to ad-destination URLs so conversions can be tied back to a specific ad click — across web, iOS apps, and the post-ATT iOS web flow. Without the right identifier flowing into your CRM, analytics, and offline-conversion uploads, Smart Bidding optimises against a partial picture of reality.

What the three click IDs are

A click identifier is a short opaque string Google adds to your destination URL when a user clicks an ad — for example ?gclid=Cj0KCQ.... Whichever ID lands on the page must be captured (typically into a hidden form field or cookie) and round-tripped back to Google through GA4, the conversion tag, or OCI via Data Manager so Google can stitch the conversion to the click (Google Ads Help: About click identifiers, 2025-09-12).

GCLID — the Google Click Identifier — is the original, used for ads that send users from any surface to a web destination. It has been the workhorse of OCI since 2013 and remains the default for desktop, Android, and most iOS browsers when third-party cookies and storage are available (Google Ads Help: Set up offline conversion imports, 2025-08-21).

GBRAID handles iOS App-to-Web journeys (ad shown in an app surface, click sends the user to a web page) when the user has granted ATT consent. Because ATT consent makes the IDFA available, GBRAID attribution is deterministic.

WBRAID covers the same iOS App-to-Web path when ATT is denied or undetermined. Without the IDFA, attribution falls back to a privacy-safe modeled signal, so reporting is partial by design (Google Ads Help: GBRAID and WBRAID parameters, 2025-10-07).

How each identifier flows through measurement

The plumbing is similar across the three IDs but the surfaces differ. The table below summarises where each ID originates and which downstream systems can consume it.

IdentifierClick originDestinationConsent / signalUsed in
GCLIDWeb (any browser)WebCookies + Consent Mode v2OCI, EC, GA4, conversion tag
GBRAIDiOS app surfaceWebATT granted (deterministic)OCI, EC, GA4 (with mapping)
WBRAIDiOS app surfaceWebATT denied / undetermined (modeled)OCI (uploaded events), modeled conversions

In practice, the URL on landing carries exactly one of gclid, gbraid, or wbraid. Your capture script should accept all three and store whichever is present alongside a timestamp, because Google's OCI Data Manager schema accepts the same upload columns for either parameter (Google Ads Help: Upload offline conversions with GBRAID/WBRAID, 2025-11-18). Once captured, the identifier feeds three downstream paths:

  1. Online conversion tag / EC: the gtag or GTM container reads the cookie and sends it back when a conversion event fires.
  2. OCI via Data Manager: for lead-gen, the click ID is stored in the CRM at form submit, then uploaded against the conversion action when the deal closes.
  3. GA4 cross-domain handoff: GA4 reads the parameter on landing, persists it in the _gcl_* cookies, and exposes it for export back into Ads via linked accounts.

What changed in 2025/26

Three shifts make click-ID hygiene more consequential than it was even a year ago. First, ATT opt-in rates remain low — Adjust's 2025 measurement benchmark reports app-side opt-in around 25-30% globally, meaning roughly two thirds of iOS app-to-web journeys land with WBRAID rather than GBRAID (Adjust Mobile App Trends 2025, 2025-04-15). Second, Consent Mode v2 enforcement in the EEA from March 2024 onward means GCLID may arrive on the page but be stripped from cookies if the user denies advertising storage — Google then fills the gap with modeled conversions, but only for advertisers running the basic or advanced Consent Mode signal (Google Ads Help: Consent mode, 2025-12-09). Third, AppsFlyer's 2025 SKAN+iOS report finds that accounts not capturing WBRAID at all show iOS web-conversion deltas of 30-45% versus accounts that do, with the gap widening as Smart Bidding learns from the truncated dataset (AppsFlyer State of App Marketing 2025, 2025-06-10).

The combined practical implication: if your CRM and conversion stack still treat "GCLID or nothing" as the design, you are leaving a measurable share of iOS conversions unattributed and feeding biased signal into bidding.

Methodology note. Whitead audits the click-ID capture chain by inspecting three points: (1) the landing-page capture script — does it read all three parameters and persist them with a timestamp? (2) the CRM schema — is there a single click_id column with a click_id_type flag, or only a legacy gclid column? (3) the OCI Data Manager upload — are GBRAID/WBRAID rows being uploaded against the same conversion action, or only GCLID rows? When any of these fails, the rule fires as part of the same conversion-tracking domain that drives fix-conversion-tracking-missing. Severity is anchored on the share of iOS app-driven traffic in your campaign mix; lead-gen and B2B SaaS accounts tend to surface this gap most prominently because enhanced-conversions-for-leads depends on the captured ID at form submit.

Common misconceptions

Isn't GCLID enough if my campaigns aren't App campaigns?

No — the click-ID type is determined by the click surface, not the campaign type. A standard Search or Performance Max campaign can still be served on iOS app inventory (in-app browser handoffs, YouTube iOS app, Discover, Search Network partners), so GBRAID/WBRAID land on web destinations of plain Search campaigns too (Google Ads Help: GBRAID and WBRAID parameters, 2025-10-07). Capture all three irrespective of which campaign types you run.

Should I de-duplicate GBRAID and WBRAID against GCLID?

No. Each landing event carries exactly one of the three; they are mutually exclusive on a given click. The CRM design pattern is one column for the value plus one column for the type — not three separate columns that you then need to reconcile.

Conceptually yes, mechanically no. WBRAID modeling fills the iOS-without-ATT gap; Consent Mode v2 modeling fills the EEA-without-ad-storage gap. Both feed into the same Smart Bidding learning signal, but they are configured in different places (Data Manager / GBRAID-WBRAID upload vs. consent signal in your CMP) and you can be missing one without the other.

Click-ID capture is the connective tissue of Whitead's measurement domain. See Conversion Tracking for the parent framework, Enhanced Conversions for hashed-PII reinforcement when click IDs are unreliable, Enhanced Conversions for Leads for the lead-gen variant that depends on captured IDs at form submit, Consent Mode v2 for the EEA modeling layer that overlaps with WBRAID, and Data-Driven Attribution for the model that consumes whatever signal these IDs deliver.

Sources

← Back to Wiki