GBRAID replaced your GCLID: keep offline conversions working

On this page

1. GCLID and GBRAID solve different measurement cases
2. Capture all three parameters before the form or booking tool loses them
3. Upload the signal you have instead of manufacturing the one you wanted
4. Hashed data supplements click identifiers; it does not resurrect them
5. Diagnose the chain in order
6. The durable fix is a multi-identifier lead schema

Short answer: capture GCLID, GBRAID and WBRAID as separate fields, keep their original case, and store whichever identifiers arrive against the lead. Do not rename a GBRAID field to GCLID, and do not expect a hashed email to recreate a click identifier you discarded. Google now accepts BRAIDs alongside GCLID and user-provided data, so the safe design is additive: preserve every supported signal and let the upload route use the one Google supplied.

If calls or forms suddenly arrive with GBRAID instead of GCLID, that is not proof that auto-tagging failed. It means your lead pipeline has to stop treating one URL parameter as the whole identity model.

GCLID and GBRAID solve different measurement cases

A GCLID is a Google Click Identifier appended to an eligible ad click when auto-tagging is active. The familiar offline-import flow stores that case-sensitive value with the prospect, then sends it back with a later qualified-lead or sale event. Google's GCLID setup guide still requires the website and lead system to capture and retain it (Google Ads Help, checked 18 September 2026).

GBRAID is not a renamed GCLID. Google describes it as a privacy-preserving parameter that measures conversions in a non-unique way, without linking the parameter to an individual user or event. Google specifically recommends adding it where web campaigns send people into apps, or where a GCLID is at risk of being dropped (Google Ads Help, checked 18 September 2026).

WBRAID belongs to the same Braid family and appears in Google's offline-import upgrade guidance alongside GBRAID. The practical rule is simple even when the underlying modelling is not:

The mistake is building a database column called gclid, then putting every identifier into it. That hides which signal you received and forces the upload process to guess later.

Capture all three parameters before the form or booking tool loses them

Google's GBRAID guide tells advertisers to update every lead-submission or transaction page so GBRAID reaches the back end, including when GCLID is unavailable. It recommends a hidden field alongside the GCLID field, plus capture on every page through a cookie or local storage where appropriate (Google Ads Help, checked 18 September 2026).

That guidance exposes the usual failure point. The landing page receives the parameter, but the conversion happens somewhere else:

1. The visitor enters through a campaign landing page.
2. They browse two or three pages.
3. They open a form, call-tracking widget or third-party booking flow.
4. The conversion record reaches the CRM without the original identifier.

By the time the sale closes, the upload file is structurally valid but has nothing useful to match.

Store the original landing parameters once, then carry them into every conversion route. A workable lead record has separate gclid, gbraid and wbraid fields, plus the landing timestamp, conversion timestamp, conversion action and consent state used by the implementation. Keep the raw identifier exactly as received. Google's GBRAID and GCLID documentation says these values are case sensitive.

This is also where choosing the right offline upload route matters. The website capture and CRM schema come first. Data Manager, an API connection or a partner integration cannot repair a field that never reached the lead record.

Upload the signal you have instead of manufacturing the one you wanted

Google's current offline-import guidance recommends uploading all available conversion events and using supported identifiers whenever they are available. Its dedicated GBRAID guide says GBRAID can be added to existing uploads and remains useful even when GCLID or other fields are present. It recommends Data Manager for the upload path (Google Ads Help, checked 18 September 2026).

That produces three rules for the exporter:

• If a record has GCLID, map it as GCLID.
• If it has GBRAID or WBRAID, map the Braid field supported by the chosen connection.
• If it has user-provided data and the account, consent state and policy allow it, include that as an additional matching signal rather than a fake replacement ID.

Do not copy a GBRAID value into a GCLID column to satisfy a required-field check. Do not lower-case identifiers during normalisation. Do not generate one upload row per identifier unless the import design explicitly requires it; duplicate conversion keys can create errors or confusing diagnostics.

Google's import guidelines say duplicate events are identified from the combination of identifier, conversion name, date and time. They also set upload windows: standard offline conversions older than 90 days after the associated last click are not imported, while enhanced-conversion-for-leads uploads have a 63-day limit (Google Ads Help, checked 18 September 2026). A monthly export that first discovers missing IDs after the window has closed is not a reporting delay. It is lost measurement.

Hashed data supplements click identifiers; it does not resurrect them

Google's GCLID documentation describes enhanced conversions for leads as an upgraded offline import that uses hashed user-provided data to supplement the identifiers you already send. That can improve matching when a lead supplied an email or phone number. It does not mean every missing GCLID can be reconstructed.

The distinction matters for both implementation and consent:

• A click identifier records campaign interaction.
• Hashed user data is customer information used for matching.
• The upload may contain both, but one is not a textual substitute for the other.
• If the person's consent state does not allow advertising user data to be sent, hashing does not change that answer.

The practical design is covered in what enhanced conversions for leads can and cannot recover. Treat user-provided data as another permitted signal, not as an excuse to stop capturing landing parameters.

Diagnose the chain in order

When GBRAID appears and imported conversions fall, work from capture to reporting. Reversing that order wastes time in the Ads interface while the identifier is already disappearing upstream.

1. Inspect the landing URL. Confirm which of gclid, gbraid or wbraid actually arrives. Check that redirects and tracking templates preserve arbitrary parameters.
2. Inspect browser storage. Confirm the original value and case survive navigation, where storage is permitted by the site's consent implementation.
3. Inspect every conversion route. Test native forms, embedded forms, booking tools and call tracking separately.
4. Inspect the CRM record. The identifier must be attached to the same lead that later receives the qualified or sold outcome.
5. Inspect the export mapping. Verify each identifier goes to the matching field, with the correct conversion account and action.
6. Inspect upload diagnostics. An accepted file is not the same as an attributed conversion. Allow for processing, then investigate unknown-click and account-mismatch errors.
7. Reconcile against the CRM. Compare closed outcomes with accepted and attributed imports by conversion action.

The durable fix is a multi-identifier lead schema

The old implementation pattern assumed one ad click produced one GCLID and one later upload. Current Google guidance is broader: retain GCLID, add GBRAID or WBRAID when available, and supplement imports with eligible user-provided data. Your schema should be broad enough to preserve those signals without pretending they are interchangeable.

Start with separate fields and an immutable raw capture. Add a conversion export that understands which fields it is sending. Then monitor identifier coverage by landing source and conversion route. If one booking widget produces 40% of leads but 0% of stored identifiers, you have found the engineering task; no bidding adjustment will compensate for it.

If the identifier has to cross browser, server, form and CRM boundaries, that routing is part of an end-to-end analytics implementation. The upload is the final step. Reliable capture is the system.

Sources

1. 1.Google Ads Help — Set up offline conversions using GBRAID · Checked 2026-09-18
2. 2.Google Ads Help — Set up offline conversions using GCLID · Checked 2026-09-18
3. 3.Google Ads Help — Guidelines for importing offline conversions · Checked 2026-09-18
4. 4.Google Ads Help — How to upgrade offline imports · Checked 2026-09-18