Attribution · Google Click Identifier
The GCLID is the single most useful piece of tracking data Google hands you, and most accounts waste it. It is the thread that ties an ad click to a signed deal in your CRM, which is the whole game in lead generation. Here is exactly what it is, how the related identifiers work, the windows that constrain it, and how we build attribution on top of it.
GCLID stands for Google Click Identifier. When auto-tagging is enabled, Google appends this unique parameter to the URL a person lands on after clicking your ad, so a visit arrives at yourdomain.com/?gclid=Cj0K... and that string uniquely identifies the click. Auto-tagging is on by default for new accounts, and it is what makes the whole system work: without it, there is no GCLID and no reliable way to tell Google which specific click produced a conversion. Capture that identifier and you can connect a single ad click to whatever happens afterward, weeks later, inside your own systems. Miss it, and you are back to guessing.
Since iOS privacy changes, Google no longer always passes a GCLID. There are three parameters, and which one shows up depends on the device and path:
The standard Google Click Identifier, present on most web clicks where full tracking is available. It is the one you want, because it supports the richest offline conversion import and the longest usable window.
Appears when a user clicks an ad inside an iOS app and lands on your website. It is the privacy-preserving web identifier that replaces the GCLID in that path, and it can still be used to import conversions.
Appears when a user clicks an ad on the web and is directed to your iOS app. It is the app-side privacy-preserving identifier, used the same way for app conversions.
A robust setup captures whichever identifier is present, GCLID, WBRAID, or GBRAID, rather than only looking for GCLID and silently dropping the rest. Offline conversion import accepts exactly one of the three per conversion.
Here is the payoff. In lead generation, the sale does not happen on the website; it happens later, on a call, in a CRM, when a contract is signed. Google's bidding cannot see any of that on its own. Offline conversion import closes the loop: you store the GCLID captured on the ad click, and when that lead becomes a qualified opportunity or a closed deal, you upload the outcome back to Google Ads against that exact GCLID. Now Smart Bidding is optimizing toward real revenue, not form fills. This is the mechanism behind everything we do, and it is why the GCLID is not a technical footnote, it is the load-bearing wall.
The GCLID does not last forever, and this is where long sales cycles get caught out. Google retains the GCLID for 90 days: a conversion uploaded more than 90 days after the associated ad click will not import, so it simply will not show in your reporting or feed bidding. Enhanced Conversions for Leads is stricter still, at 63 days. Your click-through conversion window is separately configurable from 1 to 90 days. For a business whose deals close in three or four months, this is a real design constraint, and it is why we persist the identifier and reconcile deals promptly rather than in a quarterly batch. Miss the window and the revenue is invisible to Google even though it happened.
No auto-tagging, no GCLID. It is on by default for new accounts, but it gets disabled by well-meaning setups. Without it, there is nothing to capture and offline import cannot work at all.
If your site redirects the landing URL, the GCLID must be passed through to the final page. Redirects that drop query parameters silently destroy the identifier before it is ever stored.
If the GCLID is only read at form submit, every visitor who lands, navigates, and comes back has already lost it. It has to be captured on the first landing and persisted from there.
Deals that close after 90 days, or uploads that run late, never import. Long-cycle accounts lose their best conversions to a window they never accounted for.
On every account, we make sure auto-tagging is on, then capture the GCLID, or WBRAID or GBRAID, on the very first landing and persist it server-side, out of the browser's expiry rules, so it survives the weeks a real sales cycle takes. Hashed first-party data rides alongside as a recovery net for the clicks where the identifier does not survive. When a lead becomes a qualified opportunity or collected revenue in the CRM, that outcome is reconciled against the stored identifier and imported back to Google through one unified pipeline that owns hashing, validation, and deduplication, and always inside the 90-day window. The result is bidding that optimizes toward real, closed revenue rather than the cheapest form fill.
Why first-party capture matters: cookieless tracking → · The hashed recovery net: enhanced conversions for leads →
GCLID stands for Google Click Identifier. It is a unique parameter that Google's auto-tagging appends to the landing-page URL after someone clicks your ad, so each ad click can be uniquely identified. Capturing and storing it lets you connect that click to a conversion that happens later, which is the basis of offline conversion tracking.
Google retains the GCLID for 90 days. A conversion uploaded more than 90 days after the associated ad click will not import into Google Ads. Enhanced Conversions for Leads uses a stricter 63-day window. For long sales cycles, this window is a real constraint you have to design your reconciliation around.
GCLID is the standard identifier on most web clicks. WBRAID appears when someone clicks an ad in an iOS app and lands on your website. GBRAID appears when someone clicks an ad on the web and is sent to your iOS app. WBRAID and GBRAID are privacy-preserving identifiers introduced for iOS; offline conversion import accepts exactly one of the three per conversion.
Enable auto-tagging and conversion tracking, capture the GCLID on the first landing, and store it with the lead in your CRM. When the lead converts, upload the conversion back to Google Ads against that GCLID, within the 90-day window. Where a GCLID is unavailable, you can rely on WBRAID, GBRAID, or hashed user-provided data instead.
The most common causes are auto-tagging being turned off, a site redirect that strips the parameter before the final landing page, or capturing the value too late in the visit instead of on arrival. On iOS paths you may also receive a WBRAID or GBRAID instead of a GCLID, which a setup that only looks for GCLID will silently drop.
Capturing the identifier is step one. Step two is setting a bid target that means something. Google is changing how Target CPA behaves for budget-limited campaigns on August 17, 2026, and the accounts that come out ahead are the ones whose target is anchored to closed revenue rather than to form fills.
Target CPA: how it works, and what changes on August 17, 2026 →
Next Step
If you are spending $30,000 or more per month on Google Ads and your bidding still optimizes toward form fills instead of signed revenue, the GCLID is where we start. Let's talk.
Request a Proposal →