June 2026 Ruling: Google Analytics Compliance for U.S. Providers

Hands connecting network cable to security device

Google Analytics is not HIPAA-compliant, and no configuration setting changes that. Google will not sign a Business Associate Agreement for GA4, which means any page where the tool could transmit protected health information puts a covered entity at risk. The fix isn’t quitting analytics. It’s pulling GA4 off patient-facing and authenticated pages immediately, then deciding page by page where a public marketing page can keep running it under tighter controls.

TL;DR:

Tracking pages with protected health information, such as patient portals and appointment pages, must be removed from GA4 immediately.

Google states it makes no representations that GA4 complies with HIPAA, and no Business Associate Agreement is offered for this product.

Only public marketing pages without any PHI exposure can safely run GA4, but thorough auditing of URL parameters and embedded forms is essential.

Turning off Google Signals, User-ID, and form tracking, plus implementing IP anonymization, significantly reduces PHI leakage risk.

Alternatives like self-hosted analytics, enterprise BAA-compliant platforms, or warehouse-first data architectures provide HIPAA-safe options.

Is Google Analytics HIPAA Compliant? The Legal Backdrop
Which Pages Can Still Run GA4?
How Do You Reduce PHI Leakage Risk in GA4?
What Are the HIPAA-Safe Alternatives to Google Analytics?
How Should You Audit and Fix Your Analytics Setup?
How Does an Agency Actually Implement This?
Our Take: Default to Removing GA4, Not Configuring It
Get Your Analytics Setup Audited and Fixed
Where to Verify This Yourself
Sources

Is Google Analytics HIPAA Compliant? The Legal Backdrop

No. Google states plainly that it makes no representations that Google Analytics satisfies HIPAA requirements, and it tells customers directly not to send anything that could count as PHI into the platform. That’s not fine print buried in a terms-of-service update. It’s a flat disclaimer sitting on Google’s own help page.

Here’s why that matters legally, not just practically. Under HIPAA, any vendor that receives protected health information on a covered entity’s behalf needs a signed BAA. Google does not offer one for Analytics, full stop, even though it does sign BAAs for a short list of other products. Without that agreement, there’s no contractual mechanism making Google accountable for how it handles the data, and the disclosure itself can already be the violation.

The Department of Health and Human Services’ Office for Civil Rights has said the same thing from the regulator’s side. Its bulletin on online tracking technologies makes clear that a tracker capturing IP addresses, device identifiers, or appointment details alongside health context can trigger HIPAA obligations, BAA or not.

A June 2024 ruling narrowed, but didn’t erase, that exposure. In AHA v. Becerra, a federal court vacated the part of OCR’s guidance that treated an IP address combined with a visit to an unauthenticated public webpage as PHI on its own. That theory is gone. What survived:

Authenticated pages, patient portals, and scheduling tools remain squarely in scope.
Tracking that combines identifiers with a specific condition, provider, or appointment context can still count as a disclosure.
OCR’s underlying position on tracking technology, minus that one theory, stands.

Layer state privacy law on top and the picture gets tighter, not looser. Washington’s My Health My Data Act, California’s CPRA, and New York’s SHIELD Act all impose their own consent and disclosure rules on health data collection, independent of HIPAA. A page that clears the federal bar can still create state-level liability.

Which Pages Can Still Run GA4?

Not every page on a healthcare website carries the same risk, and treating them all identically wastes engineering time on low-risk pages while leaving high-risk ones exposed. Sort every URL into one of four buckets before you touch a single tag.

PHI surfaces. Patient portals, appointment confirmation pages, lab result views, and billing dashboards. GA4 comes off these entirely, no exceptions.
PHI-adjacent pages. Condition-specific landing pages (“Diabetes Care in Austin”), physician bio pages tied to a specialty, or symptom checkers. Usually no, because the page content itself can reveal a health context when paired with a visitor identifier.
Unauthenticated public marketing pages. Homepage, general service overviews, location pages, blog content with no condition-specific targeting. Conditional. Defensible if you can show no PHI reasonably flows to Google, but only if you’ve actually verified that, not assumed it.
Administrative and non-care pages. Careers, press releases, investor relations, general “About Us” content. Fine to track normally.

The gray zone lives in bucket two and three, where a page looks generic but the URL parameters, form fields, or referral path quietly leak more than intended. Run a full tag inventory using GA4’s DebugView or a network tab audit, and flag any page where a query string could carry a patient name, appointment ID, or diagnosis code.

Pro Tip: Don’t trust your CMS template to tell you what’s on a page. A “general” blog post that embeds a symptom quiz or a chatbot widget can quietly become a PHI-adjacent page overnight. Audit the page’s actual DOM, not its category label.

How Do You Reduce PHI Leakage Risk in GA4?

Once pages are classified, the engineering work starts. None of this makes GA4 HIPAA-compliant. It reduces the odds that PHI ever reaches Google in the first place, which is the practical goal when a full migration isn’t happening this quarter.

Start with the settings that turn off entirely rather than the ones you have to configure carefully:

Disable Google Signals and User-ID. Both features exist to stitch cross-device identity together, which is precisely the kind of persistent identifier that turns an anonymous pageview into something closer to a personal record.
Strip PHI from URLs. Appointment confirmation links, patient names in query strings, and condition names in slugs all get logged by GA4 automatically. Scrub them at the routing layer, not after the fact.
Turn off enhanced measurement’s form-field tracking. GA4’s default form tracking can capture field interactions on intake or contact forms without anyone flipping a dedicated switch.
Set IP anonymization and shorten data retention. GA4’s default retention window is longer than most compliance teams want; drop it to the minimum GA4 allows.
Disable data-sharing settings and cross-product linking. Cut the export paths to Google Ads and other Google properties so a leaked identifier doesn’t propagate further than the original tag.

Server-side tagging is the control most compliance-minded IT teams land on next. Instead of the browser sending data straight to Google, requests route through a server you control, where you can apply allowlists, strip fields, and scrub payloads before anything leaves your infrastructure. It’s a genuinely strong mitigation layer, and it centralizes logic that would otherwise be scattered across dozens of client-side tags. But treat it as a technical safeguard, not a legal one. Server-side tagging doesn’t create a BAA, and it doesn’t change Google’s stated position on Analytics eligibility.

Consent gating rounds out the checklist. Tie tag firing to a consent management platform so analytics only loads after a visitor has actively opted in, and calibrate that gate to the strictest state law your patient base touches, whether that’s Washington’s My Health My Data Act or California’s CPRA.

Pro Tip: Test your server-side proxy with a fake PHI string on a staging page before you trust it in production. If “patient-jane-doe-diabetes” shows up anywhere in your GA4 debug view after passing through the proxy, the scrubbing logic has a gap.

What Are the HIPAA-Safe Alternatives to Google Analytics?

For any page carrying real PHI risk where you still need session-level analytics, the answer usually isn’t “configure GA4 harder.” It’s a different architecture.

Healthcare facility server racks glowing blue

Self-hosted Matomo puts the database on infrastructure you control, which removes the third-party disclosure problem at its root since there’s no external vendor receiving the data at all. The tradeoff is that your team now owns hosting, patching, and uptime.

BAA-signing enterprise platforms solve the same problem without the hosting burden. Piwik PRO offers a HIPAA-focused deployment path with a signed BAA. PostHog’s enterprise tier and Adobe’s Customer Journey Analytics can both fit healthcare use cases when contracted correctly. Before signing anything, confirm three things in writing: whether the vendor will sign a BAA specifically covering the analytics product (not just their broader cloud platform), what their data retention and deletion terms look like, and whether sub-processors in their pipeline are also covered.

Warehouse-first architecture is the option larger health systems increasingly land on. Send raw event data into BigQuery under a Google Cloud BAA, since BigQuery is one of the limited Google Cloud products eligible for HIPAA coverage even though standard GA4 is not. Attribution and reporting get built on top of the warehouse instead of a third-party session tool, which avoids exporting session-level PHI to an external vendor entirely.

Fastest to implement: consent-gated GA4 with server-side scrubbing on marketing pages only.
Most control, most engineering cost: self-hosted Matomo or a full BigQuery warehouse build.
Middle ground: a BAA-signing enterprise platform, faster than self-hosting, costlier than a Google-only stack.

How Should You Audit and Fix Your Analytics Setup?

Treat this as a project with a start date, not an ongoing worry. Here’s the sequence that actually gets teams from exposed to documented.

Run the 15-minute audit. Open every page template in your browser’s network tab, filter for requests to google-analytics.com or analytics.google.com, and note which page types fire GA4 at all.
Pull GA4 off PHI surfaces today. Patient portals and authenticated flows come off the tag manager container immediately, before any other remediation work starts.
Scrub URLs and disable risky features this week. Google Signals, User-ID, and form-field tracking get switched off across the entire property, not just flagged pages.
Scope the server-side proxy or self-hosting build. This is the multi-week engineering project: routing rules, allowlists, and a staging test with fake PHI strings before go-live.
Send every analytics vendor contract to legal for BAA review. Confirm in writing whether the specific product you’re using is covered, not just the vendor’s name.
Document the classification matrix and set a re-audit cadence. Quarterly reviews catch the new landing page or embedded widget that quietly reintroduces a tracking risk.

Action	Owner	Timeframe
Tag inventory and page classification	IT / Marketing	Day 1
Remove GA4 from PHI and authenticated pages	IT	Day 1 to 2
Disable Signals, User-ID, form tracking	Marketing Ops	Week 1
Server-side proxy or self-hosted build	Engineering	Weeks 3 to
Vendor BAA review	Legal / Compliance	Weeks 2 to 4
Documented re-audit cadence	Compliance	Quarterly

How Does an Agency Actually Implement This?

The gap between a compliance checklist and a working website is usually a classification matrix nobody built. Klyrmedia’s process starts there: map every page template against the four risk buckets, run a full tag inventory, then move to a server-side implementation for anything above the low-risk threshold.

For an independent practice or a small clinic group, this typically runs a few weeks from audit to a documented handoff, not months. Medium-sized systems with a patient portal and multiple location pages take longer, mostly because of the vendor BAA review cycle, which depends on how fast legal teams on both sides respond.

The recurring failure points aren’t exotic:

A third-party chat widget firing its own tracking pixel nobody classified.
A “quick contact” form embedded on a blog post that quietly captures PHI-adjacent fields.
Consent banners that let tags fire before a visitor actually clicks accept.

Each one gets caught in the same tag inventory step, which is exactly why that step happens first, not last.

Our Take: Default to Removing GA4, Not Configuring It

Most compliance guidance treats GA4 tweaks as the finish line. They’re not. Our position: remove Analytics from every PHI and authenticated surface by default, and only keep it on unauthenticated marketing pages after you’ve verified, not assumed, that no PHI reaches Google. If your organization runs a patient portal or serious session-level measurement needs, invest in self-hosting or a warehouse-first build rather than layering more configuration onto a tool Google itself won’t cover under a BAA. One rule to apply today: if a page requires login, GA4 doesn’t belong on it.

— Opinly

Get Your Analytics Setup Audited and Fixed

There’s a real cost to guessing at this. Klyrmedia is the alternative to piecing together GA4 configuration changes from scattered blog posts. We run the classification matrix, build the server-side proxy, and hand you signed-off documentation your compliance team can actually use, instead of a pile of settings screenshots and hope.

Klyrmedia

Our engagements follow the same sequence outlined above: audit your current tag setup, plan which pages need what level of control, implement the server-side or self-hosted architecture your risk profile calls for, and document the whole thing for your next audit. We also handle the parts that tend to get skipped, like HIPAA-compliant website workflows that build compliance in from the first line of code rather than bolting it on afterward. If your practice needs marketing measurement that survives a HIPAA audit, start with a HIPAA-compliant website design review and get a straight answer on where you stand before your next patch cycle.

Where to Verify This Yourself

Don’t take any vendor’s word for it, including ours. Go straight to the source documents:

HHS OCR guidance on online tracking technologies, the bulletin every other analysis on this topic references.
Google’s own HIPAA and Analytics support page, stating directly what GA4 is and isn’t cleared to handle.
One For All Medical Billing’s HIPAA audit guide for a practical walkthrough of what auditors actually check.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

June 2026 Ruling: Google Analytics Compliance for U.S. Providers