GCLID CRM tracking: keep the paid click attached to the lead
A GCLID can arrive on the landing page and disappear before the lead becomes a durable CRM record. Follow one real paid lead through every handoff and verify what survives.
Reviewed 26 August 2026
What matters
- Capture the click identifier when it first reaches the site and keep the original value unchanged.
- Test redirects, browser state, forms, backend payloads, CRM writes and record merges as separate handoffs.
- Keep original acquisition provenance separate from fields that are allowed to change on later visits.
- Preserve GCLID together with first-party data and supported BRAID parameters when they are available.
- A GCLID in the CRM confirms local continuity; Google matching and conversion quality require separate checks.
Follow one paid lead through every handoff
Test the same identifier at each boundary. A field that exists somewhere in the stack is weaker evidence than a value you can trace from the landing URL to the final CRM record.
- 01Ad clickGCLID / BRAID arrives in the URL
- 02Landing pageRedirects preserve the parameter
- 03Browser stateThe identifier survives navigation
- 04Lead captureForm or channel handoff carries context
- 05Backend / CRMThe same value is written to the lead
- 06LifecycleMerges and automations preserve provenance
Preserve the full identifier set Google supplies
Google's current offline-import guidance uses several matching signals. Preserve each supported value when it is available and keep its meaning explicit.
| Signal | Role | Capture rule |
|---|---|---|
| GCLID | Specific Google ad-click identifier | Store unchanged and keep it linked to the corresponding lead |
| GBRAID / WBRAID | Privacy-preserving URL identifiers used in supported measurement flows | Capture whenever supplied instead of assuming GCLID will always be present |
| User-provided data | Email / phone data used by enhanced conversions for leads | Collect and process under Google's implementation guidance and applicable consent requirements |
| Lead / CRM ID | Your internal continuity key | Keep stable across system handoffs and record updates |
What GCLID is doing in the CRM path
With auto-tagging enabled, Google can append a Google Click ID (GCLID) to eligible ad-click URLs. For click-based offline conversion workflows, the website can capture that value, store it with the corresponding lead and later return it with a business outcome so Google Ads can connect the imported event to the original ad interaction.
Use the final CRM record as the continuity check. Landing-page presence alone is insufficient because redirects, navigation, forms, backend writes and CRM automations can each alter what survives.
Preserve the value exactly as received
Google documents GCLID as case sensitive. Store the original value without converting case, truncating it or rebuilding it from other fields. Treat the captured click ID as acquisition evidence that should survive later visits and CRM automations.
Keep original acquisition fields separate from last-touch or most-recent-source fields. A returning lead can legitimately have a new session source without erasing the paid-click identifier captured when the record was first created.
GCLID now sits beside other matching signals
Google recommends enhanced conversions for leads for new offline-conversion implementations and advises advertisers to continue importing existing GCLIDs whenever they are available. User-provided data, GCLID and other supported identifiers can be supplied together.
Google also documents GBRAID and WBRAID as privacy-preserving URL parameters that can strengthen offline-conversion measurement when GCLID is unavailable or at risk of being dropped. A current capture design should preserve the identifiers Google supplies rather than assume every paid visit will be represented by GCLID alone.
What a GCLID in the CRM confirms
A stored GCLID confirms that a Google click identifier survived into the business record you inspected. Matching, bidding suitability and causality each require separate evidence.
Use the CRM record to verify acquisition continuity. Use offline-conversion diagnostics and reconciliation to verify the outbound event and the business outcome attached to it.
Find the handoff where acquisition provenance disappears
| Handoff | Typical failure | Evidence to inspect |
|---|---|---|
| Ad → landing | Redirect or URL rewrite removes query parameters | Original click URL, redirect chain and final landing URL |
| Landing → browser state | Identifier is read once but not retained across navigation | Storage value before and after page changes |
| Browser → form | Some forms omit the hidden identifier field | Rendered form and submitted payload for each form variant |
| Form → backend | Frontend has the value but the server payload drops it | Network request, webhook payload and backend logs |
| Backend → CRM | Mapping, normalization or automation changes the value | Incoming payload, CRM field value and write history |
| CRM lifecycle | Merge or later-source automation overwrites acquisition provenance | Duplicate rules, merge history and field-update workflow |
Run one controlled lead before trusting aggregate reports
- 1. Start with the URLRecord the exact GCLID or BRAID value visible when the test visit lands.
- 2. Navigate normallyUse the same pages, redirects and form path a real lead uses.
- 3. Inspect the submitConfirm the identifier travels in the actual request or controlled channel handoff.
- 4. Inspect the CRM writeCompare the stored value character-for-character with the original.
- 5. Trigger lifecycle rulesTest duplicate detection, merge logic, owner changes and later-source updates.
- 6. Export it back outVerify the identifier and lead ID are still available to the offline-conversion process.
Treat the website-to-WhatsApp jump as a new identity handoff
The browser session and the WhatsApp conversation are separate identity contexts. Connecting the eventual CRM contact to the paid session requires an explicit reference or backend linkage controlled by the implementation.
AdzCapture
AdzCapture traces click identifiers and source context through landing pages, forms, redirects, WhatsApp and the CRM record.
Google documentation
Related guides
Need to check this in a real account?
We trace the relevant Google Ads, website and CRM evidence before recommending a tracking or bidding change.