How Do You Capture gbraid and wbraid?

Capture gbraid and wbraid from the URL on the landing page, store them server-side against the visitor, and carry them onto the lead record so they are still present when you upload the offline conversion weeks later.

They are Google’s iOS-era click identifiers, and they appear in place of gclid on clicks where Google can’t set one. The definitional part of this topic is well covered elsewhere. The part that breaks in production — keeping the identifier alive from a landing page, through a multi-step form, onto a CRM record, until an upload three weeks after the click — is barely covered at all, and it’s the only part that determines whether your offline conversions actually attribute.

What are gbraid and wbraid?

Google click identifiers that appear when gclid can’t be used, introduced in response to Apple’s App Tracking Transparency framework.

• gclid — the long-standing Google Click Identifier, appended to ad destination URLs by auto-tagging.
• gbraid — used for app-to-web journeys on iOS: the click starts in an app and lands on your website.
• wbraid — used for web-to-web journeys on iOS, where privacy restrictions prevent a gclid being set.
• gad_source — a separate parameter identifying which Google surface the click came from. Useful context, not a substitute for a click ID.

The practical points matter more than the taxonomy. They are mutually exclusive: a given click carries gclid, or gbraid, or wbraid — not several. They are aggregated rather than individual by design; gbraid and wbraid support modelled, privacy-preserving attribution rather than tying a conversion to one identifiable user. And on a mobile-heavy account, a large share of Google clicks arrive with one of the braid parameters rather than a gclid — so a system that only looks for gclid is quietly blind to a substantial slice of paid traffic.

That last point is the reason this matters operationally. If your form captures gclid and nothing else, you haven’t built partial coverage; you’ve built coverage that fails hardest on exactly the device class where it costs most.

Where do click IDs actually get lost?

In the gap between the landing page and the conversion record — and there are five common places.

1. Only the landing page has the parameter. The click ID exists in the URL of the first page view. Navigate to a second page and it’s gone, unless something captured and stored it. This is the root cause behind everything below.

2. Multi-step forms lose it between steps. A funnel that moves through several pages or several form steps drops the query string on the first transition. The lead record is written at the end of that sequence, by which point the parameter has been gone for four page views.

3. Iframed forms never see it at all. Form platforms embedded in an iframe have their own URL, which is not your landing page URL. Code running inside the iframe reads the iframe’s parameters — of which there are none — rather than the parent page’s.

4. Redirects strip the query string. Link shorteners, geo-redirects, A/B testing tools and poorly configured 301s can forward a visitor without forwarding the parameters. Each hop is an opportunity for the click ID to be dropped.

5. The conversion happens days later, off-site. A lead is qualified by a salesperson, closes in a CRM, and gets uploaded as an offline conversion three weeks after the click. The click ID has to have survived not just the session but the entire sales cycle, attached to the right record.

Notice that none of these are tracking bugs. In every case the tag fired correctly and the click ID was genuinely present at the moment of arrival. The failure is one of persistence, not capture — which is why “make sure you have auto-tagging enabled” is such unsatisfying advice. Auto-tagging was already enabled. The parameter arrived. It just didn’t survive the journey to the record that needed it.

How do you persist a click ID through a funnel?

Capture on arrival, store it somewhere that outlives the page, and attach it to the record at write time.

Capture on the landing page, first thing. Read the query string on the first page view, before any navigation. Take all four parameters — gclid, gbraid, wbraid, gad_source — rather than only the one you expect.

Store first-touch, and don’t let later visits overwrite it. The click ID belongs to the visit that caused the journey. A visitor who returns directly a week later should not blank the identifier that explains where they came from.

Store it server-side, not only in the browser. A hidden form field works only if the visitor completes that specific form in that specific session. A server-side record against a durable visitor ID survives navigation, new sessions, and the gap between a form fill and a sale weeks later.

Handle the iframe case explicitly. If your form is embedded, the parent page has to pass the parameters down or the form has to ask for them. Nothing inside the iframe can read the parent’s URL on its own.

Attach it to the lead record, not just the session. The offline upload operates on lead records. A click ID sitting in an analytics session that nobody can join to a CRM row is not going to attribute anything.

What do you need for the offline conversion upload?

A click identifier, a conversion name, a conversion time and a value — with the click ID being the part that has to have survived.

Two things are worth knowing before you build this.

The identifiers aren’t interchangeable at upload. A conversion recorded against a gbraid click is uploaded as a gbraid conversion. You can’t substitute a gclid you don’t have, and you can’t merge them into one column. Whatever you capture, you have to carry through with its type intact.

There’s a conversion window, so latency matters. Offline conversions must be uploaded within the window Google accepts for the click; an upload that arrives too late is rejected rather than attributed. On long sales cycles this is a real constraint, and it argues for automating the upload rather than running it monthly by hand. Check Google’s current published window before designing around any particular figure — it has changed, and it differs between conversion types.

Enhanced conversions for leads is the complement, not the replacement. Where a click ID didn’t survive, hashed customer data — email, phone — can still let Google match the conversion. It’s a genuinely useful second path, and it has its own requirement: the hashing has to be done on properly normalised values, or it matches nothing. The two mechanisms cover different failure modes, and accounts that are serious about lead attribution run both.

How does PartialLeads persist Google click IDs?

By capturing all four Google parameters at first touch, holding them server-side against a durable visitor identity, and carrying them onto the lead record so they’re still present when the conversion uploads.

All four parameters captured, not just gclid. The tag reads gclid, gbraid, wbraid and gad_source from the landing-page URL, alongside UTM parameters and the click IDs for the other ad platforms. Capturing the braid parameters is what keeps mobile-heavy Google traffic from silently falling out of attribution.

Attribution captured from the URL, with a referrer fallback. Where the URL carries no parameters at all, the referrer is used instead — which is what makes attribution work on embedded forms whose own URL is bare.

Iframe boundaries handled by design. The tag listens for attribution passed in from a parent frame and broadcasts parameters down into iframes, so a form embedded in a funnel builder or a form platform still receives the click ID the parent page arrived with.

Stored server-side against a durable visitor ID. The visitor identifier lives in localStorage with a first-party cookie backup, and the cookie is set by the server rather than by script — so Safari’s seven-day cap on script-written cookies doesn’t apply. The click ID outlives the session that carried it.

First-touch and last-touch both written per conversion. Every matched purchase writes both rows, snapshotting the click IDs, UTM parameters, referrer and landing page. The identifier that explains the journey isn’t overwritten by a later direct visit.

Carried across the identity cluster. Sessions are unioned into one person across six tiers, so a conversion recorded weeks later inherits the click ID from the earlier session that actually carried it — including when that session was on a different device.

Upload-side normalisation handled centrally. For the hashed-data path, email is lowercased and trimmed with Gmail dot-and-plus normalisation applied before hashing, and phone is converted to E.164 with a country-code fallback derived from the session’s geography. This is unglamorous and it is the difference between a hashed identifier that matches and one that silently doesn’t.

Honest boundaries. Three. gbraid and wbraid are aggregated identifiers by design — they support modelled attribution rather than user-level certainty, and no tool changes that. Google Ads conversions are delivered through a scheduled upload rather than a real-time server-to-server API, so attribution appears on Google’s timetable rather than within seconds. And a click ID that never reached your site — stripped by a redirect before arrival — cannot be recovered by anything downstream; the hashed-data path is the fallback for that case, not a way of reconstructing the identifier.

Sources

1. Google Ads Help — About auto-tagging: https://support.google.com/google-ads/answer/3095550
2. Google Ads Help — About attribution models: https://support.google.com/google-ads/answer/6259715
3. Microsoft Learn — Offline conversions (ConversionTime and windows): https://learn.microsoft.com/en-us/advertising/campaign-management-service/offlineconversion
4. Wikipedia — E.164 international telephone numbering plan: https://en.wikipedia.org/wiki/E.164