How a pixel becomes a privacy problem
A tracking pixel is a data feed to the ad platform: page URL, event names, and identifiers (cookies, IP address, and often a hashed email once a form is touched). On a generic e-commerce site that's routine telemetry. On a health site the same feed changes character, because the URL and events carry meaning: a visit to a GLP-1 intake, an 'add to cart' on an ED medication, a 'schedule visit' event on a mental-health page. Identity plus condition-interest, transmitted to an advertising company, is the combination the entire enforcement record is about.
The trap is that nobody decides to build this. A growth team installs the pixel sitewide for conversion tracking, the intake flow lives on the same domain, and eighteen months later a plaintiff's firm or a regulator reads the network traffic. The question to ask isn't 'do we share health data?' but 'what does the pixel actually transmit, from which pages, with which identifiers?', and almost nobody who hasn't audited it knows the answer.
The line isn't 'marketing site versus patient portal.' It's the moment identity and health-condition interest combine in a transmission to a third party that has no duty to protect it.
The enforcement record, briefly
GoodRx (February 2023) was the FTC's first Health Breach Notification Rule action: a $1.5 million civil penalty and, more importantly, a permanent ban on sharing health data for advertising, for exactly the pixel architecture described above. BetterHelp (March 2023) followed at $7.8 million in consumer refunds for sharing therapy-intake answers with ad platforms after promising privacy. Cerebral (2024) paid over $7 million across FTC claims that included pixel disclosures of patient data, and the FTC amended the Health Breach Notification Rule in 2024 to state plainly that it reaches health apps and connected sites, not just traditional health records.
On the HIPAA side, HHS's Office for Civil Rights published its online-tracking bulletin in December 2022 and updated it in 2024; a federal court then vacated part of it in mid-2024 (the portion sweeping certain unauthenticated-page visits into protected health information). Some read that ruling as an all-clear. It wasn't: it narrowed one theory against HIPAA-covered entities, while the FTC's authority over non-covered businesses, the state laws below, and the private class-action bar were all untouched.
The states then raised the stakes. Washington's My Health My Data Act, in force since 2024, covers 'consumer health data' far beyond HIPAA's scope, requires consent before collection and sharing, and carries a private right of action, and other states have followed with their own consumer-health-privacy statutes. For a telehealth brand marketing nationally, the strictest state now effectively writes the floor.
Where the line sits in practice
Sort your surfaces into three zones. Zone one: general marketing pages (home, how-it-works, pricing). Third-party pixels are defensible here with real consent gating and honest privacy disclosures, because a page view alone reveals little. Zone two: condition-specific funnels (a weight-loss landing page, an ED product page). Pixels here transmit condition-interest tied to identifiers; post-2023 this is where cautious operators start trimming what fires and what the events are named. Zone three: intake, checkout, scheduling, and anything behind authentication. No third-party ad trackers, full stop; this is the zone every enforcement action has in common.
Two structural facts make the zones non-negotiable. Ad platforms will not sign business associate agreements for pixel data, so there is no paperwork that makes Meta or TikTok a permissible recipient of protected health information. And Google states that Google Analytics is not designed for HIPAA-regulated data, so analytics on PHI-adjacent surfaces needs either a healthcare-configured setup or a privacy-first analytics tool instead.
The compliant architecture
What the clean version looks like, concretely:
- A hard boundary: no third-party ad trackers on intake, checkout, portal, or any authenticated surface. Conversion signals that cross the boundary are minimal, scrubbed, and deliberate.
- Consent before fire on marketing surfaces: a consent manager that actually blocks the pixel until opt-in, not a banner over an already-loaded tracker.
- Event hygiene: generic event names and URLs in anything transmitted (no 'glp1-intake-step-3' reaching an ad platform), and no form-field capture features enabled.
- Server-side conversion feeds treated as the same legal act as a pixel: moving the transmission to your server changes the engineering, not the privacy analysis. What matters is what data leaves, not which machine sends it.
- A written tracker inventory: every tag, what it collects, from which zones, under what consent, reviewed whenever marketing adds a tool. The unreviewed tag-manager container is where violations breed.
- Privacy policy and consent language that describe what actually happens, because the FTC's cases were as much about broken promises as about the sharing itself.
Audit yourself before someone else does
The check takes an afternoon: open your site with the browser's network panel, walk from the home page through a condition funnel into intake, and record every third-party request and its payload. Then compare what you found against what your privacy policy claims. The gap between those two documents is your exposure.
Our free Preflight scanner automates the first pass: it detects ad-platform trackers on the pages it crawls and flags placement that certification reviewers and regulators read as high-risk, alongside the claims and disclosure checks. Embed Care's own stack is built to the architecture above (ad pixels behind consent on marketing surfaces only, and no PHI collected on the marketing site at all), because we run certified brands and their programs on the same rails we sell.
Run the network-panel walk quarterly and after every marketing-stack change. Every enforcement action started with traffic anyone could have inspected at any time, and nobody inside had.
Frequently asked
- Can I use the Meta pixel on a telehealth website at all?
- On general marketing pages, behind real consent, with hygienic events: defensibly yes as of August 2026. On intake, checkout, or anything authenticated: no. The enforcement actions all involve identity plus health-condition data reaching ad platforms, and pixels on care-adjacent surfaces are exactly that.
- Is Google Analytics HIPAA compliant?
- Google itself says Google Analytics isn't designed for HIPAA-regulated data and won't sign a BAA for it, so it doesn't belong on surfaces handling PHI. Marketing-page analytics with IP anonymization and consent is a different, defensible question; many health brands also switch to privacy-first analytics tools to simplify the answer.
- Didn't a court strike down the HHS pixel guidance?
- A 2024 federal ruling vacated part of the OCR bulletin as applied to certain unauthenticated pages, for HIPAA-covered entities. It didn't touch FTC authority (GoodRx, BetterHelp, Cerebral), state health-privacy laws like Washington's, or class-action exposure. Architecture that depends on that ruling is architecture with one load-bearing court decision.
- Does moving to server-side tracking (CAPI) fix the problem?
- No. Server-side conversion APIs change the transport, not the disclosure: if condition-revealing events tied to identifiers reach the ad platform, the privacy analysis is the same as a pixel. Server-side is useful because it gives you a chokepoint to scrub and minimize, not because it launders the transmission.
Want pricing for your program, and the Rx menu that goes with this?
The partner overview in one email; a human follows up with pricing scoped to your program.