What a GCLID is, and the six places your booking form loses it

A GCLID is a Google Click Identifier: a unique string, usually around a hundred characters, that Google appends to your landing page URL when somebody clicks an ad. It looks like ?gclid=Cj0KCQjw... and it is the only thing connecting that click to a booking that happens six weeks later.

It is also remarkably easy to lose, and every one of the failure modes below is silent. Nothing errors. The form submits, the enquiry arrives, the team follows up. The only symptom is an empty column in an export nobody looks at until somebody asks which advertising produced which patient.

This is step one of closing the attribution loop, and it is where the majority of clinic setups fail.

The journey it has to survive

Google appends the identifier. The browser loads the page. A script reads it from the URL and writes it into a hidden form field. The visitor submits. The form handler passes it to the CRM. The CRM stores it against the record.

Six handoffs, any of which can drop it.

Where it actually gets lost

1. Auto-tagging is switched off

Google only appends the identifier if auto-tagging is enabled on the Google Ads account. It sits in account settings and it is off in a surprising number of accounts, usually disabled years ago by someone keeping URLs tidy for a legacy analytics setup.

Nothing downstream can work. Check this before anything else, because it takes ten seconds and it invalidates every other investigation.

2. A redirect strips the query string

This is the most common technical cause and the least suspected.

Your ad points at example.com/treatment. Your server redirects to www.example.com/treatment/ for canonicalisation. Depending on how that redirect is configured, the query string may not survive it. The visitor lands on the right page with a clean URL and no identifier.

The same happens with http to https upgrades, trailing slash normalisation and country-based redirects. The rule to check is whether every redirect in the chain preserves query parameters. Most content management systems do this correctly by default. Most custom server configurations written by somebody optimising for clean URLs do not.

3. The booking form lives in an iframe

This one is close to universal in clinics, because most practices embed a third-party booking widget rather than building their own form.

A script inside an iframe cannot read the parent page’s URL. The widget has no idea the identifier exists. Unless the vendor supports passing parameters into the embed, usually by appending them to the iframe source, everything booked through that widget is permanently unattributable.

Practices frequently have excellent tracking on a contact form that produces twenty enquiries a month, and none at all on the booking widget producing two hundred.

4. The form handler discards unknown fields

Some handlers accept only fields they recognise. You add a hidden input, it submits correctly, and the handler silently drops it because it is not in the expected schema.

The tell is that the identifier appears in the browser’s network tab on submission and never appears anywhere afterwards.

5. A multi-step form loses it between steps

Any form that spans several screens has to carry the value forward. If step one collects contact details and step two collects treatment preference, and the identifier was captured on step one, it needs to persist into the final submission rather than living in a field that was discarded when the screen changed.

6. The CRM field truncates it

Identifiers run to roughly a hundred characters. A custom field configured with a fifty-character limit stores half of one, which is worse than storing none, because it looks populated and fails on upload.

Testing yours in five minutes

Do this properly once and you will know rather than assume.

1. Click one of your own live ads. An actual click, not a preview.
2. Check the address bar contains gclid=. If not, stop, and go back to auto-tagging or redirects.
3. Right-click, inspect the form, and confirm the hidden field is populated with the same value.
4. Submit a real test enquiry.
5. Open the record in the CRM and look at the field. Compare the full string, not the first few characters.
6. Convert that test lead to a patient, then look again. This step catches the failure described in the CRM comparison below and almost nobody performs it.

If it survives all six, your capture works. If it fails, the step it failed at names the problem precisely.

Fixing the iframe case

Since this is the failure most clinics actually have, it deserves the specific remedy.

Most embedded booking widgets accept parameters appended to the embed source. If the widget loads from book.vendor.com/clinic-name, a small script on your page can read the identifier from the parent URL and rewrite the iframe source to book.vendor.com/clinic-name?gclid=... before it loads. The widget then has the value and can pass it into whatever it submits.

Whether it stores it is a separate question, and the answer is in the vendor’s field mapping rather than in your code. Ask them directly whether an arbitrary parameter passed into the embed reaches the booking record and appears in an export. Support will usually know. Sales frequently will not.

If the widget cannot accept or store it, you have three options in ascending order of effort: move the booking form onto your own domain, capture the identifier separately at the moment the widget loads and reconcile on contact details afterwards, or accept that this channel is unattributable and stop reporting on it as though it is not.

When there is no identifier to capture

Some clicks arrive without one. Ad blockers strip parameters, some referrers rewrite URLs, and traffic that is not from Google Ads never had one to begin with.

Two fallbacks exist. Enhanced conversions for leads matches on hashed contact details rather than a click identifier, which works but shortens your reporting window from 90 days to 63 and, in healthcare, means handing hashed identifiers to a platform that is not a business associate. That is a decision to make deliberately rather than by default.

Server-side capture stores the identifier on your own infrastructure at the moment of the click and rejoins it later, which is more robust against browser-side interference and is more engineering than most practices want for the problem.

For iOS app traffic Google uses wbraid and gbraid instead, and a capture script that only looks for gclid will miss those entirely. If a meaningful share of your traffic is in-app, check for all three.

Two things worth knowing

The identifier is not personal data on its own. It identifies a click, not a person, which is why it is the field that may be sent back to Google when patient details may not. That property is the entire reason the mechanism is usable in healthcare.

Google keeps it for 90 days. Capturing it correctly and uploading it late is the second most common failure, and it is covered in offline conversion uploads for clinics.

Whether your system will hold the value through the patient journey once captured is a separate question, and it is the one missing from every med spa CRM comparison.