Is Google Analytics HIPAA Compliant? The Honest Answer for Healthcare Marketers (2026)

I’ve worked with a lot of small and medium-sized healthcare businesses across the US such as dental practices and therapists, and every time there are questions about whether or not GA4 is HIPAA compliant. There’s a lot of confusion about it, and most of what’s written online is either outdated, vendor-sponsored, or wrong in ways that put healthcare organizations at real legal risk.

This is the advice that I give my clients and I am sharing it here for the wider healthcare marketing community, as you deserve a better answer than “disable Google Signals and you’re good.”

The short answer is that Google Analytics (GA4) is not HIPAA compliant, because Google does not sign a Business Associate Agreement (BAA) for the product. The longer answer is of course more complex, and a federal court ruling from June 2024 changed part of what “HIPAA compliant” even means for a healthcare website.

A quick note before we go further: HIPAA is a United States law, so if you’re not located in the US, this doesn’t impact you. Also, nothing in this post is legal advice and I am definitely not a lawyer. Your compliance team and counsel should get the final word on your specific setup.

The standard answer in most articles goes something like this: disable Google Signals, mask the IPs, set a few extra retention controls, and you’re compliant. The problem with that answer is that HIPAA compliance for analytics has almost nothing to do with configuration. It’s about whether you have a BAA with the vendor that’s going to receive the data.

Here’s what a BAA actually does. When a HIPAA-covered entity (your clinic, your hospital, your telehealth platform) shares protected health information with a third party, that third party has to be contractually bound to handle the data under HIPAA’s rules. The BAA is that contract. Without a BAA, there is no legal pathway for the data to leave your walls.

And Google will not sign a BAA for Google Analytics. Their own help page says: “Google makes no representations that Google Analytics satisfies HIPAA requirements.” That’s not a configuration problem you can solve in the GA4 admin panel. It’s a deliberate vendor stance by Google.

Google will sign BAAs for certain Workspace services and specific Google Cloud products (Cloud Storage, BigQuery, the Cloud Healthcare API) under their HIPAA-eligible enterprise terms. Those are infrastructure products that healthcare orgs use to handle real Protected Health Information (PHI) in controlled environments. Google Analytics, Google Tag Manager, and Google Ads are not on that list and never have been.

This matters because the December 2022 HHS Office for Civil Rights (OCR) bulletin on online tracking technologies put healthcare orgs on notice that running analytics tools on pages with patient information was a HIPAA issue. OCR followed with an updated bulletin in March 2024, and the American Hospital Association sued HHS over it. In June 2024, the U.S. District Court for the Northern District of Texas vacated part of the guidance — specifically the part that said connecting an IP address to an unauthenticated public webpage about a health condition automatically triggered HIPAA. The rest of the guidance still stands.

That ruling is something that is missed in a lot of the other articles on this subject and it absolutely impacts how you approach analytics and HIPAA compliance. I’ll come back to that in a moment.

The other thing the basic answer skips is enforcement. Since 2023, US healthcare providers have paid out more than $100 million in pixel-tracking settlements, including $12.25 million from Advocate Aurora Health, $6.6 million from Novant Health, and a long list of others. Almost none of those were OCR penalties. They were class-action lawsuits filed by plaintiffs after a breach disclosure or a journalism investigation. Your compliance team isn’t only worried about OCR; they’re worried about plaintiffs’ attorneys, and the AHA ruling doesn’t help with that at all.

PHI in an analytics context is broader than most people expect, because identifiers plus health context combine to create PHI even when neither piece alone would. The classic example is an IP address paired with a page URL like /appointments/oncology. The IP isn’t PHI on its own. The URL isn’t PHI on its own. Together, on the right page, they create a record that “this person is seeking care for this specific thing” — and that is PHI.

Which means that the June 2024 court ruling decided that combination, on an unauthenticated public webpage, no longer automatically triggers HIPAA. So a public marketing page about your oncology services, viewed by someone who isn’t signed in, isn’t a HIPAA problem under the vacated portion of the OCR guidance.

What the ruling did not change is just as important:

• Authenticated pages still count. Patient portal, MyChart-equivalent flows, logged-in scheduling, anything behind a sign-in are still very much in scope. IP plus URL plus a logged-in patient context is still PHI.
• Google’s BAA stance is unchanged. Whatever the court said about HHS guidance, Google still won’t sign a BAA for Google Analytics. So even where HIPAA doesn’t strictly apply post-ruling, you can’t send PHI to GA4.
• Class-action plaintiffs don’t need the OCR bulletin to file. They file on state privacy laws, on common-law privacy torts, or on consumer protection statutes. The Advocate Aurora and Novant settlements happened independently of any HHS enforcement.

Where PHI most often leaks, in my experience auditing healthcare marketing analytics:

• URL paths and query strings. Things like /appointments/oncology or ?condition=diabetes or /search?q=hpv+treatment. Even the referrer header from a search results page could carry the query in.
• Form field values. If your form autofills patient information and GA4 captures the form_submit event even with some of the field values, that’s potentially PHI in your analytics property.
• Heatmap and session replay tools. Tools like Microsoft Clarity, Hotjar, and FullStory capture DOM state, including form input. They’re often a bigger PHI risk than GA4 because they can record what people type. The BAA test still applies.
• Click-tracking event parameters. A button labelled with a condition name, or a click event that carries a URL parameter forward, can both leak.

This is why the “disable Google Signals” advice doesn’t actually solve very much at all. Your job is to know which pages and which events touch this category, so you can make different decisions about each.

If you work for a healthcare organization in the US, you have four realistic options, and the right answer is almost always a combination, not a single tool.

Option 1: Google Analytics only on truly public marketing pages

This is the path that just got more defensible after the June 2024 ruling. Running GA4 on your homepage, your “about us,” your blog, your public services overview, as long as they are unauthenticated pages with no patient-identifying content, sits in a much friendlier legal place than it did two years ago. That doesn’t mean you can do what you want, however. You still have class-action exposure on any data sharing with named third parties like Meta or Google Ads, and state privacy laws (California’s CCPA/CPRA, Washington’s My Health My Data Act, New York SHIELD) layer their own consent and disclosure requirements on top, totally independent of HIPAA. Your compliance team will care about all of that even when OCR doesn’t.

Option 2: Server-side tagging with PHI scrubbing

Server-side Google Tag Manager lets you intercept the data your site is sending to GA4, filter out URL parameters and event payloads, and pass through only what’s safe. It’s a real engineering investment but it gives you fine-grained control. That being said, server-side tagging does not solve the BAA problem. The data still ends up in Google’s GA4 infrastructure, just pre-filtered. Server-side is a move that helps with Option 1, not a workaround for the underlying vendor stance issue.

If you don’t have the engineering capacity to host server-side GTM yourself, Stape is the most common managed option — they host the sGTM container so your team doesn’t have to. A different category worth knowing about is Freshpaint, which sits between your site and your analytics tools as a data governance layer, scrubbing PHI from event payloads before anything reaches GA4 (or any other tool you’re sending data to). Either of these helps you execute Option 1 in a way that holds up to compliance review, but neither changes Google’s underlying BAA stance. I’ve also written a beginner’s guide to server-side tagging if you want to learn more about how that method works.

Option 3: HIPAA-eligible analytics for PHI-adjacent pages

When you actually need behavioural data on pages that touch patient info, you need a vendor that will sign a BAA, or a tool you can run on infrastructure you control. The options that can work for this are:

• PostHog — signs a BAA on their platform packages.
• Matomo (self-hosted) — when you run it on your own servers, Matomo the company can’t access your data, so there’s no BAA to sign. Matomo Cloud is a different story and is not HIPAA-compliant.
• Adobe Customer Journey Analytics, Piano Analytics, and Amplitude will all also sign a BAA. (Thanks Jason Packer for the information!)

You’ll give up some of GA4’s depth and the native Google Ads integration, but you get an analytics setup that lets you realistically track behaviour on pages where GA4 can’t go.

Option 4: Split tracking by page type

This is the combination most healthcare organizations end up going with as it gives you the most data with the least risk. The way it works is that you have GA4 (and your other Google Marketing Platform tools) on the marketing pages but you use a HIPAA-eligible tool on patient-portal-adjacent pages, condition-specific flows, and anywhere PHI risk is a real concern. Then, on the most sensitive pages such as the appointment flow itself or the patient portal interior, there is no third-party tracking at all. You’ll still have basic server logs that you can use to look at usage, which realistically may be all you can know about these private systems.

This option might seem like the weakest as it involves completely removing some tracking, but I want to remind you that analytics decisions are strategy, not data accounting. You’re not running analytics to tick a box. You’re running it to make decisions, and the right setup is the one that lets you make decisions without putting your company at legal risk.

A workable healthcare analytics setup has three parts: a clear page classification, tag management that enforces it, and documentation your compliance team can get behind.

Classify your pages

Go through your site and put every page in one of four buckets:

1. Marketing — homepage, about, services overview, blog, public condition info. GA4 is OK here, with the state-law caveats above.
2. Transactional but not PHI — “Contact us” forms with no health info, location finders, general inquiries. Evaluate this on a case-by-case basis. Generally GA4 is okay to use if no health context is collected.
3. PHI-adjacent — appointment request forms, condition-specific landing pages with intake forms, anything that captures patient identity tied to a clinical purpose. Do not use GA4. Use the Option 3 tool, or nothing.
4. Patient portal / authenticated — logged-in everything. No GA4, no marketing pixels, server operational logging only.

Configure your website and tag management to enforce the classification

Work with your IT team to build in exceptions to allow Google Tag Manager on only the pages where that level of tracking is allowed, and suppress it otherwise. As a backup, create trigger exceptions on page path patterns and excluded URL parameter lists in your Google Tag Manager container, or ideally use a “page type” metadata as a lookup value. The exact setup will vary depending on your tech stack, but the principle is that the classification should be machine-enforced, not relying on someone remembering to disable a tag.

Document for compliance

Your privacy officer, your HIPAA security officer, and your legal counsel are the audience for this document. They want to see, on one page:

• The page classification matrix — which pages are in which bucket.
• The tools you’re using, what they do, and what data they receive.
• The BAA status of each tool (with the actual signed agreement attached or referenced).
• Retention settings, consent banner integration, and the GTM rules enforcing the classification.

Once this documentation is created, ensure it’s reviewed and maintained quarterly. Alongside the documentation, perform regular quality assurance spot checks to confirm that the setup is still working as expected. The goal is not to be scrambling when your compliance team wants to double-check your analytics configuration.

If you’re a healthcare marketer reading this and trying to figure out where to start, three concrete steps:

1. Review your site and classify every page into the four buckets above. Where is GA4 firing right now? Which of those pages should it not be firing on?
2. Pull the BAA list. Every tool that touches healthcare pages — analytics, heatmaps, advertising pixels, chat widgets — needs to be on the list with its BAA status next to it.
3. Bring the classification matrix and the BAA list to your compliance team before they bring questions to you. The conversation goes better when you arrive with evidence.

This work isn’t fast. You won’t change your organization’s setup overnight, and you’ll probably get pushback from somebody who likes the old tag setup. That’s okay! Two steps forward, one step back is still a step in the right direction. This is one of those projects where the work itself moves you towards compliance.

Have questions about this? Check out my related YouTube video where I walk through these concepts in detail, and drop your questions in the comments!