GCLID vs GBRAID vs WBRAID: Decoding Google's Ad Identifiers in 2026

If you run Google Ads, you've probably noticed something odd in your landing-page URLs. Some clicks arrive with the familiar gclid parameter. Others show up with gbraid or wbraid instead. And if your tracking only captures gclid, you're silently losing attribution data on a growing share of your traffic  because Google now uses three different click identifiers depending on the device, browser, and the user's privacy settings.

Here's what each one is, when Google sends it, and why capturing all three now matters more than ever.

THE SHORT VERSION
- GCLID is the original Google Click Identifier, used since 2005. It's the gold standard — a rich, deterministic identifier tied to a single click, carrying campaign, ad group, keyword, device, and more. But it only works where Apple allows it.
- GBRAID and WBRAID are the privacy-safe parameters Google introduced in 2021 for iOS traffic where gclid can no longer be used. They measure performance in aggregate, without identifying an individual user.

WHY THIS HAPPENED — AND WHY IT'S GOTTEN BIGGER

This all traces back to Apple's App Tracking Transparency, which landed with iOS 14.5 in 2021. On July 14, 2021, Google stopped sending gclid for traffic from several Google apps on iOS, and introduced gbraid and wbraid to keep campaign measurement and Smart Bidding working for non-consenting iOS users.

But the privacy squeeze didn't stop there, and this is the part the original version of this article predates:

- iOS 17 (September 2023) introduced Link Tracking Protection (LTP), which stripped known tracking parameters like gclid and fbclid from URLs in Mail, Messages, and Safari Private Browsing.
- iOS 26 (September 2025) extended LTP to all Safari sessions, not just private mode. That's the big one: gclid and fbclid are now stripped at scale across normal Safari browsing on updated iOS devices — while wbraid and gbraid, being aggregate identifiers, remain untouched.

In other words, the trend has moved decisively in one direction: deterministic click IDs are disappearing from iOS, and the aggregate parameters are what survive. If your attribution pipeline still assumes gclid will be there, an increasing share of your iOS conversions are going dark.

GCLID, GBRAID, WBRAID: WHEN YOU SEE EACH

- GCLID

Served on non-iOS environments (Android, desktop) and for iOS users who consented to tracking. Note that Google Search on iOS was historically less affected than other surfaces, but with iOS 26's expanded LTP, Safari stripping now hits gclid broadly.

- GBRAID

Used for web-to-app journeys — a user clicks a web ad and lands in an app. Associated with Search and Shopping campaign measurement on impacted iOS traffic.

- WBRAID

Used for app-to-web journeys — a user clicks an ad inside an app (e.g., YouTube) and lands on your website. Associated with YouTube, Display, and Discovery on impacted iOS traffic.

Both gbraid and wbraid use aggregation techniques so conversions can be attributed at the campaign level without tying behavior back to an individual, which is what makes them compliant with Apple's ATT framework where gclid isn't.

HOW GBRAID AND WBRAID ACTUALLY WORK

Like gclid, these parameters are dropped into a first-party cookie set by a Google tag (gtag.js, Google Tag Manager, or analytics.js linked to an Ads account) when a user lands on your page after an ad click. They help attribute conversions back to campaigns but do not uniquely identify the user. They work in tandem with Google's conversion modeling — they're not a replacement for it — to give the most complete measurement possible on iOS surfaces.

WILL YOU SEE FEWER CONVERSIONS?

You can, but often it's a configuration problem, not a real drop. If your servers and web attribution system aren't set up to receive gbraid and wbraid, those conversions break and vanish from reporting. The clicks happened; you just failed to catch the parameter. That's the single most common self-inflicted wound here.

WHAT TO ACTUALLY DO ABOUT IT IN 2026

The landscape has moved past "just capture the parameter." The current best-practice stack :

1. Capture all three IDs. Make sure your landing pages and attribution system accept gclid, gbraid, and wbraid (plus newer Google parameters like gad_source and gad_campaignid). If you only capture gclid, you're blind to a large and growing slice of iOS traffic.

2. Go server-side. Because Safari's LTP strips parameters before the page loads in the browser, client-side capture increasingly misses them. Server-side tagging (server-side GTM) routes tagging through your own infrastructure, which browsers treat differently than third-party domains — the most reliable way to preserve click IDs now. Google's tag gateway, expanded in early 2026, is built to exploit exactly this distinction.

3. Feed conversions back with the current APIs. Simultaneous gclid + gbraid upload has been available since October 2025, and the Data Manager API became the ingestion standard in early 2026. Make sure your conversion imports use the current path.

4. Don't rely on any single platform's number. This is the deeper point. Every one of these identifiers exists so a platform can measure its own performance — and each platform is measuring in its own increasingly partial, modeled way. Google's iOS measurement is aggregated and modeled; it's a reasonable estimate, not ground truth. The only way to know which campaigns actually drove revenue is to reconcile ad-platform data against your own first-party sales and CRM data, so no platform is left grading its own homework.

That last point is what a tool like Wicked Reports is built for: capturing click data across all these parameters, tying it to real orders and real people, and giving one unbiased view of which campaigns produced actual customers — not just which ones a platform decided to claim. See how it works in the platform overview.

FAQ

IS GCLID GOING AWAY?

Not entirely, but its reach is shrinking. GCLID still works on non-iOS environments (Android, desktop) and for iOS users who consent to tracking. But since iOS 26 extended Link Tracking Protection to all Safari sessions, gclid is now stripped at scale across normal Safari browsing on updated iOS devices. The aggregate parameters gbraid and wbraid are unaffected, which is why capturing all three is now essential.

WHAT'S THE DIFFERENCE BETWEEN GBRAID AND WBRAID?

Both are privacy-safe, aggregate identifiers used on impacted iOS traffic, and both attribute conversions at the campaign level rather than the individual level. The difference is journey direction: GBRAID covers web-to-app (click a web ad, land in an app) and is tied to Search and Shopping, while WBRAID covers app-to-web (click an ad in an app like YouTube, land on a website) and is tied to YouTube, Display, and Discovery.

WHY AM I LOSING CONVERSIONS ON iOS TRAFFIC?

The most common cause is a tracking setup that only captures gclid, or a server that isn't configured to receive gbraid and wbraid. When Safari strips gclid and your system isn't catching the aggregate parameters, those conversions break and disappear from reporting even though the clicks happened. Capturing all three parameters and moving to server-side tagging is the fix.

DO I NEED SERVER-SIDE TRACKING NOW?

Increasingly, yes. Because iOS 26's Link Tracking Protection strips parameters in the browser before your page loads, client-side capture misses a growing share of them. Server-side tagging routes through your own infrastructure, which preserves click IDs that browser-side tracking now loses.