Consent, analytics and what you can legally measure

Measurement and data protection are usually handled by different people who never speak, which is how clinics end up with a consent banner that satisfies nobody and an analytics setup that records things it should not.

This is a summary for planning. The Information Commissioner's Office publishes the applicable guidance and should be read directly before any decision is finalised.

Two separate regimes

1. Rules on storage and access on a device. These govern cookies and similar technologies, and generally require consent before non-essential storage or access, with narrow exemptions for what is strictly necessary to provide a service the user requested.
2. Data protection law. This governs the processing of personal data, requires a lawful basis, and treats health information as special category data with additional conditions.

Both apply to a clinic website at the same time, and satisfying one does not satisfy the other.

What that means for analytics

Analytics that sets identifiers on a device is generally non-essential and requires consent. The ICO's guidance on cookies and similar technologies sets out the position. In practice this means your analytics records a subset of visitors, and any number produced from it understates reality by an unknown factor.

Consent implementation that does not damage the site

• Do not set non-essential storage before a choice is made.
• Make refusing as easy as accepting, at the same level of the interface.
• Reserve the banner's space in the layout so it does not shift content when it appears.
• Keep the consent script small, since it runs before everything else.
• Record consent decisions so you can demonstrate them.
• Allow the choice to be changed later through a persistent, findable control.

The performance point is not incidental. A heavy banner damages the metrics discussed elsewhere on this site while also being the first thing a patient sees.

What must never enter an analytics tool

• Any clinical detail: condition, treatment, symptom or outcome tied to an individual.
• Names, email addresses or phone numbers in URLs, page titles or event parameters.
• Booking references or record numbers that identify a patient.
• Free text from an enquiry form.
• Anything that combines with other held data to identify someone.

Clinic sites leak this most commonly through form confirmation URLs containing parameters, and through page titles on booking flows. Check both, because it is a silent and serious failure.

Measuring within the constraint

• Search Console reports search behaviour without device storage on your site.
• Business Profile insights report profile activity independently of your analytics.
• Server logs record every request, including crawlers, without setting anything on a device. They are the most under-used source in clinic measurement.
• Enquiry counts from your own systems are complete by definition.
• The self-reported source question works regardless of consent state.

Together those cover most of the discovery funnel without depending on the part of the data most affected by consent.

Forms, marketing and PECR

Electronic marketing to individuals is governed by separate rules, and the ICO publishes guidance on direct marketing. For a clinic newsletter this means a genuine opt-in that is not bundled with a booking or an enquiry, a clear statement of what will be sent, and an unsubscribe route in every message. A tick box pre-ticked is not consent, and consent obtained for an appointment reminder does not extend to a promotional email.

The privacy notice as a discovery asset

A privacy notice written in plain language, stating what is collected, why, on what basis and for how long, is a page patients genuinely read before entering health information. Written properly it does double duty: a compliance obligation and a trust signal on a decision page. Written as a template full of boilerplate, it does neither.

A review that fits in an hour

1. List every script that sets storage, and confirm each waits for consent.
2. Check no personal or clinical data appears in URLs, titles or event parameters.
3. Confirm the refuse path is as easy as the accept path.
4. Check the privacy notice matches what actually happens.
5. Confirm newsletter consent is separate from enquiry and booking consent.
6. Record the date of any change so future reports can be interpreted.

Auditing the enquiry form

The enquiry form is where most clinic data problems begin. Three checks find nearly all of them. First, look at where the form submits: if it posts to a third-party service, that service is processing health-adjacent personal data and needs to be a considered choice rather than the default in a page builder. Second, check the confirmation URL for parameters carrying anything the person typed. Third, check whether the form asks for clinical detail at all, because in most cases it does not need to and collecting it creates an obligation without a benefit.

A good clinic enquiry form asks for a name, a contact route, a preferred site and a short free text box, with a clear statement of what happens to the message. Anything clinical belongs in the pre-consultation record, collected in the clinical system, after the appointment is made.

Retention, decided rather than defaulted

Most clinics have never decided how long marketing data is kept, which means it is kept forever by default. Set a period for each type: enquiry records, contact form messages, newsletter subscribers who never open, and analytics data where the tool allows a retention setting. Write it down, apply it, and note it in the privacy notice so that what the notice says and what happens are the same thing.