How PHI Leaks Through Google Ads Tags in Healthcare

The Google Ads conversion tag on your healthcare site is probably sending PHI to Google. Not because someone misconfigured it — because it is working exactly as designed.

This is the piece that trips up most healthcare marketing teams. They imagine the problem as something deliberate: uploading a patient list, connecting the EHR to Google Ads, sending medical records across the wire. That is not the problem. The problem is what the tag collects from the page automatically, without anyone explicitly sending anything.

The Misconception

Healthcare teams draw a clear mental boundary: patient data lives in the EHR, the CRM stays behind the firewall, nothing connects to Google. Therefore: no PHI in Google Ads.

That boundary is real. And it does not matter, because PHI leakage through Google Ads does not require you to connect your EHR to your ad account. It requires only that your site has condition names, treatment categories, or provider specialties in the URL — which nearly every healthcare site does.

What the Tags Actually Collect

There are four specific mechanisms through which standard Google Ads tags transmit PHI from healthcare sites. Each operates by default unless explicitly disabled or architecturally prevented.

The Conversion Linker and Full URL Collection

The Conversion Linker tag — the default in virtually every Google Ads account using GTM — reads and stores the full page URL when a user arrives from a Google Ads click. That URL gets sent with every subsequent conversion event on the session.

A patient clicks a Google Ad for "orthopedic surgeon near me" and lands on /services/orthopedics/appointments/. The Conversion Linker captures that URL. When the patient submits an appointment form two minutes later, the conversion payload sent to Google includes that path.

/services/orthopedics/appointments/ is PHI when it is associated with a user identifier. The click ID (gclid) is a user-level identifier. URL path indicating a health service plus a persistent user-level ID meets HHS's definition of PHI transmission.

The scale problem: a health system with service lines across oncology, behavioral health, cardiology, and reproductive health has PHI transmission happening across every service line, tied to gclids, with no filtering and no BAA. In every Google Ads account I have audited in a healthcare context, the Conversion Linker has been running with URL collection enabled and no parameter filtering — because that is the default configuration.

Enhanced Conversions: The Compliance Team's False Reassurance

Enhanced Conversions is how most healthcare teams convince themselves they have solved the HIPAA problem. The logic: we are hashing the email before sending it, so no PII leaves the browser in readable form.

That is not how HIPAA works.

HHS guidance on online tracking technologies is explicit: a hashed or encoded identifier paired with health information is PHI. The hash does not remove the identifier from the combination — it obscures it from casual observation while preserving Google's ability to match it to a Google account.

Here is what actually happens: a patient on /conditions/mental-health/depression-treatment/ submits a contact form. Enhanced Conversions captures their email, hashes it with SHA-256, and sends it to Google with the conversion event. The conversion payload includes the page URL. Google now has [hashed email] + [page path indicating the user sought depression treatment]. That is PHI. The hash is not a HIPAA Safe Harbor de-identification technique — Safe Harbor requires removing or transforming 18 specific identifiers, not encoding them.

Remarketing Tags Building Lists from Condition Visits

Google Ads remarketing works by adding users to audience lists based on pages they visit. In healthcare, those pages are condition pages, treatment pages, and provider specialty pages.

A remarketing audience defined as "users who visited /conditions/fertility-treatment/" is a list of patients who sought fertility treatment. That list lives in your Google Ads account. HIPAA does not require that PHI be stored in a database you own — a remarketing audience in your ad account, built from visits to condition-specific pages, is a PHI data asset.

Retargeting campaigns built on these audiences create a second-order problem: you are now serving ads tied to a health condition to patients elsewhere on the web, which is itself a disclosure of health information.

Smart Bidding Signals and Page Context

When Smart Bidding optimizes bids, it ingests signals from the conversion event payload — including page URL and page category. Those signals are used in Google's bidding model training. Patient health information is flowing into Google's model as a training input. There is no BAA governing that use.

This is not theoretical. Every conversion event from a condition-specific page, every audience signal from a treatment URL — all of it flows into the bidding model as behavioral signal. The fact that Google processes it as a bidding feature rather than storing it as a patient record does not change the HIPAA analysis. Disclosure is disclosure.

How to Check

This is a 20-minute audit. You do not need anything except Chrome DevTools.

1. Inspect Conversion Linker payloads. Navigate to a condition-specific landing page or treatment category page with ?gclid=test123 appended. Open DevTools, go to the Network tab, filter for googleadservices.com. Find the request from the Conversion Linker. Look at the url or page parameter in the payload. If it contains the condition or treatment type from the path, PHI is in the payload.

2. Test Enhanced Conversions on form pages. Submit a test form on a condition-specific appointment or contact page. In the Network tab, filter for google.com/pagead/1p-conversion. Open the payload. Look for em (hashed email) and ph (hashed phone). Then note which page the conversion fired on. If that page is condition-specific, the hash plus page context equals PHI transmission.

3. Audit your remarketing audiences. In Google Ads, go to Tools → Audience Manager. Review each audience and its URL rule criteria. Any audience defined by condition page paths, treatment category URLs, or provider specialty pages is a PHI audience. Note the audience size — that is a count of patient records.

4. Review the Conversion Linker tag configuration. In GTM, open the Conversion Linker tag. Look for any URL parameter filtering or page path exclusions. By default there are none. If the tag fires on All Pages with no exclusions or parameter restrictions, the full URL is being collected everywhere — including every condition page, every portal page, and every scheduling flow.

The Fix

There are two layers here. The first is what you send to the tag. The second is whether you have the contractual basis to use the tag at all.

Layer 1: URL normalization before Google Ads tags fire

The fix for URL-based PHI collection is a normalization layer that strips condition identifiers from page paths before they reach any Google tag. In sGTM, you intercept the incoming event payload, replace specific path segments with category labels, and only forward the normalized version downstream.

A page path like /services/oncology/breast-cancer-screening/ becomes /services/oncology/ before the Conversion Linker sees it. The service line category is preserved for conversion reporting. The specific condition is not transmitted.

This is not achievable with browser-side GTM alone. By the time any custom JavaScript runs in the browser, the Conversion Linker has already read the URL. The normalization has to happen at the server layer, before the tag fires.

Layer 2: Move Enhanced Conversions to server-side

Browser-side Enhanced Conversions hashes the identifier and sends it with the full page URL in a single request — the identifier and the condition context leave together. Server-side Enhanced Conversions through sGTM lets you hash the identifier on the server, normalize the URL, and send them in a way that decouples the health context from the user identifier.

This reduces exposure surface. It does not fully resolve the HIPAA problem — the BAA gap still exists — but it eliminates the most direct form of PHI transmission.

Layer 3: Delete and rebuild remarketing audiences

Any audience list built from condition-specific URL rules needs to be deleted. Replace condition-based audiences with targeting signals that do not encode health information: campaign-level RLSA from non-condition pages, Customer Match from first-party data that has been properly de-identified under Safe Harbor, or intent signals from non-health content.

The BAA reality

Google does not sign BAAs for Google Ads. This means the data processing described above — Smart Bidding signals, audience building, conversion modeling — has no compliant legal basis under HIPAA for covered entities, regardless of how carefully the tags are configured.

A server-side architecture with URL normalization reduces PHI exposure. It does not create a BAA. For healthcare advertisers running patient-facing campaigns, the fundamental question is whether Google Ads can be used at all in those contexts — not just how to configure the tags better.

It's not a tagging problem. It's a contract problem that has been deferred into a tagging problem.

If you have not done a broader audit of your measurement stack — consent gating, hardcoded scripts, vendor BAA inventory — the full healthcare tracking audit checklist covers the rest of the surface area.

The Bottom Line

The tags are working correctly. They are collecting what they were built to collect: page URLs, user identifiers, form data, behavioral signals. In any other vertical, that is the job. In healthcare, it produces PHI violations at scale without anyone doing anything deliberately wrong.

Your Google Ads account is not a patient database. But the remarketing lists, conversion signals, and Smart Bidding training data that accumulate in it tell a different story. The audit is the first step. The rest is architecture.