What a GCLID is, and why yours probably dies before the job books.

Google Ads says your campaigns produced 43 conversions last month. Your schedule shows 12 booked jobs from ads — maybe. Nobody can say which keyword produced the $6,400 system replacement and which one produced six price-shoppers, so budget meetings run on vibes.

The thread that's supposed to connect those two numbers is the GCLID: a string of gibberish Google attaches to every ad click. Hold onto it from click to booked job and you can tell Google exactly which ads make you money. Drop it — and most setups drop it somewhere — and your budget optimizes toward form fills instead of revenue. Here's how the whole thing works, with zero ads jargon assumed.

What is a GCLID?

GCLID stands for Google Click Identifier. Every time someone clicks one of your ads, Google generates a unique ID for that specific click and tacks it onto your landing-page URL — the homeowner arrives at yoursite.com/ac-repair?gclid=Cj0KCQjw... and everything after gclid= is the ID.

Think of it as a claim ticket. You can't read it — only Google can — but Google's side of the ledger records everything about the click it belongs to: the campaign, the ad group, the keyword, the device, the time. Hand that ticket back later with a dollar value attached, and Google credits the exact ad that earned the money.

You don't create GCLIDs. They come from a Google Ads setting called auto-tagging, which is on by default in new accounts — Google's own GCLID definition is about two sentences long. The hard part was never generating the ticket; it's keeping it alive for the days or weeks between the click and the finished job.

Where does a GCLID live between the click and the job?

A GCLID that survives all the way to the invoice makes four handoffs. Miss any one of them and the thread is cut.

1. Click: a homeowner searches 'AC repair near me', clicks your ad, and lands on your site with ?gclid=... in the URL.
2. Browser: a small script stores the ID in a first-party cookie — a note saved in the visitor's own browser — so it survives while they read your reviews and click around your site.
3. Form: when they book or submit a form, the stored ID gets copied into a hidden field and saved onto the lead record in your CRM, right next to the name and phone number.
4. Upload: when the job is booked or completed, the GCLID goes back to Google with a conversion name, a date, and the job's dollar value.

Step 1 is automatic. Steps 2 through 4 are your responsibility, and each one is a place the ID quietly dies.

How does a GCLID die before the job gets booked?

Five failure points cover nearly every broken setup we see.

• The form never captures it. If nothing copies the gclid parameter into a hidden field, it evaporates the second the form is submitted. This is the most common break, and it's invisible — ads run, leads arrive, everything looks fine.
• The customer calls instead of clicking. A GCLID lives in a browser; it doesn't travel down a phone line. In the trades, where the highest-intent homeowners pick up the phone rather than fill out a form, that's a big share of your paid leads arriving on a channel that drops the ID by default. Dynamic number insertion bridges the gap by showing each ad visitor a unique tracking number, matching the call back to the session that holds the GCLID.
• The customer switches devices. They click the ad on a phone in the driveway, then book from the laptop after dinner: new browser, no cookie, thread cut.
• Time runs out. Google's offline-import rules accept conversions tied to a GCLID for up to 90 days after the click. Plenty for a water heater swap; tight for a replacement quote that shops around all summer.
• It's captured, then ignored. Some shops store GCLIDs in a CRM field forever and never send anything back. A claim ticket you never redeem pays exactly the same as one you lost.

What is an offline conversion upload — and why bother?

Out of the box, Google Ads only counts what it can see in a browser: form submits, button clicks, calls placed from the ad itself. It cannot see which leads became booked jobs or what any job was worth. So Smart Bidding — the automated bidding most accounts run — optimizes toward whoever fills out forms, including the out-of-area callers, the price-shoppers, and the duplicates.

An offline conversion upload is you handing the claim tickets back. It's a list — GCLID, conversion name, timestamp, dollar value — sent to Google Ads after the real-world outcome happened, by spreadsheet or by API. Google matches each ID to its original click and credits the exact campaign, ad group, and keyword; Google's guide to importing conversions from clicks documents the format.

The payoff is what happens next: with real revenue flowing back, Smart Bidding starts hunting for clicks that resemble your booked jobs instead of clicks that resemble your form fills. Ad platforms optimize whatever number you feed them. Feed them jobs.

Do you have to build all this yourself?

You can. The DIY version is a snippet that stores the GCLID in a cookie, hidden fields on every form, a custom field in ServiceTitan, Jobber, or Housecall Pro, and a recurring upload — either a CSV someone in the office exports weekly or a script against the Google Ads API. If you have a developer and the discipline to keep the uploads running, it works.

The failure mode isn't building it — it's keeping it alive through website changes, form rebuilds, and staff turnover. That's the part Peach automates: every online booking lands in your CRM with its GCLID already attached, every booked job is matched back to its originating click ID, and revenue is pushed to Google, Meta, and Bing within about 60 seconds of the booking. The full click-to-job loop is laid out on the lead attribution page.

At Copeland Home Services, closing this loop took cost per booked job from $332 to $143 — same ads, same budget, better feedback to the bidding. The full case study has the complete numbers. If you run ServiceTitan, the ServiceTitan–Google Ads integration walkthrough shows the connected version step by step.

Either way, start with the 60-second audit above. If TEST123 never shows up in your CRM, your Google Ads budget is being graded on form fills — and the GCLIDs that could prove which ads book real jobs are dying at your own front door.

FAQ

How long is a GCLID valid?

Google's offline-import documentation accepts conversions tied to a GCLID for up to 90 days after the click; uploads older than that simply don't import. The practical move is uploading daily or weekly rather than batching at month end, so slower sales cycles don't age out of the window.

What's the difference between a GCLID and UTM parameters?

UTM tags are labels you write yourself and read in your own analytics; a GCLID is generated by Google, unreadable to you, and is the ID Google Ads matches offline conversions against. They coexist fine in the same URL, and well-built setups capture both — UTMs for your reporting, the GCLID for closing the loop with Google.

Does a GCLID track phone calls?

Not by itself — the ID exists in the caller's browser and doesn't travel down a phone line. Call tracking with dynamic number insertion bridges the gap by giving each ad visitor a unique tracking number, so the call gets matched to the session holding the GCLID. Without a bridge, phone-in jobs from ads report as direct traffic, or as nothing at all.

Do I need to turn GCLIDs on in Google Ads?

Almost certainly not — auto-tagging is on by default, so your clicks are already arriving with a GCLID attached. You can verify it in your account settings; the toggle is literally called auto-tagging. The real work is capturing the ID at the form, storing it with the job, and sending it back with revenue.