This is a technical article for hospital marketing operations, CRM administrators and the engineer or vendor who looks after the hospital information system (HIS). The task is to send Google Ads a single fact, that a click led to a completed appointment, without sending any health information. The key design choice is to keep the link between the click and the patient record inside the hospital, and send Google only a click identifier, an event name, a time and a value.
Our earlier article on offline conversion tracking for clinics explains why the loop matters for Google Ads and Meta. This one is narrower: the identifiers, the data flow, the upload and the failure modes. It assumes a hospital with a CRM or enquiry system and a HIS that issues a unique health ID, commonly called a UHID.
A note on regulation: how India's data protection law applies to your specific data flows needs advice from your counsel and data protection owner. This article describes a minimisation pattern, not a legal opinion.
The design principle
Three systems hold three kinds of data.
- The website and CRM hold the enquiry: name, phone, the click ID, the form and the lead ID.
- The HIS holds the clinical and administrative record, keyed by UHID.
- Google Ads should receive only: a click ID, a conversion action, a time, a value, and optionally hashed contact identifiers if you use enhanced conversions for leads.
The bridge between the CRM and the HIS is a mapping your hospital controls: lead ID to UHID, created when a front-desk or call-centre user registers the enquirer as a patient. That mapping never leaves the hospital. Google never sees the UHID or any clinical field.
Step 1: Capture the click ID
Google's help on offline conversion imports using GCLID sets out the requirements.
- Auto-tagging must be on.
- You must be able to change code on the pages to capture the GCLID parameter.
- Store each GCLID with the prospect's information in your lead system. The GCLID is case sensitive.
- Add a hidden GCLID field to every form, and a script that reads the URL parameter and stores it in local storage or a cookie. Google's sample sets a 90-day expiry.
- Create the conversion actions first and wait 4 to 6 hours before uploading conversions for them.
Google reminds advertisers to observe local rules on cookie consent. Hospitals should apply their consent approach before the script stores anything, and the privacy notice should say that campaign identifiers are used for measurement.
Where the click leads to a phone call rather than a form, the GCLID is not available at the call. Use call tracking that records the session's click ID against the call, as described on our call tracking and attribution page. For WhatsApp enquiries, capture the click ID on the page before the user is sent to the chat, and attach it to the conversation record on your side.
Step 2: Store it against the lead, not the patient
When the form submits, the CRM should create a lead record with fields such as:
| Field | Example (hypothetical) | Notes |
|---|---|---|
| lead_id | a generated unique ID | The only key shared outward |
| gclid | the captured value, exactly as received | Preserve case |
| clickcapturedat | timestamp with time zone | Needed for the 90-day check |
| source_page | the landing URL | Useful for the URL audit |
| consent_flags | marketing and measurement consent | Drives what you may upload |
| uhid | empty at this stage | Filled in later, inside the hospital |
Do not put diagnosis, symptom text or treatment interest into the same table as the GCLID. If the form has a free-text message field, keep it out of any export that feeds the upload job.
Pioneer CRM is one place for enquiries, lead ownership and follow-ups, which is the kind of lead table this step needs.
Step 3: Link the lead to the HIS record internally
When the enquirer becomes a registered patient, front-desk staff or an integration set the uhid on the lead. Two ways to do it:
- Manual selection. The coordinator picks the existing lead when registering the patient. Simple, but error-prone.
- Integration by phone number or appointment ID. The HIS or booking system returns an appointment ID that the CRM stores. A match on a normalised phone number is a fallback, and needs a rule for shared family numbers.
Our service page on EHR and CRM integration describes the integration work. Whatever you choose, test it for false matches. A wrong UHID link sends the wrong value for a click.
The completed-appointment event comes from the HIS status: registered, billed or checked out. Choose the status that really means the patient attended. A booked appointment is a weaker event than a completed one.
Step 4: Build the export without PHI
The upload job reads only completed appointments and outputs rows with these fields, which map to Google's click conversion fields:
- the click identifier (GCLID);
- the conversion action name;
- the conversion time, with a time zone, in the format Google specifies;
- a value and currency, if you use values;
- an order or transaction ID, to prevent duplicates and allow later adjustments.
Google's developer documentation on uploading click conversions lists the required fields: the conversion action, the date and time with a time zone in the format yyyy-mm-dd HH:mm:ss followed by the offset, the value and currency code, and the click ID. The order ID is optional but strongly recommended, because adjustments require it if it was set at import.
Use a hashed or random transaction ID, not the UHID. If you set the order ID to the UHID, you have put a health identifier into an advertising system. Use the lead ID or a random event ID that the CRM generates.
Name the conversion action in plain terms such as "Appointment completed". Do not create actions named after diagnoses or procedures. The action names are visible to everyone with access to the Google Ads account.
