Is Heap HIPAA Compliant? Product Analytics Verdict

Yes, with conditions. Heap states publicly that it is HIPAA compliant and signs Business Associate Agreements with customers, which puts it in the small group of product analytics tools a covered entity can contract with at all. The condition is autocapture. Heap's defining feature is that it records interactions automatically without you defining events first, which means a patient portal or intake flow starts sending sensitive detail the moment the script loads unless you have suppressed it. For the advertising layer, Curve is the HIPAA-compliant tracking platform that keeps conversion data flowing to Meta and Google without the disclosure, with a signed BAA on every plan.

The direct answer, in more detail

Heap, now part of the Contentsquare group, is a digital analytics product built around retroactive event definition. Instead of instrumenting a click and waiting for data, Heap captures interactions as they happen and lets you define the event afterwards. That is a real advantage for product teams, because you can answer a question about last month without having planned for it last month.

On compliance, Heap's own published material states that Heap is HIPAA compliant, that it signs BAAs with customers, and that HIPAA training is part of employee onboarding. Heap also lists ISO 27001, 27701, 27017, and 27018 certifications. Taken together, that is a vendor that has done the work to be contractable by healthcare organizations.

Two caveats are worth stating plainly rather than glossing over. First, BAA availability does not appear as a listed feature on Heap's public pricing page, so which contract or tier it attaches to is not something you can confirm from the website. Get it in writing from Heap directly before you assume your current plan includes it. Second, if you use other products in the Contentsquare family alongside Heap, do not assume the BAA scope follows across them. Ask which named products the agreement covers, and treat anything unlisted as outside the boundary.

Why autocapture is the real question

The BAA settles whether Heap may lawfully hold PHI. It does not settle whether Heap should be holding as much PHI as your default configuration is sending it.

Autocapture works by observing the DOM. It records clicks, page views, form field interactions, and in many configurations the text entered into those fields. On a marketing site selling running shoes, that is a rich dataset with no downside. On a healthcare property, the same mechanism captures a condition selected from a dropdown, a symptom typed into a free-text box, a date of birth, an insurance member number, and the URL of the page describing a specific treatment.

Heap provides the controls to prevent this. Sensitive fields can be suppressed so their contents never leave the browser, and data privacy tooling exists precisely for this scenario. The controls are opt-in. That asymmetry is the whole story: the volume of PHI your analytics vendor holds is set by how thoroughly your engineering team configured suppression, not by anything in the contract.

A BAA covering a mountain of unnecessary PHI is still a compliance posture you would rather not defend. Minimum necessary is a HIPAA principle, not a nice-to-have. If the analytics answer you need is "how many people completed intake," you do not need what they typed into it.

The fields that catch people out

• Free-text reason-for-visit boxes. The single richest source of unstructured PHI on any clinic site.
• Condition and service dropdowns. Structured, easy to capture, and unambiguous about what the person is seeking care for.
• URL paths and query strings. A path naming a procedure is health information attached to a session identifier.
• Confirmation pages. Frequently render the appointment type, the provider name, and sometimes the location specialty in visible text.
• Chat widgets and scheduling embeds. Third-party iframes with their own capture behavior, sitting inside pages you thought you had audited.

Where Heap is genuinely fine

Product analytics has an honest and valuable role in healthcare. Understanding where patients abandon an intake flow, which step of a scheduling funnel is slowest, whether a redesigned form improved completion: these questions improve patient experience and they do not require the vendor to know anyone's diagnosis.

Heap is a good fit when:

• You have a BAA executed and you can name its scope.
• Suppression is configured on every sensitive field before launch, not retrofitted after a compliance review.
• URLs are structured so that path segments do not name conditions or treatments.
• Access to the analytics workspace is limited and reviewed, particularly for agency users.
• The analysis you run is aggregate behavior, not individual patient journeys reconstructed by name.

Under those conditions you are measuring the product, not the patient, and the BAA covers the residue that inevitably slips through.

What a BAA covers here, and what it does not

A BAA is a boundary drawing exercise. It names a vendor, names the data, and sets that vendor's obligations for it. Everything outside the boundary is yours.

Inside the boundary: Heap's storage of captured events, its access controls, its breach notification duties, its obligations to pass requirements down to its own subcontractors.

Outside the boundary: every other script on the page, and every destination you export to. This is where healthcare analytics deployments actually fail. A clinic signs a BAA with its analytics vendor, feels covered, and leaves a raw Meta Pixel and an untamed Google tag loading on the same intake page. Meta and Google do not sign BAAs for their advertising products. They will not, and no amount of configuration inside Heap changes what those separate scripts transmit.

The healthcare pixel litigation that has produced more than $100 million in cumulative settlements did not turn on analytics warehouses. It turned on browser calls to ad platforms. Advocate Aurora settled at roughly $12.225 million on that theory, which requires only that an identifiable person's health interest was disclosed to a third party.

Where the ad tracking problem shows up

Picture a typical clinic stack. Heap is installed with suppression configured and a BAA in place. The compliance team signs off. On the same page sits a Meta Pixel, because the marketing team needs conversion tracking, and a Google tag, because someone needs Enhanced Conversions to work.

Those two scripts do not respect Heap's suppression rules. They have their own. The pixel fires a page view carrying the full URL. If that URL is a treatment page, the disclosure is complete before anyone fills in a form. On submission, standard pixel implementations frequently pick up form values, and Google's Enhanced Conversions flow is designed to send hashed customer data for matching. All of it is tied to a persistent browser identifier that binds the sequence to one person.

Nothing in your Heap contract addresses that. We covered the mechanism in detail in our explanation of whether the Meta Pixel or the Conversions API is HIPAA safe, and the answer is that moving to a server-side API only helps if you control the payload on the way through.

How Curve handles the advertising layer

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. It does not replace product analytics. It replaces the ad platform scripts sitting next to it, which is the part of the page a Heap BAA cannot reach.

The Curve tracking script installs in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure instead of directly to ad platforms, and decisions get made there:

• Per-destination field mapping. Only fields you explicitly map reach a given destination, configured separately per destination. The default is that nothing goes. Page URLs, form values, and service selections stay behind unless mapped deliberately.
• Identifier hashing. Email, phone, and name are SHA-256 hashed to each platform's conversion API requirements before forwarding.
• Neutral event aliases. The ad platform sees a generic conversion name rather than one that encodes the service line, so the treatment never appears in a shared ad account interface.
• PHI-pattern detection. Curve flags PHI-shaped values including SSNs, MRN-style identifiers, dates, and long numeric sequences. It is a monitoring layer that tells you when something upstream changed. The protection is the field mapping plus hashing.
• Bridge tokens. Attribution survives the handoff when a patient clicks out to a separate booking or intake tool, which is normally the exact point where measurement dies.
• Offline conversion uploads. Outcomes that close later in a CRM or EHR upload in bulk and match on click ID, so a booked appointment still credits the campaign that produced it.

Clean conversions forward server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, and LinkedIn. Server-side delivery is also immune to ad blockers and browser tracking prevention, which usually raises measured conversion volume rather than lowering it. Every Curve plan includes a signed BAA. The architecture behind this is laid out in our technical overview of conversion API architecture for HIPAA compliance.

What to check in your own deployment

1. Get the BAA countersigned and read its scope. Confirm which named products it covers and its effective date.
2. Audit suppression field by field. Load a staging intake form, submit test data, and inspect the outbound payload rather than trusting the configuration screen.
3. Read your URLs as a stranger would. If a path segment names a condition, that is a disclosure every time it travels.
4. Inventory every script on patient-facing pages. Tag managers hide more than most teams expect. Our free compliance scanner gives you a fast first pass.
5. Review workspace access. Agency and contractor logins into an analytics tool holding PHI need the same scrutiny as EHR access.
6. Set retention deliberately. Behavioral data kept forever has diminishing analytical value and increasing breach exposure.

Frequently asked questions

Does Heap sign a BAA?

Heap's own published material states that it signs BAAs with customers and is HIPAA compliant. Because the public pricing page does not list BAA availability by tier, confirm with Heap which contract includes it and obtain the countersigned document before sending any PHI.

Is autocapture compatible with HIPAA?

It can be, under a BAA and with suppression configured on sensitive fields. What is not compatible is leaving autocapture at its defaults on patient-facing pages and assuming the contract absorbs the consequences. Minimum necessary still applies to your analytics vendor.

Does the BAA cover other Contentsquare products we use?

Do not assume so. BAA scope is defined by the named services in the agreement, and product families frequently have different positions on health data. Ask for the list of covered products and treat anything absent from it as uncovered.

Can we keep our Meta Pixel if Heap is properly configured?

No. Heap's configuration governs Heap. The pixel is a separate script with its own behavior, sending to a company that has not signed a BAA and does not offer one for advertising. Replace it with a server-side path where you control what forwards.

Do we lose retroactive analysis if we suppress fields?

You lose retroactive analysis of the suppressed content specifically, which for clinical free-text is the correct trade. You keep retroactive analysis of behavior: which steps were reached, in what order, how long they took, and where people dropped. That is where the product insight lives anyway.

Will replacing pixels with server-side tracking hurt campaign performance?

Generally the opposite. Conversion optimization runs on conversion events and matching keys, not on descriptive labels, and server-side delivery bypasses ad blockers and browser tracking prevention that suppress client-side pixel firing. Most clinics see measured volume hold or improve.

Where to start

Heap is contractable for healthcare, which is more than most product analytics vendors can say. Treat the BAA as permission to proceed carefully rather than proof that you are finished. The work that follows is unglamorous and decisive: suppress the sensitive fields, restructure URLs that name conditions, restrict who can open the workspace, and set retention like it matters.

Then look at what else is loading on the same page, because that is where the exposure that ends up in a complaint actually lives. Curve replaces the ad platform scripts with a server-side path built for healthcare: per-destination field mapping, SHA-256 hashed identifiers, neutral event aliases, PHI-pattern monitoring, bridge-token attribution, and offline conversion uploads, with a signed BAA on every plan. Run the free compliance scanner against a patient-facing page to see what is leaving right now, or visit curvecompliance.com to walk through the architecture. If your CRM is next on the list, our verdict on whether HubSpot is HIPAA compliant covers marketing automation on the same terms.

Reviewed August 2026. Vendor BAA policies change. Confirm current terms with the vendor.