The Meta Pixel and Conversions API in the FTC's Hims and Hers Case: What Healthcare Advertisers Should Learn

The most important line in the FTC's July 2026 complaint against Hims & Hers Health, Inc. is not about the Meta Pixel. It is about the Conversions API sitting right next to it. In paragraph 70, the agency names both tools, and it describes the Conversions API correctly, noting that it operates differently "to the extent it creates a direct connection between the advertiser's server, website, app or other internal software and Meta's systems." The FTC understood that this is server-side infrastructure, and it pled the conduct as a violation vector anyway.

That should end a long-running argument in healthcare marketing. Moving a tag from the browser to a server changes the transport. It does not change what is inside the payload, and the payload is what regulators read. Curve is a HIPAA-compliant conversion tracking platform that lets healthcare advertisers run and optimize Meta campaigns while protected health information is stripped before anything is transmitted to Meta, on either the browser path or the server path.

The case is Federal Trade Commission; The People of the State of California; and Utah Division of Consumer Protection v. Hims & Hers Health, Inc., Case No. 3:26-cv-7871 in the Northern District of California. Everything below is an allegation. Nothing has been proven. Hims has denied the allegations, has said its privacy policy makes clear that users may choose how their data is used, and has said it intends to defend the case.

The Short Version

• Complaint paragraph 70 names the Meta Pixel and the Conversions API together, as two mechanisms for the same alleged disclosure.
• The FTC described server-side transmission accurately and still treated it as a sharing vector, which undercuts the idea that a server-side deployment is a compliance control on its own.
• Paragraph 67 defines the shared "Events" as "the actions of website visitors on Hims' website," which means the behavior itself, not just form fields, is the alleged sensitive signal.
• Hashing is not de-identification. A hashed email is a stable identifier whose entire purpose is to match a specific person inside Meta's systems.
• Paragraph 74 alleges that audience precision was only possible because privacy promises were flouted, which links the targeting output back to the data intake.
• The audit that matters is not "is the pixel installed," it is "what exactly leaves, on every path, including the ones marketing does not own."

What the Complaint Actually Alleges About Meta

Paragraph 66 sets the stage by quoting the promises Hims published. According to the complaint, the company told consumers its service was "100% online, private, and secure," that it treats conditions "privately," that the experience was "totally private" and "discreet." The FTC notes those promises ran in television, radio, and podcast advertising as well as on the website. The agency then alleges that sensitive health information was nonetheless shared with third-party advertising platforms.

Paragraph 67 is the definitional one. The complaint says the sharing happened through "Events," which it defines as "the actions of website visitors on Hims' website." Read that carefully, because it is broader than most compliance reviews assume. The alleged sensitive disclosure is not limited to a diagnosis typed into a field. It includes the fact that a specific identified visitor viewed a particular page, started a particular intake, or completed a particular checkout. In a condition-specific telehealth funnel, the action is the diagnosis by implication.

Paragraph 70 then names the two Meta mechanisms. The Meta Pixel is the browser-side tag. The Conversions API is the server-side channel. The complaint puts them in the same sentence because, from the FTC's perspective, they accomplish the same thing: they deliver identified event data to an advertising platform. Paragraph 74 closes the loop on why any of it mattered commercially, alleging that Hims "was only able to create audiences with such specificity because it flouted the promises it made to its users about treating their medical conditions 'privately' or keeping their health information private."

Paragraph 78 addresses knowledge, pointing to Hims SEC filings going back to 2021 that acknowledged privacy and consumer-protection regulatory risk, and to a Civil Investigative Demand the FTC issued in October 2023. The agency is building a record that the risk was understood internally well before the filing.

How the Meta Pixel Actually Transmits Event Data

To evaluate your own exposure you need to know what the browser tag sends without anyone configuring it to. The Meta Pixel loads a script that establishes a queue, usually reached through the fbq function. On initialization it fires a PageView and, from that moment, every event it sends carries a standard envelope.

That envelope includes the full page URL where the event fired, the referring URL, the user agent string, the IP address as seen by Meta, and the first-party browser cookies the pixel sets and reads. Those cookies are the identity spine. One is a browser identifier that persists across sessions on your domain. The other captures the click identifier appended when a user arrives from a Meta ad, which ties the visit to a specific ad click.

On top of the envelope sit the event name and its parameters. Standard events such as Lead, CompleteRegistration, Subscribe, and Purchase carry custom data objects that commonly include content names, content categories, product identifiers, and values. In a telehealth build, those fields are where the treatment or condition tends to appear, because engineering populated them from the same catalog that powers the product pages.

Then there is advanced matching. In its manual form, the site passes identifiers such as email, phone, name, city, state, and ZIP into the pixel, hashed in the browser before transmission. In its automatic form, the pixel can be configured to scan form fields on the page and collect those same identifiers without a developer writing a line for it. Automatic advanced matching is a setting, and settings get toggled by people who do not attend compliance reviews. It is one of the most common sources of surprise findings in a pixel audit that hunts for PHI leakage.

How the Conversions API Transmits the Same Thing

The Conversions API replaces the browser hop with a server request. Your backend, or a server container, or a hosted gateway, sends a POST to Meta's graph endpoint for a given dataset. The body carries an event name, an event time, an action source, an event source URL, a custom data object, and a user data object.

The user data object is the part that matters. It accepts hashed email, phone, first and last name, city, state, ZIP, country, date of birth, gender, and an external identifier of your choosing, plus two values that are not hashed at all: the client IP address and the client user agent. It also accepts the same browser cookie values the pixel sets, so server events can be stitched to browser events, with a shared event identifier handling deduplication.

Set that list against the pixel's. The server path can carry more identity, not less. It is not throttled by browser privacy controls, it is not visible in a network tab, and it does not appear in the tag inventory marketing keeps. The argument that server-side deployment equals HIPAA compliance gets it backwards. Server-side gives you a place to enforce controls. It does not enforce them for you.

Why hashing does not solve the problem

The standard reassurance is that identifiers are hashed with SHA-256 before they leave, so no personal data is transmitted. This misreads what hashing does here. The hash is deterministic and the normalization rules are published, which means the same email produces the same hash for every advertiser on the platform. That is the design goal. Matching works precisely because the hash is a stable, portable identifier for one human being.

Under HIPAA the question is not whether a value looks scrambled. It is whether the information can identify an individual, and a hash built specifically to identify an individual inside a third-party system does not stop being an identifier because it is unreadable to you. Pair it with an event that implies a condition and you have transmitted a linkage, whatever the encoding.

How Curve Handles Meta Tracking on Both Paths

Curve sits between your site and Meta rather than alongside it. Events are captured first-party, then sanitized on Curve's servers before any egress, so identifiers and condition-revealing parameters are removed or replaced at the point of transmission rather than being trusted to a tag setting a marketing hire can flip. The Meta destination is configured explicitly: you decide which events go, and what each one carries, per platform, rather than inheriting whatever the tag collected by default. Because the browser path and the Conversions API path are both routed through the same sanitization layer, there is no second door that skips the rules. Curve offers a Business Associate Agreement, which puts the tracking vendor inside the covered entity's compliance perimeter instead of outside it.

Meta still receives what it needs for optimization, meaning that a conversion happened, when, and which click it belongs to, without the payload that makes a complaint paragraph write itself. The underlying reasoning is laid out in whether the Meta Pixel or the Conversions API is ever HIPAA-safe.

What Healthcare Advertisers Running Meta Should Check This Week

The complaint is a decent checklist if you read it as one. These are the specific things worth pulling up.

• Event source URL on every event, on both paths. If your URLs contain condition names, treatment names, or intake step identifiers, the URL alone is the disclosure. Server-side does not fix it, because the server dutifully forwards the same string.
• Custom data parameters. Open the payload for your Lead, Subscribe, and Purchase events and read every key and value. Content names populated from a product catalog are the usual offender in telehealth.
• Automatic advanced matching. If it is enabled at the dataset level, the pixel may be harvesting form fields on intake pages you never intended to instrument. See which Meta Pixel events can be tracked safely in healthcare.
• Custom conversions defined by URL rules. A custom conversion whose rule is a URL containing a condition name is a standing instruction to Meta about what that page means.
• Every writer to the dataset. Datasets accept events from browser tags, server containers, hosted gateways, partner integrations, platform connectors, and offline uploads. Marketing usually knows about one or two of those, and agency partners with dataset permissions can add more without appearing in your change log.
• Custom audiences and their names. An audience named after a condition is a disclosure at the account level, before a single event fires. Paragraph 74 makes the audience layer part of the FTC's theory, and the alternative is covered in building healthcare lookalike audiences without PHI.

Why the FTC Treated the Two Tools as Equivalent

Consumer protection law does not have a transport layer. Section 5 of the FTC Act asks whether a representation was deceptive and whether a practice was unfair. If a company promised that a health condition would be treated privately, and identified event data describing that condition went to an advertising platform, the mechanism is a footnote. Whether the bytes traveled from a browser or from a server changes nothing about the consumer's expectation or the platform's receipt.

The same logic applies under HIPAA. The Privacy Rule governs uses and disclosures of protected health information. It does not distinguish between disclosures made by JavaScript and disclosures made by a cron job. The one thing server-side genuinely provides is a chokepoint you control, which is why it is a necessary component of a compliant architecture and a useless one by itself.

Against the precedent line, the escalation is the story. GoodRx settled in February 2023 for $1.5 million and BetterHelp in March 2023, ultimately at $7.8 million, both without litigation. The Hims matter is being litigated, seeks civil penalties, and carries two state co-plaintiffs. That is escalation rather than repetition.

Frequently Asked Questions

Does the FTC complaint say the Conversions API is illegal?

No. It alleges that Hims used the Conversions API, alongside the Meta Pixel, to share event data that the FTC characterizes as sensitive health information, in tension with published privacy promises. The tool is not the violation. The contents of the transmission and the promises made about them are what the complaint targets. Hims has denied the allegations and intends to defend the case.

If I move my Meta tracking server-side, am I HIPAA compliant?

Not by that step alone. Paragraph 70 is the clearest available signal that regulators understand server-side architecture and will treat it as a disclosure path when the payload carries identified health information. Server-side gives you a single point where sanitization can be enforced, which is valuable, but the enforcement has to actually exist and be verified against real outbound payloads.

Is a hashed email safe to send to Meta from a healthcare site?

Treat it as an identifier, because that is what it functions as. Hashing is deterministic and standardized specifically so the value can be matched to a person in the platform's system. When that identifier travels with an event that implies a condition, you have created a linkage between a person and their health status in a third party's hands, which is the thing the rules are about.

Can I keep running Meta ads for a condition-specific service line?

Yes, if the measurement layer is built so the platform learns that a conversion happened without learning who converted or what for. That usually means removing condition context from URLs and event parameters, dropping direct identifiers before egress, and consolidating conversion actions so the naming itself is not descriptive. Practical removal steps are covered in the guide to removing or replacing the Meta Pixel in healthcare.

What is the fastest way to find out if I have this problem?

Capture the actual outbound payloads rather than reading the configuration. Open a real intake flow, record what the browser sends to Meta, then pull the request bodies your server sends to the Conversions API for the same session, and read every field. Configuration documents describe intent. Payloads describe what is happening.

This article reflects the record as of July 2026, based on the redacted complaint e-filed on ftc.gov. The allegations are unproven, and Hims has denied them, stated that its privacy policy makes clear that users may choose how their data is used, and said it will defend the case.

If you run Meta campaigns for a healthcare or telehealth brand and cannot currently produce the exact payload your pixel and your Conversions API integration send on an intake completion, that is the gap worth closing before anyone else asks. Curve was built for exactly that boundary, keeping conversion signal flowing to Meta while protected health information stays on your side of the line. See how it works at curvecompliance.com.