Is Google Optimize HIPAA Compliant?

For seven years, tracking code ran silently on Kaiser Permanente's websites, patient portals, and mobile apps. That code transmitted health information to Google, Microsoft, Meta, and X without member consent. When the dust settled, 13.4 million members had been affected and Kaiser agreed to a $47.5 million class action settlement. The tools responsible were not exotic hacking instruments. They were standard marketing and optimization scripts that someone had installed years earlier and never revisited.

That pattern should concern any healthcare organization that ever used Google Optimize. Google officially sunset Optimize in September 2023, but "sunset" does not mean "removed." The snippet may still be sitting in your site's tag. And even if it is no longer running experiments, its JavaScript loaded alongside Google Analytics, creating data flows that most compliance teams never fully mapped.

When a Sunset Tool Still Casts a Shadow

Google Optimize was Google's free A/B testing platform. It allowed marketers to create experiments (split tests, redirect tests, multivariate tests) directly on their websites using a client-side JavaScript snippet. That snippet worked by modifying page content in the visitor's browser before the page rendered, and it was deeply integrated with Google Analytics to track experiment results.

Here is what matters from a compliance standpoint: Optimize did not operate independently. Installing Optimize meant giving Google's servers access to your visitor data through the browser. The snippet communicated with Google's infrastructure, transmitted page URLs, experiment variant assignments, and behavioral data, and relied on Google Analytics for measurement. Every data point that flowed through Google Analytics also informed Optimize's reporting.

Google never offered a Business Associate Agreement for Optimize. There was no healthcare tier, no HIPAA configuration, and no mechanism to prevent protected health information from being captured in experiment data.

When Google shut down Optimize, it stopped serving experiment variations. But many organizations never removed the JavaScript snippet from their sites. A snippet that no longer runs experiments can still load resources, set cookies, or interact with other Google tags on the page. For healthcare organizations, an abandoned script from a vendor with no BAA is not just technical debt. It is an active compliance liability.

The Real Cost of "Install and Forget" Marketing Scripts

The Kaiser case is instructive precisely because it mirrors what happened at dozens of healthcare organizations. Tracking code was added to support a legitimate business goal (understanding patient needs, optimizing conversions, measuring marketing spend), and then it ran for years without anyone reviewing what data it was actually collecting or where that data was going.

Advocate Aurora Health followed the same pattern. The health system installed Meta Pixel and Google Analytics on its website, app, and patient portal to "better understand patient needs." That decision exposed data for approximately 3 million patients and resulted in a $12.25 million settlement. The tools were standard. The intentions were good. The outcome was a breach.

Sutter Health deployed Google Analytics, Meta Pixel, and other tracking tools on its MyHealthOnline patient portal, sharing private patient data with Google and Facebook without authorization. That case settled for $21.5 million.

In every one of these cases, the root cause was the same architectural decision: client-side JavaScript running in the patient's browser, sending data to third-party servers with no BAA in place. Google Optimize used exactly this architecture.

Why Past Usage Still Matters Today

Even if you confirmed that the Optimize snippet has been fully removed from your codebase, your compliance exposure does not reset to zero. There are three dimensions to consider.

Historical data exposure. If Optimize ran on pages where patients entered health information, searched for conditions, or scheduled appointments, that data was transmitted to Google's servers during the period Optimize was active. Google received experiment variant data alongside Google Analytics session data, which could include page paths containing condition names, search queries, appointment types, and more. That historical exposure is the basis for regulatory scrutiny and class action claims, as the Kaiser and Sutter Health cases demonstrate.

Lingering scripts and tag interactions. Large healthcare websites accumulate scripts over time. Marketing teams add tags, agencies install tracking code, CMS plugins load third-party resources. When Optimize was sunset, Google encouraged migration to other tools, but not every organization completed a thorough audit. The Optimize container script, references to the Optimize API in custom code, or Google Analytics configurations that were built to support Optimize experiments may still be present. Each represents a potential data flow that was never governed under a BAA.

Incomplete removal across environments. Healthcare organizations often maintain multiple web properties: the main website, patient portals, landing pages, microsites for specific service lines, and mobile web experiences. Removing Optimize from the primary site does not guarantee it was removed from every property. Without a systematic scan across all web assets, you cannot confirm complete removal.

What Compliant Experimentation Actually Requires

The question "Is Google Optimize HIPAA compliant?" has a straightforward factual answer: Google never signed BAAs for Optimize, the tool operated entirely client-side, and it is now discontinued. But the more useful question is what any A/B testing or experimentation tool needs to meet healthcare compliance standards.

A BAA that covers the full data pipeline. A Business Associate Agreement is the legal foundation. It means the vendor accepts liability as a Business Associate under HIPAA and covers collection, processing, storage, and transmission of data. Not all BAAs are equal. Some exclude marketing data or analytics data. A legitimate healthcare BAA covers everything the tool touches.

Server-side experiment delivery. Client-side A/B testing tools modify page content in the browser and send behavioral data back to the vendor's servers through the browser. Server-side experimentation evaluates variants on your server before the page reaches the visitor. The browser never communicates with the experimentation vendor. This is not a minor technical preference. It is the architectural difference between data flowing through an uncontrolled environment (the browser) and data staying within your governed infrastructure.

SOC 2 Type II with all five trust criteria. SOC 2 Type II certification across Security, Availability, Processing Integrity, Confidentiality, and Privacy means independent auditors verified sustained compliance, not a point-in-time snapshot. Most vendors certify only Security (one of five criteria). For healthcare, that is table stakes.

Consent-gated data flows. Experimentation data should only flow to destinations after consent is verified server-side. A JavaScript-based consent check can be bypassed, delayed, or fail to load. Server-side consent gating means data physically does not move until consent is confirmed.

Continuous monitoring of your tracking surface. This is the lesson every enforcement case teaches. Installing a compliant tool does not make your website compliant. Marketing teams add scripts. Plugins update. Third-party tags load other tags. Your site's tracking surface changes constantly. A web scanner that crawls your site on an ongoing basis can detect every cookie, script, localStorage entry, and tracking pixel across every page, flagging which scripts lack a BAA, which cookies are set by third parties, and which tracking pixels are sending data to ad platforms. This is the difference between "we set it up right once" and "we know it's still right today."

A Five-Point Evaluation for Your Current Stack

If you previously used Google Optimize and are now evaluating alternatives, or if you want to assess whether your current experimentation setup meets healthcare standards, work through these five questions.

1. Does the vendor sign a BAA that explicitly covers experimentation and analytics data? Not a BAA that carves out "marketing use" or "non-clinical data." The BAA should cover every data type the tool processes.

2. Does the tool operate server-side? If experiment variations are delivered through client-side JavaScript that communicates with the vendor's servers via the browser, you have the same architectural risk that Google Optimize carried.

3. Has the vendor achieved SOC 2 Type II certification across all five trust criteria? Ask to see the report. Verify the scope covers the product you are using, not just a different product in the vendor's portfolio.

4. Can you verify consent before data flows? Server-side consent verification means data does not leave your infrastructure until you have confirmed the visitor's consent status. Client-side consent banners are a starting point, but they are not sufficient on their own.

5. Do you have continuous visibility into what is actually running on your site? Not what you think is running. Not what was running when you last checked six months ago. What is running right now, across every page, every subdomain, every patient-facing property. This requires ongoing scanning, not a one-time audit.

Moving Forward After Google Optimize

The sunset of Google Optimize is an opportunity, not just a disruption. It forces healthcare organizations to make an active decision about experimentation tooling rather than defaulting to whatever was installed years ago.

That active decision should start with an audit. Scan every web property for remnants of the Optimize snippet, references to the Optimize API, and any Google Analytics configurations that were purpose-built for Optimize experiments. If you find lingering code, remove it and document the removal. Then assess what data may have been exposed during the period Optimize was active, because that historical exposure informs your ongoing compliance posture.

When selecting a replacement, prioritize architecture over features. A server-side experimentation platform with a healthcare BAA, SOC 2 Type II certification, and consent-gated data flows will protect you from the pattern that generated $193 million in enforcement actions and settlements since 2023. A feature-rich client-side tool without those foundations will leave you exposed to the same risks that caught Kaiser, Advocate Aurora, and Sutter Health.

Healthcare compliance is also moving toward stronger consent requirements. State privacy laws are expanding, patient expectations around data control are rising, and regulators have signaled that consent management will be a central enforcement focus going forward. Building your experimentation stack on consent-gated, server-side infrastructure now means you will not need to rebuild it when those requirements formalize.

Ours Privacy provides server-side experimentation, web scanning, and consent-gated data architecture purpose-built for healthcare. If you are evaluating your options after Google Optimize, start a conversation with our team.

Frequently Asked Questions

Is Google Optimize still collecting data on my website?

Google stopped serving experiment variations when Optimize was sunset in September 2023. However, if the Optimize JavaScript snippet is still present in your site's code, it may still load resources or interact with other Google tags. The only way to confirm is to audit your site's source code and use a scanning tool to check for active third-party scripts across all pages.

Did Google ever offer a BAA for Google Optimize?

No. Google never offered a Business Associate Agreement for Optimize. The tool was a free product with no healthcare tier, no HIPAA-specific configuration options, and no mechanism for covered entities to establish a Business Associate relationship with Google for experimentation data.

What should I do if my healthcare organization used Google Optimize before it was sunset?

Start with a thorough audit. Remove any remaining Optimize code from all web properties (not just the main site). Review what pages Optimize was active on and whether those pages involved health information. Document your findings and consult with your compliance team about whether historical data exposure requires breach analysis or notification. Then evaluate a compliant replacement using the five-point framework above.

Can I use Google's recommended Optimize replacement (A/B Testing in GA4) for healthcare?

Google directed Optimize users toward A/B testing features within GA4. The same compliance considerations apply: does Google sign a BAA covering that specific feature, does it operate server-side, and does it meet the SOC 2 and consent requirements healthcare demands? Evaluate GA4's experimentation capabilities against the same compliance checklist you would apply to any tool.

How do I find out if the Optimize snippet is still on my site?

You can check manually by viewing your site's page source and searching for "optimize.google.com" or the Optimize container ID (which starts with "GTM-" or "OPT-"). For a comprehensive check across all pages, subdomains, and patient-facing properties, use an automated web scanner that identifies every third-party script, cookie, and tracking pixel active on your site.