Healthtech is the vertical where a single careless event parameter can turn a product-analytics dataset into a regulated health record. Under the GDPR, data about someone’s health is a special category — Article 9 — with protections far stricter than ordinary personal data. Yet healthtech products still need to measure onboarding, engagement, and retention like any other app. The trick is drawing a hard line between product behavior, which you can track, and health information, which you must never let near your analytics.
This reference covers the event schema for a healthtech product — the events worth tracking, what each payload may contain, and the strict boundary that keeps Article 9 data out of your warehouse entirely.
The Boundary: Product Behavior vs Health Data
Before any event fires, you need one rule burned into the team’s head: track the action, never the condition. “User opened the symptom checker” is product behavior. “User searched for diabetes” is health data. The first is safe analytics; the second is an Article 9 incident waiting to happen.
| Safe to track (product behavior) | Never track (special category) |
|---|---|
| Feature opened, screen viewed | Diagnoses, conditions, symptoms |
| Appointment booked (that it happened) | The medical reason for the appointment |
| Content category viewed (generic) | Specific health topics searched or read |
| Subscription started, plan chosen | Medication names, test results, vitals |
Everything below is designed so the schema captures the left column and structurally cannot capture the right. If you’re unsure where a field belongs, treat it as health data and leave it out.
Onboarding Events
signup_started
Fires when a user begins registration. Payload: method (email, sso), plan_intent if known. No health context exists yet, so this is the cleanest event in the schema.
account_created
Fires on successful registration. Payload: account_type (patient, provider, caregiver) — a role, not a condition. Avoid any field that hints at why the person signed up.
profile_completed
Fires when setup finishes. Track that the profile is complete and which generic steps were done — never the health details entered into it.
Engagement Events
feature_opened
The workhorse event. Payload: feature_name from a fixed, generic allow-list (dashboard, messaging, scheduler). Never pass a free-text feature label that could leak a condition.
content_viewed
Fires on article or resource views. Payload: content_category at a coarse level only (wellness, billing). Resist the urge to log the exact article title — that’s often health data in disguise.
tool_completed
Fires when a user finishes an in-app tool. Track completion and duration, never inputs or outputs. The fact that someone used a tool is behavior; what they entered is not yours to measure.
Appointment & Conversion Events
appointment_booked
Fires on a confirmed booking. Payload: appointment_type only if it’s generic (video, in_person) — never the specialty or reason. This is the highest-risk event in most healthtech apps, so keep it ruthlessly thin.
appointment_completed / appointment_canceled
Lifecycle events for the booking. Status and timing are fine; clinical context is forbidden. These power your activation and retention reporting without revealing anything medical.
subscription_started
Fires when a paid plan begins. Payload: plan, billing_cycle, price. Standard conversion tracking — the same shape you’d see in any subscription event schema.
What Events Must Not Carry
This section is the whole point of the schema. The following must never appear in any payload, parameter, or user property:
- Health conditions or diagnoses — even as IDs that map back to a condition.
- Symptoms, medications, test results, or vitals — in any field, including free text.
- Specific content identifiers that reveal a health interest (article slugs, search terms).
- Appointment reasons or clinical specialties attached to a person.
The safest architecture is structural: use fixed allow-lists for every categorical field, ban free-text parameters outright, and validate payloads against a schema before they’re sent. That way a developer can’t accidentally pass a diagnosis even if they try. The same discipline underpins our guide to GDPR-compliant event tracking.
Common Parameters for All Events
| Parameter | Example | Notes |
|---|---|---|
user_pseudo_id |
Hashed app ID | Pseudonymous — still personal data |
account_type |
patient / provider | Role, never condition |
platform |
ios / android / web | Standard context |
app_version |
4.2.0 | For debugging and cohorts |
consent_state |
granted / denied | Gate analytics on this |
Note that user_pseudo_id is pseudonymous, not anonymous — it still counts as personal data. The distinction matters more in healthtech than anywhere else, as I explain in pseudonymization vs anonymization.
Regulatory Notes
Three points keep a healthtech schema defensible. First, Article 9 forbids processing special-category data without an explicit legal basis — and “we wanted product metrics” is not one. Second, consent must be explicit and granular; bundle it into a generic cookie banner at your peril. Third, run a privacy review before launch, since the cost of getting this wrong is regulatory, not just reputational. A structured privacy audit is the right tool for that final check.
Validation Checklist
- Every categorical field uses a fixed allow-list — no free text.
- No payload contains conditions, symptoms, medications, or results.
- Appointment events carry status and generic type only.
- Analytics events fire only when
consent_stateis granted. - Payloads are validated against the schema before sending.
FAQ
Can I track which health articles users read?
Not at the specific level. The exact article a user reads can reveal a condition, making it special-category data. Track only coarse, non-medical categories, and never the precise title or slug tied to a user.
Is a hashed user ID enough to make healthtech analytics compliant?
No. A hashed ID is pseudonymous, so the data is still personal — and if any payload carries health context, it’s special-category data regardless of hashing. Compliance comes from excluding health data, not from masking identifiers.
Can I record the reason for an appointment for analytics?
No. The clinical reason is health data and must stay out of analytics entirely. Track that an appointment was booked, its generic type, and its status — nothing about the medical purpose.
Does this schema work with GA4?
Yes. The event and parameter structure maps cleanly to GA4 custom events, following standard naming conventions. The key is configuring it so no health data is ever passed as a parameter or user property.
The Bottom Line
A healthtech event schema lives or dies on one boundary: you measure what users do, never what’s wrong with them. Track signups, feature usage, bookings, and subscriptions with thin, allow-listed payloads, and structurally bar conditions, symptoms, and clinical context from ever entering the pipeline. Get that separation right and you can run a full product-analytics practice — funnels, retention, activation — without ever processing a byte of Article 9 data. In healthtech, that discipline isn’t optional. It’s the difference between analytics and a compliance breach.