Google Analytics 4 is not HIPAA compliant. Google states this explicitly: it “makes no representations that Google Analytics satisfies HIPAA requirements” and does not offer Business Associate Agreements (BAAs) for the service. Without a BAA, a HIPAA-covered entity cannot legally use GA4 in any context where protected health information (PHI) might be collected or transmitted to Google.
That’s the short answer, but the practical reality is more nuanced. Healthcare organizations can still use GA4 in limited ways, and the legal landscape shifted in mid-2024. Here’s what you need to know.
Why Google Won’t Sign a BAA for GA4
HIPAA requires that any third-party vendor handling PHI on behalf of a covered entity sign a Business Associate Agreement. A BAA spells out how the vendor will protect that data, report breaches, and limit its use. Google offers BAAs for some of its products (certain Google Cloud and Google Workspace services, for example), but GA4 is specifically excluded.
Google’s support documentation is unusually direct about this. It tells customers that they “must refrain from using Google Analytics in any way that may create obligations under HIPAA for Google” and that HIPAA-regulated entities “may only use Google Analytics on pages that are not HIPAA-covered.” In other words, Google isn’t trying to close the gap. It’s telling healthcare organizations to keep PHI away from GA4 entirely.
What Counts as PHI on a Website
This is where most confusion lives. PHI isn’t limited to obvious data like names, Social Security numbers, or medical record numbers. Under HIPAA, PHI is any individually identifiable health information, and that definition can extend to combinations of data that seem harmless on their own.
The U.S. Department of Health and Human Services (HHS) issued guidance clarifying that information collected through tracking technologies on a healthcare website “generally is PHI, even if the individual does not have an existing relationship with the regulated entity.” An IP address paired with a visit to a page about a specific medical condition could qualify if the visit relates to that person’s past, present, or future healthcare.
Consider a real example from the HHS guidance: if someone visits a hospital’s oncology services page to seek a second opinion on treatment for a brain tumor, the collection of their IP address, location data, or device identifiers showing that visit is a disclosure of PHI. The information is both identifiable (the IP address) and related to the individual’s health.
The 2024 Court Ruling That Changed the Picture
In June 2024, a U.S. District Court in Texas partially struck down the HHS guidance in a case brought by the American Hospital Association. The court vacated the portion of the guidance saying that HIPAA obligations are triggered simply when a tracking technology connects an IP address with a visit to an unauthenticated public webpage about a health condition or healthcare provider.
After this ruling, HHS updated its guidance to clarify that “the mere fact that an online tracking technology connects the IP address of a user’s device with a visit to a webpage addressing specific health conditions or listing health care providers is not a sufficient combination of information to constitute” individually identifiable health information, as long as the visit isn’t related to that person’s actual health or healthcare.
This ruling narrows the scope of what counts as PHI on public-facing pages. Visits to general informational pages on a hospital’s website are less risky than before. But the ruling does not change the picture for authenticated pages (patient portals, appointment scheduling, intake forms) or pages where the visitor’s interaction reveals something specific about their health situation. And it doesn’t change Google’s position: no BAA, period.
Where GA4 Can and Can’t Be Used
Google’s own guidance draws a clear line: you can use GA4 on pages that are “not HIPAA-covered.” In practice, that means public-facing marketing pages that don’t collect or expose any health-related data tied to an identifiable individual. A hospital’s homepage, its “About Us” section, or a general careers page would typically fall into this category.
Pages where GA4 becomes a liability include:
- Patient portals and authenticated pages. Any page behind a login where the user’s identity is known and their activity relates to their care.
- Appointment scheduling and intake forms. These inherently tie an identifiable person to a healthcare interaction.
- Symptom checkers or condition-specific tools. If the tool collects user input about health conditions alongside identifiers, that’s PHI.
- Pages where URL structures reveal health information. If your URL reads something like /departments/oncology/appointment-confirmed, even a public page can leak health context through the page path GA4 collects automatically.
The challenge is that GA4 collects a wide range of data by default: page URLs, referral sources, device identifiers, geographic location, and behavioral signals. Even if you don’t intentionally send PHI, the combination of what GA4 automatically gathers can cross the line on pages with health-related content.
Server-Side Tagging as a Partial Workaround
Some organizations try to use GA4 through a server-side tagging setup, where data from the user’s browser goes to a server you control before anything reaches Google. The idea is to strip out identifying information and health-related data points before forwarding sanitized analytics data to GA4.
Google’s own server-side Tag Manager runs in your Google Cloud project (or another environment you choose), and “only you have access to the data in the server until you choose to send it elsewhere.” You have full control over how data is shaped and where it’s routed. In theory, this lets you redact IP addresses, strip URL parameters that contain health information, and remove any identifiers before the data reaches GA4’s servers.
This approach reduces risk, but it doesn’t eliminate the core problem. Google still won’t sign a BAA for GA4, so if PHI leaks through your redaction process due to a misconfiguration or oversight, you have no contractual protection. The entire burden of ensuring zero PHI transmission falls on your technical team, and that burden is ongoing. Every new page, every URL change, every form addition needs to be audited. Most compliance officers and legal teams consider this too fragile for comfort.
HIPAA-Compliant Analytics Alternatives
Several analytics platforms are built specifically for environments where PHI protection matters. The features that set them apart from GA4 include native BAA support, data encryption, access controls, audit logs, anonymization options, and hosting environments designed for regulatory compliance.
Piwik PRO is one of the more widely adopted options in healthcare. It offers customizable BAAs, secure hosting through Microsoft Azure, and advanced anonymization controls. Heap is another platform that supports HIPAA compliance through BAAs, encryption, and privacy controls.
Matomo, a popular open-source analytics tool, takes a different approach. It doesn’t offer a BAA, but it can be self-hosted on your own infrastructure. If you run Matomo on servers you control, the data never leaves your environment, which sidesteps the need for a third-party BAA entirely. The tradeoff is that you’re responsible for securing, maintaining, and updating the platform yourself.
When evaluating alternatives, the key capabilities to look for are: whether the vendor will sign a BAA, where your data is stored and whether you can control the hosting environment, what anonymization and data minimization options exist, whether the platform provides audit logs for access tracking, and how it integrates with consent management tools you may already use.
The Bottom Line for Healthcare Organizations
GA4 is not HIPAA compliant, and Google has no plans to make it so. You can use it on truly public, non-health-related pages where no PHI is at stake. But for any part of your digital presence where a visitor’s identity could be connected to their health, GA4 is a compliance risk. The 2024 court ruling gives some breathing room for unauthenticated public pages, but it doesn’t change GA4’s fundamental limitation: no BAA, no access controls designed for healthcare, and automatic data collection that’s difficult to fully sanitize. Organizations serious about analytics and compliance are better served by platforms purpose-built for regulated environments.