GCLID, GBRAID and WBRAID: How to Connect Paid Clicks to CRM Leads
Preserve available Google Ads attribution identifiers through the landing page, accepted form and CRM record, then associate the eligible business outcome with that record. An identifier helps measurement; it does not prove that the visitor is human, the contact owns the submitted details or the lead is valuable.
Quick answer
Keep GCLID, GBRAID and WBRAID as separate fields, alongside a stable lead ID, event times and the applicable permissions. Use the supported upload path and diagnostics for the conversion destination. Never create a missing identifier or treat an accepted upload as proof of attribution or lead quality.
- Preserve available identifiers and a stable lead association.
- Keep event time, qualification and upload receipt as separate fields.
- Review final matching and diagnostics without treating attribution as identity proof.
For marketing, analytics, media buying and security teams reviewing paid traffic quality. This guide is technical and operational information, not a legal finding about a specific source.
Identifier mapping: preserve meaning, not just a string
Google's Data Manager API exposes separate gclid, gbraid and wbraid fields in AdIdentifiers. Their presence does not create a universal person identifier or guarantee a row-level CRM match.
| Identifier | Measurement role | Suggested CRM evidence field | Important limit |
|---|---|---|---|
| GCLID | Google ad-click identifier used for attribution | gclid, captured unchanged when available | Association with an ad click does not validate the enquiry |
| GBRAID | Identifier associated with app events from iOS ad journeys | gbraid, separate from gclid | Not a general-purpose identity for a person or arbitrary browser session |
| WBRAID | Identifier associated with web events from iOS ad journeys | wbraid, separate from gbraid | Privacy-aware measurement does not guarantee an observable one-click-to-one-lead join |
| Internal lead / event ID | Your own stable association and event deduplication key | lead_id and a separate unique outcome event ID | Not a replacement for a Google attribution identifier |
A practical form-to-CRM evidence flow
Conceptual flow: paid visit → authorized identifier capture → accepted form → stable lead record → assessed outcome → eligible measurement upload → diagnostics. This is an advertiser-side design example, not an existing AdFraud.pl CRM integration.
At the landing step, test redirects and parameter handling without manufacturing an ad click. At form acceptance, associate available fields with the server-created lead ID. Hidden fields are client input and can be modified; the presence of a syntactically plausible identifier is not a security validation.
Preserve separate landing, submission, qualification and conversion-event times with time zones. Keep the original attribution context and later changes traceable instead of silently overwriting it. If several visits are candidates for one lead, document the association rule and preserve ambiguity rather than joining solely by IP address.
Separate accepted lead records from browser-only submission events
Measure evidence coverage before importing outcomes
Count accepted lead records, records with each available identifier and records reliably associated with an assessed outcome. Report overlaps rather than adding identifier counts as though they were distinct people. Capture failure, refusal, unsupported journeys and ambiguous association remain separate reasons for missing evidence.
Identifiers are useful for matching, not a licence to collect every available field. Apply the relevant consent, data terms, access restrictions and retention rules. Avoid putting contact details or full lead records into analytics URLs and logs. Hashing contact data does not remove the need for permissions and a valid processing basis.
Data Manager API and current offline upload requirements
The Data Manager API Event resource supports a destination, event timestamp, attribution fields and other conversion information. Mapping fields is only one step: the account, conversion destination, permissions and supported event configuration must also be correct. Follow the current schema rather than copying field names from an older API payload.
Google's June 2026 access restriction directs new offline-conversion upload workflows away from the Google Ads API to the Data Manager API. Some previously eligible uploaders retain legacy access; this is not a claim that every existing Google Ads API upload stopped. Verify current access and migration guidance for the actual project.
Google's offline-import guidance supports available click identifiers and eligible user-provided data, with a timestamp and event deduplication. Check the current BRAID conversion-count requirements and destination support before rollout; this guide is not a production upload recipe.
Accepted, matched and qualified are different states
An API receipt is not a final attribution result. Review validation errors, destination diagnostics, processing delay, event-time eligibility and duplicate handling. Preserve accepted-but-unresolved records until reporting is mature enough to evaluate them.
Do not infer actor identity or lead validity from successful matching. A genuine paid click can be followed by fabricated contact details, and a genuine qualified lead may lack a usable attribution identifier. Assess business quality independently, then measure how much of that assessment the paid-media system can associate.
Choose the qualified outcome separately from the matching methodDistinguish click validity from the validity of a lead
Verification checklist for conversion evidence
Before a live upload, agree who owns collection, the CRM association and the measurement destination. Retain a small, permission-appropriate test record and the expected result at each stage.
- Parameters survive the approved landing and redirect path without being renamed or invented.
- One accepted form creates the intended lead record; retries do not create extra successes.
- Outcome time, action, deduplication ID and value match the documented business event.
- Missing and ambiguous associations are reported, not forced into a match.
- Import diagnostics and final attribution results are reviewed separately from CRM qualification.
Review the evidence connecting paid traffic to business outcomes
Related reading
Sources and further verification
Platform rules, standards and detection practices change. Check the current primary source and your own measurement scope before applying a control.