Running ads · Updated October 11, 2026
How do I save the Google Ads click ID with each form lead?
Updated October 11, 2026
Save the Google Ads click ID in a hidden form field named gclid, filled by a script on every page that stores the ID when a visitor lands. Prefill from the page address alone loses it once someone browses to another page. Upload each booked lead within the conversion window: 30 days by default, 90 at most.
If you want Google Ads to learn which leads became jobs, save the click ID with every lead
If you run Google Ads and book work after a form lead, save the click ID in the lead record the moment the form is sent. It is the one piece of data that ties a booked job back to the ad click that started it.
With auto-tagging on, Google adds a gclid, the Google Click ID, to the address of every ad click. A click to example.com lands as example.com/?gclid=123xyz. Auto-tagging is on by default for new accounts, and Google says it is required for importing offline conversions. You can check it under Admin, Account settings, Auto-tagging.
The saved ID does two jobs. First, it sorts your leads: a lead that carries a click ID came from an ad click, and one without it came some other way or lost its ID on the way. Second, it lets you tell Google Ads which leads turned into paying work. Google's help describes the loop plainly: save the ID with the lead, and when that person converts later, "you give that GCLID back to Google Ads along with a few details about the type of conversion it was and when it happened."
Google now steers new setups to enhanced conversions for leads, which matches imported jobs on the lead's hashed email or phone number as well. That does not make the click ID optional. Google's setup guide says "It's recommended you continue to send the GCLID to maximize measurement and performance benefits," and Google reports a median 10% increase in conversions for advertisers who imported first-party data such as email addresses and phone numbers alongside GCLIDs, compared with standard offline imports. Save both: the click ID in a hidden field, and the email or phone in the visible ones.
For example
A moving company takes 80 form leads in a month. 45 of them carry a click ID, so 45 came from ad clicks. 20 of all 80 book a move, and 12 of those 20 carry a click ID. Uploading those 20 booked jobs, with click ID, email and phone where each lead has them, tells Google which searches produced paying customers rather than just form fills. Without the hidden field, the only signal Google has is the form fill.
If anyone can reach your form from a second page, store the click ID on landing, not just in the address
If your form sits on a different page from the one your ads send people to, a field that reads the click ID from the current page address will come up empty. Save the ID when the visitor lands, and fill the field from that saved copy when they reach the form.
This is the trap in most form builders' prefill features. Prefill reads the address of the page the form is on, at that moment. A visitor who lands on your home page from an ad, reads your services page and then opens your contact page arrives at the form with a clean address. The lead looks like it came from nowhere, and nothing warns you.
Google publishes a script for exactly this. Its help page on offline conversions with GCLID says to add a hidden field for the GCLID to each form and to "capture and store the GCLID (via cookie or local storage)" on every page. Its suggested script reads the gclid from the address, keeps it in the browser's local storage with a 90-day expiry, and fills any field whose id you list in the script. Google says it is "strongly recommended that you add this script to every web page on your site (not just your landing pages)," for example in the page footer, and that it can go in Google Tag Manager as a Custom HTML tag firing on All pages.
Two limits of that script are worth knowing. It reads only gclid. Google says it no longer sends a gclid for iOS traffic from "a handful of Google apps" and adds a wbraid instead, which Google's developer docs describe as present when someone clicks an ad in an iOS app and lands on a webpage. Having whoever maintains your site extend the script to save wbraid and gbraid in their own hidden fields is a small change; that is a judgment, not a Google instruction. And Google notes that you should observe "local regulations regarding cookie consent," so if your site uses a consent banner, the script belongs under the same rules as your other ad tags.
Google's sample script keeps the ID for
90 days
It stores the gclid in the browser's local storage with a 90-day expiry and fills the hidden field on any page that has one.
What to keep exactly as it arrives
Google says the GCLID is case sensitive, so store it exactly as it arrived: no trimming, no changing case, and a text field long enough to hold it whole. Google's import errors include one for a gclid that "could not be decoded," which is what a mangled ID produces.
UTM tags, the utm_source and utm_campaign values some advertisers add to ad links, can go into hidden fields the same way. They describe the campaign, not the click, so they help with reporting but cannot replace the click ID for an import.
What each form builder can do
If you use Typeform, add a hidden field and pass the click ID in through the embed
If your Typeform is embedded on your site, add a hidden field named gclid and configure the embed to hand it the value. Typeform's pricing page, checked on 2026-10-11, ticks Personalize with hidden fields for all four plans in its comparison table: Basic, Plus, Business and Growth. The table does not list the free plan.
Typeform's embed library has two documented ways in. `transitiveSearchParams` forwards named "search parameters ... from host page to form," so listing gclid passes the click ID from the address of the page the embed sits on. The `hidden` option passes values you supply, so a script on your page can hand over the ID it stored on landing. The first only works on the landing page; the second works on any page, but someone has to write that line of embed code.
Whether Google Ads can count the Typeform submission as a conversion on its own is a separate question with its own answer on this site.
If you use Jotform, name a hidden field gclid and let the embed pass the address through
If you use Jotform, add a field, hide it, and set its unique name to gclid. Jotform's help says prefill works by "key-value pairs where 'key' is the field's unique name," that "for hidden fields, you can manually add them as parameters in the URL," and that "this also works on embedded forms," with an example where the parameters sit on the host page's address.
Jotform's prefill guide names no plan requirement, and its pricing page says the free Starter plan "includes all standard features," with limits that rise on paid plans. The catch is the same as everywhere: the embed reads the address of the page it is on. A visitor who browses first arrives without the ID unless your site stores it on landing and adds it to the embed's address.
If you use Google Forms for ad leads, move them to a form that has hidden fields
If your ad leads fill in a Google Form, there is nowhere tidy to put a click ID. Google's list of question types has no hidden type. Google's Pre-fill form link fills answers in visible questions, so a click ID would show on screen as a question the visitor can edit or delete.
Google Forms is fine for surveys and internal sign-ups. For leads you want to send back to Google Ads, a builder with hidden fields is the practical choice; that is a judgment, and the question of whether Google Forms can track Google Ads conversions at all has its own answer.
If your site runs on Wix, plan for custom code, because Wix Forms has no built-in way
If you use Wix Forms on a Wix site, budget for a developer or Wix's own coding tools, because Wix documents no setting for this. Wix's help center lists adding UTM parameters to Wix Forms as a feature request and says "Currently, it is not possible to add UTM (Urchin Tracking Module) parameters to Wix Forms."
The route that exists is Velo, Wix's developer platform. Its `query()` function "gets an object that represents the query segment of the current page's URL," and `setFieldValues()` "sets Wix Form field values." Together they let code read the gclid and put it into a form field, and store it for later pages. Wix does not document a hidden field type in its form field guide, so how the field is kept out of view is part of that custom work.
If you use HubSpot forms, check the Google ad click ID property, then add your own hidden field
If your forms are HubSpot forms with HubSpot tracking on your site, look at a test contact first. HubSpot's list of default contact properties includes Google ad click ID, which it says "is automatically set by HubSpot based on a Google Click identifier (GCLID) provided by Google Ads." The page does not say under which conditions it is set, so confirm it fills on a real test before relying on it.
For a field you control, add a hidden field. HubSpot's help says hidden fields "capture known values passed at the time of submission, such as ... information from a query string or page URL," and that form fields, "including hidden fields, will automatically populate based on the query string added," keyed on the property's internal name. A custom property with the internal name gclid therefore picks up ?gclid= from the address. Two HubSpot notes matter: a required field cannot be hidden, and with Pre-populate fields for returning visitors on, a hidden value "may be overwritten."
Google lists HubSpot as a supported route for importing offline conversions, so the click ID does not have to leave HubSpot to reach Google Ads.
If your site is WordPress with Gravity Forms or WPForms, use a hidden field filled from the query string
If you build forms in Gravity Forms, add a Hidden field, tick Allow Field To Be Populated Dynamically on its Advanced tab, and set the Parameter Name to gclid. In WPForms, add a Hidden Field and set its Default Value to the Query String Variable smart tag, {query_var key="gclid"}. The Hidden Field is a WPForms "fancy field," which its docs say needs the Basic license or higher.
Watch your page cache. Gravity Forms warns that "some hosts using aggressive caching techniques, like WP Engine, are known to cache not only pages but also query string parameters," so a cached page can serve one visitor's value, or none, to the next. Both plugins read only the current address, so pair them with a store-on-landing script for visitors who browse first.
Test it, then send the jobs back in time
Test the whole path with a fake click ID before you trust a single lead
If you have just added the field, send one test lead the long way round before you trust it: land with a fake click ID, browse, submit, then check the record. It takes about five minutes and catches most of the failures described above.
- Open your ad's landing page with ?gclid=TEST123 added to the end of the address, in a private browser window. If the page redirects, check the address it ends on still carries gclid=TEST123.
- Click through to a different page of your site, the way a real visitor would, and then open the page with your form.
- Fill in and send the form with your own details.
- Open the lead in your form builder's responses, inbox or CRM. The gclid field should read exactly TEST123, in the same case.
- Repeat with the form opened straight from the landing page, and once on a phone. If the field is empty only after browsing, the store-on-landing step is missing. If it is empty every time, the field is not reading the address at all.
Delete the test leads afterwards so they never go into an upload. A made-up ID will not match any click in Google Ads.
Upload each booked job within the conversion window, and no sooner than 6 hours after the click
Once leads carry click IDs, send booked jobs back while the click is still inside the conversion action's window. Google's click-through conversion window can be set from 1 to 90 days and is 30 days by default, and an upload whose click falls outside it is rejected: Google's import error reads that the click "occurred before this conversion's click-through window."
Google also rejects a click less than 6 hours old, and says to wait 4 to 6 hours after creating a new conversion action before uploading to it. Neither matters for a job booked days later, but both trip up a same-day test.
How often you upload matters as much as the window. Google's GCLID setup page says Data Manager imports from Google Cloud Storage, Amazon S3, HTTP, SFTP and Google Sheets look back 90 days on every run, while Salesforce and HubSpot imports start with the last 14 days and then pick up changes between runs, and database sources import the last 14 days on every run. For a business whose quotes take weeks to turn into work, a regular scheduled upload is safer than an occasional manual one. If your sales cycle is longer than 30 days, raise the window on the import action first, because Google applies a changed window only to conversions from that day forward.
For example
A landscaping company quotes a garden redesign on day 3 after the click and the customer signs on day 41. With a 30-day window the upload is refused. With the import action set to 60 days before the lead came in, the same upload counts.