Google Ads: The Complete Guide to wbraid and gbraid Parameters for iOS Tracking
Introduction and Challenges
Apple's iOS 14.5 update and the introduction of the App Tracking Transparency (ATT) framework have disrupted the advertising attribution landscape. By requiring explicit user consent for cross-app tracking, Apple forced market players to revise their technical standards.
For Google Ads, this meant the end of using GCLID (Google Click Identifier: "?gclid=123") for non-consenting iOS users. To maintain performance measurement and continue feeding Smart Bidding algorithms, Google introduced two new privacy-centric identifiers: the WBRAID and GBRAID parameters.
This article details how these parameters work, their impact on your analytics, and most importantly, how to adapt your technical infrastructure (GTM Server-Side, Conversion API) to avoid losing any data.
💡 Key Takeaways
- End of deterministic tracking on iOS: GCLID is replaced by wbraid and gbraid for iOS traffic impacted by Apple's privacy policies.
- Aggregated and modeled approach: Unlike GCLID (centered on the unique user), WBRAID and GBRAID parameters measure performance in an aggregated manner, without identifying the individual user.
- Statistical latency: Modeled conversions via these parameters can take up to 48 hours to appear in your GA reports.
- Major technical changes (Roadmap 2025-2026): Simultaneous identifier import (GCLID + GBRAID) has been active since October 2025, and the Data Manager API became the ingestion standard in early 2026.
Understanding Identifiers: GCLID vs WBRAID vs GBRAID
To ensure compliance with the ATT framework while preserving attribution, Google has segmented its parameters according to conversion environments:
- GCLID (Google Click ID): The historical standard. It allows for deterministic and individual click tracking. It remains active for non-iOS environments (Android, Desktop) and iOS users who have consented to tracking.
- WBRAID (Web Browser Ad ID: "?wbraid=456"): Primarily used for non-consented iOS traffic (or ATT-limited). It covers "Web-to-App" and "App-to-Web" journeys, as well as Search traffic on iOS where GCLID is unavailable.
- GBRAID (Google Bridge for Attribution ID: "?gbraid=789"): Designed specifically for "App-to-App" measurement. It comes into play when a click originates from a Google property (such as the YouTube or Gmail app) and redirects the user to another app via a deep link.
Impacts on Google Analytics and Google Ads Steering
The integration of wbraid and gbraid marks the transition from "observed" reporting to "modeled" reporting.
Modeling and Latency
In Google Analytics, ATT-impacted traffic uses machine learning to fill in the absence of GCLID. This aggregated approach comes with voluntary statistical latency: there is often a delay of up to 48 hours before modeled conversions are fully integrated into reports. This delay is a built-in technical protection to prevent reverse-engineering of user identities on small conversion volumes.
Bidding and Optimization
The final goal of WBRAID and GBRAID parameters is to "re-feed" Smart Bidding models (Target CPA, Target ROAS) that were blinded by the loss of GCLID.
Google's Recommendation: During the initial transition to these parameters, avoid making manual bid adjustments. It is advisable to allow a period of about four weeks (or three conversion cycles) for the modeled data to normalize.
Technical Implementation: New Collection Standards
If you send offline conversions (Offline Conversion Imports) or leads via the Google Ads API, validation rules have become extremely strict:
- Exclusivity Rule: The
ClickConversionobject currently requires exactly one of these three identifiers: GCLID, WBRAID, or GBRAID. Providing more than one identifier will trigger a validation error. - Custom Variables: Google Ads does not support the use of custom conversion variables (custom_variables) for a conversion attributed via a WBRAID or GBRAID parameter.
- 1st-party Data Hashing: Using these parameters must be combined with Enhanced Conversions. PII data must be normalized and SHA-256 hashed.
⚠️ Crucial technical detail: For email addresses ending in @gmail.com and @googlemail.com, all dots (.) and suffixes (+) before the @ symbol must be removed prior to SHA-256 hashing to guarantee matching at Google.
Roadmap 2025-2026: Anticipate Google's Evolution
The WBRAID and GBRAID ecosystem is not static. Several major milestones will redefine how we manage these parameters:
October 2025: Dual Identifier Import
Since the major update in late 2025 (active since October 3, 2025), Google allows the simultaneous import of a GCLID and a GBRAID for the same conversion event. Google's matching engine evaluates both signals, choosing the most precise one for direct attribution, while using the second for aggregated modeling.
Source: Google Ads Developer Blog
February 2026: The Era of the Data Manager API
Since February 2, 2026, the standard Google Ads API no longer accepts
new integrators for session_attributes (which provide conversion
environment context). Google has mandated a migration to the Data Manager API, designed to consolidate the ingestion of WBRAID and GBRAID
parameters, first-party data, and session attributes into a single,
scalable engine for the entire Google Marketing Platform.
Source: Google Ads Help
The EdgeAngel View
Taking WBRAID and GBRAID parameters into account is now essential to guarantee the reliability of attribution tracking on iOS.
In 2026, basic tracking is no longer sufficient. Advertisers who succeed in maintaining a reliable ROAS are those who combine:
- Server-Side Tagging (sGTM) for robust tracking.
- Implementing Consent Mode v2.
- Hashed 1st-party data to bridge the gap of lost deterministic signals.
👉 Need an audit of your implementation or support on Server-Side GTM?
Our Data Engineering and Privacy experts are here to help you turn these technical constraints into a competitive advantage.
Learn more →Sources and Useful Links