The Healthcare Pixel Audit Checklist Built From the FTC's Hims and Hers Complaint

The fastest way to audit a healthcare advertising stack in 2026 is to stop inventing your own checklist and borrow the one a regulator already wrote. On July 29, 2026, the Federal Trade Commission, the People of the State of California acting through Los Angeles County Counsel Dawyn R. Harrison, and the Utah Division of Consumer Protection sued Hims & Hers Health, Inc. in the Northern District of California, Case No. 3:26-cv-7871. The complaint names specific tracking technologies, specific data flows, and specific marketing promises. Read as an audit instrument rather than as news, it tells you which drawers to open. Curve is a HIPAA-compliant conversion tracking platform that lets healthcare advertisers keep measuring and optimizing paid campaigns while protected health information is stripped from events before they ever leave the advertiser's control.

Everything in the filing is an allegation. Nothing has been proven, no court has ruled, and Hims has denied the allegations, saying its privacy policy makes clear that users may choose how their data is used and that it intends to defend the case. That does not reduce the checklist's value. The FTC did not need a verdict to tell you what it looks at.

What follows is a working audit you can run with browser dev tools, tag manager access, and a few hours of contract review. It is built around the complaint's own abstraction: paragraph 67 says sharing occurred through "Events," defined as "the actions of website visitors on Hims' website." Audit at the event level and you are auditing the same object the agencies describe. For a lighter first pass, a 14-point self-assessment will tell you whether to escalate to this.

The Short Version

• Use paragraph 77 as your literal tag inventory checklist. It names fifteen tracking technologies, from the Bing Pixel to PebblePost to The Trade Desk, and the full list is reproduced in Phase 1 below.
• Audit list uploads and offline conversion imports separately. Paragraph 76 alleges Hims uploaded customer lists to Snap for matching to Snapchat accounts, a flow that never appears in a browser network tab.
• Server-side is in scope. Paragraph 70 names the Meta Pixel and the Conversions API together, describes the server-side connection accurately, and pleads it as a vector anyway.
• Intake flows and confirmation pages hold the highest-severity findings, and the URL is often the leak rather than the payload.
• Your published marketing copy is part of the audit. Paragraph 66 quotes phrases from Hims' own advertising, including television, radio, and podcast reads.
• A finding names the tag, the page, the parameter, the recipient, the volume, and the contract status.

Phase 0: Get Access Before You Go Looking for Problems

Most failed pixel audits fail here, when the auditor finds something on day one and then waits three weeks for the access needed to confirm it.

1. Publish access to every tag manager container, including subdomains, landing page builders, and legacy containers nobody has opened in a year.
2. Read access to every ad account: Google, Meta, Microsoft, TikTok, Reddit, Pinterest, Snap, and any DSP in use.
3. The CRM, EHR, or practice management system holding the customer list, plus whatever tool performs uploads.
4. The CDP, server-side tag manager, or reverse ETL tool. The highest-severity findings usually sit here, and this access is most often forgotten.
5. The vendor contract folder, including affiliate agreements, which usually live separately from martech contracts.
6. A browser profile with no ad blocker, no extensions, and a clean cookie jar.

What a Finding Actually Looks Like

Write every finding in the same shape. An unusable finding is missing the last three fields.

• Tag or integration: Meta Pixel, ID 1234567890, loaded via container GTM-XXXX, trigger "All Pages."
• Where it fires: /consultation/weight-management/step-3, plus every page matching /consultation/*.
• What leaves: the parameter and the shape of its value, for example a document location parameter carrying a URL with the path segment weight-management, alongside a hashed email address.
• Who receives it: the destination endpoint and the account it lands in.
• Volume: events per day and how long this has been true. "Since the March redesign, roughly 4,000 per day" is a different finding from "fired 12 times last week."
• Contract status: whether a BAA exists with this recipient, and whether the platform's terms permit health data. For most major ad platforms, both answers are no.
• Promise conflict: whether a published claim of yours is inconsistent with this flow. Almost nobody fills this in, and it is what paragraph 66 is about.

Rate severity by inference, not by whether a field is labeled "diagnosis." A URL path containing a condition name, sent with a stable identifier, tells the recipient that a specific person is interested in a specific condition, and that inference is what is being alleged.

Where a Sanitization Layer Changes What This Audit Finds

This audit produces two kinds of finding: tags that should not exist, and tags that should exist but send more than they should. The first is a deletion problem. The second is an architecture problem, and deleting the tag is the wrong fix because it also deletes your ability to measure. Curve sits between the site and the ad platforms and treats the event payload as the control point: events are collected first-party, sanitized server-side against a field allowlist, and only then forwarded, so identifiers and condition-revealing URL segments are removed before egress rather than filtered at a destination you cannot inspect. Destinations are configured per platform, because Google, Meta, Microsoft, TikTok, and Reddit each accept different fields, and a BAA is available covering the data Curve handles. That turns the second category of finding into a configuration review rather than a rebuild, and lets the next auditor read what was sent instead of inferring it.

Phase 1: Inventory Every Tag, Including the Ones Nobody Owns

1. Load a representative page with the network tab open, filtered to third-party requests, and record every distinct host receiving a request.
2. Repeat across at least five page types: homepage, a service page, the first step of intake, a mid-funnel step, and a confirmation page. Firing rules differ by page and the interesting behavior is rarely on the homepage.
3. List every tag in the tag manager, including paused ones and every custom HTML tag. Custom HTML is where undocumented pixels live.
4. Reconcile the two lists. Anything firing in the browser but absent from the container is hardcoded in a template, injected by a third-party script, or installed by a platform integration such as a chat widget.
5. Check specifically for each technology named in paragraph 77: Microsoft Bing Pixel and Bing Image Pixel, Google Ads Pixel and Google Ads S2S Pixel, Criteo, MediaBids.com, PartnerCentric, PebblePost.com, Pinterest, Podsights or Spotify Ad Analytics, Reddit, StackAdapt, TikTok including its server-side integration, The Trade Desk, and X.
6. Name an owner for each tag found. An unowned tag is a finding on its own, because nobody will notice when a platform changes its default parameter set.

PebblePost and MediaBids deserve a note. Direct mail retargeting and offline referral networks are not what most marketers picture when they hear "pixel," yet they appear in the same list as Pinterest and Reddit. Anything that maps a web visit to a postal address or an inbound phone lead belongs in this inventory, and the detection techniques are those of a structured PHI leakage audit.

Phase 2: Audit List Uploads and Offline Conversion Imports Separately

Paragraph 76 alleges Hims uploaded customer lists to Snap so users could be matched to Snapchat accounts. No amount of browser inspection surfaces that flow. It runs between your customer database and a platform's matching service, often executed by a person on a schedule.

1. List every audience in every ad account sourced from a customer file, a CRM sync, or a manual upload. Meta calls these Custom Audiences with a customer list source, Google calls it Customer Match, and Snap, TikTok, Reddit, and Pinterest have equivalents.
2. Determine the membership criterion. "All customers" is a very different finding from "customers who purchased a specific medication." Paragraph 74 alleges Hims could create audiences with such specificity only because it flouted its own privacy promises, a claim about the criterion rather than the mechanism.
3. Identify who produced the file and where the query lives. If a saved CRM report feeds a recurring upload, get its query text.
4. Apply the same treatment to offline conversion imports. Google offline imports and Meta offline events both carry an identifier plus a conversion label, and the label is often the service purchased.
5. Check retention. A 2023 audience built from a condition-specific segment is still live today.
6. Confirm whether any upload ran after a consent signal that should have suppressed it, a separate question from whether consent was collected.

The fix is not to abandon audiences but to seed them from behavioral and in-market signals rather than clinical attributes, an approach covered in building lookalike audiences without PHI.

Phase 3: Review Server-Side and S2S Integrations Against Paragraph 70

Paragraph 70 matters most to anyone who has already migrated server-side. It names both the Meta Pixel and the Conversions API, describing the latter as operating differently to the extent that it creates a direct connection between the advertiser's server, website, app, or other internal software and Meta's systems. The agency described the mechanism correctly and pled it as a vector regardless, and paragraph 77 separately names a Google Ads S2S Pixel and TikTok s2s. Moving the request from browser to server changes who sends the data, not what the data is, which is why server-side tracking alone is not HIPAA compliance.

1. Enumerate every server-side integration: Conversions API, Google Ads S2S or Data Manager, TikTok Events API, Reddit CAPI, Microsoft UET offline, and anything running through a server-side container.
2. Obtain an actual sent payload for each. Not the documentation, not the mapping spreadsheet, the real JSON. Most platforms expose a diagnostics view showing received fields.
3. Read every field, especially event source URL, custom data objects, content names, content IDs, and anything added to improve match rates. Match-rate optimization is the most common reason PHI reaches a server-side payload.
4. Check whether the browser tag and the server-side tag are both live. Dual firing is common after a partial migration and produces the pairing paragraph 70 describes.
5. Find anywhere your documentation treats hashing as anonymization. A hashed email is designed to be matched to a person, and is submitted for that purpose.
6. Confirm where sanitization happens. If it happens at the destination, you cannot prove it and neither can your vendor.

Phase 4: Inspect High-Risk Pages and the URLs Themselves

Intake flows concentrate the severity. A user answering questions about a condition is producing exactly the "actions of website visitors" that paragraph 67 defines as Events.

1. Walk each intake flow start to finish with the network tab recording, once per service line. Multi-service telehealth sites often have one clean flow and three built by a different team.
2. Read every URL as the recipient would. A path or query string containing a condition, medication, or service name travels in the referrer and in most pixels' default page-location parameter.
3. Check query parameters for anything reflecting a form entry. Email addresses land in URLs more often than expected, usually because a form posts via GET or a confirmation page passes state.
4. Inspect confirmation pages closely. They carry order values, product names, and identifiers at once, and they are the most heavily instrumented pages on the site.
5. Determine whether session replay runs here and whether inputs are masked at capture rather than at playback.
6. Repeat for the mobile app and any embedded webview, which often carries a different tag configuration.

Intake-specific leak points, including hidden fields, autofill behavior, and third-party form embeds, are covered in medical intake form leak points.

Phase 5: Audit Your Own Marketing Copy, Including Spoken Ad Reads

This phase is missing from every technical checklist and it is what paragraph 66 is about. The complaint quotes published phrases including "100% online, private, and secure," treating conditions "privately," "totally private," and "discreet," and notes these promises appeared in television, radio, and podcast advertising as well as on the website. The alleged violation is the gap between the promise and the practice.

1. Collect every privacy claim you publish: homepage, service pages, FAQ, privacy policy, app store listings, email footers.
2. Collect spoken claims. Pull podcast host-read scripts, radio copy, television voiceover, and influencer briefs. These are rarely reviewed by compliance and are often the strongest promises anywhere in the estate, because "totally private" reads better aloud than a qualified version.
3. Ask whether each claim is true given what Phases 1 through 4 found, not whether it is defensible in principle.
4. Flag absolute words. "Never," "100%," "totally," and "fully" turn a technical finding into a deception claim.
5. Check whether your privacy policy's disclosure of advertising sharing is consistent with your marketing copy. Hims has said its privacy policy makes clear that users may choose how their data is used, and whether a policy disclosure cures a promise made in a podcast read is one of the questions this litigation will test.

Phase 6: Check BAAs, Vendor Contracts, and Affiliate Networks

1. For every recipient identified in Phases 1 through 3, record whether a BAA exists. For major ad platforms it will not, and their terms typically prohibit sending health data at all.
2. Where a BAA does exist, read what it covers. A signed agreement does not by itself satisfy the Security Rule obligations around it, a distinction covered in why a BAA alone is not enough.
3. Pull affiliate and partner network agreements specifically. PartnerCentric and MediaBids appear in paragraph 77 alongside the ad platforms, and affiliate contracts are usually owned by a different team and never read by anyone who has seen your tag inventory.
4. Determine whether affiliates place their own tracking on your pages, and whether the agreement permits it.

Phase 7: Establish Monitoring So the Audit Does Not Expire

A pixel audit stays accurate until someone publishes a new landing page.

• Alert on any new third-party host appearing in requests from your domains. Daily synthetic checks on your five highest-risk page types catch most regressions.
• Diff the tag manager container on every publish, and require a named reviewer for custom HTML tags.
• Sample real outbound payloads on a schedule and check field names against an allowlist. An allowlist fails safe; a blocklist fails open the moment a platform adds a parameter.
• Add a privacy-claim review step to marketing approval, covering spoken scripts.
• Re-run Phase 2 quarterly. Audiences drift silently because nobody deletes them.
• Keep the finding log. The record of when you looked is what demonstrates the program exists.

Frequently Asked Questions

Does moving to the Conversions API fix a pixel problem?

Not on its own. Paragraph 70 names the Meta Pixel and the Conversions API together and describes the server-side connection accurately before pleading it as a sharing vector, and paragraph 77 separately names a Google Ads S2S Pixel and TikTok s2s. Server-side changes the sender, not the content, so the audit question stays the same: what is in the payload.

What counts as PHI in an advertising context?

The test is inference, not labels. If a recipient can connect a specific person to a specific health interest or treatment, the combination is the problem even when no field is named "diagnosis." A condition name in a URL path plus a stable identifier is the most common example, which is why Phase 4 focuses on URLs.

Is the Hims case decided?

No. It was filed in July 2026 and is being litigated, with civil penalties sought and two states as co-plaintiffs. Every statement in the complaint is an allegation. Hims has denied the allegations, says its privacy policy makes clear that users may choose how their data is used, and intends to defend the case. The redacted complaint is public on ftc.gov.

What should I fix first if the audit finds several issues?

Order by inference strength combined with volume. A condition-revealing URL firing on every intake page to a platform with no BAA outranks a low-volume tag on a blog post. Then handle anything where a published promise contradicts a live flow, because that pairing is what the complaint is built around.

This article reflects the record as of July 2026 and describes an audit method, not legal advice. The case is at the pleading stage and the allegations remain unproven.

If your audit surfaces flows you need to keep measuring but cannot keep sending as they are, that is an architecture problem rather than a deletion problem. Curve was built for that gap: first-party collection, server-side sanitization before egress, per-platform destination configuration, and a BAA covering the data it handles. See how it works at curvecompliance.com.