What Is Enhanced Conversions? Healthcare Compliance Considerations

Your digital marketing agency sends over a recommendation: "Turn on Enhanced Conversions in Google Ads. It will improve your conversion tracking accuracy by 15 to 20 percent." The setup looks simple. Add a code snippet to your conversion pages that captures the user's name, email, and phone number from form submissions, hashes them using SHA-256, and sends the hashes to Google alongside the conversion event. Google matches the hashed data against its own user database to attribute the conversion to the ad click that drove it.

For a SaaS company or an e-commerce store, this is a straightforward performance optimization. For a hospital whose conversion pages include appointment request forms, patient intake questionnaires, and consultation scheduling, this "simple optimization" means sending hashed patient identifiers alongside health-specific conversion events to Google's advertising infrastructure. Every appointment request becomes a data point that connects a patient's identity to a specific medical service, stored on Google's servers, for the purpose of advertising measurement.

How Enhanced Conversions Work Under the Hood

Enhanced Conversions is Google's solution to a measurement gap created by browser privacy changes. As third-party cookies decline and browsers like Safari restrict tracking, Google can no longer reliably connect ad clicks to website conversions using cookies alone. Enhanced Conversions fills this gap by using first-party data, information the user provides directly on your site, to match conversions back to ad interactions.

The technical process works in three stages.

Stage 1: Data capture. When a user completes a conversion action (submitting a form, booking an appointment, requesting information), Google's tag captures the user's email address, phone number, name, and/or mailing address from the form fields on that page. This can happen automatically through Google's auto-detection or through manual configuration specifying which form fields to capture.

Stage 2: Client-side hashing. The captured data is hashed using SHA-256 before it leaves the browser. Google's documentation emphasizes that the data is "hashed for privacy" before transmission. The hashed values, not the raw text, are sent to Google.

Stage 3: Server-side matching. Google receives the hashed user data alongside the conversion event. Google hashes its own user data (from Gmail accounts, Google profiles, Android devices) using the same algorithm. If the hashes match, Google attributes the conversion to the correct ad click and campaign.

Google offers two implementation methods: a web tag (client-side JavaScript) and a server-side API through Google Tag Manager. Both send hashed user data to Google; the difference is where the hashing and transmission originate.

Why Hashing Does Not Equal Anonymization

The core compliance problem with Enhanced Conversions in healthcare is the assumption that hashing makes data anonymous. It does not.

SHA-256 hashing is a deterministic process. The same input always produces the same output. The hash of "patient@email.com" will be identical every time, everywhere. This is precisely what makes it useful for matching: Google hashes its own database of user emails and compares them against the hashes you send. If it were truly anonymous, matching would be impossible.

Hashing is also reversible in practice for constrained data sets like email addresses and phone numbers. A relatively small dictionary of possible email addresses can be hashed and compared against captured hashes. More importantly, Google does not need to reverse the hash because Google already has the original data. The hash is a lookup key, not a privacy protection.

For HIPAA purposes, hashed email addresses and phone numbers remain individually identifiable information. When combined with the context of the conversion event (which page it occurred on, what form was submitted, what service was requested), they constitute PHI. The hash adds a mathematical step to the process; it does not remove the identification.

The Conversion Page Problem in Healthcare

Enhanced Conversions captures data specifically from conversion pages: the pages where users complete an action. In healthcare, these are among the most sensitive pages on the site.

Consider what a typical healthcare "conversion" looks like.

A patient visits a hospital website, navigates to the cardiology department page, clicks "Request an Appointment," fills in their name, email, phone number, and selects "Heart Failure Consultation" from a dropdown. They submit the form. With Enhanced Conversions enabled, Google's tag captures the patient's name, email, and phone number from the form, hashes them, and sends them to Google alongside the conversion event. The event is associated with the page URL (which contains "cardiology"), the referral source (a Google ad for heart care), and the conversion action ("appointment_request").

Google now holds hashed patient identifiers connected to a specific medical interest, captured through an advertising system, stored for attribution and optimization purposes. No BAA exists between the healthcare organization and Google Ads. Google does not accept HIPAA liability for advertising data.

This pattern echoes the Sutter Health case. Sutter Health implemented Google Analytics, the Meta Pixel, and other tracking tools on its MyHealthOnline patient portal. The tools tracked and disclosed private patient data to Google and Facebook without authorization, resulting in a $21.5 million settlement. While Sutter Health involved analytics rather than Enhanced Conversions specifically, the data flow pattern is structurally identical: patient identifiers combined with health context, sent to Google's servers, without a BAA.

Server-Side Enhanced Conversions: Better but Not Sufficient

Google offers a server-side implementation of Enhanced Conversions through server-side Google Tag Manager (sGTM). In this setup, the hashing and data transmission happen from a server container you control rather than from the visitor's browser.

Server-side implementation is better than client-side for two reasons. First, your server processes the data before it reaches Google, giving you the opportunity to filter or modify what is sent. Second, no Google JavaScript executes in the visitor's browser, eliminating the direct browser-to-Google connection.

However, server-side Enhanced Conversions still sends hashed patient identifiers to Google by design. That is its core function. If your sGTM container forwards hashed emails from appointment forms alongside health-specific conversion events, the PHI exposure persists regardless of where the hashing occurs.

A compliant implementation through sGTM requires an additional layer: a data governance system that evaluates each conversion event, strips or replaces identifiable information, removes health-specific context from the event, verifies consent, and only then forwards a sanitized event to Google. At that point, you are no longer using Enhanced Conversions as Google designed it. You are using server-side conversion tracking with your own compliance logic, which is the CAPI approach with proper healthcare safeguards.

What Compliant Conversion Tracking Looks Like

Healthcare organizations can measure Google Ads performance without Enhanced Conversions by building a conversion tracking architecture that separates identity from measurement.

Use a HIPAA-compliant CDP as the conversion gateway. A compliant CDP collects conversion events from your site through server-side infrastructure. It evaluates each event against consent policies and data governance rules. It strips identifiers and health context. Then it sends a sanitized conversion signal to Google through the server-side API. Google receives confirmation that a conversion occurred, associated with a click ID, without receiving any patient data.

Accept modeled attribution over deterministic matching. Google's machine learning models can estimate conversion performance using aggregate data, partial signals, and statistical modeling. The accuracy is lower than deterministic matching through Enhanced Conversions, but it does not require sending patient data to Google. Many healthcare organizations find this tradeoff acceptable when weighed against the compliance risk.

Gate all conversion signals on verified consent. Consent must be verified server-side before any conversion event is forwarded to Google. This ensures no data flows until the patient has explicitly opted in, enforced at the infrastructure level rather than through client-side JavaScript. As state privacy laws like the Washington My Health My Data Act expand consent requirements, server-side enforcement becomes essential.

Monitor for unauthorized re-enablement. Enhanced Conversions can be turned on through the Google Ads interface, through GTM, or through code changes. A web scanner that continuously monitors your site will detect if Google's Enhanced Conversions tag reappears after removal. Henry Ford Health's case, where Meta Pixel and Google tracking ran from 2020 to 2023 resulting in a $12.2 million settlement, demonstrates how tracking technologies persist undetected for years.

FAQ

Does Google sign a BAA for Enhanced Conversions?

No. Google does not sign BAAs for Google Ads or any of its advertising products, including Enhanced Conversions. Google Workspace and Google Cloud Platform offer BAAs for certain healthcare use cases, but the advertising stack is explicitly excluded. Any patient data sent through Enhanced Conversions has no HIPAA protection on Google's end.

Is hashed data considered PHI under HIPAA?

Hashed data that can be matched back to an individual, as Enhanced Conversions is specifically designed to do, remains individually identifiable health information when combined with health context. SHA-256 hashing is a transformation, not an anonymization technique. HIPAA's Safe Harbor method for removing identifiers requires removing 18 specific data types and having no reasonable basis to identify individuals. Hashed email addresses fail this test.

Can we use Enhanced Conversions only on non-health pages?

In theory, limiting Enhanced Conversions to pages with no health context (like a general "Contact Us" page) reduces risk. In practice, maintaining this separation is difficult. Google's auto-detection can capture data from forms on pages you did not intend to track. Site redesigns can move health content onto tracked pages. And if the visitor arrived via a health-specific ad campaign, the conversion event carries health context through the campaign association even if the page itself is generic.

What is the difference between Enhanced Conversions and Conversion API?

Enhanced Conversions is Google's specific feature for improving conversion attribution by sending hashed user data to Google. Conversion API (CAPI) is a broader term for server-to-server conversion tracking offered by multiple platforms (Meta, TikTok, LinkedIn). Both involve sending conversion data from a server rather than a browser, but Enhanced Conversions specifically focuses on user identity matching through hashed data, while CAPI implementations can be configured to send minimal or no user identity data.

Should we turn off Enhanced Conversions immediately?

If Enhanced Conversions is active on pages where patients submit forms, schedule appointments, or interact with health-specific content, and you do not have a compliance layer filtering the data before it reaches Google, then yes. Disable it and implement server-side conversion tracking with proper data governance. The performance improvement from Enhanced Conversions does not justify the compliance exposure in healthcare.

Enhanced Conversions is designed to improve advertising measurement by sending patient data to Google. In healthcare, that design conflicts directly with HIPAA requirements. If your team needs accurate Google Ads attribution without exposing patient data, Ours Privacy provides the server-side infrastructure to measure conversions compliantly.

Related reading:

• What Is Conversion API (CAPI)? Healthcare Implementation Explained

• Server-Side Google Ads Tracking for Healthcare Advertisers

• What Is a Tracking Pixel? Why Healthcare Websites Should Remove Theirs

• Is Google Analytics HIPAA Compliant?