What Are WBRAID and GBRAID? Google’s New Click IDs Explained

You check your Google Ads landing page URLs and notice something unfamiliar. Instead of the ?gclid= parameter you are used to seeing, some URLs now carry ?wbraid= or ?gbraid=. Your tracking setup was built around GCLID. Are these new parameters breaking your data?

Probably, yes — at least partially. WBRAID and GBRAID are Google’s privacy-compliant alternatives to GCLID, created in response to Apple’s App Tracking Transparency (ATT) framework. They appear on a growing share of your traffic, and most WordPress form tracking setups do not capture them. Here is what they are, why they matter, and what to do about it.

Why Strange New Parameters Are Showing Up in Your URLs

In April 2021, Apple released iOS 14.5 with App Tracking Transparency — a framework that requires apps to ask permission before tracking users across other apps and websites. Most users opt out. This broke the mechanism GCLID relies on for iOS users: cross-app tracking and deterministic click-to-conversion matching.

Google’s response was to create two new click identifiers that comply with Apple’s privacy requirements: GBRAID and WBRAID. These parameters appear automatically in your ad URLs when the visitor is on an ATT-affected iOS device. Google’s auto-tagging system decides which parameter to use — you do not choose.

This affects a significant share of traffic. Safari holds roughly 30-32% of the US browser market, according to StatCounter data. If you are running Google Ads, a meaningful portion of your paid clicks now arrive with one of these new identifiers instead of GCLID.

What Is GCLID (Quick Refresher)

GCLID (Google Click Identifier) is a unique string that Google appends to your landing page URL when someone clicks your ad with auto-tagging enabled. It links that specific click to your Google Ads account, campaign, ad group, and keyword. Google stores the GCLID in a first-party cookie and uses it to attribute conversions back to the exact click that produced them.

GCLID uses deterministic attribution — one click, one identifier, one conversion match. The attribution window extends up to 90 days. It remains the primary click identifier for desktop browsers, Android, and iOS users who opted into tracking.

GCLID is not going away. But for the growing share of traffic where Apple’s privacy controls block it, Google needed alternatives. That is where GBRAID and WBRAID come in.

If you have encountered issues with GCLIDs not persisting as visitors navigate your site, that is a separate (but related) problem covered in our guide on why your GCLID disappears between pages.

What Are GBRAID and WBRAID?

Both are privacy-compliant click identifiers that Google uses on iOS devices where ATT restricts traditional tracking. They differ in their measurement context:

GBRAID

GBRAID (Google Browser Ad ID) appears when the conversion being measured involves an app — for example, when someone clicks a Google ad on iOS and the conversion happens within an app, or when the click originates from within a Google app (YouTube, Gmail, Google Discover, Google Maps). It is used in app-to-app and web-to-app measurement scenarios on iOS.

Unlike GCLID, GBRAID does not function as a unique user-level identifier. It uses aggregated, modelled attribution that meets Apple’s privacy requirements. The attribution window is shorter than GCLID’s 90 days — typically limited by Safari’s Intelligent Tracking Prevention (ITP), which caps first-party cookie lifetime.

WBRAID

WBRAID (Web Browser Ad ID) is used when the conversion being measured happens on the web — specifically on iOS devices where GCLID cannot be used due to ATT restrictions. The most common scenario: someone clicks a Google ad inside the YouTube app on their iPhone and lands on your website. The URL carries ?wbraid= instead of ?gclid=.

Like GBRAID, WBRAID uses privacy-preserving, aggregated attribution rather than deterministic user-level tracking.

GCLID vs GBRAID vs WBRAID: Key Differences

Feature	GCLID	GBRAID	WBRAID
Full name	Google Click Identifier	Google Browser Ad ID	Web Browser Ad ID
Use case	General web conversion tracking	App-involved conversions on iOS	Web conversions on iOS
Platforms	Desktop, Android, consented iOS	iOS 14.5+ (ATT-affected)	iOS 14.5+ (ATT-affected)
Tracking method	Deterministic (individual click)	Aggregated / modelled	Aggregated / modelled
Attribution window	Up to 90 days	Shorter (limited by Safari ITP)	Shorter (limited by Safari ITP)
Offline conversion upload	UI or API	API only	API only
Privacy compliance	Not ATT-compliant on iOS	ATT-compliant	ATT-compliant

The key takeaway: Google’s auto-tagging system selects the appropriate parameter automatically. You do not need to configure anything in your Google Ads account — this happens behind the scenes when auto-tagging is enabled.

What This Means for Your WordPress Form Tracking

This is where it gets practical — and where most existing guides on this topic fall short.

Most WordPress form tracking setups — whether custom-built or using a plugin — only look for gclid in the URL. If a visitor arrives with ?wbraid=xyz or ?gbraid=xyz, the tracking captures nothing. That lead shows up in your inbox with zero source attribution.

From a WordPress capture standpoint, the mechanism is identical for all three parameters. A visitor arrives, the parameter is in the URL, and your tracking needs to:

1. Read the URL and detect whichever parameter is present — gclid, gbraid, or wbraid
2. Store the value in a first-party cookie so it survives internal page navigation
3. When the visitor submits a form (possibly on a different page), retrieve the stored value
4. Attach the click identifier to the form submission data as a hidden field
5. Store it alongside the lead in your database or CRM

The capture process is the same. The difference is what happens downstream in Google Ads when you try to use that data — which we cover in the next section.

If your current tracking only checks for gclid, you are blind to every iOS visitor who clicks your ad. Depending on your audience, that could be 25-35% of your paid traffic arriving with no attribution data at all.

Feeding Click Data Back to Google Ads: Where It Gets Complicated

Capturing the click identifier with each form submission is step one. Step two — sending that conversion data back to Google Ads — is where the differences between GCLID and WBRAID/GBRAID create real friction.

With GCLID, the workflow is straightforward:

1. Capture the GCLID when the lead submits a form
2. Store it alongside the lead record
3. When the lead converts (e.g., becomes a paying customer), upload the conversion to Google Ads via CSV through the Google Ads UI or via the API
4. Google matches the conversion to the original click and feeds this into Smart Bidding

With WBRAID and GBRAID, the process is more limited:

• No UI upload. The Google Ads web interface does not support offline conversion uploads using WBRAID or GBRAID. You cannot include these identifiers in a CSV upload. This is API-only.
• API required. To upload conversions attributed to WBRAID or GBRAID, you must use the Google Ads API. For most SMBs, this means either hiring a developer or using a third-party tool that handles the API integration.
• Processing delay. GCLID conversions typically process within 12 hours. WBRAID/GBRAID conversions can take up to 72 hours to appear in your Google Ads reporting, according to the Google Ads API documentation.

In July 2025, Google announced an API update (effective October 2025) that allows combining GCLID and GBRAID conversions in a single upload request — previously, each identifier type required a separate upload call. This simplifies the API integration but does not change the fundamental limitation: you still need API access.

For SMBs who have been manually uploading GCLID-based conversions via CSV, this is a significant gap. The leads that arrive via iOS are the ones you cannot upload through the interface you are used to.

Enhanced Conversions for Leads: A Workaround

There is an alternative path that sidesteps the click identifier entirely. Enhanced Conversions for Leads uses hashed first-party data — typically the email address collected in your form — to match conversions back to ad clicks. Instead of uploading a GCLID or WBRAID, you upload a SHA256-hashed email address and Google matches it on their end.

This works regardless of which click identifier was used, and it can be uploaded through the Google Ads UI. The trade-off is lower match rates compared to GCLID-based uploads, and it requires that the user was signed into their Google account when they clicked the ad.

For a detailed walkthrough of the full offline conversion tracking process, including how to set up uploads without a CRM like Salesforce or HubSpot, see our dedicated guide.

iOS 17 and Safari’s Link Tracking Protection

As if ATT was not enough, Apple introduced Link Tracking Protection (LTP) in iOS 17, which strips known tracking parameters from URLs in specific contexts:

• Apple Mail — tracking parameters stripped from links in emails
• Messages — tracking parameters stripped from links shared via iMessage
• Safari Private Browsing — tracking parameters stripped from all URLs

GCLID is confirmed to be stripped by LTP in these contexts. Whether GBRAID and WBRAID are also stripped depends on Apple’s parameter list, which is not publicly documented in full.

Currently, regular Safari browsing (non-private) does not strip these parameters. However, Apple has been testing expanded privacy features in Safari Technology Preview builds. If LTP is extended to regular Safari browsing in a future update, even GBRAID and WBRAID could be affected for normal web sessions.

The broader trend is clear: Apple is tightening privacy controls on each release. Building your tracking around a single identifier type — whether GCLID, GBRAID, or WBRAID — is increasingly risky. Server-side tracking and first-party data collection provide more durable foundations. Related challenges with tracking through embedded forms and iframes follow the same pattern: browser-side restrictions are getting stricter, and server-side approaches are becoming more important.

How to Verify You Are Capturing All Three Click IDs

Run through this checklist to make sure your WordPress site captures GCLID, GBRAID, and WBRAID correctly:

1. Verify auto-tagging is enabled. In your Google Ads account, go to Settings → Account Settings → Auto-tagging. Without this, none of these parameters appear in your URLs.
2. Test parameter acceptance. Add ?gclid=test123, ?gbraid=test456, and ?wbraid=test789 to your landing page URL and load each one. The parameter should appear in the URL bar. If your site strips or redirects away the parameter, your server configuration or a plugin is interfering.
3. Check your tracking solution. Does your lead source tracking setup read all three parameters, or only GCLID? Test by submitting your form with each test parameter in the URL and checking whether the value was captured.
4. Test on an actual iOS device. Borrow an iPhone, click one of your ads in Safari or the YouTube app, and check the landing page URL. Note which parameter appears — this is what your real visitors are seeing.
5. Verify cookie persistence. After landing with a test parameter, navigate to two or three other pages on your site, then submit the form. Check whether the click identifier was still captured. If it was lost, your tracking does not persist the value through internal navigation.
6. Check your stored data. Look at your recent form submissions in your CRM, email, or tracking dashboard. If some leads show a GCLID and others show no click identifier at all, the ones with missing data likely arrived via iOS with a WBRAID or GBRAID that your system did not capture.
7. Confirm your offline upload method. If you upload conversions to Google Ads, check whether your upload method supports WBRAID/GBRAID (API) or only GCLID (UI CSV upload). If you rely on the UI, your iOS conversions cannot be uploaded.

Frequently Asked Questions

Is GCLID being replaced by GBRAID and WBRAID?

No. GCLID remains the primary click identifier for desktop browsers, Android, and iOS users who opted into tracking. GBRAID and WBRAID only appear where Apple’s ATT framework prevents GCLID from functioning. All three coexist — Google selects the appropriate one automatically.

Do I need to change my Google Ads settings?

No changes needed in Google Ads itself. GBRAID and WBRAID are applied automatically when auto-tagging is enabled. The change you may need to make is on your website: ensuring your tracking solution captures all three parameters, not just GCLID.

Can I see GBRAID and WBRAID data in Google Analytics 4?

GA4 can attribute sessions from these parameters, but with less granularity than GCLID-attributed sessions. Since GBRAID and WBRAID use aggregated/modelled attribution, the data in GA4 is less precise at the individual session level.

Why do some of my leads show GCLID and others show nothing?

The leads with no click identifier likely arrived from iOS devices carrying WBRAID or GBRAID — parameters your tracking setup did not capture. Different devices and browsers determine which parameter Google uses, so a mix is normal. The fix is to ensure your tracking reads all three.

Will WBRAID and GBRAID work with Contact Form 7 or WPForms?

Only if your tracking solution captures them. Neither Contact Form 7 nor WPForms captures any click identifiers natively — you need either custom hidden fields that read the URL, or a tracking plugin that handles this automatically.

How long does attribution take with GBRAID and WBRAID?

GCLID-based conversions typically appear in Google Ads reporting within 12 hours. GBRAID and WBRAID conversions can take up to 72 hours to process, according to Google’s API documentation. Factor this lag into your reporting schedule.

---

The Bottom Line

GCLID still works for most of your Google Ads traffic. But the iOS/Safari share — roughly 30-32% in the US — is too large to ignore. If your WordPress forms only capture GCLID, you are losing attribution data on a quarter or more of your paid leads.

The trend is moving in one direction. Apple is tightening privacy controls with each iOS release. Google is shifting toward aggregated, modelled attribution. Building your tracking around a single identifier is increasingly fragile.

Three things to do now:

1. Audit your current tracking to see if you are capturing GCLID, GBRAID, and WBRAID (use the checklist above)
2. Store the click identifier type with each lead so you know which leads can be uploaded via the UI and which require the API
3. Consider server-side tracking as insurance against future browser restrictions — it captures data regardless of what happens in the browser