None of these organizations set out to leak patient data. They installed analytics and advertising tags the same way every other business does, and those tags did exactly what they were built to do: collect identifiers and browsing behavior and ship them to a third party. On a retail site, that's Tuesday. On a medical practice site, it can be an impermissible disclosure of protected health information.

Which brings us to the question every practice owner eventually asks: is Google Analytics HIPAA compliant?

The short answer is no. The longer answer — and the reason this article exists — is that you don't have to give up GA4 to fix the problem. You have to change how the data gets there.

The Verdict: No, GA4 Is Not HIPAA Compliant Out of the Box

Two facts settle the question.

1. Google will not sign a BAA for Google Analytics

HIPAA requires that any vendor handling protected health information (PHI) on your behalf sign a Business Associate Agreement (BAA). Google signs BAAs for certain Google Workspace and Google Cloud services — but Google Analytics is explicitly excluded. Google's own guidance tells customers not to send PHI to GA4 at all, and its measurement terms prohibit sending Google any personally identifiable information.

No BAA means that if PHI reaches Google Analytics, you have an impermissible disclosure. There is no configuration toggle inside GA4 that changes this. IP anonymization, consent mode, data redaction settings — none of them substitute for a BAA, because none of them guarantee PHI never arrives.

2. Client-side GA4 sends identifying data by design

The standard GA4 installation is a JavaScript tag running in your visitor's browser. Every hit it fires includes, at minimum:

• The visitor's IP address (used for geolocation, received by Google's servers even when truncated for reporting)
• The full page URL and title — which on a practice website often reveals the reason for the visit: /services/vasectomy-consultation/, /conditions/depression-treatment/, /book-appointment?service=std-testing
• A persistent client ID stored in a first-party cookie, which links every pageview in the session — and across sessions — to the same device
• Referrer and campaign parameters, which can carry search terms or email-campaign identifiers

Under HIPAA, an identifier (IP address, cookie ID) combined with information suggesting an individual sought or received care (a /schizophrenia-treatment/ pageview, an appointment-confirmation page) can constitute PHI. On a hospital or practice website, that combination happens on nearly every hit.

That's the whole problem in one sentence: client-side GA4 pairs "who" with "why they're here" and hands both to a vendor who won't sign a BAA.

"But Wasn't the OCR Guidance Struck Down?"

Partially, yes — and this is where most articles you'll find on this topic are out of date in the other direction.

In June 2024, a federal court in the Northern District of Texas vacated the portion of OCR's online-tracking guidance that treated an IP address plus a visit to an unauthenticated health-information page as PHI in essentially all cases. The court held OCR had stretched the statutory definition too far.

What that ruling did not do:

• It did not amend HIPAA. Disclosures of actual PHI through tracking tools remain violations.
• It did not touch authenticated pages — patient portals, intake forms, appointment booking flows, confirmation pages. Tracking there is as dangerous as it ever was.
• It did not stop class-action lawsuits, which are filed under state wiretapping and privacy laws, not just HIPAA. URMC and Froedtert both settled after the legal landscape shifted.
• It did not stop state regulators and the FTC, which pursued Cerebral and others under consumer-protection authority.

So the vacatur narrowed OCR's most aggressive theory, but the practical risk — regulators, plaintiffs' attorneys, and your own patients' trust — is intact. We break down exactly what was vacated and what still binds you in The OCR Tracking Guidance Was Vacated: Here's What Still Applies.

Treat the ruling as a reason to be precise, not a reason to relax.

Why Practices Don't Just Delete GA4

If GA4 is this risky, why not remove it and move on? Because the data genuinely matters:

• Ad spend decisions depend on it. If you're spending $3,000–$30,000 a month on Google Ads and Meta, you need to know which campaigns produce booked appointments, not just clicks.
• Google Ads optimizes on conversions. Smart Bidding needs conversion signals. Starve it and your cost per acquisition climbs.
• You can't improve what you can't see. Which service pages convert, where visitors drop out of booking, whether that site redesign helped — all of it lives in analytics.

Ripping out GA4 protects patients but blinds the practice. Blocking all measurement is a compliance strategy the way closing the practice is a malpractice strategy. The right answer keeps the measurement and removes the disclosure.

How to Keep GA4 Anyway: Server-Side Forwarding

The fix is architectural. Instead of letting Google's JavaScript run in the patient's browser and collect whatever it collects, you:

1. Remove the client-side GA4 tag entirely. No gtag.js, no GA4 tag in a browser-side container. Google's code never executes on the visitor's device, so it never sees their IP, cookies, or raw URLs.
2. Capture events first-party. Your own website records pageviews and conversion events and sends them to a server you control.
3. Scrub and translate on the server. Before anything is forwarded, a filtering layer strips identifiers and anything PHI-shaped.
4. Forward clean events to GA4 via the Measurement Protocol. Google's Measurement Protocol is a server-to-server API — GA4 receives exactly the fields you choose to send, and nothing else, because there's no tag on the page to collect anything else.

This is the architecture PilotPractice is building its GA4 forwarder on. In brief, a safe forwarder needs three properties working together: an identifier minted server-side (never the visitor's actual cookie or device ID), a scrubbing pass that removes anything person-identifying before the request leaves your infrastructure, and — most importantly — an allowlist rather than a blocklist, so only explicitly approved fields ever ship. The full step-by-step, with what a practice keeps and gives up under this design, is in How a Private Practice Keeps GA4 Conversion Data Without Violating HIPAA.

The result: your GA4 property keeps working — traffic, engagement, conversion events, the reports your team already knows — but Google receives an anonymized, minimized event stream instead of a live wire into your patients' browsers. And on the ads side, campaigns learn that a conversion happened, never who converted or what they typed into an intake form.

The same principle extends to the rest of the stack. If you run tags through Google Tag Manager, the browser-side container has the same problem and the same server-side answer — covered in Is Google Tag Manager HIPAA Compliant? Server-Side GTM Explained. And if your bigger worry is ad retargeting, the playbook for doing that without pixels is here: Healthcare Retargeting Under HIPAA.

What About Google's Own Privacy Features?

A few settings get suggested as fixes. None of them are.

• IP anonymization / "IP masking." Google truncates the IP for reporting, but its servers still receive the full address on the request. Receipt is the disclosure; what Google stores afterward doesn't cure it.
• Consent Mode. Consent mode governs advertising personalization, not HIPAA. A patient clicking "accept cookies" is not a HIPAA authorization — authorizations require specific, written elements a cookie banner doesn't have.
• GA4 data redaction. GA4 can redact email-looking strings from URLs it has already received. Again: the data arrived first. And it does nothing about IP, client ID, or a URL path that itself reveals the reason for the visit.
• "We only use GA4 on non-sensitive pages." Maintaining a page-by-page tag inventory by hand fails the first time someone publishes a new service page. Post-vacatur, unauthenticated general pages are lower risk — but booking flows, confirmations, and portals are exactly where conversion tracking wants to live, and exactly where client-side tags are most dangerous.

The Ungated Checklist: GA4 HIPAA Self-Audit

Run this today. No email required.

1. Open your website, open browser DevTools → Network, filter for google-analytics.com and analytics.google.com. If requests fire from the browser, you have client-side GA4 sending visitor IPs to Google.
2. Load a sensitive page (a condition or treatment page, then your booking flow). Inspect the collect requests — look at the dl (page URL) parameter. Does the URL reveal why the person is there?
3. Check for a client ID. Look for the cid parameter and the _ga cookie. That's a persistent device identifier being paired with health-related browsing.
4. Ask whether you have a BAA with Google covering Analytics. You don't — Google doesn't offer one. Note that gap in writing.
5. Inventory where the GA4 tag fires. Every page? Including appointment confirmation and intake pages? Those are your highest-exposure hits.
6. Check your booking and intake forms. Are form-field values or thank-you-page URLs (with query strings) reaching any analytics or ad tag?
7. Review your privacy policy. Does it accurately describe what your tags actually send? A mismatch is FTC bait independent of HIPAA.
8. Decide the architecture. Either remove GA4 entirely, or move to server-side Measurement Protocol forwarding with synthetic IDs, a PII scrub, and parameter whitelisting.

If step 1 or 2 fails, you're in the same position URMC and Froedtert were in before their settlements. The good news: it's fixable in days, not quarters.

Freshpaint vs. Included-With-Your-Agency

If you've researched this problem, you've met Freshpaint — a healthcare privacy platform that solves it the same architectural way: intercept events, scrub them, forward clean data to analytics and ad platforms. The approach is sound. The difference is the business model.

Freshpaint is a software subscription — a five-figure annual line item, and you (or another vendor) still have to implement it, maintain the event schema, and run the marketing it feeds.

PilotPractice takes the other model: the compliant infrastructure is plumbing under the agency service, not a product you license. Our first-party tracker and server-side conversion uploads run on every client site today, and the GA4 Measurement Protocol forwarder described above is in development as the next layer of that same stack — built once, then rolled out across the platform rather than sold as a line item. Full comparison here: Freshpaint Alternatives for Medical Practices.

Either way, the takeaway is the same: the compliant answer to "is Google Analytics HIPAA compliant?" is not a setting. It's a server between your patients and Google.

Keep the Data. Lose the Disclosure.

So: Google Analytics is not HIPAA compliant — no BAA, and a client-side tag that pairs identifiers with health-revealing browsing on every hit. But the practices that handle this well don't go dark. They keep GA4's reporting, keep feeding conversions to their ad campaigns, and keep improving their websites — by moving measurement server-side, where identifiers are replaced, PII is scrubbed, and only approved parameters ever leave, so Google gets counts and conversions while patient information never leaves the practice's control.

If you want the deeper how-to, read How a Private Practice Keeps GA4 Conversion Data Without Violating HIPAA, or start at the top with the full HIPAA-Compliant Marketing Guide for 2026.

Find out what your site is leaking right now. Run our free PHI leak scanner — it checks your website for trackers sending visitor data to Google, Meta, and others, in about a minute, no email gate.

Then let us fix it — and run the marketing on top of it. PilotPractice builds HIPAA-compliant patient acquisition for medical practices: compliant first-party tracking today, a server-side GA4 forwarder in development, plus the ads, website, and booking system the analytics are supposed to measure. Book a demo and we'll walk through your current exposure and the compliant architecture.

Compliance documentation, SOC 2 details, and our BAA are at trust.pilotpractice.com.