Google Ads Click ID Guide: Why Leads Lose Their GCLID and How to Fix It

A lead value Google cannot attribute cannot influence Smart Bidding.

Everything else in your value-based bidding setup can be right. The model can be trained on real closed deals. The values can reflect meaningful differences in win rate and deal size. The feed can run every night without an error.

But if Google cannot connect an uploaded lead value to an ad interaction, that value cannot help the campaign bid better.

This is one of the most dangerous failures in lead-generation measurement, because the surrounding systems can still look healthy. Forms submit. The CRM fills up. The upload job completes. Yet the share of leads carrying a usable matching signal quietly falls, and Smart Bidding receives less of the business data you intended to send.

What Google uses to match an offline conversion

For standard web ad clicks, Google usually adds a Google Click Identifier, or gclid, to the landing-page URL when auto-tagging is enabled. Capturing that identifier and storing it with the lead gives Google a direct way to connect a later offline conversion to the original ad click.

There are two related identifiers for some iOS journeys:

• wbraid can identify an ad click in an iOS app that sends the user to a webpage.
• gbraid can identify a web ad click that sends the user to an iOS app.

These identifiers are not interchangeable, and they are not simply alternative names for gclid. Google may also associate both gclid and gbraid with the same conversion in some cases, and its API documentation recommends sending both when both are available.

Google also supports enhanced conversions for leads. This adds hashed first-party data, such as an email address or phone number, to the matching process. Google compares that data with information collected by your Google tag and with signed-in users who interacted with an ad.

The practical rule is simple: preserve every relevant identifier you can collect with consent. Google recommends including gclid wherever possible and supplementing it with user-provided data. The stronger the matching inputs, the more of your offline outcome data can contribute to measurement and bidding.

The six places click IDs disappear

1. Auto-tagging is disabled

Without auto-tagging, Google does not append gclid to eligible landing-page URLs, leaving nothing for the site to capture.

Auto-tagging is normally enabled, which is why teams often assume it is still working. It can be disabled during analytics migrations, account restructures, or changes made by an agency or implementation partner.

Check auto-tagging first. Every later fix depends on the identifier reaching the site in the first place.

2. The site never reads the parameter

The click ID reaches the address bar, but the page does nothing with it. The visitor submits a form, the form sends the fields it was built to collect, and the identifier is left behind in the URL.

Nothing appears broken. The form is working exactly as designed. It simply was not designed to capture advertising identifiers.

3. The visitor changes pages before submitting

The click ID arrives on the landing page, while the form lives on /contact, /demo, or the final step of a longer funnel. Once the visitor leaves the original URL, the new page no longer has access to that parameter unless the site stored it.

Funnels with a pricing page, multiple content pages, or a multi-step form are especially exposed to this problem.

4. A redirect removes the query string

An http to https redirect, www normalisation, geo-routing rule, consent flow, or old campaign URL can send the visitor through another URL before the final page loads. If the redirect fails to preserve the query string, the click ID disappears in transit.

Test the exact URL used in the ad. A clean final landing page does not prove that the original parameter survived the route.

5. Browser storage does not last as long as the journey

Capturing an identifier in a cookie or localStorage helps it survive navigation, but neither should be treated as permanent storage.

Safari applies a seven-day cap to script-writable storage after seven days of Safari use without interaction with the site. That includes client-side cookies and localStorage. Consent choices, browser settings and extensions can reduce coverage further.

For most same-session form submissions this is not a problem. It becomes relevant when a buyer clicks an ad, leaves, and returns much later to submit a form.

6. The CRM drops or overwrites the identifier

The website captures the click ID, but the form integration does not map it to a CRM field. Or the field is stored on the contact while the export contains deals. Or a later visit overwrites the original value, making the last interaction look like the acquisition source.

Preserve the original identifier and the latest identifier in separate fields when both are useful. Confirm that the field survives every step from form submission to the object you export.

Fix the chain in this order

1. Confirm that auto-tagging is enabled

This takes minutes and removes the simplest failure first. Then click a live ad test URL, or use an approved test method, and confirm that the expected identifier reaches the landing page.

2. Capture every relevant click identifier

Read gclid, wbraid and gbraid when they appear. Store the value in first-party storage where consent allows it, then write it into a hidden field when the visitor submits a form.

Google's offline conversion setup guide provides a sample implementation for capturing and storing gclid. Your implementation should also account for the other identifiers relevant to your traffic.

Write the value at submission time rather than only when the page loads. Many forms render after the initial page load, especially forms delivered through CRM or marketing automation tools.

The one-line script

We publish a script that does all of the above. Paste it once, before </body>, on every page that has a form, or in your site's global footer:

<script src="https://valuebasedbidding.com/vbb.js" async></script>

It has no dependencies, loads asynchronously so it never delays the page, and needs no account. Use the hosted tag rather than a pasted copy of the file, so it updates itself when the script improves. Your developer can read it as it is, unminified, or implement the same logic directly if you would rather own the code.

What it does, read from the file and no more:

• Captures the click ID from the URL. gclid from Google, plus gbraid and wbraid, which iOS sends instead of gclid and which a script watching gclid alone never sees. fbclid from Meta too. A fresh click always replaces an older one.
• Keeps it for 90 days. In a first-party cookie and in local storage, each covering for the other. Safari caps script-written storage at seven days without a visit, which is why the identifier has to reach the CRM on the day the lead arrives rather than wait in the browser.
• Adds it to every form as a hidden field. Named gclid, gbraid, wbraid or fbclid, so the value lands in your CRM under a column you can map. It adds only its own fields and never touches one your site already has under that name.
• Catches forms that load late. HubSpot, Typeform and Marketo embed their forms after the page loads. The script watches for them and fills each one the moment it appears.
• Sends nothing anywhere. It stores the ID on the visitor's own device and puts it in your form. No request leaves the page, and it reads no other field.

Then submit one test lead from a URL carrying ?gclid=test123 and open the record in your CRM. If gclid is on it, every future lead will carry the real one. The snippet page checks a live URL for the tag if you want to confirm it is installed before testing.

3. Store the identifier in the CRM immediately

Browser storage only needs to preserve the identifier until the lead submits a form. Once the lead exists, move the identifier into the CRM and keep it there as a server-side record.

This distinction matters for long sales cycles. A six-month deal cycle does not require a six-month browser cookie if the click ID entered the CRM on day one.

The hidden field arrives with the form submission under the name gclid (or gbraid, wbraid, fbclid). Most form tools store an unknown field automatically; some need a matching custom field created first. In HubSpot that is three contact properties with those exact names, which its forms then map on their own. Either way, the test lead above tells you: if the ID is on the record, the field is mapped.

4. Add enhanced conversions for leads

Enhanced conversions for leads gives Google additional matching information through hashed first-party data. Google describes it as an upgraded version of offline conversion import and recommends continuing to send existing gclid values alongside user-provided data wherever possible.

Treat the two methods as complementary. Click identifiers provide direct click-level attribution. Hashed first-party data can improve durability, including cross-device and engaged-view measurement.

5. Check the full CRM mapping

Verify that the identifier:

1. enters the hidden form field;
2. reaches the form submission record;
3. maps to the correct contact or lead field;
4. survives contact-to-deal conversion;
5. appears in the file or connection used for the offline upload.

Testing only the website is not enough. The field can disappear at any handoff.

6. Consider Google tag gateway for advertisers

Google tag gateway for advertisers serves Google tag scripts and measurement requests through your own domain and first-party infrastructure. It can be configured through a CDN, load balancer, web server, or server-side tagging setup.

This improves measurement durability more broadly. Complete the basic click ID capture, CRM mapping and enhanced conversions setup first.

Measure click ID coverage, not upload success

An upload job completing successfully does not tell you how many conversions Google could attribute.

Start with leads created during the last ninety days. For the subset attributed to Google Ads, calculate the percentage with at least one relevant click identifier. Break the result down by:

• landing page;
• form;
• browser and device;
• country or consent region;
• week of lead creation;
• CRM source and pipeline.

Call this number your click ID coverage. A non-empty CRM field shows that the identifier survived your funnel. It does not prove that Google successfully matched and attributed the imported conversion. Use Google Ads upload results and enhanced-conversion diagnostics to assess that next stage of the chain, so a healthy-looking CRM field is never mistaken for confirmed attribution.

There is no universal target across all leads, because many leads come from channels other than Google Ads. The trend within your Google Ads cohort is more useful. If coverage falls from 70% to 40%, the date, page, browser or form where it changed will usually point toward the cause.

The diagnostic checks the identifier fields in your own CRM export and reports how much of the file is ready to match. The file is read in your browser and is not stored.

Common questions

Why does a lead need the click ID at all? A conversion Google can join back to an ad click can influence bidding. A lead carrying its gclid matches that click exactly. A lead with only an email relies on Google finding the click from hashed data, which needs enhanced conversions for leads switched on and still misses a share.

I already have the Google tag. Does that not capture it? The Google tag stores the click ID in its own cookie for its own conversions. It does not put it in your form, so it never reaches your CRM, and an offline conversion uploaded months later has nothing to carry.

Does the script work with HubSpot forms? HubSpot's own tracking code records the Google click ID on contacts created through HubSpot forms, in its hs_google_click_id property, so a site using HubSpot forms with the tracking code installed may already have it. The script covers the forms HubSpot does not own. For any embedded form tool, submit one test lead after installing and check the record: whether an extra field is passed through to the CRM is the form tool's decision, not the script's.

What if the visitor comes back a week later without clicking an ad? The ID is read from storage on every page, so a lead who first arrived from an ad and returns direct a week later, or a month later, still carries it into the form. That is what the 90 days are for.

Does it need consent? It writes a first-party cookie holding an advertising click identifier, so treat it as you treat your Google tag under your consent setup: load it under the same condition. It has no dependency on a consent tool and no opinion about one.

My site is a single-page app. The script runs once when the page loads and then watches the page for new forms, so a form rendered after a client-side route change is filled when it appears. To trigger it yourself, it exposes window.vbbCapture.run().

Is it free, and do I need an account? Yes, and no. It is a static file on this site with no account behind it.

The part that matters

Value-based bidding depends on a chain: the ad interaction must reach the lead record, the lead record must carry the business outcome, and the resulting conversion value must return to Google with enough information to be attributed.

A sophisticated value model cannot compensate for a broken first link.

If you do only two things after reading this article, confirm that auto-tagging is enabled and measure click ID coverage for your recent Google Ads leads. Together, those checks tell you whether the values you calculate have a reliable path back to Smart Bidding.