Google Ads Publishes GBRAID Offline Conversions Guide: The Click ID Has to Survive the Form
Digital Marketing

Google Ads Publishes GBRAID Offline Conversions Guide: The Click ID Has to Survive the Form

Google Ads has a new Help Center document, titled “Set up offline conversions using GBRAID.” The page describes GBRAID as a privacy-preserving identifier used to measure ad performance, and it walks through how to capture the parameter and carry it into an offline conversion upload. The document itself carries no visible publish date, but Search Engine Roundtable reported it as new on July 30, crediting Shauvik Kumar with spotting the change on X.

What is GBRAID?

GBRAID is a Google Ads URL parameter, &gbraid=xyz. Google describes it as “a privacy-preserving identifier used to measure ad performance,” one that “measures conversions in a non-unique fashion (like Campaign ID) without linking them to individual users or events.” The document positions it as a signal that adds data strength to offline conversions, and warns that it is case sensitive.

The gap this closes: campaign tags stop at the form

Campaign tagging answers one question: where did this visitor come from. That answer stops mattering the moment the visitor submits a lead form, unless something carries the click identifier past that point. Google’s document frames GBRAID as built for that handoff. It calls GBRAID useful “even when Google Click ID or other fields are present,” and instructs advertisers to update every lead and transactional page so it gets passed to the back-end system, “including when the GCLID isn’t available.”

The document names two scenarios where GBRAID adds value: sites with deep links measuring in-app conversions from web campaigns, and sites where the GCLID “is at risk of being dropped.” Read plainly, teams that store only GCLID are choosing to lose exactly the rows where GCLID never made it through. GBRAID is the backstop for those rows, not a second copy of the same data.

Case sensitivity is the step that silently breaks this

The setup itself is mechanical. Add a hidden form field for GBRAID next to GCLID on every lead submission page. Capture and store the value, via cookie or local storage, on each web page or deep-linked app screen. Keep it on the same lead row as GCLID and any other signal in the lead management system.

Two lines in the documentation repeat one warning, once for each parameter: “GBRAID is case sensitive and shouldn’t be converted to upper or lower case,” and separately, “The GCLID is case sensitive, so make sure you’re uploading it correctly.” Neither line names a cause. A form handler or CRM that lower-cases query parameters as a routine hygiene step would corrupt the value before it ever reaches an upload, and nothing downstream flags it.

Uploading, and the two settings that catch teams out

Google recommends uploading through Data Manager over legacy upload methods, calling it “a resilient and feature-rich method.” Two best practices sit next to that recommendation. First, set app conversion windows at parity with web conversions, since a mismatch can delay when app conversions surface in performance metrics. Second, confirm the conversion events import into the correct MCC CID or CID for the account structure they belong to.

Where UTM parameters fit, and where they don’t

None of this changes what UTM parameters do. A UTM tells your own analytics which campaign or channel sent a visit; GBRAID lives entirely inside Google Ads’ click measurement, and per Google, “powers bidding models to deliver ads more efficiently.” They answer different questions, and Google’s document is concerned with only one of them: capture the click identifier, store it, upload it. The campaign-tagging layer still has its own job to do on the analytics side, and it is worth keeping clean on its own merits. Teams that build consistent campaign URLs with our UTM builder keep that layer tidy from the start; our UTM parameters guide covers what keeps the parameters themselves from drifting.

What to check before the next upload

Open a lead form and confirm a hidden field exists for GBRAID next to GCLID. Trace what the form handler does with both values end to end, since normalizing case anywhere in that path would corrupt the value. Store the value on the same lead record as GCLID, verify app and web conversion windows match, and confirm the account structure is correct before the next Data Manager upload.

Alex Savich

Digital marketing journalist covering MarTech, AI, SEO, and analytics for Elsop Insights.