Capture
- First-party event library in each app
- Events checked against the naming plan
- No third-party analytics SDKs in health flows
Digital Analytics
Digital analytics for health apps and patient portals
Product teams need funnels and retention; patients need their health information kept out of third-party tools. Agnotic Technologies sets up digital analytics for health apps and portals that gives you both, with events collected into your own warehouse.
Event reviewSDK auditServer-side collectionConsent enforced
Trusted by global innovators
Health app analytics
What is digital analytics for a health app?
Digital analytics for a health app is measuring how people use a patient app, portal or digital front door, such as sign-ups, bookings, drop-off and return visits, without sending health information to third parties. Agnotic Technologies designs the event plan, collects events server side into the client's own warehouse and enforces consent.
This page covers logged-in apps and portals. Tag rules for a public marketing website are part of our medical website design work, and dashboards are part of our data engineering work.
In a health product the event name itself can be health information. An event called insulin_dose_logged tells an analytics vendor something about the user even with no other fields, so we review the event plan before any SDK is added.
Event review
Which app events may leave your environment?
We review every planned event against this table with your privacy lead. Your counsel decides which rules apply to your organization.
| Event | May it go to a third-party tool? | What to strip or hash | Rule that applies |
|---|---|---|---|
| Screen view on a public information page | Yes, as an aggregate count, with consent | Path parameters, user ID and precise location | Consent choices; HIPAA if a covered entity offers the app |
| Sign-up or login completed | Only without identifiers, or to a vendor under a BAA | Email, phone and account ID; keep a pseudonymous ID in your own store | HIPAA for covered entities; FTC Health Breach Notification Rule for consumer apps |
| Appointment booked | No, keep it in your environment | Visit reason, specialty, clinician and location | Can reveal a condition, so it is treated as health information |
| Symptom checker answer | No | Never sent as an analytics event; counts only, in your warehouse | Health information under HIPAA or the FTC rule |
| Medication or reading logged | No | The medicine, dose or value; record only that a log happened | Health information under HIPAA or the FTC rule |
| Push notification opened | Only as an aggregate without the message content | Notification text, and the campaign name if it names a condition | Marketing consent; health information if the content is clinical |
When in doubt, an event stays in your warehouse. Product teams still get funnels and retention, from a store you control.
Event taxonomy
How should health app events be named?
A naming plan keeps events the same across iOS, Android and web, and keeps clinical detail out of names.
| Event name | Pattern | How it is used |
|---|---|---|
| account_created | Object, then action in the past tense | One event per completed step, with platform and app version as properties |
| booking_started | Funnel step | Paired with booking_completed to measure drop-off without recording the visit reason |
| booking_completed | Funnel step | Carries an internal booking ID that only your warehouse can join to clinical records |
| log_entry_saved | Generic action | Replaces names such as glucose_logged, so the name reveals nothing clinical |
| message_sent | Generic action | Counts secure messages without recipient, subject or content |
| consent_updated | Consent event | Records the new choice so every downstream tool can honor it |
Collection
How does server-side collection work?
Events travel from the app to a collection endpoint you host, then into your warehouse. Nothing reaches a third party unless it passed review.
Collect
- Collection endpoint in your cloud
- Strip and hash rules applied
- Consent checked per event
Store
- Your own warehouse
- Pseudonymous user IDs
- Retention rules per event type
Analyze
- Funnels and retention
- Cohorts by release and channel
- Dashboards for product teams
Share, if needed
- Aggregates to third-party tools
- Only events that passed review
- Vendors under a BAA where PHI could be involved
SDK audit
Mobile SDK audit checklist
Third-party SDKs often send more than the feature you added them for. We check each one before release.
Inventory
- Every SDK in the iOS and Android builds
- Dependencies they pull in
- Versions and update history
- Privacy manifest for each iOS SDK
Traffic
- Network calls captured on a test device
- Fields sent at launch and on each screen
- Device and advertising identifiers
- Calls made before consent is given
Configuration
- Automatic screen and event collection
- Crash reports that capture screen content
- Data sharing settings in the vendor console
- Retention set in the vendor account
Decision
- Keep, reconfigure or remove
- Contract and BAA status
- An owner for each SDK
- Recheck on every SDK update
Consent
How are consent and opt-out handled?
Consent is enforced where the data is collected, not only in the app's settings screen.
- Analytics that needs consent stays off until the user chooses, on every platform
- A consent_updated event reaches the collection endpoint, and the server enforces the choice
- Opting out stops collection and removes the user from future third-party exports
- Users can change their choice in app settings, not only in a first-run banner
- Each consent record keeps the version of the text the user saw
- Agnotic signs a business associate agreement before any PHI is shared with us
Metrics
Product metrics you can measure without sharing PHI
All of these come from your own event store, with pseudonymous IDs.
Activation
The share of new accounts that finish setup and complete a first key action.
Booking funnel
Drop-off between booking_started and booking_completed by platform and release, with no visit reasons.
Retention cohorts
Return visits by sign-up week and channel.
Feature adoption
Which features each release is used, counted by generic action names.
Portal task completion
Bill payments, record requests and messages completed versus started.
Digital analytics for startups
A lean event plan with a few funnel steps, set up so it can grow without renaming everything later.
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Rules and platforms
Rules and platform policies for app analytics
The rules behind the event review table. Which ones apply depends on who offers the app.
16 CFR Part 318HIPAA Privacy and Security Rules45 CFR 164.502(e)Apple privacy manifestsGoogle Play Data safetyConsent records
Facts and sources
Facts behind digital analytics for health apps
Rules and vendor statements that shape how a health app is measured, each linked to its primary source.
Under the FTC Health Breach Notification Rule, a breach of security includes an unauthorized disclosure of identifiable health information from a personal health record, not only a hack.
Source: 16 CFR 318.2 (eCFR)Notices to affected individuals under the FTC Health Breach Notification Rule are due no later than 60 calendar days after a breach is discovered, and for 500 or more individuals the FTC must be told at the same time.
Source: 16 CFR 318.4 and 318.5 (eCFR)Google states that it makes no representations that Google Analytics satisfies HIPAA requirements and does not offer business associate agreements for the service.
Source: Google Analytics Help: HIPAA and Google AnalyticsApple reminds developers that they are responsible for all the code a third-party SDK adds to their app, and Xcode combines SDK privacy manifests into one report for the App Store privacy label.
Source: Apple Developer: Third-party SDK requirements
Scope and cost
What drives the cost of digital analytics for a health app?
We do not publish prices. These change the size of the work.
Platforms
iOS, Android, web portal, or all three, and how many app versions are live.
Existing SDKs
How many third-party SDKs the audit has to cover.
Event plan size
How many funnels and events the first release needs.
Collection and warehouse
Whether you have a warehouse in AWS, Microsoft Azure or Google Cloud, or need one.
Consent model
Regions, consent types and how choices sync across devices.
Dashboards
Which product and executive views you want on top of the event store.
Engagement
How does a digital analytics engagement work?
Three stages, each with a clear output.
1.
Event and SDK audit
We capture what your live apps send today, to whom, and list what must change.
Audit2.
Event plan and collection build
The naming plan, the review table, the collection endpoint and the warehouse tables, built and tested.
Build3.
Dashboards and handover
Funnel and retention views, plus a review step your team runs before each new event ships.
RunFrequently Asked Questions
Google states it makes no representations that Google Analytics satisfies HIPAA and does not offer business associate agreements for it. For a HIPAA-regulated app we keep PHI out of it entirely, or collect events into your own warehouse instead.
It can apply to consumer health apps that are not covered by HIPAA. The rule counts an unauthorized disclosure of health information as a breach, so sending health details to an analytics or ad vendor without authorization can trigger notice duties. Your counsel makes the call; we design for it.
We do not publish prices. It depends on the number of platforms, the SDKs to audit, the size of the event plan, whether a warehouse exists and the dashboards you need. You get a written proposal after the scoping call.
Yes. We capture the network traffic of a test build, list every SDK and event, and compare it with the review table. You get a list of changes ranked by risk, and we can make the changes or hand them to your team.
No. The same metrics come from your own event store. You lose some ready-made vendor reports, which we replace with dashboards on your warehouse.
Yes. The collection endpoint writes to the warehouse you already run, with tables for raw events, sessions and consent, so analytics sits beside your other data.
AI tools may help engineers write event code and tests, but every event still goes through the review table and a human sign-off. No user or patient data is ever sent to an AI tool during delivery.