
You are running Google Ads campaigns to promote your app and wondering how a click on the mobile web turns into an attributed in-app conversion? You are not alone — I get this question from clients all the time. With the upheaval of iOS 14 and Apple's ATT policy, tracking app conversions has become a real headache for marketers.
The gclid, our old friend, has lost its shine. So Google introduced two new parameters: wbraid and gbraid.
In this article we unpack these identifiers and, above all, walk you through the journey of the information — from the Google Ads creative to mobile measurement tools (MMPs) such as Adjust, AppsFlyer or Branch.
Contents:
Let's go back to basics.
The GCLID (Google Click Identifier):
The gclid is a unique tracking parameter Google appends to your landing page URL when a user clicks one of your ads. It lets you tie conversions on your website back to the originating campaign, keyword and ad — which is how you measure your campaigns' performance.
The impact of iOS 14 and ATT
Since Apple introduced its App Tracking Transparency (ATT) policy, if a user on iOS 14.5+ declines tracking, apps can no longer access their advertising identifier (IDFA). As a result, Google can no longer send the gclid for traffic coming from some of its iOS apps. The outcome is simple: fewer web and offline conversions reported in Google Ads, which makes campaign optimization harder for your agency or acquisition lead.
Wbraid & Gbraid:
To fill that gap and comply with Apple's rules, Google introduced two new parameters.
wbraid (Web B-roll Ad ID) : designed to measure web conversions coming from clicks in iOS apps. It works in aggregate and relies on modeling to attribute conversions to your campaigns, even without user consent.
gbraid (App B-roll Ad ID): This is the one that concerns us most here. It is specifically meant to measure in-app conversions resulting from iOS ad campaigns. It has to be appended to landing page URLs, which normally happens when auto-tagging is switched on. Worth knowing too: the gbraid is an aggregated identifier, tied to several users to preserve anonymity, and carries no unique information about the click itself.
Now that the basics are covered, let's get to the attribution part. 🐝
Picture a typical user journey:
So how does the gbraid reach your MMP (Adjust, Branch or AppsFlyer) along the way?
Worth reading too: our MMP guide.
It is a well-choreographed dance between Google Ads and your MMP's SDK.
How do the main MMPs handle the gbraid?
This is the most common scenario, and the trickiest 🤔. A user taps your ad, lands on your product page, checks the about page, reads a blog post, and finally taps the “Download the app” link in the footer. The gbraid was only present on the URL of that first page.
How do you make sure it is not lost along the way?
This is where first-party persistence comes in.
The answer is to store the gbraid on the first visit so it can be reused later. Here are the main methods:
So what actually happens?
> Page A (the landing page): the URL contains &gbraid=.... The Google tag or the MMP SDK captures that value and stores it in a cookie or in session storage.
> Pages B, C, D...: the user browses. The URL no longer carries the gbraid, but it is still in browser storage.
> Tapping the download link: when the user taps the link to the App Store (your Branch, AppsFlyer or other link), the MMP's JavaScript fires. It fetches the gbraid from the cookie or session storage and adds it dynamically as a parameter on the redirect URL.
> Attribution: the rest plays out as described above. The MMP picks up the gbraid and uses it to attribute the install to Google.
For marketers and data specialists, success comes down to a flawless technical implementation. Here is what we would keep an eye on:
The post-iOS 14 era has forced us at Smart Bees — and our clients with us — to become more technical and more precise about tracking, app tracking in particular.
The wbraid and gbraid parameters are Google's answer for keeping performance measurement reliable in a privacy-conscious ecosystem.
Got a web-to-app attribution project, or questions about your tracking?
At Smart Bees, this is our daily work. Get in touch and let's talk it through.
The gclid (Google Click ID) is a URL parameter Google Ads adds automatically on every ad click. It carries conversion data from your site or app back to Google Ads, which is what allows precise performance tracking and bid optimization through Smart Bidding.
The gbraid is used to track conversions in iOS App Store campaigns (app-to-app), while the wbraid is used for web campaigns targeting iOS users for in-app conversions (web-to-app). Google introduced both in response to Apple's iOS 14 and App Tracking Transparency restrictions.
Since iOS 14 and the App Tracking Transparency framework, users can decline tracking across apps and sites. That stops third-party-cookie-based solutions from working properly. Google introduced gbraid and wbraid to work around those limits while respecting Apple's privacy framework.
To set up web-to-app tracking with Adjust, enable gbraid and wbraid parameter support in your dashboard, implement the Adjust SDK in your app, and use universal deep links to route users correctly. Adjust then picks the parameter up from the URL and ties it to the matching install or in-app event.
Yes. Capturing these parameters server-side as soon as the user arrives avoids losses caused by ad blockers, Safari's ITP restrictions or browsers that shorten cookie lifetimes. It is a recommended complementary approach for advertisers with significant volumes. You then need to be able to pass the information on to your MMP.
Losing the gclid means under-counted conversions, degraded signals for Smart Bidding, and conversions wrongly attributed to other channels. Estimates put the loss at 10 to 30% of conversions depending on the browsers and devices in play.
Worth reading too: our articles on MMP 👈