Industry · Healthcare providers and health information
Clinics, hospital groups and health publishers need to know which channels bring appointment requests. But a visit to a condition or treatment page can reveal health information once a tool ties it to an identifier, and a consent banner removes part of the traffic anyway. Sealmetrics counts visits and conversions in aggregate, without cookies or stored identifiers, and documents exactly what it stores so your DPO and counsel can decide.
Aggregate counts · no cookies · no cross-session identifier · EU-hosted in Dublin · not legal advice
Quick answer
Analytics for healthcare is web measurement of how patients find a provider and request care, set up so that reading a condition or treatment page is not tied to an identifiable person. The risk comes from tools that set cookies or identifiers: combined with the page URL, they can show that a person looked up a condition, which data protection law may treat as health data. Sealmetrics sets no cookies, stores no IP addresses, user IDs or cross-session identifiers, and keeps page views and conversions as aggregate counts processed in Dublin; the event row with the full URL is purged after one day. That describes what it stores, not a legal conclusion. Whether your deployment involves health data depends on what your site sends, including URLs and custom properties, and on the assessment of your DPO and counsel. It does not change the obligations of the other tags on the site.
What a visit leaves behind
The question for a health website is not whether an analytics tool is private in general. It is what one visit to a sensitive page leaves in each tool, and whether anything links it to a person.
| What a visit to a treatment page leaves | Tag with cookies or identifiers | Sealmetrics, as documented | Where to verify |
|---|---|---|---|
| Something on the device | A cookie or client ID, often set on the first page | No cookies, localStorage or sessionStorage | What we track |
| An identifier linking visits | A client or user ID that recognises the visitor next time | No cross-session identifier; a session marker pseudonymised server-side expires after 2 hours of inactivity | What we track · DPA Annex 1 |
| The IP address | Received by the vendor, with retention set by the vendor | Used in memory to handle the request, never stored | What we track |
| The page URL | Sent together with the identifier, sometimes to an advertising platform | Kept as an aggregate page count; the full URL sits in the event row for 1 day | DPA Annex 1 |
| Where it is processed | Often a US provider, relying on a transfer framework | Dublin, Ireland; no non-EU sub-processor receives visitor data | DPA clause 7 · Annex 3 |
What Sealmetrics stores is listed field by field in what we track and in Annex 1 of the DPA, which names special categories among the data not stored. Whether any processing on your site involves personal data or health data is a decision for your DPO and counsel, and the answer changes if URLs or properties carry patient information.
What the usual choices cost
Health websites tend to end up at one of two extremes, and each is paid for in a different currency.
A tag that sets cookies or identifiers on condition, symptom or treatment pages creates the combination a DPO has to assess: a person, and the health topic they read about. The exposure sits in the processing, whatever the report shows.
One response is to take analytics off treatment pages and appointment flows. The channels that bring appointment requests are then judged on the pages that matter least to the decision.
Where a banner stays, a consent-based tool loses the visitors who reject it. In our experience with clients, between 40% and 60% of traffic doesn't accept cookies; no healthcare figure has been published. How that gap forms is explained under data loss in analytics.
From review to reporting
Most of the privacy work in a health deployment is deciding what never leaves your site. The review itself is covered in more depth in analytics for DPOs.
Give the DPO the DPA with its data inventory, retention periods and sub-processors, and the public field list. Decide which purposes you enable: aggregated audience measurement, and marketing attribution as a separate, optional purpose to be assessed on its own terms. Sealmetrics assists with impact assessments under clause 4.6 of the DPA.
Check that no URL on the site carries a name, email, patient number, appointment reference or diagnosis in its parameters. Send appointment requests as conversions with generic properties agreed with your DPO, such as clinic or form name, never symptoms, conditions or anything that identifies a person. There is no server-side list of allowed properties, so this is your decision as controller.
Add the tracker to public pages and appointment-request flows, which takes 5 to 30 minutes depending on the platform. Leave patient portals and other logged-in areas without the tracker unless your DPO has reviewed that deployment separately.
Keep the current setup for a full campaign cycle and compare measured appointment requests with the requests your booking system received for the same period, by total and by channel. The comparison is in aggregate, never request by request.
Read appointment requests and conversion rate by channel, campaign and landing page. No report shows a patient: with nothing personal in what the site sends, no stored identifier links a visit to a person.
Who is involved
Each function has a different question about the same deployment. The boundary of what is stored is what they share.
Know which channels bring appointment requests.
Requests by source, medium and campaign, credited to the last click of each session, without consent loss.
Conversion trackingDecide whether the deployment involves personal or health data.
The DPA data inventory, the public field list and the country analyses, as material for your own assessment rather than a conclusion.
Analytics for DPOsControl what the tag sends and who can see the reports.
Which pages run the tracker, which properties are sent, role-based access and 2FA; audit logs from Scale, IP allowlist on Enterprise.
Security overviewInvest in patient acquisition without adding patient data to analytics.
Channel decisions on measured counts, reconciled with the booking system before any channel is compared.
Single source of truthEvidence, not a sector case
Sealmetrics has no published case study from a healthcare provider, and this page does not imply one. The documents below are what a health organisation can check today. The measured figure comes from a hotel group and is shown only as context for how missing source data distorts channel decisions.
every field processed, what is never stored, special categories included, and each retention period
before the event-level log with the full URL is purged; only aggregate counts remain after that
of the bookings GA4 recorded had no channel; hotel context, not a healthcare result
What it does not do
State the limits before the deployment, not after it. Attribution is last click within each session, by design.
This page describes what Sealmetrics stores. Whether your deployment processes personal or health data, and whether it needs consent, is for your DPO and counsel under your national rules.
Patient names, emails, record numbers or conditions in URLs, custom properties or campaign names bring personal or health data into the system. Keep them out.
No individual journeys, no returning-visitor recognition and no patient profiles. A patient who comes back tomorrow is a new visit.
Advertising pixels, chat widgets, video embeds and booking tools on the same pages keep their own consent and data protection requirements.
The DPA, the field list and the self-assessments are material for your impact assessment, not a substitute for it.
No ISO 27001 or SOC 2, no health-sector certification, and no claim about HIPAA or other health-data rules outside the EU.
Questions health organisations ask
Sealmetrics does not collect names, emails, IP addresses, user IDs or cross-session identifiers, and Annex 1 of its DPA lists special categories among the data not stored. It does record page URLs and conversions, kept as aggregate counts. Whether a count of visits to a treatment page, or anything your implementation sends, involves health data is a decision for your DPO and counsel, and the answer changes if URLs or properties carry patient information.
Yes. Send each completed request as a conversion with generic properties agreed with your DPO, such as clinic or form name, and never the patient's name, contact details, symptoms or condition. Check that booking URLs carry no personal parameters. There is no server-side list of allowed properties, so what you send is your responsibility as controller.
For the analytics itself, Sealmetrics sets no cookie and stores nothing on the visitor's device. Whether your deployment is exempt from consent depends on its configuration, the purposes you enable and your national authority's criteria. Advertising pixels, chat widgets and other tools on the site keep their own consent requirements, so a banner may still be needed for them.
Only after your DPO has reviewed that specific deployment. Logged-in areas are where URLs and events are most likely to carry patient information, and Sealmetrics does not analyse individual users in any case. A cautious deployment starts with public pages and appointment-request flows, which is where the acquisition questions are.
Visitor data is stored and processed in Dublin, Ireland. Annex 3 of the DPA lists the sub-processors; the only one outside the EU sends service emails to account users and receives no visitor data. Event-level rows are purged after one day, hourly aggregates after 90 days, and daily aggregates and conversions after 24 months.
No. Sealmetrics holds no ISO 27001 or SOC 2 certification and no health-sector certification, and it makes no claim about HIPAA or other health-data rules outside the EU. Its security measures are listed in Annex 2 of the DPA, and customers have audit rights under clause 4.7.
No. Sealmetrics assists with impact assessments under clause 4.6 of the DPA and provides the data inventory, retention periods and security measures as input. The assessment, and the decision, remain with you as controller.
Deployment review
Thirty minutes with the person responsible for the implementation: the data inventory, what your site should never send, and how appointment requests are measured by channel.
