Google matches fewer offline conversions when there is no GCLID: what are GBRAID and WBRAID, and should you capture them?
Short answer
Capture all three Google click identifiers at landing, store them on the server, send click ID plus hashed details together, and check whether the unmatched leads are real.
Capture the GCLID first, and capture GBRAID and WBRAID too, because Google uses them in cases where a GCLID is not available. Then treat the hashed email and phone as a fallback, not the main route. Accounts that rely on hashed details alone have reported weaker matching, and the cleanest explanation is that a click ID is a direct link to the ad click while a hashed email is a guess at who it was.
Here is the difference. A GCLID is the click identifier Google adds to the landing page URL when auto-tagging is on. Uploading a conversion with the GCLID tells Google exactly which click it came from. A hashed email or phone lets Google look for a signed-in user who interacted with your ads, which only works when that person can be found and the interaction was recent enough.
GBRAID and WBRAID are the other identifiers Google may add in some cases, notably where privacy limits on iOS prevent a standard GCLID. Check Google's current documentation for exactly when each appears and how to upload it, because the rules have changed over time. The practical point is the same: if you store only the GCLID, you lose the leads that arrived with one of the others.
One detail people hit with lead forms: practitioners report that the BRAID parameters do not behave like a GCLID for conversions set to count one per click. If your conversion is set to count once, test what the upload accepts, and read the error messages Google returns, which can be obscure.
So what should you do? On every landing, capture all three parameters if present, store them on the server and with the lead, and put them in the record that your sales team works from. Do not rely on one cookie in the browser, because script-set cookies are limited in some browsers.
When you upload, send whichever identifier you have, plus the hashed email and phone where the platform accepts them together. Several practitioners recommend sending both in one row so a missing GCLID does not lose the lead. If you see errors for rows with no GCLID, check how your upload template maps empty values, and test with a small file.
Also ask whether your match rate fell because the leads changed. If more of your submissions are junk, with throwaway emails and invented numbers, there is nothing for Google to match, and the drop is a lead quality problem, not a Google change. Read a sample of unmatched leads before you blame the platform.
DataCops captures the GCLID and the other click IDs on your own domain at the first request, keeps them on the server for up to 90 days, and sends each CRM stage back with the click ID or the hashed email and phone, counted once. Its delivery log shows each send as sent, held, skipped or failed with the reason.
What share of your leads carry a click ID today?
DataCops in short
For this question: DataCops captures the GCLID and the other click IDs on your own domain at the first request, keeps them on the server for up to 90 days, and logs every send with the reason.
DataCops is a tool that makes the ads learn from real sales: it sends booked, showed, won and paid stages from your CRM back to your ad platforms, gives every visit a bot verdict with a Real people only switch per platform, warms up new campaigns with your existing customers, and logs every send. It is not an attribution report.
How DataCops does it
- The sale after the form. HighLevel natively (lead, booked, showed, won with value, paid; cancelled, no-show and lost are never sent), any other CRM through a private webhook, matched to the click by click ID or hashed email and phone.
- The click is kept on the server. Click IDs are stored for up to 90 days, so a deal that closes weeks later still finds its click.
- Real people only. Every visit gets a bot verdict against 360+ billion IPs and 350+ monitoring points, with a Real people only switch per ad platform, off by default. CRM events carry no bot flag.
- Counted once, logged every time. Pixel and server events share an event ID, and a delivery log shows each send as sent, held, skipped or failed, with the reason.
- One script, one DNS record. Collection runs on your own domain; with DNS on Cloudflare, the free Worker reads the click at the edge before the page loads.
Best for: ad-funded businesses whose sales close in a CRM or on a call: clinics, home services, agencies, B2B and lead gen.
Ads Warmup: tell the ads who pays
Ads Warmup, DataCops' flagship feature, sends customers you already have to Meta, Google Ads and TikTok before a new campaign spends: upload a CSV (only email is required, up to 20,000 rows), see a 0 to 10 match score per person, pick the event, and send. Rows are dated when you send, and Google Ads credits only people who clicked a Google ad. Preview is free; sending needs a paid plan. Check your own consent basis for the list first. See Ads Warmup.
Ways to do this job
| Option | Best for |
|---|---|
| DataCops | CRM stages to Meta and Google Ads, with a bot verdict and a delivery log |
| Zapier or Make | One simple CRM-to-ad flow you build and maintain |
| Direct API upload | Teams with an engineer |
| Manual CSV upload | Occasional batches |
When not to use DataCops
- You want a reporting dashboard. DataCops cleans and sends what goes into your ads. It is not a multi-touch reporting layer.
- Your sales never leave one store checkout. If everything happens in one checkout, the platform's own pixel plus server events may be enough.
Sources and further reading
More on this: Google Ads offline conversions, and the complete guide to offline conversion tracking.
Read twenty unmatched leads. If most have throwaway emails, the fix is at the form, not in the upload.