Healthcare Marketing Tracking: What You Can (and Can't) Send to Ad Platforms

Advocate Aurora Health paid $12.25 million to settle a class action over the Meta pixel and Google Analytics running on its website, patient portal, and scheduling app. GoodRx paid a $1.5 million FTC penalty for sharing medication and condition data with advertisers. BetterHelp paid $7.8 million. Same tracking setup that's completely normal on a Shopify store. In healthcare, it's a lawsuit.

One thing up front: I build tracking systems, I don't practice law. This is technical guidance, not legal advice — run your specific setup past healthcare counsel before you ship it.

1. Patient books online — Appointment form with a reason-for-visit field
2. Thank-you page loads — /book/fertility-consult/thanks
3. Default pixel fires — Sends the full URL, the IP address, _fbp
4. Meta gets the story — An identifiable person plus a health context
5. Server strips it — Generic booking-complete, no path, no PHI

Why is conversion tracking different in healthcare?

Because in healthcare, the data a pixel collects can become protected health information (PHI) under HIPAA, and disclosing PHI to a vendor without a Business Associate Agreement is a reportable breach. A standard Meta pixel or GA4 tag sends the page URL, the user's IP address, and identifiers like the _fbp cookie with every hit. On an ecommerce site, harmless telemetry. On a page like /oncology/appointment-confirmed, that same payload says "this identifiable person has a cancer-related appointment" — and it just landed on Meta's servers.

That's the mechanism behind the entire 2022–2024 enforcement wave. HHS and the FTC sent joint warning letters to roughly 130 hospital systems and telehealth providers in 2023, and the class action bar went to work. The lawsuits weren't about exotic hacking. They were about default pixel installs doing what default pixel installs do.

What does the HHS guidance on tracking technologies actually say now?

The current state, after a messy couple of years: tracking on authenticated pages — patient portals, logged-in scheduling, anything behind a health-plan or provider login — is treated as a PHI disclosure and effectively off-limits for third-party ad tech. Tracking on public, unauthenticated marketing pages is in much safer territory than it looked in 2023.

The timeline matters. In December 2022, HHS's Office for Civil Rights published a bulletin saying that even a visit to a public page about a specific health condition could create PHI when combined with an IP address. That reading swept in almost every hospital homepage. In June 2024, a federal court in Texas vacated exactly that part of the guidance in the American Hospital Association's lawsuit against HHS, and HHS later dropped its appeal.

So the aggressive "any condition page + IP = PHI" theory is gone. What survived:

• Authenticated pages remain fully covered. No ad pixels, no third-party analytics receiving identifiers, inside the portal or logged-in booking flows.
• Unauthenticated pages can still create PHI when the visit genuinely relates to someone's own care — a symptom-checker that collects details, a booking form with a reason-for-visit field.
• State laws and the FTC didn't go anywhere. Washington's My Health My Data Act, California's CMIA, and wiretapping-theory class actions keep their own teeth regardless of the federal guidance.

Does this apply to you if you're not a hospital?

HIPAA applies to covered entities — providers, health plans, clearinghouses — and their business associates. If you run a supplement brand, a fitness app, or a wellness coaching business, HIPAA itself probably doesn't cover you. The FTC does. GoodRx wasn't a HIPAA case; it was the FTC's first enforcement of the Health Breach Notification Rule, which reaches health apps far outside HIPAA. BetterHelp was an FTC Act case about sharing the fact that someone sought mental-health services. Covered entities have hard legal lines; health-adjacent businesses have softer ones the FTC has shown it will enforce. Either way, "the pixel guide I found was written for ecommerce" is not a defense that ages well.

What do Meta and Google themselves restrict for health advertisers?

The platforms have their own walls, separate from the law. Since January 2025, Meta restricts ad accounts it categorizes as health and wellness from sharing mid- and lower-funnel events — Purchase, Add to Cart, appointment bookings — through the pixel or CAPI. Affected accounts can still optimize on upper-funnel signals like landing page views, but the conversion events that make Advantage+ campaigns work are blocked. Plenty of borderline businesses (med spas, supplements) get swept into that categorization, sometimes wrongly, and have to appeal in Events Manager.

Google's version: its personalized advertising policy prohibits targeting people based on health conditions, so remarketing built from condition-related pages gets disapproved, and Google states plainly that its ads products aren't built to receive PHI and it won't sign a BAA for them. Same with Meta. That settles a question I get on almost every healthcare call: there's no paperwork path that makes sending PHI to an ad platform legal. None of them will take on business-associate liability. You design around it.

Public marketing pages	Booking and intake	Authenticated areas
Homepage, locations, insurance info	Appointment forms, insurance upload	Patient portal, records, messaging
Analytics and ad tags with consent	No third-party tags on the flow	Treated as a PHI disclosure
Keep condition detail out of URLs	One generic server-side conversion	No ad platform receives anything
Keep it out of event parameters too	Identifiers and health context stripped	No BAA exists to make it legal

So what can you actually track, and where?

Split your site into zones and treat them differently — that's the whole strategy.

Zone	Examples	What's workable
Public marketing pages	Homepage, locations, insurance info, general service pages	Analytics and ad tags with consent — keep condition detail out of URLs and event parameters
Condition-specific content	Symptom articles, treatment pages, "do I have X" quizzes	Gray zone. First-party analytics yes; sending those URLs to ad platforms deserves real caution
Booking and intake	Appointment forms, reason-for-visit fields, insurance upload	No third-party tags. Fire a generic server-side conversion with identifiers and health context stripped
Authenticated areas	Patient portal, records, messaging, telehealth visits	Nothing that reaches an ad platform. Full stop

The conversion event most practices care about — "someone booked" — can usually be measured as a bare fact: a generate_lead or booking-complete event with no name, no email, no condition, no revealing URL. "A conversion happened from this ad click" is a very different disclosure than "Jane Smith booked a dermatology consult." The trap: default tag setups don't make that distinction. The page URL rides along automatically, and if your thank-you page is /book/fertility-consult/thanks, you just sent the sensitive part anyway.

Layer	What sits there
Inputs	Public page views, Booking-complete event, Symptom-quiz completion, Patient portal activity
data.yourclinic.com	Allowlists events, drops condition paths and reason_for_visit, enforces consent, logs it
Destinations	GA4: booking-complete only, Google Ads: no PHI fields, Meta CAPI: health limits apply

Why is first-party server-side tracking the control point here?

Because it moves the decision about what leaves your site from the browser to a server you own. Plain-language version: normally, tags in the visitor's browser send data straight to Meta and Google — whatever the platform's script grabs, full URL, IP, cookies. Server-side tracking inserts a middle step. Events go from your site to a tagging server on your own subdomain (something like data.yourclinic.com, usually a server-side Google Tag Manager container), and that server decides what, if anything, gets forwarded.

For most of my clients the pitch is recovered signal and cheaper CPAs. In healthcare, the order flips: control first. On a browser pixel, redaction is a promise; on your server, it's an allowlist. The server layer lets you:

1. Forward only approved events — the generic booking conversion goes out, the symptom-quiz completion never does.
2. Strip or rewrite fields on every event: drop the path from condition URLs, remove reason_for_visit style parameters, redact IP where it isn't needed.
3. Enforce consent server-side, so a "reject" actually stops data from leaving instead of asking twelve browser scripts to behave.
4. Keep a log of exactly what was sent — what you'll wish you had when a privacy officer or plaintiff's lawyer asks.

The first-party part carries its own weight too. Events flow through your subdomain, so measurement stops depending on third-party scripts that ad blockers and Safari's ITP eat, and the data lands in infrastructure you control before anyone else sees it. Where tracking is allowed, you get more complete numbers; where it isn't, you have an enforcement point instead of a policy document. The hospitals that got sued didn't have one. The pixel saw everything, and everything got sent.

What about offline conversions and aggregate measurement?

Offline conversion imports are the quiet workhorse of compliant healthcare measurement. You record the ad click ID (a gclid, or Meta click data) at first touch, then later upload the bare outcome: this click became a new-patient appointment, with a value. No condition, no service line, and de-identification handled properly first — de-identification under HIPAA has a specific meaning, and hashing an email by itself doesn't get you there, so design this workflow with counsel rather than improvising. Layer on aggregate measurement — GA4's modeled conversions, geo holdouts, before/after cohorts — and you can tell whether ad spend works without narrating any patient's story to an ad platform.

This isn't tracking-but-worse. Platforms need to know that conversions happened and which clicks drove them, not what the patient was seeking.

Frequently asked questions

Is it a HIPAA violation to use the Meta pixel on a healthcare website?

On authenticated pages like patient portals, yes — HHS treats that as a PHI disclosure to a vendor without a BAA. On public marketing pages it's not automatically a violation, but pixels on booking flows or condition pages still carry real regulatory and class-action risk.

Will Google or Meta sign a BAA for conversion tracking?

No. Both state their advertising products aren't intended to receive PHI, and neither signs BAAs for ads or analytics tools. Compliant setups are designed so PHI never reaches them in the first place.

Can a medical practice track appointment bookings as conversions?

Generally yes, as a stripped-down event: a generic booking-complete conversion with no name, email, condition, or revealing URL, sent through a server-side layer that enforces those limits.

Does HIPAA apply to my wellness or supplement brand?

Usually not — HIPAA covers providers, health plans, clearinghouses, and their business associates. But the FTC's Health Breach Notification Rule and Section 5 enforcement (GoodRx, BetterHelp) reach health-adjacent businesses, so sharing health status with ad platforms without consent is still a live risk.

What is HIPAA-compliant conversion tracking?

A setup where no PHI reaches third-party ad or analytics vendors: no tags in authenticated areas, generic conversion events with identifiers and health context stripped, and a first-party server layer controlling what gets forwarded.

Does server-side tracking make healthcare tracking HIPAA compliant by itself?

No. It's the enforcement mechanism, not the compliance program. You still need the legal analysis of what may be shared — server-side tagging is how you guarantee the technical reality matches that analysis.