WBRAID and GBRAID are tracking parameters that Google Ads adds to some ad clicks from Apple devices in place of the usual click ID. They let Google measure conversions from iPhone and iPad users in aggregate, without tying any conversion to an identifiable person, which is what Apple’s privacy rules require.
How WBRAID and GBRAID work
When auto-tagging is on, Google normally adds a GCLID to the landing page address. That click ID is unique, so when the visitor later converts, Google can match the conversion to the exact click. Apple’s App Tracking Transparency framework, which arrived with iOS 14.5 in 2021, restricts that kind of tracking across apps on iOS unless the user opts in.
Google’s answer was two parameters that identify clicks in groups rather than one by one:
- wbraid is used when someone taps an ad inside an iOS app, such as the YouTube or Google app, and the conversion then happens on your website (app to web).
- gbraid is used when the click happens on the web and the conversion happens inside an iOS app (web to app).
So a visitor may land on your site with an address ending in ?wbraid= followed by a long string, instead of ?gclid=. The Google tag reads the parameter, stores it in a first-party cookie where consent allows, and sends it with the conversion. Google then reports the conversion against the campaign, with modelling filling some of the gaps.
Why it matters
iPhones are common among UK consumers, and many Google ad clicks on iOS come through the YouTube and Google apps. If your tracking expects a GCLID and nothing else, conversions from those clicks can drop out of your reports, and Smart Bidding then learns from an incomplete picture.
The gap is widest for businesses that close sales offline. A solicitor or a builder in Manchester who uploads won deals from a CRM needs the click identifier for each lead. If the website form captures only the gclid, every lead that arrived with a wbraid has nothing to match, and the upload quietly undercounts the campaigns that produced it.
Common mistakes
- A form or CRM that stores gclid only. Keep gclid, wbraid and gbraid in separate fields.
- Redirects, link shorteners or website plugins that strip unfamiliar query parameters before the page loads.
- Expecting these parameters to behave like a GCLID. They do not identify one person, so you cannot use them to trace an individual’s journey.
- Sending more than one identifier with a single uploaded conversion. At the time of writing (October 2026), Google’s offline import expects one click identifier per conversion.
- Treating them as a way round consent. Under UK GDPR and PECR, the cookie that stores the value still depends on the visitor’s choice in your consent banner.
How to act on it
Tap one of your own ads on an iPhone from inside the Google app and look at the landing page address. Then follow the parameter through: does it survive your redirects, is it written to a cookie, and does a hidden field on your form pick it up? Add hidden fields for all three identifiers and pass them into your CRM with each enquiry.
If you import offline sales, update the upload so each row sends whichever identifier was captured. Set up enhanced conversions for leads as well, so leads can be matched with hashed contact details when no click ID was captured at all. Checking the whole chain from click to CRM is a standard part of my Google Ads management work.