HIPAA and Google Analytics: What You Can and Can't Track

Healthcare marketing teams treat GA4 as a marketing tool, not a clinical one. Their logic: GA4 tracks campaign performance, not patient records. The two systems never touch.

That logic doesn't hold under HIPAA. And since December 2022, the regulatory guidance has been explicit about why.

Start With the BAA Question

Does Google sign a BAA for GA4?

No. Google signs BAAs for Cloud Platform and Workspace. Not for Analytics, not for Ads, not for Tag Manager. This is a categorical exclusion documented in Google's HIPAA terms — not a configuration gap, not an oversight. You cannot negotiate a GA4 BAA with Google. It does not exist.

HIPAA requires a BAA with any business associate that could access PHI in the course of providing services to a covered entity. "Could access" is the standard — not "has accessed." If GA4 runs on a healthcare site and patients interact with it, Google qualifies as a business associate. Without a BAA, the arrangement is a violation independent of what data is actually flowing.

Healthcare IT teams sometimes point to an existing GCP BAA and assume GA4 is covered. It is not. Google's HIPAA terms explicitly exclude Google Analytics from BAA coverage. Ask your compliance team to pull the contract language.

What GA4 Actually Collects

Setting aside the BAA problem for a moment: what does GA4 capture by default?

With Enhanced Measurement enabled — the default in every new GA4 property — the tag collects:

• Full page URL and page path
• Page title
• HTTP referrer
• Client ID (a persistent cross-session identifier stored in a first-party cookie)
• Session ID
• User agent
• IP address (sent to Google before truncation happens server-side)
• Form interactions, scroll depth, and outbound clicks

On most websites, this list describes marketing data. On a healthcare site, the same fields describe PHI.

A user visiting /services/behavioral-health/anxiety-treatment and scrolling to the provider directory triggers a GA4 scroll event. That event payload includes the full page path — which contains a condition category — alongside the client ID, which is a persistent identifier. Under HIPAA's 18-identifier framework, a persistent identifier combined with health information constitutes PHI. The combination is what matters, not the individual fields in isolation.

This is not a hypothetical. HHS addressed it directly.

The December 2022 Guidance That Changed the Analysis

In December 2022, the HHS Office for Civil Rights published a bulletin titled "Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates." It named Google Analytics and Meta Pixel explicitly.

The key language: tracking technologies on pages where individuals seek information about their past, present, or future health transmit PHI "when the tracking technology connects the individual's IP address or other identifying information... with their visits to web pages addressing specific health conditions or treatments."

Pre-authentication pages are included. The guidance does not limit itself to patient portals or authenticated areas. If a patient visits your cardiology service line page and GA4 captures the full URL alongside a persistent client ID, that interaction is PHI — regardless of whether the patient ever logged in.

The FTC issued companion guidance the same month, invoking the Health Breach Notification Rule for health apps and websites transmitting health information to third parties without authorization. Between the two agencies, the regulatory posture shifted from ambiguous to explicit in 30 days.

If your GA4 compliance review predates December 2022, it is out of date.

What You Can Track with GA4 in Healthcare

There is a narrow, defensible use case. It requires:

• GA4 running only on public marketing pages with no health information in URL paths or page titles
• URL structure containing no condition names, treatment types, service-line identifiers, or provider specialties
• No user ID assignment, no cross-site linking, Enhanced Measurement disabled on any health-adjacent page
• Hard exclusion from every authenticated area, scheduling flow, symptom checker, provider directory, and condition-specific page

In practice, this describes a homepage and a generic "About Us" page. It does not describe the pages healthcare marketing teams actually care about: condition pages, service line pages, campaign landing pages for specific treatments. Those pages are where patients seek health information. That is where GA4 is categorically off the table.

What You Cannot Track

Standard GA4 configuration cannot legally run on:

• Any page where a URL contains a condition name, treatment category, or provider specialty
• Any authenticated area or patient portal
• Any appointment scheduling or intake flow
• Any symptom checker or care navigator
• Any provider directory page
• Any campaign landing page targeting a health condition

This is most of the healthcare site — and most of the marketing funnel.

The Audit You Need to Run First

Before making architectural decisions, establish an accurate inventory.

1. Pull your GTM container configuration and list every page or page pattern where a GA4 tag fires. Do not rely on memory or the analytics UI — export the container JSON and look at the actual triggers.

2. Cross-reference those pages against your URL structure. Flag every URL containing a condition name, provider specialty, treatment type, or service-line identifier.

3. Review your vendor contracts for a signed Google BAA covering GA4. You will not find one. Document the absence explicitly so your legal team has it in writing.

4. Run the same check on every other analytics or session recording tool on the site. Hotjar, FullStory, Microsoft Clarity, Heap — any tool capturing session-level data on health-adjacent pages has the same BAA exposure as GA4.

5. Search your HTML source for hardcoded third-party scripts. Anything not loaded through GTM bypasses your consent layer entirely. On healthcare sites, session recording tools and chat widgets added directly by developers are often where the worst PHI exposure lives.

The Fix

It's not that healthcare organizations can't do analytics. It's that they need two separate measurement layers — different tools, different data flows, different compliance posture — and most run everything through a single GA4 property.

Marketing layer: Campaign attribution, conversion tracking, and funnel analysis, running on a HIPAA-eligible tool. Options that sign BAAs: Heap, Mixpanel, or self-hosted Matomo on your own infrastructure. A first-party BigQuery stack built on Google Cloud is covered under GCP's existing BAA and gives you more control. This layer handles condition pages, campaign landing pages, and conversion measurement. GA4 is not in this layer.

Clinical/post-auth layer: Authenticated user behavior, appointment flow optimization, patient portal analytics. Separate tooling, separate governance, separate consent architecture.

The mechanism connecting them: sGTM as the server-side event layer. Browsers send raw events to your sGTM endpoint. The server container filters PHI from page paths — stripping condition names, provider identifiers, and treatment types — before forwarding events to downstream marketing tools. Consent state is enforced server-side, not just in the browser, so it cannot be bypassed by script injection or banner-level failures.

This is not a tag reconfiguration. It is an architecture decision that has to precede any tool selection. The tools change. The architectural requirement — PHI never reaches a vendor that won't sign a BAA — stays constant.

The Bottom Line

GA4 is not a healthcare analytics tool. Not because it lacks features — because Google has decided not to participate in the BAA infrastructure that would make it one.

It's not a configuration problem. It's an architecture problem — and the architecture has to be built around tools that can actually operate in a regulated environment.