GBRAID and WBRAID Explained: What Google's iOS Click IDs Actually Cost You

The short answer. GBRAID and WBRAID are Google Ads click parameters that carry attribution for iOS traffic where Apple’s App Tracking Transparency rules leave no GCLID. They identify a group of clicks, not a person. Both land on your web pages, both work with offline conversion imports, and neither supports custom conversion variables.

Every page ranking for this term defines the parameters. Google’s own help page does it first and does it best, so a tenth restatement is worthless to you.

Here is what the definitional posts leave out, and what actually costs you money: these are not smaller GCLIDs. They are a different kind of identifier with a different resolution, and swapping one for the other quietly changes what your measurement stack is capable of. If your capture logic looks for gclid and nothing else, you are discarding the only identifier a slice of your iOS traffic will ever carry.

Where they came from

Apple’s App Tracking Transparency policy took effect on April 26, 2021. Google’s response, in its own words: “we no longer send the Google Click Identifier (GCLID) for iOS 14 traffic coming from ads on a handful of Google apps.”

Two parameters filled the gap.

WBRAID arrived in March 2021, aimed at website and offline conversions. Google’s guidance pairs it with a first-party cookie set by the Google tag, Google Tag Manager, or Analytics with a linked Google Ads account.

GBRAID arrived in May 2021, aimed at app conversions. Google describes it as the parameter that helps “measure app conversions driven by ad campaigns on iOS,” appended to landing page URLs when auto-tagging is on for all iOS 14.5+ clicks. It is limited to Search, Shopping, Display, and Performance Max, it requires deep links to be set up correctly, and some accounts need allowlisting by their Google account manager.

The mnemonic everyone uses misleads you

The folk rule says W is for web and G is for app. People then reason that a web-only business should only ever see WBRAID, and treat a GBRAID in their logs as a bug.

It is not a bug. Look at the two definitions in Google’s Ads API documentation, which are precise about direction in a way the help center is not:

“A gbraid is a URL parameter that is present when a user clicks on an ad on the web and is directed to your iOS app.”

“A wbraid is a URL parameter that is present when a user clicks on an ad in an iOS app and is directed to your webpage.”

Read those twice. GBRAID describes a click that started on the web. WBRAID describes a click that started in an app. If you assumed the letter told you where the click came from, you had it backwards.

More importantly, the letters describe what the parameter is built to measure, not where it lands. Both get appended to landing page URLs. That is why the top Reddit thread on this keyword is an advertiser asking why they are “getting gbraid instead of gclid from search traffic,” with no good answer underneath it. Auto-tagging appends GBRAID on iOS 14.5+ clicks. It shows up on your website whether or not you have an app, whether or not you ever asked for it.

So the practical rule is simpler than the taxonomy: on iOS you may receive GCLID, GBRAID, or WBRAID, and you do not get to choose. Build for all three.

What you give up, concretely

This is the part no competitor has written down. A GCLID identifies a click. A braid identifies a bucket of clicks that Apple’s rules will not let Google resolve any further. That resolution gap shows up in four specific places.

The custom variables limitation is the one that bites, and it is stated flatly in Google’s API documentation: “Google Ads does not support custom conversion variables in combination with wbraid or gbraid.” If you pass custom variables on offline imports to segment by lead quality, deal size, or product line, that segmentation disappears for every braid-keyed conversion you upload. Google’s troubleshooting table lists a VALUE_MUST_BE_UNSET error for a braid-keyed row that carries them, and the fix it gives is to unset custom_variables. Do that and the conversion imports, but the dimension you built your reporting on is absent for part of your iOS traffic.

Two more operational notes worth having before you need them. Google recommends populating the consent field on imports, warning that without it “it’s possible that your conversions won’t be attributable.” And IP address matching is not supported for users in the EEA, the UK, or Switzerland, so any enrichment logic that leans on IP needs a regional branch.

They are not a replacement, and Google says so

The framing in almost every guide on this keyword is substitution: GCLID is gone on iOS, braids take its place. Google’s own API documentation contradicts that directly.

“In some cases you may be able to associate both a gclid and a gbraid with a conversion. In such cases we recommend setting both the GCLID and GBRAID onto the conversion message in your import request.”

Both. Not whichever one you found first. Until October 3, 2025 the API rejected a conversion carrying both, which is why so much existing code picks one. A capture layer written as a fallback chain, “use gclid, else gbraid, else wbraid,” throws away information Google is now explicitly asking for. That fallback pattern is exactly what most tag manager setups and most tutorials implement, including, in fairness, the short version we published in our own iOS 14 tracking recovery guide. Capture them the same way, yes. Collapse them into one field, no.

The pairing has limits. A conversion carrying both gbraid and wbraid is rejected with GBRAID_WBRAID_BOTH_SET, and no documented combination pairs wbraid with gclid, so a wbraid goes on its own. Store everything at capture and choose at upload.

Here is the shape that preserves the pair:

// Capture every Google click ID present, not the first one found.
// Returns null when the URL carries none, so callers can branch cleanly.
const GOOGLE_CLICK_IDS = ['gclid', 'gbraid', 'wbraid'];

export function readGoogleClickIds(url = new URL(location.href)) {
  const found = GOOGLE_CLICK_IDS
    .filter((key) => url.searchParams.has(key))
    .reduce((acc, key) => {
      acc[key] = url.searchParams.get(key);
      return acc;
    }, {});

  return Object.keys(found).length ? found : null;
}

// At upload time, send the combination Google accepts: gclid and gbraid
// together when you hold both, wbraid only on its own.
export function clickIdsForUpload({ gclid, gbraid, wbraid } = {}) {
  if (gclid || gbraid) {
    return { ...(gclid && { gclid }), ...(gbraid && { gbraid }) };
  }
  return wbraid ? { wbraid } : {};
}

// Store everything at capture: you cannot recover a parameter you decided
// not to store six weeks ago. Google de-duplicates on the order ID.
export function buildConversionPayload(stored, order) {
  return {
    ...clickIdsForUpload(stored ?? {}),
    orderId: order.id,
    value: order.total,
    currency: order.currency,
  };
}

The failure mode nobody warns you about

Buried in Google’s iOS 14 guidance is a line that reads like boilerplate and is not: “a small percentage may need to allow arbitrary URL parameters on their website.”

Translated: some site platforms, some CDN configurations, and a good number of aggressive caching rules strip query parameters they do not recognize. They were configured years ago against a list containing gclid and utm_*. Nobody went back and added the braids. The parameter arrives at your edge and never reaches the page, so your tag captures nothing, and the traffic looks organic.

You can test this in under a minute. Append ?gbraid=test123 to a landing page URL, load it, and read location.search in the console. If the parameter is missing, it is being stripped upstream and no amount of tag configuration will fix it. That single check is worth more than most of what is written about these parameters.

Why server-side changes the arithmetic here

Braids are aggregate identifiers, which means they are already the degraded tier. Losing them on top of that leaves campaign-level attribution with nothing at all.

Two things make them survivable. The first is durable storage: a click ID captured on landing has to still exist at conversion, which on Safari means a cookie set in an HTTP response from your own server rather than one written in JavaScript and capped at seven days. The second is sending them from your server rather than the browser, where ad blockers and extensions are not a factor. Server-side conversion tracking is the general form of both.

This is the problem Convultra is built for. One line of JavaScript captures gclid, gbraid, wbraid, fbclid, msclkid, and oppref at first touch with a 90-day retention window and persists them server-side, and conversions are delivered server-side to Google Ads and OpenAI Ads today, with Meta, Microsoft Ads, and TikTok coming soon. Match rate on the conversions we capture runs at about 98 percent against the 30 to 40 percent that browser pixels typically lose. Verify that against your own backend numbers rather than taking ours on faith, which is the only honest way to read any vendor’s accuracy claim.

Where Convultra is the wrong tool: if your conversions happen inside an iOS app, GBRAID’s real job is app measurement, and that runs through Firebase or an app attribution partner, not through a web tracking product. We are not that, and a web-side capture layer will not make us that.

And the ceiling is real regardless of vendor. If the parameter was stripped before your page loaded, nothing recovers it. If a user declines consent, nothing recovers that either. Anyone selling per-click recovery on aggregate-identified traffic is describing fingerprinting, which Apple is actively hunting.

One date to put in your calendar

If you upload offline conversions through the Google Ads API, there is a deadline that has already passed and may affect you retroactively. As of June 15, 2026, UploadClickConversions requests fail if the developer token has not previously sent offline conversion or enhanced conversions for leads uploads, and a restricted caller gets a CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE error. Google has since deprecated developer tokens in favor of Google Cloud projects, and says the restriction remains in effect. New integrations built on the old endpoint do not work; they are expected to use the Data Manager API instead.

Existing uploaders with history are not cut off by that particular rule. If you are standing up a new offline import in 2026, build it on Data Manager from the start.

What to do this week

1. Grep your capture code for gclid. If gbraid and wbraid are not next to it, you are losing iOS attribution silently.
2. Run the ?gbraid=test123 strip test on your top three landing pages.
3. Check whether any offline import you run depends on custom conversion variables. If it does, strip them from braid-keyed rows before upload, accept that those rows will arrive without them, and stop reconciling a gap that is working as designed.
4. Confirm your click IDs survive longer than seven days, which on Safari means server-set cookies. Our Google Ads conversion tracking guide covers the full setup, and the iOS 14 tracking recovery guide covers which Apple system is costing you what.

The parameters are not the problem. Assuming they behave like a GCLID is.

FAQ

What is the difference between GBRAID and WBRAID?

Per Google’s Ads API documentation, GBRAID is present when a user clicks an ad on the web and is directed to your iOS app, and WBRAID is present when a user clicks an ad inside an iOS app and is directed to your webpage. Both are appended to landing page URLs, so a web-only advertiser can receive either one.

Why am I getting GBRAID instead of GCLID on search traffic?

Google stopped sending GCLID for iOS traffic originating from several Google apps after Apple’s App Tracking Transparency policy took effect on April 26, 2021. Auto-tagging appends GBRAID on iOS 14.5 and later clicks instead. It is expected behavior, not a misconfiguration, and it appears on web landing pages whether or not you have an app.

Do GBRAID and WBRAID replace GCLID?

No. They are aggregate identifiers that cover traffic where GCLID is unavailable, and they identify a group of clicks rather than an individual one. Google’s API documentation recommends sending both a GCLID and a GBRAID on the same conversion when both are available, so treat them as additional identifiers rather than substitutes.

Can I use custom conversion variables with GBRAID or WBRAID?

No. Google Ads does not support custom conversion variables in combination with wbraid or gbraid. Google documents a VALUE_MUST_BE_UNSET error when a braid-keyed conversion carries them, so strip them before upload. The conversion then imports without that data, which breaks any reporting that segments on those dimensions.

How long do GBRAID and WBRAID click IDs need to be stored?

Long enough to cover your full consideration window. Safari’s Intelligent Tracking Prevention caps JavaScript-set cookies at seven days, so click IDs stored client-side often expire before the conversion happens. A cookie set in an HTTP response from your own server avoids that cap. Convultra retains captured click IDs for 90 days.

Are GBRAID and WBRAID stripped by browsers or CDNs?

They can be. Google notes that some advertisers need to allow arbitrary URL parameters on their website for campaign measurement to work. Caching rules and platform allowlists written years ago often permit gclid and utm parameters but not the braids. Test by loading a landing page with ?gbraid=test123 appended and checking whether the parameter survives to the page.

See what your iOS traffic is actually carrying

Convultra captures gclid, gbraid and wbraid on landing, keeps them for 90 days, and delivers your conversions to Google Ads server-side, so the iOS conversions your pixel never saw still reach your bidding. Start a free Convultra trial.