Is Google Analytics HIPAA Compliant? A Healthcare Website Risk Assessment

Reviewed October 2026

Google Analytics is not represented by Google as a HIPAA-compliant service, and Google does not offer a Business Associate Agreement for Google Analytics. A HIPAA-regulated organization should not use Google Analytics in a way that gives Google access to or collects protected health information (PHI). Whether a particular website page or data flow creates that risk depends on the facts: the page, the visitor interaction, the information collected, and the destination of that information all matter.

That does not mean every public healthcare webpage with an analytics tag automatically creates a HIPAA violation. HHS explains that many unauthenticated webpages may not involve PHI. However, authenticated portals generally present a much higher risk, and some unauthenticated pages or workflows can transmit information that is individually identifiable health information. The correct question is not simply, “Is Google Analytics installed?” It is, “What information leaves this page, who receives it, and does that create a HIPAA-regulated disclosure?”

This article offers general information for healthcare marketing and operations teams. It is not legal advice or a compliance determination. A practice’s privacy, security, compliance, and legal leaders should evaluate its specific services, contracts, data flows, and applicable laws.

What Google Says About HIPAA and Analytics

Google states that HIPAA-regulated entities using Google Analytics must refrain from exposing to Google any data that may be considered PHI, even when that data is not expressly described as personally identifiable information in Google’s policies. Google also states that it makes no representation that Google Analytics satisfies HIPAA requirements and does not offer BAAs in connection with the service.

Google’s guidance directs HIPAA-regulated customers to avoid using Google Analytics in a way that creates HIPAA obligations for Google. It specifically identifies authenticated pages as likely to be HIPAA-covered and says customers should not set Google Analytics tags on those pages. The practice remains responsible for determining which pages and uses are permitted for its circumstances.

Why Page Context Matters

HHS distinguishes between authenticated and unauthenticated webpages. An authenticated portal, telehealth platform, or other login-protected experience generally presents a high-risk environment because the page may expose information such as account details, appointment information, diagnoses, treatments, prescriptions, or billing details. If a tracking technology vendor is a business associate because it creates, receives, maintains, or transmits PHI on behalf of the regulated entity for a covered function or service involving PHI, the disclosure must be permitted by the Privacy Rule and the parties must have an appropriate business associate agreement.

Unauthenticated pages require a more careful, fact-specific analysis. A general location, visiting-hours, employment, or policy page may not involve PHI. At the same time, a public workflow that lets someone schedule care, enter health-related information, use a symptom-checker, begin an intake path, or otherwise disclose information about healthcare can create a different risk profile. After a 2024 court order vacated part of OCR’s earlier guidance, OCR explains that an IP address or other identifier paired only with a visit to an unauthenticated public page addressing a health condition or provider is not sufficient to be individually identifiable health information when that visit is not related to the individual’s past, present, or future health, health care, or payment for health care. The actual data collected, page function, and recipient’s context must be assessed together.

Start With a Data-Flow Assessment

A responsible decision starts with an inventory of what each website and app page sends to each vendor. Include analytics tags, tag-manager containers, advertising pixels, session-replay tools, embedded scheduling widgets, chat tools, form providers, cookie-consent platforms, and custom scripts. Do not limit the review to the Google Analytics tag.

For each tool and page type, document the data elements sent, when they send, the recipient, the business purpose, whether the page is authenticated, and whether the information could relate to a person’s past, present, or future health, healthcare, or payment for healthcare. Record the owner of the page and the owner of the vendor relationship so the review has accountable decision-makers.

Questions worth answering include:

• Which pages contain tracking code? Include subdomains, landing pages, patient portals, scheduling paths, form-confirmation pages, embedded widgets, and mobile apps.

• What is actually transmitted? Review URLs, page titles, query parameters, form values, site-search terms, event names and parameters, custom dimensions, campaign values, user IDs, device or location data, and any data-layer variables.

• Who receives it? Identify the direct vendor, downstream destinations enabled by integrations, and any advertising or data-sharing features.

• Could the combination reveal health, care, or payment information? The answer can change by page and interaction. Do not rely on the tool’s name or a generic privacy setting.

• What permits the disclosure? If PHI may reach a vendor, the practice needs an appropriate HIPAA pathway, including a valid business-associate arrangement when the vendor is acting as a business associate. Cookie consent, a generic privacy notice, or an assumption that data is “anonymous” does not independently resolve that question.

Data Elements That Need Special Scrutiny

Google’s own Analytics guidance says its policies prohibit customers from passing data that Google could use or recognize as personally identifiable information. It also warns that page URLs and titles, user-entered information, campaign parameters, custom dimensions, site-search values, and event fields can inadvertently send prohibited data.

In a healthcare environment, review these paths before relying on analytics reporting:

• URLs and page titles: A basic Analytics page tag collects the viewed page’s URL and title. Inspect paths and query parameters for names, emails, record numbers, appointment details, referral information, or condition-related inputs.

• Forms and searches: Do not pass form entries, on-site search terms, form labels, form errors, or confirmation-page details to analytics without a documented assessment.

• Events and custom fields: Review booking, intake, chat, call-tracking, navigation, and conversion events. An event label that appears harmless may carry a value from a page, form, or data layer that needs review.

• Campaign and audience features: Check UTM values, advertising features, audience definitions, data sharing, and integrations. Do not use campaign names or audience rules that include sensitive patient information.

• Embedded tools: Scheduling, payment, portal, chat, maps, video, and third-party form tools can add their own scripts or data destinations. Include them in the same inventory.

Do Not Treat Redaction as a Compliance Conclusion

Data redaction, tag controls, consent settings, or removal of selected URL parameters can reduce the chance of passing certain data to Analytics. They do not, by themselves, establish that a complete healthcare website configuration is HIPAA-compliant. The practice should test what is actually transmitted and evaluate the full workflow, including new pages, vendor updates, and tag-manager changes.

Likewise, “anonymized” is not a substitute for a defined HIPAA analysis. HHS recognizes two methods for de-identifying PHI under the Privacy Rule: Safe Harbor and Expert Determination. Safe Harbor requires removing specified identifiers, including IP addresses, URLs, and device identifiers, and requires that the entity have no actual knowledge that the remaining information could identify an individual. Do not describe a web-analytics setting as producing HIPAA-de-identified information unless the practice can substantiate either Safe Harbor—including removal of every required identifier and no actual knowledge that the remaining information could identify the individual—or a documented Expert Determination.

A Practical Decision Framework

After the inventory, assign each page or workflow a decision. For each public-page data flow, determine whether the tracking tool receives PHI; if it does not, that use of the tool is not regulated by the HIPAA Rules. Document the page-by-page reasoning rather than applying one answer to the whole domain. For an authenticated portal or workflow that can expose PHI, keep Google Analytics and other unapproved third-party tracking off that experience until qualified review identifies an appropriate permitted approach.

For any vendor that may receive PHI, pause implementation until the practice confirms the vendor’s role, contract terms, applicable BAA requirements, safeguards, and permitted purpose. If a data flow may be impermissible, preserve relevant configuration records and involve the practice’s incident-response, privacy, security, and legal stakeholders. Finding a tag does not automatically establish a reportable breach; that determination requires a fact-specific review.

Build Measurement Around Minimum Necessary Information

Healthcare organizations can still measure website performance without using every possible identifier or event. Start with business questions that do not require sensitive data: which approved public resources are useful, whether visitors can find locations or services, whether pages function correctly, and whether the content path supports an appropriate, privacy-reviewed next step.

Define each reporting metric with an owner, data source, purpose, permitted page scope, and retention approach. Before adding a new tag, campaign, form, integration, or AI feature, require a data-flow review. Recheck the inventory after major website releases, vendor changes, and tag-manager updates. For a hands-on workflow, use the companion healthcare website tracking audit.

When to Escalate

Escalate promptly when a page includes login access, appointment scheduling, patient-intake fields, portal information, condition-specific search terms, referral or insurance details, payment data, or a third-party tool that receives user interactions. The same is true when a marketing or analytics team cannot identify what a tag sends, where it sends it, or whether a vendor relationship is governed appropriately.

Patient10x can help a practice inventory its public website tracking and measurement requirements. A practice’s privacy, security, compliance, and legal leaders should make the final determination about HIPAA obligations, vendor agreements, and incident response. Contact Patient10x to discuss a tracking-inventory and measurement-planning engagement.