If you run a healthcare website and someone has told you “you need to remove Google Analytics,” you may have wondered whether that advice was accurate, alarmist, or somewhere in between.
The honest answer is: the concern is real, the risk is context-dependent, and the decision requires understanding what Google Analytics actually does – not just what it’s called.
This guide is written for physicians, practice owners, clinic administrators, compliance officers, and healthcare marketers who need a clear, non-technical explanation of what’s happening, what the government has said, what the actual risks are, and what your realistic options look like. It does not exist to frighten you into switching platforms. It exists to help you make an informed decision.
Read the Quick Answer if you need an immediate summary. Read the full article if you’re making a compliance decision.
Is Google Analytics HIPAA compliant?
In standard configurations, no – Google Analytics is not HIPAA compliant for healthcare websites that collect or process protected health information. Google does not offer a Business Associate Agreement (BAA) for Google Analytics, which is a prerequisite for any vendor that handles PHI on behalf of a covered entity. The HHS Office for Civil Rights December 2022 guidance confirmed that analytics tools can create HIPAA violations when they transmit identifiable patient information to third parties. However, the risk level of any specific implementation depends heavily on what data your website collects, how it’s configured, and what pages analytics are active on. Low-risk configurations exist. Zero-risk requires either a HIPAA-safe alternative or a carefully documented, legally reviewed analytics architecture.
The Short Version for Busy Providers
Here is what you need to know in four minutes:
What Google Analytics does: It tracks visitor behavior on your website – which pages they visit, where they came from, how long they stayed, what they clicked. To do this, it sends data about each visitor to Google’s servers. That data includes IP addresses, browser fingerprints, and behavioral patterns.
Why this creates HIPAA risk: When a patient visits your “HIV Treatment” service page, then your appointment scheduling page, then submits a contact form – Google Analytics records that journey. If any of the data transmitted to Google’s servers can identify that individual and connect them to health-related behavior, it may constitute PHI. HIPAA prohibits disclosing PHI to third parties without either patient authorization or a Business Associate Agreement covering that third party.
What the government said: In December 2022, the HHS Office for Civil Rights issued a bulletin explicitly warning healthcare organizations that analytics tools and advertising pixels deployed on their websites may violate HIPAA. This was not a change in the law – it was clarification of how existing law applies to modern website tracking technology.
What Google said: Google does not offer a Business Associate Agreement for Google Analytics. When you use Google Analytics on your healthcare website, Google is receiving visitor data without a HIPAA-mandated agreement in place.
What your actual risk depends on: Whether your website collects patient health information in any form (if not, risk is lower but not zero), what pages analytics are active on, how your analytics are configured, what data-sharing settings are enabled, and whether your legal counsel has reviewed your specific implementation.
What you can do: Option one – remove Google Analytics and use a HIPAA-safe alternative. Option two – implement a carefully configured, legally reviewed privacy-first setup that minimizes PHI exposure. Option three – do nothing and accept the compliance risk. Most healthcare attorneys recommend option one or two.
Why Google Analytics Creates HIPAA Concerns
To understand the concern, you first need to understand what web analytics actually do at a technical level – and then understand what HIPAA actually regulates.
How Web Analytics Work
When a visitor arrives on your website, a small piece of JavaScript code (the analytics tracking script) executes in their browser. This script sends a data packet to the analytics provider’s servers – in Google Analytics’ case, to Google’s infrastructure. That data packet typically includes:
The visitor’s IP address (a numerical identifier that can often be used to determine the visitor’s approximate geographic location, internet service provider, and – with additional data – their identity), a unique client identifier stored in a browser cookie (which allows Google to recognize the same browser on a return visit), the URL of the page being visited (which in healthcare contexts may reveal which condition, treatment, or service the patient was seeking), the referring URL (which may include the search query the patient used to arrive – potentially including condition names, medication names, or symptom descriptions), browser type, operating system, screen resolution, session timing data, and any custom events configured to fire on specific interactions (form views, button clicks, appointment scheduling page visits).
This data is transmitted to Google’s servers every time a page is loaded. It continues across the visitor’s entire session. And it is transmitted without the patient’s awareness that their browsing behavior on a healthcare website is being shared with a technology company.
What HIPAA Actually Regulates in This Context
HIPAA’s Privacy Rule prohibits covered entities from using or disclosing PHI without patient authorization except in circumstances specifically permitted or required by the rule. The Security Rule requires covered entities to implement safeguards protecting electronic PHI.
The foundational question in the analytics context is: does web analytics data from a healthcare website constitute PHI?
PHI is individually identifiable health information – meaning information that identifies or reasonably could identify an individual and relates to that person’s health condition, healthcare treatment, or healthcare payment.
The HHS Office for Civil Rights answered this question explicitly in December 2022: the combination of an IP address or other identifier with a visit to a health condition page, an appointment scheduling page, or any page containing health-related content can constitute PHI. The agency noted that this applies even where the individual cannot be identified with certainty from the data alone – reasonable identifiability is sufficient.
This creates a direct problem for standard Google Analytics: the tool transmits IP addresses combined with page visit data from healthcare websites to Google’s servers. Google is not a covered entity. Google has not signed a BAA with your practice. The transmission of reasonably identifiable health-related data to an entity without a BAA is a potential HIPAA violation under the Privacy Rule.
The BAA Gap: Why This Isn’t Just a Configuration Problem
Some healthcare organizations have attempted to solve the Google Analytics HIPAA problem through configuration – enabling IP anonymization, disabling certain data sharing settings, limiting event tracking. These measures reduce risk. They do not eliminate it.
The fundamental problem is not configuration – it is the absence of a BAA. Under HIPAA, if a third-party vendor receives PHI on behalf of your covered entity, that vendor must sign a Business Associate Agreement. This is a legal contract that obligates the vendor to protect the PHI, use it only for permitted purposes, report breaches, and allow compliance audits.
Google has explicitly stated that it does not offer BAAs for Google Analytics. This position has not changed with GA4. When asked directly, Google’s documentation states that Google Analytics is not intended to be used in connection with sensitive data categories, including medical or health data.
The absence of a BAA is not a technical problem you can configure your way out of. It is a structural legal gap.
What Regulators Have Focused On
Understanding what HHS OCR has actually said – and what enforcement actions have occurred – is important for calibrating your risk assessment accurately.
The December 2022 HHS OCR Bulletin
The most significant regulatory statement on this topic came on December 1, 2022, when the HHS Office for Civil Rights published its bulletin titled “Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates.”
The bulletin made several explicit points that directly address the Google Analytics question:
First: Tracking technologies on healthcare websites can “track a user’s online activities and collect individually identifiable information” that constitutes PHI when combined with health-related context.
Second: The fact that a tracking technology is “standard” or widely used in marketing does not make it HIPAA-compliant for use on healthcare websites. The OCR specifically declined to grant a safe harbor for common industry practice.
Third: Covered entities using tracking technologies must ensure that those technologies are covered by a BAA with the tracking vendor, or must otherwise ensure that PHI is not being disclosed to the vendor. Since Google does not offer a BAA for Analytics, this means healthcare organizations cannot disclose PHI through Google Analytics.
Fourth: The bulletin identified specific contexts of heightened concern: pages where patients seek information about specific conditions or treatments, pages where patients access patient portals, and pages where patients submit any form of personal health information.
Fifth: The bulletin confirmed that IP addresses combined with health-related page visits can constitute PHI – directly applying to standard Google Analytics implementations.
Enforcement Actions and Litigation
Following the December 2022 bulletin, several significant developments occurred in healthcare website tracking enforcement:
Class action lawsuits were filed against healthcare organizations including hospitals and health systems alleging that their use of the Meta Pixel and Google Analytics constituted unlawful disclosure of patient health information. Several of these lawsuits resulted in significant settlements.
The HHS OCR began incorporating website tracking technology into its audit process, adding specific inquiry into analytics and pixel usage to compliance investigations.
State attorneys general – particularly in California, New York, and Illinois – launched independent investigations into healthcare website tracking practices under state privacy laws, some of which have broader applicability than HIPAA.
The FTC took enforcement action against GoodRx Holdings in 2023, resulting in a $1.5 million penalty specifically related to sharing consumer health data with advertising platforms – an enforcement action that, while not a HIPAA action, confirmed regulatory intent to address this category of data practice.
These developments collectively confirm that regulatory scrutiny of healthcare website analytics is not theoretical – it is active and ongoing.
What OCR Has Not Said
Calibration requires understanding what regulators have not said, not just what they have:
OCR has not issued an enforcement action specifically and exclusively targeting Google Analytics on a healthcare website as of the time of this writing. Most HIPAA enforcement actions in this space have involved more egregious facts – patient portals with tracking pixels, scheduling platforms sharing appointment data with advertisers, and similar high-volume PHI disclosures.
OCR has acknowledged that implementation context matters – a hospital system deploying the Meta Pixel on a cancer treatment appointment page has meaningfully different risk exposure than a small primary care practice with a general analytics implementation that captures no form data.
OCR has not issued a blanket prohibition on all web analytics in healthcare contexts – the guidance requires that analytics use be compliant, not that it be nonexistent.
The takeaway is not “any analytics = immediate enforcement” but rather “unconfigured standard analytics on healthcare websites creates real compliance risk that should be addressed.”
Common Healthcare Website Tracking Risks: Tool by Tool
Google Analytics 4 (GA4)
GA4 is the current version of Google’s analytics platform, replacing Universal Analytics in 2023. From a HIPAA perspective, GA4 presents the same fundamental problem as its predecessor: Google does not offer a BAA, and the tool transmits visitor data – including IP addresses and page-level behavioral data – to Google’s servers.
GA4 also introduced new capabilities that complicate the healthcare privacy picture: enhanced measurement features that automatically capture form interaction events, scroll depth, outbound clicks, and video engagement without requiring explicit configuration. This means GA4 may automatically collect data about a patient’s interaction with an appointment request form – capturing form field focus events, form submission attempts, and form completion – even without intentional event tracking setup.
Risk factors specific to GA4: Automatic enhanced measurement event collection, advertising data sharing enabled by default in some configurations (requires explicit opt-out), Google Signals enabled by default in some configurations (connecting analytics data to Google account profiles), data collection connected to Google’s advertising infrastructure, and lack of BAA regardless of configuration choices.
Partial risk mitigation possible (not full compliance): Disabling data sharing with Google advertising products, disabling Google Signals, implementing server-side tagging to reduce client-side data exposure, configuring referral exclusions for sensitive pages, and using consent mode to limit tracking for non-consenting users. None of these measures resolves the BAA gap.
Google Tag Manager (GTM)
Google Tag Manager is a tag management system that serves as the deployment mechanism for analytics and advertising scripts – it is the container through which Google Analytics, Meta Pixel, and other tracking tools are typically deployed on healthcare websites.
GTM itself does not collect visitor data – it simply manages the deployment of scripts that do. However, GTM creates HIPAA risk in two ways: it is the system through which non-compliant tracking is deployed (making GTM configuration central to risk management), and GTM’s server-side implementation (sGTM) can be used as part of a privacy-preserving architecture that reduces data sent to third parties.
GTM-specific risks: Unauthorized scripts added to the GTM container by agency personnel or marketers without compliance review, GTM firing non-compliant tags across all pages including sensitive health condition and appointment pages, and GTM event triggers configured to capture form field values (including health information submitted in contact forms).
GTM as part of a risk reduction strategy: Server-side GTM (deployed on your own infrastructure) can intercept data before sending it to third parties, enabling PHI stripping from data streams before transmission to analytics platforms. This is a legitimate technical approach but requires implementation expertise and does not resolve the fundamental BAA gap with Google Analytics.
Meta Pixel (Facebook Pixel)
The Meta Pixel is the advertising tracking tool deployed by healthcare organizations for Facebook and Instagram advertising measurement. It has received more regulatory attention than Google Analytics specifically in the healthcare context – and for more immediate practical reasons.
When the Meta Pixel fires on a healthcare website page, it transmits data to Meta’s advertising infrastructure including: IP address, browser fingerprint, a Facebook Click ID (fbc) that connects the website visit to a specific Facebook user profile when the visitor clicked a Facebook ad, custom event data configured by the site administrator, and – through Meta’s Advanced Matching feature – any contact information (email, phone, name, date of birth) submitted through forms that the pixel is configured to collect.
This means the Meta Pixel can literally transmit a patient’s name, email address, and phone number to Facebook’s advertising systems when that patient submits an appointment request form – if Advanced Matching is enabled and the form is not excluded from pixel tracking.
The class action lawsuits filed against healthcare organizations following the 2022 HHS guidance primarily alleged Meta Pixel misuse, not Google Analytics misuse – in part because the PHI disclosure through Meta Pixel is more direct and more clearly documented.
Current regulatory consensus: Most healthcare legal counsel and compliance professionals advise removing the Meta Pixel entirely from healthcare websites. The risk-benefit ratio of advertising measurement capability versus HIPAA exposure has shifted decisively toward removal.
Microsoft Clarity
Microsoft Clarity is a free behavioral analytics tool that provides heatmaps, session recordings, and click maps. It is increasingly used by healthcare organizations as a conversion optimization tool because it visualizes exactly how visitors interact with a website – including how they fill out forms.
This creates a specific and significant HIPAA risk: session recordings capture what patients type into form fields. If a patient types their name, their symptoms, their insurance information, or their appointment reason into a contact form – and Microsoft Clarity is recording that session – that data is captured by Microsoft Clarity and transmitted to Microsoft’s servers.
Microsoft does not offer a BAA for Clarity. Session recordings of form completion on a healthcare website represent one of the most direct forms of PHI capture possible through a website analytics tool.
Risk assessment: Very High for any healthcare website where Clarity session recordings are active on pages with contact forms, appointment forms, or health history intake. The session recording capability specifically – not the heatmap functionality – is the primary risk vector.
If behavioral analytics are needed: Microsoft Clarity should not be used on healthcare websites without form field exclusion configuration and legal review. Tools with healthcare-specific configurations and BAA availability should be evaluated instead.
Heatmap Tools (Hotjar, Crazy Egg, and Similar)
Heatmaps and click tracking tools work similarly to Microsoft Clarity – they record visitor behavior to produce visual representations of engagement patterns. Session recording functionality in these tools carries the same PHI risk as Clarity: the potential capture of patient-submitted form data.
Hotjar has made efforts toward healthcare compliance but should be evaluated for BAA availability and specific PHI exclusion capabilities before deployment on healthcare websites. Crazy Egg similarly requires evaluation. The same form exclusion and BAA considerations apply to all heatmap tools.
General guidance: Heatmap tools on healthcare websites should have form field data explicitly excluded from recording, should operate only under a signed BAA, and should not be active on pages where patients submit health information.
Call Tracking Systems
Call tracking software (CallRail, CallTrackingMetrics, Invoca, and similar) assigns unique phone numbers to different marketing channels, enabling practices to attribute inbound calls to specific advertising sources. This is a legitimate and valuable marketing measurement tool – and it creates specific HIPAA considerations.
The HIPAA risk in call tracking is both on the website (the dynamic number insertion script creates a form of visitor tracking) and in the recorded call content (if calls are recorded, those recordings constitute PHI when the caller is a patient discussing their health concern).
Website-side tracking risk: Dynamic number insertion tracks visitors similarly to analytics tools, using cookies to identify which marketing channel a visitor came from before they called. If this tracking data includes health-related page visit context, the same PHI concerns apply as with analytics.
Call recording risk: Call recordings from healthcare practice phone lines are PHI. Any call tracking system that stores call recordings must sign a BAA and operate HIPAA-eligible storage infrastructure. This is true regardless of how the phone number is displayed on the website.
Compliant call tracking approach: Use a call tracking vendor that offers a HIPAA-eligible plan with a signed BAA (CallRail offers HIPAA-compliant plans; verify current BAA availability for other vendors), configure call recordings with appropriate patient consent notifications, and evaluate whether visitor-level call attribution tracking creates acceptable PHI exposure.
Cookies and Browser Storage
Cookies are small data files stored in a visitor’s browser that enable tracking across sessions and sometimes across websites. Analytics cookies (like the _ga cookie set by Google Analytics) store a unique identifier that allows the analytics platform to recognize the same browser on return visits.
In healthcare website contexts, cookies create HIPAA considerations in two ways: they enable persistent tracking of a visitor’s behavior over time (allowing an analytics platform to connect multiple visits, including visits to different condition-specific pages), and they create compliance obligations under state privacy laws that may require consent before setting non-essential cookies.
The intersection of cookie consent requirements (under CCPA, CPRA, GDPR, and state equivalents) with HIPAA creates a practical compliance framework: if a healthcare website must obtain consent before setting analytics cookies, and a visitor declines, analytics must not fire on that visitor’s session. This is the function of a Consent Management Platform (CMP).
Can Google Analytics Ever Be Used Safely on a Healthcare Website?
This is the question that generates the most debate among healthcare compliance professionals, and the honest answer has several components.
The unresolvable problem: Google does not offer a BAA for Google Analytics. Until that changes, no configuration of Google Analytics on a healthcare website that handles PHI fully satisfies HIPAA’s Business Associate requirements. Any legal analysis starts from this constraint.
Risk reduction through configuration is real: A healthcare website where Google Analytics is configured with IP anonymization verified, advertising data sharing disabled, Google Signals disabled, form interaction event tracking excluded, referral data from sensitive pages excluded, and consent mode implemented – is meaningfully lower risk than a standard GA4 implementation. Risk reduction is not the same as compliance.
Context matters significantly: A solo primary care practice whose website contains only a phone number and address – no contact forms, no scheduling widget, no patient portal – with Google Analytics tracking general page views on general informational pages, operates in a materially different risk environment than a hospital system deploying standard GA4 across an appointment scheduling platform.
The legal answer from most counsel: Healthcare attorneys who have reviewed this question following the December 2022 HHS guidance consistently advise that the absence of a BAA for Google Analytics creates unacceptable legal risk for covered entities that use the tool on pages where PHI is collected or where health-related visitor behavior can be tracked. The gap between “meaningfully lower risk” and “compliant” is significant in a regulatory context.
The practical answer: If you require analytics functionality on your healthcare website, HIPAA-safe alternatives exist that provide actionable data without the PHI risk of Google Analytics. The information loss compared to GA4 is real but manageable – you can understand your traffic, measure your conversions, and optimize your website without exposing patient data to Google’s systems.
Compliant vs. Risky Configurations
Table 1: Compliant vs. Risky Analytics Configurations
| Configuration Element | Risky Configuration | Lower-Risk Configuration | Compliant Configuration |
| Analytics platform | Standard GA4 with default settings | GA4 with privacy configurations | Fathom / Plausible / Matomo self-hosted |
| Advertising data sharing | Enabled (GA4 default in some regions) | Explicitly disabled | Not applicable (HIPAA-safe tool) |
| Google Signals | Enabled | Explicitly disabled | Not applicable |
| IP address handling | Default (collected) | Anonymization configured | Not collected at all |
| Form interaction tracking | Enhanced measurement capturing form events | Form events excluded from tracking | No form-level tracking |
| Referral URL data | Full referral strings including health query terms | Referral exclusions on sensitive pages | No referral data to third parties |
| Session recording | Microsoft Clarity or Hotjar on form pages | Explicitly excluded from form pages | Not deployed without BAA |
| Advertising pixels | Meta Pixel / TikTok Pixel on appointment pages | Pixels removed from health-sensitive pages | Pixels removed entirely from healthcare site |
| Call tracking | Standard CallRail without BAA | CallRail HIPAA plan without recordings | CallRail HIPAA plan with BAA + consent |
| Cookie consent | No consent management; all cookies fire on load | CMP present but does not block pre-consent | CMP blocking all non-essential tracking pending consent |
| BAA status | No BAA with any analytics vendor | No BAA (partial risk reduction only) | BAA in place with all PHI-adjacent vendors |
| Data sharing | Analytics connected to advertising platform | Advertising connection disabled | Analytics data not shared with any advertising system |
Analytics Tool Risk Comparison
Table 2: Analytics Tool Risk Comparison for Healthcare Websites
| Tool | BAA Available | PHI Risk Level | Form Capture Risk | Session Recording | Recommended Action |
| Google Analytics 4 | No | High | High (enhanced measurement) | No | Remove or implement HIPAA-safe alternative |
| Google Tag Manager | No | Medium (as deployment tool) | High (if misconfigured) | No | Review all tags; use server-side with caution |
| Meta Pixel | No | Very High | Very High (Advanced Matching) | No | Remove from all healthcare pages |
| Microsoft Clarity | No | Very High | Very High (session recording) | Yes – primary risk | Remove; do not use on healthcare forms |
| Hotjar | Verify current status | High | High (session recording) | Yes – primary risk | Verify BAA; configure form exclusions |
| Crazy Egg | Verify current status | Medium-High | Medium (heatmaps) | Limited | Verify BAA; configure exclusions |
| CallRail | Yes (HIPAA plan) | Medium | N/A | No | Use HIPAA plan; sign BAA; review recording consent |
| LinkedIn Insight Tag | No | Medium | Medium | No | Remove from health-sensitive pages |
| TikTok Pixel | No | Very High | High | No | Remove from all healthcare pages |
| Google Ads Conversion | No | High | High (URL parameters) | No | Configure carefully; no form field capture |
| Fathom Analytics | N/A (no PHI collected) | Very Low | Very Low | No | Recommended HIPAA-safe alternative |
| Plausible Analytics | N/A (no PHI collected) | Very Low | Very Low | No | Recommended HIPAA-safe alternative |
| Matomo (self-hosted) | N/A (self-hosted) | Low (with configuration) | Low (with configuration) | Optional | Recommended with HIPAA hosting |
| Heap Analytics | Verify current status | High | High (auto-capture) | Yes | Not recommended without legal review |
Risk levels reflect typical implementation risk, not theoretical maximum risk. Always verify current BAA availability directly with vendors, as policies change.
HIPAA-Friendly Analytics Alternatives
Fathom Analytics
Fathom Analytics is the most widely recommended Google Analytics alternative for healthcare websites. It is a privacy-first analytics platform built around data minimization – it provides traffic and conversion data without collecting personal information, setting tracking cookies, or creating individual visitor profiles.
How Fathom works: Rather than tracking individuals, Fathom aggregates behavioral data before storing it. It does not collect IP addresses in ways that could identify individuals, does not use cookies that persist across sessions, does not create cross-site visitor profiles, and does not share data with advertising platforms.
What you get: Traffic volume, traffic sources (referral domains, not individual search queries), page-level engagement data, goal completion rates, campaign performance data, and geographic data at country/region level. You do not get individual session data, user journeys, or form field-level event data.
HIPAA suitability: Because Fathom does not collect PHI by design, the fundamental HIPAA risk vector of analytics tools is eliminated. There is no BAA requirement because there is no PHI to protect. Most healthcare compliance professionals consider Fathom an appropriate analytics solution for covered entities.
Cost: Approximately $14–$54/month depending on traffic volume, compared to free for GA4. This cost differential is the primary barrier to adoption.
Plausible Analytics
Plausible Analytics is an open-source, privacy-first analytics platform with a philosophy and data model similar to Fathom. It is EU-hosted, fully GDPR compliant, and does not use cookies or collect personal data.
How Plausible works: Plausible uses a daily rolling hash of the visitor’s IP address, user agent, and page URL to estimate unique visitors without storing identifiable information. No cookie is set. No personal data is stored. No cross-site tracking occurs.
What you get: Traffic volume, source attribution, page-level data, goal completions, and geographic aggregates. Similar to Fathom in capability.
HIPAA suitability: Similar to Fathom – privacy-by-design architecture eliminates the PHI exposure risk. Appropriate for healthcare websites.
Cost: Starting at approximately $9/month, making it the most cost-effective GA4 alternative for smaller practices.
Matomo (Self-Hosted)
Matomo is an open-source analytics platform that can be self-hosted on your own HIPAA-eligible infrastructure. In a self-hosted configuration, all visitor data stays on your servers – it is never transmitted to a third party.
How self-hosted Matomo works: You install Matomo on your own HIPAA-eligible hosting environment. Visitor data is collected and stored in your own database. No data is sent to Matomo’s company servers (cloud-hosted Matomo is a separate product with different privacy characteristics).
What you get: A feature set comparable to Google Analytics, including individual session data, user journey tracking, heatmaps, and goal funnels. Because you control the data, you can implement appropriate protections.
HIPAA suitability: Self-hosted Matomo on HIPAA-eligible infrastructure, with appropriate access controls and data handling protocols, can be made HIPAA-compatible. This is more technically complex than Fathom or Plausible but provides significantly more feature depth. Note that self-hosted Matomo creates data responsibility – your practice becomes responsible for securing the analytics data, not a vendor.
Cost: Open-source license is free; hosting costs apply (typically integrated with existing HIPAA-eligible hosting); implementation and maintenance require technical expertise.
Alternative Analytics Platforms Comparison
Table 3: HIPAA-Friendly Analytics Platform Comparison
| Platform | Privacy Model | BAA Needed? | Data Ownership | Feature Depth | Best For | Monthly Cost |
| Fathom Analytics | Privacy-first; no personal data | No | Vendor (no PHI) | Moderate | Most healthcare practices | $14–$54 |
| Plausible Analytics | Privacy-first; no personal data | No | Vendor (no PHI) | Moderate | Cost-conscious practices | $9–$39 |
| Matomo (self-hosted) | Full control; self-hosted | No (self-hosted) | Practice (on your server) | High | Practices needing deep analytics | Hosting cost only |
| Matomo Cloud | Privacy-respecting; EU-hosted | Verify current status | Vendor | High | Practices without IT resources | $23–$60+ |
| Simple Analytics | Privacy-first; no personal data | No | Vendor (no PHI) | Low-Moderate | Minimal analytics needs | $19+ |
| GoatCounter | Open-source; minimal collection | No | Self-hosted | Low | Technical users; minimal data needs | Free (self-hosted) |
| GA4 + Privacy Config | Partial – BAA gap remains | Not available | Google (no BAA) | Very High | Not recommended without counsel | Free |
Tracking Technology Comparison for Healthcare Context
Table 4: Tracking Technology Use Case and Risk Summary
| Technology | Primary Purpose | PHI Risk | BAA Available | Healthcare Recommendation |
| Google Analytics 4 | Traffic and behavior analytics | High | No | Replace with HIPAA-safe alternative |
| Meta Pixel | Facebook/Instagram ad attribution | Very High | No | Remove from all healthcare pages |
| Google Ads Conversion Tracking | Search ad attribution | High | No | Configure carefully; no PHI in events |
| LinkedIn Insight Tag | B2B ad attribution | Medium | No | Remove from sensitive health pages |
| TikTok Pixel | TikTok ad attribution | Very High | No | Remove from all healthcare pages |
| Google Tag Manager | Tag deployment management | Medium | No (deployment tool) | Use with compliance-reviewed tags only |
| Microsoft Clarity | Session recording, heatmaps | Very High | No | Remove from form-containing pages |
| Hotjar | Session recording, heatmaps | High | Verify status | Verify BAA; exclude form pages |
| CallRail | Call attribution and recording | Medium-High | Yes (HIPAA plan) | Use HIPAA plan with BAA |
| Fathom / Plausible | Privacy-first traffic analytics | Very Low | Not needed | Recommended for healthcare |
| Matomo self-hosted | Full-featured analytics | Low | Not needed (self-hosted) | Recommended with HIPAA hosting |
| HubSpot (healthcare) | CRM + marketing analytics | Medium | Yes (healthcare tier) | Evaluate per use case |
| Salesforce Health Cloud | Healthcare CRM | Low | Yes | Enterprise-appropriate |
| Consent Management Platform | Cookie consent management | Low | Yes (verify) | Required for CCPA/GDPR contexts |
Risk Assessment Framework
Use this framework to assess your specific website’s analytics risk level. Work through each question and sum your risk points.
Question 1: Does your website have any contact forms, appointment request forms, or health history forms? No forms of any kind: 0 points. General contact form (name, phone only): 1 point. Appointment request form (name, reason for visit, insurance): 3 points. Health history or intake form: 5 points.
Question 2: What analytics tools are currently active on your website? No analytics tools: 0 points. Privacy-first analytics only (Fathom, Plausible): 0 points. GA4 with full privacy configuration: 2 points. Standard GA4 with default settings: 4 points. Meta Pixel active: 5 points. Microsoft Clarity with session recording: 5 points.
Question 3: Do you have signed BAAs with your analytics vendors? BAAs in place with all PHI-adjacent vendors: 0 points. Some BAAs in place; gaps exist: 3 points. No BAAs with analytics vendors: 5 points.
Question 4: What type of health content is on your website? General practice information only (hours, location, staff): 0 points. General service descriptions (dental cleanings, primary care): 1 point. Specific condition pages (HIV, mental health, addiction, fertility): 4 points. Combination of condition pages and appointment scheduling: 5 points.
Question 5: Is there a patient portal linked from or embedded in your website? No patient portal: 0 points. Patient portal linked (separate domain, HTTPS): 1 point. Patient portal embedded in website with analytics active: 4 points.
Question 6: Do you have a consent management platform controlling cookie deployment? Yes, CMP blocks non-essential tracking before consent: 0 points. Partial – consent banner present but doesn’t block scripts: 2 points. No consent management: 3 points.
Scoring: 0–3 points: Low risk. Your current setup has minimal PHI exposure from analytics. Annual review recommended. 4–8 points: Moderate risk. Specific configurations should be reviewed and remediated. Legal counsel consultation recommended. 9–15 points: High risk. Multiple significant compliance gaps likely present. Immediate legal and technical review required. 16–27 points: Critical risk. Implement remediation immediately. Consult HIPAA-qualified counsel before your next business day if possible.
Frequently Asked Questions
- Is Google Analytics 4 more HIPAA compliant than Universal Analytics?
No – GA4 does not address the fundamental HIPAA compliance problem with Google Analytics, which is the absence of a Business Associate Agreement. GA4 introduced some privacy-enhancing features compared to Universal Analytics, including different data retention models and consent mode capabilities. However, it also introduced new privacy risks: enhanced measurement automatically captures form interaction events that Universal Analytics did not, and GA4’s data model is more deeply integrated with Google’s advertising infrastructure. The BAA gap that makes Universal Analytics non-compliant for healthcare websites applies identically to GA4.
- If I turn off IP anonymization in GA4, does that make it worse?
IP anonymization in GA4 reduces the precision of geographic data collected from visitors. Enabling it (or verifying it is active) is a best practice that slightly reduces the identifiability of individual visitors. However, IP anonymization does not remove GA4’s fundamental HIPAA compliance problem – the absence of a BAA – and it does not prevent GA4 from collecting other identifying data including client IDs, page URLs, referral strings, and behavioral patterns. It is a marginal risk reduction measure, not a compliance solution.
- Can I use Google Analytics on non-patient pages of my healthcare website?
This is a common question with a nuanced answer. If your website has clearly segmented sections – for example, a careers page, a general about-the-practice page, and a media page – where no patient health information is collected and where health condition content is absent, the argument for lower HIPAA risk on those specific pages has some merit. However, implementing GA4 selectively across a website while ensuring it never fires on health-condition pages requires technical implementation that most organizations don’t have in place. The safest approach is either full deployment of a HIPAA-safe alternative or a legally reviewed selective deployment with documented exclusions. “We only have it on non-patient pages” without documentation and verification is not a defensible compliance posture.
- What does it mean that Google doesn’t offer a BAA for Analytics?
A Business Associate Agreement is a legally required HIPAA contract between a covered entity and any vendor that handles PHI on its behalf. When Google states it does not offer a BAA for Google Analytics, it means that using Google Analytics on a healthcare website creates a structural HIPAA violation whenever the tool handles PHI – because there is no contractual framework governing Google’s handling of that PHI. This is not a paperwork technicality. The BAA creates legal accountability for the vendor’s data handling, establishes breach notification obligations, limits the vendor’s use of the data, and enables compliance auditing. Without it, the covered entity has no HIPAA-compliant basis for the data disclosure to Google that occurs every time the analytics script fires.
- Is there any way to use Google Analytics on a healthcare website with zero HIPAA risk?
No configuration of Google Analytics provides zero HIPAA risk on a healthcare website, for the simple reason that Google does not offer a BAA. A theoretically compliant path would require a server-side GTM implementation that intercepts all data before sending to Google, strips all potential PHI (including IP addresses, URL parameters, referral strings, user identifiers, and behavioral event data connected to health-related interactions), and sends only fully de-identified aggregate data to Google Analytics. Whether such a configuration is achievable in practice, and whether the resulting stripped data would satisfy Google Analytics’ use terms, requires expert technical and legal review. For most healthcare organizations, this path is more complex and costly than simply using a HIPAA-safe alternative.
- What happens if HHS audits my practice and finds Google Analytics on my website?
OCR audits examine the totality of an organization’s HIPAA compliance program. If GA4 is found on your healthcare website without a BAA, that fact will be documented as a potential Privacy Rule violation. The severity of the outcome depends on factors including: whether PHI was actually collected and transmitted (what pages, what forms, what event data), how long the non-compliant tool was deployed, whether the practice can demonstrate good-faith remediation efforts, whether other HIPAA compliance documentation is in order, and the OCR’s assessment of culpability level. Documentation of your risk assessment process, compliance efforts, and remediation timeline significantly improves outcomes in audit scenarios. “We didn’t know” is not a defense, but good-faith, documented compliance efforts can reduce penalty severity.
- Is the Meta Pixel worse than Google Analytics from a HIPAA perspective?
For most healthcare website implementations, yes. The Meta Pixel creates more direct and documentable PHI exposure than standard Google Analytics for several reasons: Meta’s Advanced Matching feature explicitly captures form field data (including name, email, and phone number) and connects it to Facebook user profiles; the Facebook Click ID (fbc) cookie provides a direct link between a website visitor and their Facebook account when that visitor arrived via a Facebook ad; the class action litigation arising from Meta Pixel use on healthcare websites has produced extensive documentation of how directly PHI can flow through the tool; and the FTC’s 2023 enforcement action against GoodRx explicitly targeted Meta Pixel deployment as the mechanism of unlawful health data sharing. Most healthcare compliance attorneys treat Meta Pixel removal from healthcare websites as a non-negotiable recommendation.
- Does Microsoft Clarity create HIPAA risk on a healthcare website?
Yes – and in some ways more directly than GA4 or Meta Pixel. Microsoft Clarity’s session recording functionality can capture what patients type into contact and appointment request forms. When a patient types their name, their symptoms, their insurance information, or their appointment reason into a form, and Microsoft Clarity is recording that session, that data is captured and transmitted to Microsoft’s servers. Microsoft does not offer a BAA for Clarity. Session recordings of form completion on a healthcare website represent one of the most direct forms of PHI capture through analytics tooling. Microsoft Clarity should not be used on healthcare websites with forms unless form recording is explicitly disabled and legal counsel has reviewed the configuration.
- What about call tracking software like CallRail – is that HIPAA compliant?
CallRail offers a HIPAA-compliant plan that includes a Business Associate Agreement and HIPAA-eligible data storage – making it one of the few marketing technology tools in this space that has addressed the compliance gap directly. The HIPAA risk in call tracking is primarily in the call recording functionality (recordings of patients discussing their health conditions are PHI) and in the website-side dynamic number insertion tracking. Using CallRail’s HIPAA plan with appropriate configuration, signed BAA, and patient notification of call recording (where state law requires consent) provides a defensible compliance framework for call attribution. Always verify current BAA availability and plan requirements directly with the vendor.
- Should I be worried about cookies specifically?
Cookies themselves are a delivery mechanism, not an inherent HIPAA risk. The risk depends on what the cookies enable – specifically, whether they enable cross-session or cross-site tracking of individuals in ways that create PHI exposure. Analytics cookies (like the GA4 _ga cookie) enable Google to connect a visitor’s current session with past sessions on the same site, creating a longitudinal behavior record. This record, in the context of a healthcare website, can constitute PHI. Advertising cookies enable cross-site tracking that can directly connect a person’s identity to their health-related website visits. Essential functional cookies (session cookies for website functionality, language preference cookies) do not create HIPAA risk in themselves. The key question is not “do you have cookies” but “what tracking do those cookies enable and what data do they create.”
- What is consent mode and does it solve the HIPAA problem?
Google’s Consent Mode is a feature that allows GA4 to adjust its data collection behavior based on a visitor’s cookie consent choice. When consent is not given, Consent Mode sends reduced data (“pings”) to Google for modeling purposes rather than full behavioral data. Consent Mode is an important GDPR compliance tool in European contexts and is increasingly relevant in US privacy law contexts (California, etc.). However, Consent Mode does not resolve the HIPAA compliance problem. Under HIPAA, the question is not whether a patient consented to analytics tracking – HIPAA’s requirements for PHI protection apply regardless of patient consent to marketing activities. The BAA gap that makes GA4 non-compliant under HIPAA persists regardless of Consent Mode implementation.
- Is it possible to use GA4 for advertising measurement while using a HIPAA-safe tool for site analytics?
Some healthcare organizations attempt a split approach: deploying Fathom or Plausible for general site analytics while using a server-side Google Ads conversion tracking implementation for advertising attribution – configured to fire only on a post-appointment-confirmation page that contains no PHI in its URL parameters. This approach requires careful technical implementation and legal review. The goal is to enable advertising measurement without creating PHI exposure through the conversion tracking path. Whether this fully satisfies HIPAA requirements depends on the specific implementation and requires case-specific legal review – it is not a blanket recommendation.
- How do I know if my website currently has tracking tools that create HIPAA risk?
Several tools can help you audit your current tracking setup. The Markup’s Blacklight (themarkup.org/blacklight) is a free, public tool that scans any URL and reports which advertising trackers and data collectors are active on that page – it does not require technical expertise and takes 30 seconds. Your browser’s developer tools (Network tab) show every script and data request firing on a page in real time. Google Tag Manager’s Preview mode lets you see exactly which tags are firing on which pages. Your web developer or web agency should be able to provide a complete tag inventory from your GTM container or website source code. If you discover unexpected tracking tools through any of these methods, document the finding and address it as a compliance gap.
- What should I tell my digital marketing team about Google Analytics HIPAA compliance?
Your marketing team may be accustomed to using GA4, Meta Pixel, and similar tools without compliance consideration – these tools are standard in non-healthcare digital marketing. The conversation should cover three points: the legal reason these tools create HIPAA risk (no BAA; PHI disclosure to third parties), the practical implication (HIPAA-safe alternatives exist that still provide actionable marketing data), and the organizational decision (compliance takes precedence over analytics convenience, and the data loss is manageable). Framing it as “we’re switching to better-suited tools for our industry” rather than “we have to stop measuring marketing” reduces resistance and focuses the conversation on solution.
- What is the single most important action a healthcare provider should take regarding website analytics in 2026?
Conduct a complete audit of every tracking tool active on your website – analytics, advertising pixels, session recording tools, call tracking, and form tools – and determine BAA status for each. The audit itself is the highest-priority action because most healthcare organizations do not have complete visibility into what is running on their websites. Use The Markup’s Blacklight for a quick initial scan. Then determine your remediation path based on what you find: replace high-risk tools with HIPAA-safe alternatives, remove advertising pixels from health-sensitive pages, ensure BAAs are in place with any remaining PHI-adjacent vendors, and document your remediation process. Consult HIPAA-qualified legal counsel if the audit reveals significant historical exposure.
Final Verdict
The question “Is Google Analytics HIPAA compliant?” has a clear technical answer: no – because Google does not offer a Business Associate Agreement for Google Analytics, and HIPAA requires a BAA with any vendor that handles PHI on behalf of a covered entity.
The more useful question for most healthcare providers is: “What is my actual risk, and what should I do about it?”
Your actual risk depends on what your website collects, how analytics are configured, and what your legal exposure looks like if a complaint or audit surfaces. A solo family practice with a phone-number-only website and unconfigured GA4 is in a different risk category than a multi-location specialty group with appointment scheduling forms and a Meta Pixel active on every page. Both have compliance gaps – but the urgency and consequence of remediation are different.
What is not in question: regulators have issued explicit guidance on this issue. Class action litigation has followed. FTC enforcement has occurred against analogous data practices. The compliance risk from standard analytics deployment on healthcare websites is real, documented, and actively monitored by regulators in 2026.
The good news is that the remediation path is clear, affordable, and well-established. HIPAA-safe analytics alternatives – Fathom, Plausible, self-hosted Matomo – provide actionable traffic and conversion data without PHI exposure. Removing or properly configuring advertising pixels is a one-hour technical task. Replacing a non-compliant scheduling widget with a HIPAA-eligible alternative is a project, not a transformation.
The practices that handle this correctly are not the ones with the most sophisticated legal teams. They are the ones that take the compliance question seriously, audit their current state honestly, make evidence-based decisions about their risk tolerance, and implement documentation that demonstrates good faith.
That’s what HIPAA compliance has always required – and website analytics are no different.
How DevRivo Handles Analytics for Healthcare Websites
Every healthcare website DevRivo builds is configured from the ground up with HIPAA-safe analytics – specifically, replacing standard Google Analytics with privacy-first tools (Fathom Analytics or Plausible Analytics, depending on practice preference) that provide actionable traffic and conversion data without PHI exposure. Advertising pixel management, tracking script audits, and analytics configuration documentation are standard deliverables.
Practices that are currently running non-compliant analytics on existing websites can request a tracking audit from DevRivo’s team.
Start with a consultation at devrivo.com.