Is Mixpanel HIPAA Compliant? Product Analytics Rules for Digital Health

Is Mixpanel HIPAA compliant? Conditionally, yes. Mixpanel will sign a Business Associate Agreement (BAA) on paid plans, which is the single most important prerequisite for using any analytics tool with protected health information (PHI). However, signing a BAA alone does not make your implementation compliant. Mixpanel's default configurations, including autotrack, identity resolution, and certain SDKs, can capture PHI in ways that violate the HIPAA Privacy Rule unless you actively restrict what data flows into the platform. This article, current as of July 2026, provides a clear breakdown of what is safe, what is not, and what you must configure before sending any patient or member data to Mixpanel.

TL;DR

• Mixpanel offers a signed BAA on paid plans (Growth and Enterprise tiers); free-tier usage with PHI is not HIPAA compliant.
• Default autotrack and client-side SDKs can inadvertently capture IP addresses, device IDs, URL paths containing patient identifiers, and form field values that constitute PHI.
• Identity resolution features (ID merge, alias) can link de-identified event data back to a specific patient, creating PHI even when individual events seem safe.
• HHS OCR's December 2022 guidance on online tracking technologies treats any individually identifiable health information collected by a tracking tool as PHI, regardless of whether you intended to collect it.
• A compliant Mixpanel implementation requires server-side event ingestion with explicit allowlisting of non-PHI properties, disabled autotrack, and contractual BAA coverage.
• If your team cannot maintain these controls reliably, a purpose-built HIPAA compliant product analytics platform eliminates the configuration burden entirely.

What Mixpanel Does with Visitor and Patient Data

Mixpanel is an event-based product analytics platform. It collects data about user interactions (page views, button clicks, feature usage, funnels, retention) and ties those events to user profiles. In a digital health context, this means Mixpanel can ingest data about which patients used which features, how often they accessed appointment scheduling, what symptom checkers they interacted with, or which telehealth flows they completed.

By default, Mixpanel's JavaScript SDK and mobile SDKs collect device-level identifiers, IP addresses (used for geolocation), referrer URLs, and browser metadata. When autotrack is enabled, the SDK captures every click and page view automatically, including URL paths and element text. In a healthcare application, a URL like /patient/12345/lab-results or a button labeled "Refill Prozac" constitutes PHI the moment it is tied to an identifiable user.

Mixpanel's identity resolution system merges anonymous and authenticated user profiles. This means that even if pre-login events seem anonymous, once a user authenticates, Mixpanel retroactively links those events to the identified profile. If any of those anonymous events contained health-related context (a page path referencing a condition, a referrer from a condition-specific campaign), you have created a PHI record inside Mixpanel's servers.

BAA Availability and Terms

Mixpanel offers a BAA as part of its paid plans, specifically the Growth and Enterprise tiers. The BAA covers Mixpanel's role as a business associate under HIPAA, meaning the company contractually agrees to safeguard PHI, limit its use and disclosure, and report breaches. You should confirm current terms with the vendor, as plan structures and BAA eligibility may shift over time.

Key points about the Mixpanel BAA:

• It is not available on the free plan. Any digital health company using Mixpanel's free tier with data that could constitute PHI is operating without the minimum legal safeguard required by the HIPAA Privacy Rule.
• The BAA does not override your obligations as a covered entity or business associate. You remain responsible for ensuring that only appropriately scoped data enters Mixpanel.
• Mixpanel's BAA typically includes data retention and deletion provisions, but the specifics (retention periods, deletion timelines, audit rights) vary by contract. Confirm these align with your organization's HIPAA policies before signing.

For a broader comparison of how analytics BAA terms differ across platforms, see Traditional Analytics vs HIPAA-Compliant Alternatives: The Real Cost of Non-Compliance.

What HHS OCR Guidance Means for Mixpanel

In December 2022, the HHS Office for Civil Rights published guidance on the use of online tracking technologies by HIPAA-regulated entities. The guidance makes several points directly relevant to product analytics tools like Mixpanel:

• Any tracking technology that collects individually identifiable health information on behalf of a regulated entity is handling PHI, even if the tool vendor does not consider itself a healthcare company.
• IP addresses combined with a visit to a health-condition-specific page or feature constitute PHI.
• Regulated entities must have a BAA in place with any tracking technology vendor that receives PHI.
• Merely having a BAA does not satisfy the Privacy Rule's minimum necessary standard. You must still limit the PHI disclosed to what is reasonably necessary for the analytics purpose.

The FTC has also taken enforcement action against health companies (BetterHelp, GoodRx, Cerebral) for sharing health data with analytics and advertising platforms without adequate consent or safeguards. The FTC Health Breach Notification Rule applies to entities not covered by HIPAA, meaning even non-covered digital health startups face regulatory risk from uncontrolled analytics data flows.

State laws add additional constraints. Washington's My Health My Data Act (MHMDA) creates a private right of action for consumers whose health data is collected or shared without consent, applying to a broader definition of health data than HIPAA uses. Similar laws in Connecticut, Nevada, and other states expand the compliance surface for product analytics in health applications.

Safe vs. Unsafe Configurations

Unsafe (default) configurations

• Client-side SDK with autotrack enabled: captures every interaction, including health-related page paths, button text referencing conditions or medications, and form inputs.
• IP address collection enabled: Mixpanel uses IP for geolocation by default. Combined with health-related event data, this creates PHI.
• Identity resolution linking pre-authentication browsing to authenticated patient profiles without scrubbing health-related anonymous events.
• Sending user properties that contain names, email addresses, dates of birth, MRNs, or diagnosis codes directly into Mixpanel profiles.
• Using Mixpanel's client-side SDK on pages that display or reference PHI (lab results, prescriptions, provider messages).

Safe configurations

• Server-side event ingestion only: route events from your backend to Mixpanel's ingestion API, giving you full control over which properties are included.
• Explicit property allowlisting: define a strict schema of non-PHI properties (feature name, timestamp, plan tier, anonymous session hash) and reject any event property not on the list.
• Autotrack disabled: never use Mixpanel's automatic event capture in a healthcare application.
• IP address collection disabled: set the ip=0 flag on ingestion requests.
• Pseudonymous user IDs: use a one-way hashed identifier rather than email, MRN, or any directly identifiable value as the distinct_id.
• No PHI in user profiles: do not sync patient demographics, condition lists, or appointment details into Mixpanel's people profiles.
• Data retention controls: configure project-level data retention to the minimum period needed for analytics, and establish a deletion workflow for user-level data upon patient request.

Hospital systems and large health organizations managing multi-channel acquisition campaigns face particular complexity here. For guidance specific to those environments, see Hospital System Marketing Compliance: HIPAA-Compliant Digital Advertising for Health System CMOs.

Safe-Use Checklist for Mixpanel in Healthcare

Before you send any data

• Confirm your Mixpanel plan includes BAA eligibility and execute the BAA.
• Disable autotrack in all SDK configurations.
• Disable IP address collection (ip=0).
• Define and document an explicit allowlist of event names and properties that contain no PHI.
• Implement server-side ingestion; remove client-side SDKs from patient-facing pages.

Identity and user profile controls

• Use a pseudonymous, non-reversible identifier as the distinct_id (not email, name, or MRN).
• Do not use Mixpanel's people profiles to store demographics, diagnoses, or other PHI.
• If using identity resolution (ID merge), audit merged profiles to ensure no pre-auth events contain health-related URL paths or referrers.

Ongoing governance

• Audit event streams quarterly to detect property drift (new engineers adding fields that contain PHI).
• Maintain a data map documenting exactly what flows to Mixpanel and why it does not constitute PHI.
• Train product and engineering teams on what constitutes PHI under HIPAA's broad definition.
• Establish a breach response workflow that includes Mixpanel data in your incident scope.

When Mixpanel Works and When It Does Not

Mixpanel can work for HIPAA-regulated product analytics if your engineering team has the resources, discipline, and ongoing governance to maintain a strictly server-side, PHI-free implementation. This is feasible for well-resourced digital health companies with dedicated privacy engineering staff.

Mixpanel becomes risky when:

• Your team is small and cannot dedicate ongoing engineering effort to auditing event schemas.
• You need to track conversion events that inherently involve health context (e.g., "completed intake for anxiety," "scheduled dermatology appointment").
• You want to connect product analytics to advertising conversion APIs (Meta CAPI, Google Ads) where PHI leakage into ad platforms creates additional regulatory exposure.
• Multiple teams (product, marketing, growth) instrument events independently without centralized review.

For teams working with Meta's Conversion API in sensitive health categories, see Leveraging Meta's Conversion API for HIPAA-Compliant Data Tracking for Mental Health Services.

Compliant Alternatives

Several approaches exist for HIPAA compliant product analytics beyond configuring a general-purpose tool:

• Purpose-built HIPAA-compliant analytics platforms that enforce PHI boundaries architecturally rather than through configuration. These platforms strip or hash identifiers before data enters the analytics layer, removing the possibility of accidental PHI ingestion.
• Self-hosted analytics (PostHog self-hosted, Plausible self-hosted) where data never leaves your infrastructure. This eliminates the need for a third-party BAA but shifts the operational burden to your team.
• Server-side proxy architectures that sit between your application and any analytics tool, filtering PHI at the network layer before events reach the vendor.

For a detailed side-by-side of architectural approaches to this problem, see Curve vs Mixpanel for Healthcare Product Analytics: HIPAA Data Boundaries.

Similarly, if you are evaluating email and SMS tools alongside product analytics, the same PHI boundary questions apply; see Is Klaviyo HIPAA Compliant? Email and SMS Marketing Risks for DTC Health Brands for a parallel analysis.

A Simpler Path for Healthcare Teams

If your organization needs product analytics, session replay, form tracking, and conversion measurement without the ongoing engineering burden of maintaining a PHI-free Mixpanel configuration, Curve provides a HIPAA-compliant tracking and analytics platform built specifically for healthcare marketers. Curve signs a BAA, strips PHI before data enters the analytics layer, and delivers conversion signals server-side to Google, Meta, and Microsoft ad platforms without exposing patient identifiers. The platform handles session replay, form analytics, and funnel measurement within architecturally enforced HIPAA boundaries, so your team can focus on growth rather than compliance engineering.

Frequently Asked Questions

Does Mixpanel sign a BAA?

Yes, Mixpanel signs a BAA on its paid plans (Growth and Enterprise tiers). The BAA is not available on the free plan. Confirm current plan eligibility and BAA terms directly with Mixpanel's sales team before sending any data that could constitute PHI.

Can I use Mixpanel's autotrack feature in a patient-facing health app?

No. Autotrack captures every user interaction automatically, including URL paths, button text, and element content that may reference health conditions, medications, or patient identifiers. In a healthcare application, autotrack creates uncontrolled PHI ingestion and should always be disabled.

Is it enough to just sign a BAA with Mixpanel and use it normally?

No. A BAA is necessary but not sufficient. The HIPAA Privacy Rule's minimum necessary standard requires you to limit the PHI disclosed to Mixpanel to only what is needed for the analytics purpose. In practice, the safest approach is to send zero PHI by using server-side ingestion with strict property allowlisting and pseudonymous identifiers.

What happens if Mixpanel accidentally collects PHI without a BAA in place?

This constitutes an impermissible disclosure of PHI under the HIPAA Privacy Rule. Your organization must treat it as a potential breach, conduct a risk assessment, and potentially notify affected individuals and HHS OCR. The FTC may also have jurisdiction under the Health Breach Notification Rule if you are a non-covered entity.

Can I send Mixpanel data to Meta or Google for ad optimization?

Only if the data sent to the ad platform contains no PHI. If you are passing Mixpanel events or user properties that include health-related context to advertising APIs, you are disclosing PHI to a third party (the ad platform) that will not sign a healthcare BAA. Server-side conversion delivery with PHI stripping is required for this workflow to be compliant.

Is Mixpanel compliant with state health privacy laws like Washington MHMDA?

Mixpanel's BAA addresses HIPAA obligations, but state laws like Washington's My Health My Data Act have broader definitions of health data and require explicit consumer consent before collection. Compliance with these laws depends on your consent implementation, data flows, and whether Mixpanel receives data that qualifies as "consumer health data" under the relevant state statute. A BAA alone does not satisfy state consent requirements.