Most hospital GA4 properties we are asked to review share one problem: the data is there, but it cannot answer the questions the marketing team asks. Which department's booking form loses the most people at step two? Do visitors who view a consultant profile book more often than those who view only the department page? Is the Hindi version of the form completed less often than the English one? A default install records page views and a few automatic events. It does not record the structure of a hospital.
This article is for marketing leads, web teams and analysts at hospitals and multi-specialty clinics. It sets out an event and parameter naming system that works at department, doctor and booking-step level, and it deliberately stops short of recording anything about a visitor's health. The rules that keep it safe are part of the design, not a footnote.
The examples use a hypothetical 200-bed hospital in Pune with eight departments, about sixty consultants and two campuses. Adapt the vocabulary to your own service lines, but keep the structure.
Decide what the taxonomy must answer
Write the questions first, then design events. For a hospital, a workable list is short:
- Which departments get traffic, and how much of it reaches a booking form?
- At which step of the booking form do visitors leave, by department and by device?
- Which doctor profiles lead to a request, and which are viewed but never lead anywhere?
- Which entry points (department page, doctor page, health-check package, ad landing page) produce completed requests?
- How many completed requests become confirmed appointments? That last answer lives in your CRM, not in GA4, and the taxonomy should leave a hook for it.
If an event does not help answer one of these, do not create it. Google's collection limits allow event and parameter names of up to 40 characters and 25 parameters per event, so there is room, but every extra event is something someone must document, test and maintain.
Naming rules
Pick a convention and write it down before the first tag is built.
- snake_case, verb first for actions:
appointment_start,doctor_profile_view,department_cta_click. - Names under 40 characters. Google documents 40 characters as the limit for event names and parameter names, and a key event whose name is too long will not be reported as a key event.
- One event name per behaviour, parameters for the variation. Do not create
cardiology_form_startandorthopaedics_form_start. Createappointment_startwith adepartmentparameter. Eight departments then cost you one event, not eight. - Use Google's recommended names where they exist. Recommended events include
generate_leadfor a submitted form andqualify_leadfor a lead that meets your criteria. Reusing them keeps reports and Google Ads imports predictable. - Controlled values. Every parameter that takes a value from a list gets a published list, in lower case, with no free text.
The core event set
This set covers most hospital sites. Parameter names are suggestions; the point is that they are consistent.
| Event | Fires when | Parameters |
|---|---|---|
department_view | A department landing page loads | service_group, campus |
doctor_profile_view | A consultant profile loads | doctor_id, service_group, campus |
appointment_start | The visitor first interacts with the booking form | form_type, entry_point, service_group |
appointment_step | A step is completed | step_number, step_name, form_type |
generate_lead | The request is submitted and the server accepts it | form_type, entry_point, service_group, language |
call_click | A tel: link is tapped | click_location, campus |
whatsapp_click | A WhatsApp link is tapped | click_location, campus |
qualify_lead | Sent later, from the CRM, when the enquiry is confirmed as a real appointment request | form_type, entry_point |
Two notes. First, generate_lead should fire on a confirmed server response or a thank-you state, not on the button click. A click that triggers a validation error is not a lead. Second, qualify_lead is the bridge to the offline side. Sending it needs a server-side step; the offline conversion tracking post covers how to join a CRM outcome back to a click.
Handling departments without recording conditions
This is the design decision that matters most. A parameter such as department=oncology attached to a visitor who has just opened an appointment form reveals something about that person, even if the form never captured a name. For most departments (dental, orthopaedics, general medicine) a department label is ordinary navigation data. For others it edges toward information about a health condition: oncology, mental health, fertility, HIV and sexual health, addiction medicine.
A practical rule is to use two levels:
service_group: a coarse, hospital-defined grouping used in all event parameters. For exampleheart_vascular,bone_joint,women_children,general_adult,specialist_care.department: the detailed department name, kept out of GA4 for sensitive specialties and held only in your own CRM, where access controls and consent records exist.
Your clinical and legal leads decide which specialties go into the coarse bucket. The marketing team should not make that call alone, and clinical review applies to any wording that implies a diagnosis. Report-level detail for those departments comes from the CRM and from page-level counts.
Never put these in event parameters: symptoms, diagnoses, procedure names chosen in a form, free-text fields, search terms typed into the site search, patient or visit IDs, phone numbers or email addresses. Google's PII guidance says no data may be passed that Google could use or recognise as personally identifiable, and it names user-entered text, site search terms and custom dimensions as places where PII leaks in. The DPDP Act for healthcare marketing explains why that matters for an Indian provider.
