Gclid, Gbraid, Wbraid: the complete guide to web-to-app attribution

Gclid, Gbraid, Wbraid : Le guide complet pour maîtriser l'attribution web-to-app
Logo Profil writer Smart Bees
By Gauthier Haicault
Last updated 28 June 2025

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:

  • Gclid, Wbraid, Gbraid: what are they?
  • The web-to-app attribution journey: how does it work?
  • In practice: the user browses before downloading — how do you keep their trail?

1. Gclid, Wbraid, Gbraid: what are they?

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. 🐝

2. The web-to-app attribution journey: how does it work?

Picture a typical user journey:

  • They tap a Google Ads ad on their phone and land on your website.
  • A smart banner appears on your site.
  • They tap the banner, which redirects them to the App Store.
  • They download and open the app.
  • The install is attributed to the original Google Ads campaign.

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.

  • Capturing the gbraid : when the user lands on your site, Google Ads auto-tagging has already appended the &gbraid=... parameter to the URL. Your MMP's web SDK (for instance the one powering AppsFlyer's Smart Banner) is built to read the parameters of the landing URL.
  • Persisting the gbraid : the web SDK has to hold on to that gbraid for the whole of the user's browsing session on your site. More on that in the practical case below.
  • Passing it to the App Store : the moment the user taps the download link (the smart banner), the web SDK passes that gbraid — along with other attribution information — to the MMP's tracking link (an AppsFlyer OneLink, for example).
  • Attribution inside the app : after installation, when the user opens the app for the first time, your MMP's mobile SDK (embedded in your app) retrieves the information from the tracking link, gbraid included. It then sends a postback to Google Ads to report the conversion, using the gbraid to attribute it to the right campaign.

How do the main MMPs handle the gbraid?

  • Adjust: receives gbraid information through deep links and link URLs. Auto-tagging must be enabled in Google Ads and the SDK properly configured to handle deep links.
  • Branch: supports conversion postbacks via gbraid. Careful — Google often requires apps to be allowlisted, so you need to contact your Google account manager to enable it. The latest Branch SDK version is required.
  • AppsFlyer: the web SDK, notably through its Smart Banners, saves the landing URL parameters (UTMs, pid and so on) for the duration of the session and applies them to the banner's outbound URL. The gbraid is preserved and passed along.

3. In practice: the user browses before downloading — how do you keep their trail?

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:

  • The first-party cookie: This is the most robust method. When you have correctly implemented the global site tag (gtag.js) or Google Tag Manager (GTM), and your Ads account is linked, the tag drops a first-party cookie on your domain by default. That cookie stores the ad click information (including the gbraid), making it available across every page of your site for the duration of the session.
  • Your MMP's web SDK: Modern MMP solutions are built for this case. Their web SDK captures the gbraid on the landing page and keeps it in browser storage (sessionStorage or localStorage) for the duration of the session.

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:

  • Always enable auto-tagging in Google Ads.
  • Make sure your website allows arbitrary URL parameters.
  • Use the latest SDK versions from your attribution partners (MMPs).
  • Work with your developers to get the deep link implementation exactly right.

In closing

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.

FAQ

What is the gclid and what is it for in Google Ads?

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.

What is the difference between gbraid and wbraid?

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.

Why does the gclid no longer work properly on iOS after iOS 14?

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.

How do you set up web-to-app tracking with an MMP such as Adjust?

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.

Does server-side tracking improve collection of gclid, gbraid and wbraid?

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.

What does losing the gclid do to my campaign performance?

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 👈