Tracking Pixels and Health Data: The FTC/HHS Enforcement Theme and How to Kill the Leak

The enforcement theme of the last three years is not a novel legal theory. It is a marketing tag, dropped onto a page about a health condition, quietly posting what the visitor is looking at to an advertising network.

Most writing on this subject frames it as a privacy-law problem for lawyers to argue about. It is not, primarily. It is an architecture problem: a third-party script executing in your users’ browsers, with access to the page they are on and the identifiers riding in their cookies, sending both to a company whose business is targeted advertising. The regulators worked that out. The fix is technical, and it lives in the browser, not in the privacy policy.

What the regulators actually did

Two agencies moved, on two different legal footings, and the combination is what makes this hard to shrug off.

The Federal Trade Commission ran the enforcement. In February 2023 it settled with GoodRx for a 1.5 million dollar civil penalty, its first case under the Health Breach Notification Rule, for disclosing personal health information to Meta, Google and others without consent. A month later, in March 2023, it settled with the online therapy provider BetterHelp for 7.8 million dollars, this time under Section 5 of the FTC Act, over the sharing of mental-health intake data for advertising. The mechanism in both cases was the same: tracking pixels and SDKs handing user data to ad platforms.

The Department of Health and Human Services moved on the covered-entity side. Its Office for Civil Rights issued a bulletin in December 2022, updated in March 2024, telling HIPAA-covered entities that IP address plus a visit to an unauthenticated page about a specific condition could amount to protected health information. In July 2023 the FTC and OCR jointly wrote to roughly 130 hospital systems and telehealth providers, warning them about exactly this. The regulators do not agree on everything, but they agreed to send that letter together.

One caveat matters, and pretending otherwise would be dishonest. In June 2024, in American Hospital Association v. Becerra, a federal court in Texas vacated the bulletin’s most aggressive position, the treatment of IP address combined with an unauthenticated page visit as PHI. OCR withdrew its appeal in September 2024. That narrows the HIPAA theory for public-facing pages. It does nothing to the FTC’s authority, nothing to the Health Breach Notification Rule, and nothing to the state consumer-health-data statutes now in force. The exposure is still live; one of its legal supports simply got weaker.

Why this keeps happening

Nobody decides to leak health data to an advertiser. It happens because tag deployment is decoupled from engineering review. A marketing team adds a conversion pixel through a tag manager to measure a campaign. The pixel, by design, reads the page URL and the first-party identifiers in the browser and posts them to the network. If the page is /conditions/diabetes/treatment, the URL itself is the disclosure. Add a form that auto-populates an email into the ad platform’s advanced-matching parameters, and you are transmitting a hashed identifier alongside a health context, without a single line of that appearing in a code review.

The governance failure is that the people who can add a tag are not the people who understand what the tag sends, and there is no gate between them. Closing the exposure means being able to answer one question on demand: what leaves the browser, to whom, carrying what. If you cannot answer that today, you have the same gap GoodRx and BetterHelp had.

Find the leak before a regulator does

Start by observing your own site the way an auditor would, from inside a real browser session. The script below drives a headless browser to a target page, captures every outbound request to a third-party host, and flags any payload carrying a known identifier, a condition term or something that looks like an email. Run it against your health-adjacent pages and you get a factual inventory of what your tags actually transmit, rather than what the tag manager claims.

// pixel-leak-audit.mjs — data-flow audit for outbound tag payloads.
// Loads a page, captures third-party requests, flags PII/PHI.
// Run: node pixel-leak-audit.mjs https://example.com/conditions/diabetes
import { chromium } from 'playwright';

const target = process.argv[2];
if (!target) { console.error('usage: node pixel-leak-audit.mjs <url>'); process.exit(1); }

const firstParty = new URL(target).hostname.replace(/^www\./, '');

// Values that must never leave the browser to an advertising network.
const identifierKeys = /(_fbp|_fbc|fbclid|_ga|_gid|gclid|\bem\b|\bph\b|external_id|client_id|user_id)/i;
const conditionTerms = /(diabetes|pregnan|hiv|oncolog|mental[-_ ]?health|therapy|addiction|fertility)/i;
const emailLike     = /[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}/;

const findings = [];
const browser = await chromium.launch();
const page = await browser.newPage();

page.on('request', req => {
  const host = new URL(req.url()).hostname.replace(/^www\./, '');
  if (host.endsWith(firstParty)) return;              // ignore first-party calls
  const haystack = req.url() + ' ' + (req.postData() ?? '');
  const flags = [];
  if (identifierKeys.test(haystack)) flags.push('identifier');
  if (conditionTerms.test(haystack)) flags.push('condition');
  if (emailLike.test(haystack))      flags.push('email');
  if (flags.length) findings.push({ host, method: req.method(), flags });
});

await page.goto(target, { waitUntil: 'networkidle' });
await browser.close();

if (findings.length === 0) {
  console.log('No PII/PHI detected in third-party payloads.');
} else {
  console.log('Potential leaks to third parties:');
  for (const f of findings) console.log(` ${f.host} [${f.method}] ${f.flags.join(', ')}`);
  process.exitCode = 1;                                // fail a CI gate on any hit
}

The regex lists are deliberately short; extend them to your own condition taxonomy and the identifier keys your ad platforms use. The point is not the specific patterns. It is that the check runs, produces a list, and exits non-zero when it finds something, so it can sit in a pipeline rather than in a quarterly review that never happens.

Stop it, then stop it coming back

Detection tells you where you stand. Three controls keep you there.

• Govern tag deployment. Tags that touch health-adjacent pages go through review, not through a marketing self-service console. A Content Security Policy that allow-lists script origins turns “anyone can add a pixel” into a change that has to pass a gate.
• Strip the payload, not just the tag. Where a pixel is genuinely needed, route it server-side and redact the URL path and any identifiers before forwarding. The advertiser gets a conversion count; it does not get the condition the user was reading about.
• Prevent regression. Put the audit in continuous integration against your sensitive routes, so a re-added tag fails the build rather than surfacing in a warning letter.

This is the same discipline that the revised Health Breach Notification Rule now assumes of any app handling health data, and that Washington’s My Health My Data Act extends well beyond regulated healthcare to anyone processing consumer health data. If your business touches the EU as well, the browser-side data flow is the same object the GDPR enforcement pattern scrutinises, under a different name.

The firms that got fined were not reckless. They ran a tag they did not read, on a page that meant more than they realised. The distance between them and a defensible position is one script and a gate.