How to Track Offline Conversions with GBRAID and WBRAID

To track an offline conversion from a GBRAID or WBRAID journey, preserve the identifier exactly, attach it to the lead or order, join the later CRM outcome, and upload the supported conversion fields to Google. Then check Google Ads offline data diagnostics to prove the event was processed.

This guide replaces the common but incorrect idea that WBRAID means “web to app” and GBRAID is simply a backup for any blocked GCLID. Google’s current definitions are specific:

• GBRAID connects an ad click on the web to a conversion in an iOS app.
• WBRAID connects an ad click in an iOS app to a conversion on a web page.
• GCLID remains Google’s standard click identifier where it is available.

The correct setup captures every supported identifier Google provides. It does not choose one identifier in advance or manufacture a value when none is present.

First, choose the right Google Ads import path

Google recommends enhanced conversions for leads for many lead-generation setups. It uses eligible first-party customer data to improve matching and can work alongside available click identifiers. Google also supports click-based offline imports for eligible sources.

Use this decision table before asking engineering to build anything:

Read Google’s overview of offline conversion imports and current API upload guidance before selecting the method. The supported fields and restrictions vary by conversion source.

The end-to-end data flow

A working implementation has six connected steps:

Google ad click
  -> landing page receives available identifiers
  -> website or app preserves them
  -> form, order system, or CRM stores them
  -> sales or commerce system records the real outcome
  -> integration sends the conversion to Google
  -> marketer validates it in offline data diagnostics

Most failures happen between these steps. A tag can capture a parameter correctly while a redirect removes it. A form can submit it while the CRM discards the hidden field. An API can accept a request while Google later rejects or cannot process the event.

The team must test one complete record, not six isolated screenshots.

Step 1: Preserve every available identifier

Your landing-page and form stack should recognize these separate parameters:

gclid
gbraid
wbraid

Follow these rules:

1. Preserve case. Google says GBRAID values are case-sensitive. Store the exact value rather than lowercasing or rebuilding it.
2. Allow arbitrary URL parameters. Redirects, routers, landing-page tools, and security rules must not delete a parameter just because the application does not recognize it.
3. Store every available identifier. Google recommends including GCLID whenever possible and notes that GCLID and GBRAID can sometimes exist together.
4. Keep each identifier in its own field. Do not overwrite GCLID with a later GBRAID or WBRAID.
5. Never use GBRAID or WBRAID as a person ID, CRM primary key, or deduplication key. Google describes BRAIDs as privacy-preserving and non-unique.

Google’s GBRAID setup documentation specifically tells implementers to capture the value case-sensitively, configure servers to accept arbitrary URL parameters, and store GBRAID alongside GCLID.

Test this step

Use a non-production test value and follow the complete redirect chain:

https://example.com/landing?gbraid=TestValueABC123

Confirm that:

• the final landing page loads;
• the parameter remains available to the approved tracking process;
• capitalization is unchanged;
• navigation to the form does not silently erase the stored value;
• the submitted CRM record contains the same test value.

Do not send the fake value to Google Ads. This test proves collection and storage only.

Step 2: Define the business conversion

Google Ads cannot optimize toward “revenue” if the integration sends only a generic form submission. Name the business stage you want Google to learn from.

For lead generation, useful stages can include:

• qualified lead;
• sales-accepted lead;
• opportunity created;
• demo completed;
• closed-won revenue.

For ecommerce or offline retail, useful stages can include:

• paid order;
• in-store purchase;
• fulfilled order;
• cancellation or refund adjustment;
• repeat purchase.

Create or select the corresponding conversion action in Google Ads. Keep different business meanings in different actions. A form fill worth zero and a closed deal worth thousands should not be uploaded as if they are the same event.

Document who owns the stage definition. Marketing should not infer “qualified” from a page visit if Sales defines it using CRM fields.

Step 3: Store a complete conversion record

The final record needs more than a click parameter. At minimum, design fields for:

Use a unique order ID or another stable business identifier for deduplication. Do not substitute GBRAID or WBRAID because those parameters are not guaranteed to be unique.

Send consent information required by the selected Google import method. A tool cannot make a company compliant by default. Your consent policy, collection purpose, regional rules, and Google configuration must agree.

If you send user-provided data, follow Google’s normalization and hashing requirements. Do not copy a browser-side hashing snippet from a blog and assume it handles every required field, encoding rule, and consent state correctly.

Step 4: Join the CRM or offline outcome

When a person submits a form, attach the captured identifiers to the new lead. When Sales updates the lead to the agreed stage, create a conversion record using the original identifiers and the stage timestamp.

For an order, retain the click context on the order or resolved customer record. Use the actual order event and its stable order ID when preparing the conversion.

Three controls prevent common CRM failures:

1. Field persistence: verify that imports, lead merges, and lifecycle automation do not blank the identifier fields.
2. Stage auditability: retain the old stage, new stage, and transition time instead of exporting only the current status.
3. Idempotency: retrying the integration must not create a second business conversion for the same order or stage transition.

Cross-device matching is not automatic just because a BRAID was captured. The CRM, identity process, and selected Google matching method still need enough permitted data to connect the outcome.

Step 5: Send through the current Google interface

Google introduced the Data Manager API as the unified interface for sending audience and conversion data. Google recommends it for new offline data integrations.

The date matters. Since June 15, 2026, certain Google Ads API developer tokens without recent conversion-upload history are no longer allowed to start using the older upload path. A restricted request can return:

CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE

If that error appears, repeatedly retrying the same request will not fix eligibility. Plan a migration to the Data Manager API and confirm the account, data source, OAuth credentials, and destination configuration.

Existing integrations should not be changed blindly. First establish which interface is running, whether it still succeeds, what Google has announced for that token, and whether the Data Manager equivalent supports every required field.

Important BRAID limitation

Google’s current documentation says custom conversion variables are not supported for conversions identified by GBRAID or WBRAID. Do not build a reporting requirement around those variables for BRAID-keyed uploads.

Send all identifiers and eligible matching data the chosen method supports. Do not discard GCLID merely because GBRAID is present. Do not put a GBRAID value into a GCLID field.

Step 6: Validate acceptance and processing

Check offline data diagnostics in Google Ads after the upload. Review the selected conversion action, upload volume, warnings, errors, and processing status.

Separate these four states in your launch checklist:

Google says processing usually completes in less than 12 hours, but conversions keyed by GBRAID or WBRAID can take up to 72 hours. That is not a rule to upload within 72 hours. It is the maximum processing expectation stated in Google’s offline data diagnostics guidance.

Upload promptly and consistently so bidding receives current outcomes, while still following the applicable attribution window. Do not turn “daily is operationally useful” into an unsupported universal match-rate guarantee.

Implementing the flow with CustomerLabs

CustomerLabs can act as the first-party data operations layer between website activity, CRM or order outcomes, and Google Ads.

The product documentation verifies two foundations:

• CustomerLabs client-side tracking captures ad-click context such as GCLID.
• CustomerLabs identity resolution can retain external IDs and connect website, CRM, and offline activity on a resolved profile.

A CustomerLabs implementation should be reviewed at the live account seam:

1. Open the Google Ads destination and confirm the correct ad account.
2. Map each CustomerLabs event to the intended Google Ads conversion action.
3. Enable only the approved client-side or server-side events in the destination workflow.
4. Map eligible enhanced-conversion fields when that method is configured.
5. Trigger one test lead or order through the real source.
6. Confirm the later stage or purchase on the same CustomerLabs profile.
7. Verify the outbound destination event and then Google Ads diagnostics.

For GBRAID and WBRAID specifically, require evidence that the live source, form, CRM, CustomerLabs profile, and destination mapping all retain the field. A product statement or source-code capability does not prove a customer’s configured journey works.

The CustomerLabs offline conversions workflow explains how the operations layer connects later business outcomes with ad platforms. The tracking-method reference also documents website data collection and click context.

Launch checklist for the marketer

Do not mark the project complete until every answer has attached proof.

• Google Ads auto-tagging and the intended conversion source are configured.
• Redirects preserve gclid, gbraid, and wbraid test parameters.
• The site preserves parameter values without changing case.
• The CRM has separate fields for each identifier.
• The real lead, order, or stage event contains the original identifier.
• Conversion action, timestamp, value, currency, and timezone are mapped correctly.
• A stable lead or order ID prevents duplicate business events.
• Consent fields and eligible user-provided data follow the selected Google method.
• The team knows whether the integration uses Data Manager API or the legacy Google Ads API path.
• No custom conversion variable is required for a GBRAID- or WBRAID-keyed event.
• Google Ads offline data diagnostics show the test event’s outcome.
• An owner is assigned to monitor upload failures and volume drops each week.

What not to claim

A strong implementation guide must state its limits:

• Capturing an identifier does not guarantee Google will match or report the conversion.
• GBRAID and WBRAID do not create unrestricted person-level tracking across devices.
• A successful API response does not prove reporting or bidding impact.
• Enhanced conversions for leads require eligible first-party data and correct consent handling.
• Processing can take time; absence from an immediate report is not automatically a failed upload.
• Better conversion data can improve the inputs available to bidding, but no implementation can promise a specific ROAS lift.

Need to verify the complete click-to-CRM-to-Google path rather than another isolated tag? Book a demo and ask the CustomerLabs team to review one real conversion record end to end.

Official Google sources used for this guide

• Manage offline conversions with Google Ads APIs
• Set up offline conversion imports using GBRAID
• About offline conversion imports
• Google Ads API feature deprecations
• Data Manager API overview
• Check offline data diagnostics
• Upgrade to enhanced conversions for leads