Google Ads Enhanced Conversions for Healthcare: Server-Side Setup Without PHI Leakage

Google Ads Enhanced Conversions promise better attribution by matching first-party customer data to Google's logged-in user base. For most industries, the setup takes thirty minutes: add a code snippet, hash an email address, and let Google reconcile conversions across devices. For healthcare, that thirty-minute shortcut is a direct path to a HIPAA violation.

The feature works by sending hashed personally identifiable information (names, email addresses, phone numbers) from your website to Google at the moment a conversion fires. In healthcare, the "conversion" is often an appointment request, a contact form submission, or a page visit that signals clinical intent. Sending any of that data to Google through a client-side tag means the patient's browser is transmitting identifiable information alongside health context to a third party that has no Business Associate Agreement with your organization.

This guide walks through exactly how to set up Enhanced Conversions server-side so your healthcare marketing team gets the attribution data it needs without any patient information reaching Google through the browser.

What Enhanced Conversions Actually Send to Google

Before configuring anything, your compliance and marketing teams need to understand the data flow. Enhanced Conversions work in two modes: web (client-side) and server-side. The distinction matters enormously in healthcare.

Client-side Enhanced Conversions (the default). A Google tag on your website captures user-provided data at conversion time. This typically includes email addresses, phone numbers, names, and mailing addresses. The tag hashes this data using SHA-256 before sending it to Google. The problem: hashing happens in the browser, meaning the raw data exists in the page DOM before hashing. Browser extensions, network inspection tools, and Google's own tag infrastructure all have access to the pre-hashed values. More critically, the conversion event itself carries health context. When a patient submits an "Orthopedic Consultation Request" form and Google receives their hashed email alongside that conversion label, Google now holds the association between an individual and a medical service.

Server-side Enhanced Conversions. Your server sends hashed user data to Google's API after the conversion occurs. The browser never communicates with Google. Your server controls what data gets hashed, what conversion labels are applied, and whether consent has been verified before any data moves. This is the only architecture that gives healthcare organizations the control HIPAA requires.

Prerequisites Before You Start

Before writing a single line of configuration, confirm these foundations are in place.

1. Google Ads API access. Server-side Enhanced Conversions require the Google Ads API, not just Google Tag Manager. Your team needs a Google Ads developer token, OAuth credentials, and a linked Google Ads account. If you are running campaigns through an agency, the agency's MCC account needs the appropriate API permissions.

2. A server-side intermediary. You need infrastructure between your website and Google that can receive conversion events, validate consent, strip or hash sensitive fields, and forward clean data to Google's API. This can be a custom-built middleware, a server-side tag management container, or a HIPAA-compliant CDP that handles the transformation automatically.

3. Consent verification. Your consent management platform must be integrated with your server-side pipeline. Consent status should be checked server-side before any data leaves your infrastructure. Client-side consent banners are a starting point, but they are not sufficient because JavaScript-based consent checks can be delayed by page load timing, circumvented by browser behavior, or simply fail to load.

4. Conversion action mapping. Audit every conversion action in your Google Ads account. For each one, document: what user data is captured, what health context exists in the conversion label or page URL, and whether the conversion fires on a page that implies a medical condition or service. Rename conversion actions that contain clinical terms. "Form Submit: Cardiology" becomes "Form Submit: Service Line A."

Step-by-Step Server-Side Implementation

Step 1: Configure Conversion Actions Without Health Context

In your Google Ads account, create or modify conversion actions so that names, labels, and categories contain no clinical language. Google stores conversion action names and makes them available across its reporting interfaces. A conversion action named "Appointment: Psychiatry" associates your account with mental health services at the platform level.

Use neutral naming: "Lead Form A," "Contact Request B," "Schedule Action C." Map these internally to service lines using your own analytics, not Google's reporting.

Step 2: Build the Server-Side Data Pipeline

Your server needs to receive conversion events from your website, process them, and forward them to Google. The flow looks like this:

1. Patient submits a form on your website.

2. Your website sends the form event to your own server (not to Google).

3. Your server checks consent status for this user.

4. If consent is verified, your server hashes the user's email address and/or phone number using SHA-256.

5. Your server strips any health context from the event payload. The conversion label sent to Google should contain no clinical terms, page paths referencing conditions, or service line identifiers.

6. Your server sends the hashed data and sanitized conversion event to Google's Ads API via the ConversionUploadService.

The critical principle: Google receives only the hashed identifier and a generic conversion label. Your internal systems maintain the mapping between generic labels and clinical service lines.

Step 3: Implement Consent Gating at the Server Layer

This step is where most implementations fall apart. Consent must be verified server-side before step 4 above executes. If a patient has not consented to advertising data use, the conversion event stops at your server. It never reaches Google.

This is not just a HIPAA requirement. It is where healthcare compliance is heading broadly. State privacy laws from Washington, Connecticut, and others are creating consent frameworks that apply to health data regardless of whether the organization is a HIPAA covered entity. Server-side consent gating handles both HIPAA and state law requirements in a single architecture.

Step 4: Validate the Data Google Actually Receives

After implementation, verify what Google sees. Use the Google Ads API's UploadConversionAdjustments diagnostics to review what data reached Google. Confirm that:

• No unhashed email addresses or phone numbers appear in any payload.

• No conversion action names contain clinical, diagnostic, or treatment-related terms.

• No page URLs with health context are included in the conversion data.

• Only events with verified consent were transmitted.

Run this validation monthly. Marketing teams change conversion actions, add new campaigns, and modify form flows. Each change is an opportunity for health context to leak into Google's systems.

Step 5: Remove Client-Side Google Tags from Conversion Pages

If you previously used client-side Enhanced Conversions or standard Google Ads conversion tracking, remove those tags from pages where health context exists. This includes appointment scheduling pages, service line landing pages, patient portal login pages, and any form that collects information about a patient's medical needs.

A web scanner that continuously monitors your site can catch cases where a Google tag is still firing on a page that should be server-side only. Marketing teams frequently add tags through Google Tag Manager without realizing a page carries health context. Continuous scanning catches those additions before they become exposure.

Where Standard Implementations Create PHI Exposure

Two enforcement cases illustrate why client-side tracking creates liability for healthcare advertisers.

GoodRx ($1.5M FTC + $25M class action, 2023). GoodRx configured Google tracking pixels that shared prescription drug names, health conditions, and personal identifiers with Google and other ad platforms. The data flowed through standard client-side tags. The FTC's enforcement was the first under the Health Breach Notification Rule and established that health data shared through advertising pixels constitutes a breach requiring notification. Source

Henry Ford Health ($12.2M class action, 2025). Henry Ford used Google tracking technologies on its website and MyChart patient portal between 2020 and 2023, sharing PHI of over 819,000 consumers with Google. The tracking tools operated exactly as configured. The problem was architectural: client-side tags on pages with health context sent data directly from patient browsers to Google. Source

In both cases, the organizations were using Google's standard tracking implementation. The data flows were by design, not by accident. Server-side architecture would have prevented both exposures by ensuring patient browsers never communicated with Google directly.

Common Mistakes in Healthcare Enhanced Conversions

Mistake 1: Hashing on the client side and calling it "server-side." Some teams hash data in the browser using JavaScript before sending it to Google Tag Manager's server container. This is still client-side. The browser still processes the raw data. True server-side means the conversion event goes from the browser to your server, and only your server communicates with Google.

Mistake 2: Using Google Tag Manager's server-side container without sanitizing payloads. A server-side GTM container receives events from the client-side GTM container. If the client-side container is sending page URLs like /services/oncology/appointment-request, that health context passes through to the server container and potentially to Google. Sanitize before the data reaches even your own server-side container.

Mistake 3: Forgetting about Google Ads auto-tagging. When auto-tagging is enabled, Google appends a gclid parameter to every click URL. If a patient clicks an ad and lands on a service-specific page, the gclid ties that user's Google profile to the health-specific page visit in Google's systems. Server-side conversion tracking mitigates this by decoupling the click from the conversion, but you need to handle gclid storage carefully. Store it in your own first-party cookie or server session, never in a way that Google's client-side tags can access alongside health context.

Mistake 4: Not monitoring for tag drift. Your server-side implementation is only as good as the day it was verified. Marketing teams add new conversion tags, agencies install scripts, and CMS plugins update with embedded trackers. Without continuous monitoring, client-side tags can reappear on healthcare pages weeks or months after you removed them.

FAQ

Do hashed email addresses count as PHI under HIPAA?

Hashing alone does not remove the compliance obligation. SHA-256 hashing is reversible through rainbow table attacks and does not meet HIPAA's standard for rendering data unusable. More importantly, the issue is not whether Google can reverse the hash. The issue is that a hashed email sent alongside a health-contextual conversion event creates an association between an identifier and health information in Google's systems. Even if the identifier is hashed, the association is the PHI.

Can I use Google Tag Manager's server-side container for Enhanced Conversions?

Yes, but with significant caveats. Google Tag Manager's server-side container is a processing layer, not a compliance layer. It will forward whatever data it receives. You must ensure that: (a) the client-side container sends events to your server container without health context in page URLs or event parameters, (b) the server container strips any remaining health signals before forwarding to Google, and (c) consent is verified server-side before the event forwards. A HIPAA-compliant tag management solution handles these requirements automatically.

What conversion data can I safely send to Google?

You can send hashed first-party identifiers (email, phone) alongside generic conversion labels that contain no health context, provided the user has consented to advertising data use. The conversion value (dollar amount) is generally safe if it does not reveal the type of service. Avoid sending page URLs, service line names, or any custom parameters that reference medical conditions or treatments.

How does this differ from Google's Consent Mode v2?

Consent Mode v2 adjusts Google tag behavior based on user consent signals. It modifies what data Google's client-side tags collect. Server-side Enhanced Conversions operate independently: your server decides what to send to Google after verifying consent. For healthcare, server-side Enhanced Conversions provide stronger protection because they eliminate client-side data flows entirely rather than modifying them.

Do I need a BAA with Google to use Enhanced Conversions?

Google does not sign BAAs for Google Ads or related advertising services. This is precisely why server-side architecture is necessary. By ensuring that no PHI reaches Google, you remove the need for Google to act as a Business Associate. Your server-side intermediary, whether a custom pipeline or a HIPAA-compliant CDP, should be the entity that signs the BAA and handles PHI.

Enhanced Conversions are one of Google Ads' most effective attribution tools. Healthcare organizations should not avoid them; they should implement them correctly. The server-side approach described here preserves attribution accuracy while ensuring patient data never reaches Google's infrastructure through the browser.

If your team needs help building a server-side conversion pipeline that satisfies both marketing performance and HIPAA requirements, Ours Privacy provides the infrastructure, BAA coverage, and continuous monitoring to make it work.

Related reading:

• Google Ads for Healthcare: The Complete HIPAA Compliance Setup Guide

• Server-Side Google Ads Tracking for Healthcare Advertisers

• What Is Enhanced Conversions? Healthcare Compliance Considerations

• The Healthcare Pixel Problem