What the FTC Means by Events: The Legal Unit of Harm in Pixel Cases

Buried in paragraph 67 of the Federal Trade Commission's new complaint against Hims & Hers Health, Inc. is a definition that deserves more attention than the headline. The complaint says sharing with advertising platforms occurred through "Events," and defines Events as "the actions of website visitors on Hims' website."

That is a marketing analytics term being promoted to a legal unit. The agency is not alleging that charts were leaked or that a database was breached. It is alleging that the ordinary, per-click, per-page exhaust of a website constituted the disclosure of sensitive health information. Once you accept that framing, the thing you have to audit is not your record system. It is every event your site emits. Curve is a HIPAA-compliant conversion tracking platform that inspects and strips each individual event before it leaves your infrastructure, so healthcare advertisers can send conversion signal to ad platforms without sending the health context attached to it.

The case is FTC, the People of the State of California, and the Utah Division of Consumer Protection v. Hims & Hers Health, Inc., Case No. 3:26-cv-7871 in the Northern District of California. Every claim in it is unproven. Hims has denied the allegations, says 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

• Paragraph 67 defines Events as "the actions of website visitors," making the event, not the medical record, the unit of alleged disclosure.
• A single event is a bundle: a name, a timestamp, page context, one or more identifiers, and custom parameters. Exposure comes from the bundle, rarely from one field.
• No individual component has to be health information for the event to be health information. Identity plus context is sufficient.
• "We never send names" is not a defense, because names are the one identifier ad platforms least need.
• Events are countable, which means disclosures are countable. Granularity that helps you optimize also helps a plaintiff enumerate.
• Audit at the event level, not the page level. A clean page can still emit a dirty event, and a page nobody flagged can emit dozens.

Why the Definition Is Doing Legal Work

Complaints define terms for a reason. By defining Events broadly and neutrally, the FTC avoids having to prove that any particular field contained a diagnosis. It only has to establish that visitor actions on a site about specific medical conditions were transmitted to advertising platforms, and that the company had promised those conditions would be treated "privately" (paragraph 66, quoting published claims including "100% online, private, and secure" and "totally private").

Notice how little that theory requires. It does not need a leaked prescription. It does not need a spreadsheet of patient names. It needs a set of actions, attributable to identifiable people, on pages whose subject matter is itself revealing. In telehealth, the subject matter is almost always revealing, because the site is organized by condition. That is what makes a browsing session functionally clinical.

Paragraph 74 completes the argument. The FTC alleges the company "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." Specificity is downstream of event quality. You cannot build a precise audience out of vague events. The complaint reads audience precision as evidence of what the events must have contained.

Anatomy of an Event

To audit at the event level you have to know what an event actually is. Strip away the vendor branding and nearly every tracking event, browser-side or server-side, is the same five-part structure.

• The event name. PageView, ViewContent, Lead, Schedule, Purchase, or a custom name your team wrote. Custom names are the most dangerous field on this list because nobody reviews them. An event named after an intake flow for a specific condition, or after a weight-loss medication quiz, is a diagnosis-adjacent label transmitted in plain text.
• The timestamp. Usually harmless alone, useful for correlation, and the reason a sequence of events reconstructs a journey rather than a snapshot.
• Page context. Full URL, path, query string, page title, referrer. This is the single most common carrier of clinical context in healthcare, because URLs are built to be readable and paths are built around conditions. A path that reads "/treatments/hair-loss/consultation" needs no additional parameters to be revealing.
• Identifiers. Browser cookie IDs, click IDs from ad platforms, IP address, user agent, and in server-side and enhanced setups hashed email, hashed phone, name, ZIP, date of birth, and an external ID of your own. Any one of these lets the recipient attach the event to a person or a household.
• Custom parameters. content_name, content_category, value, currency, order or transaction IDs, item SKUs, form field values captured by automatic event detection. This is where product catalogs leak. If your SKU names are medications, your purchase events are medication records.

Read that list against your own implementation and the audit stops feeling abstract. Most healthcare sites we look at have clean intentions in parts one and two, and problems concentrated in parts three and five. Our walkthrough of how to track Meta Pixel events in healthcare safely goes field by field on the browser side.

How Curve Handles Events

Curve treats the individual event as the object to be governed rather than the page or the tag. Every event is collected first-party and then inspected on Curve infrastructure, where page context is stripped of clinical detail, identifiers are reduced to what a destination actually needs for attribution, and parameters that would carry condition or product meaning are removed before anything is transmitted. Because the check runs at egress rather than in the browser, an event added by a marketer through a tag manager on Friday afternoon is governed by the same rules as one an engineer shipped in a release. Destinations are configured separately, since a Google Ads conversion upload and a Meta Conversions API call need different fields and stripping them identically leaves either signal or exposure on the table. A Business Associate Agreement is available for the arrangement.

The Combination Rule, and Why "We Don't Send Names" Fails

The most common objection to all of this is that a pixel does not send names. That is usually true and almost entirely beside the point.

Health information is information about a person's health status, care, or payment, tied to that person. The tie does not have to be a name. It has to be a handle the recipient can resolve. Ad platforms are, structurally, identity resolution companies. Their core competence is turning a cookie, a click ID, a device fingerprint, a hashed email, or an IP and user agent pair into a logged-in account they already hold a full profile for. Handing such a platform a pseudonymous identifier is not handing it a pseudonym. It is handing it a lookup key.

So the question is never whether one field is PHI. It is whether the tuple resolves. Run each event through this pair:

• Does anything in this event indicate a health status, condition, treatment, or care interaction? The event name, the URL path, the content category, the SKU, and the conversion action name are the usual carriers. Page subject matter counts even when no parameter names the condition.
• Does anything in this event let the recipient attach it to a person? If yes, and the first answer was also yes, you have transmitted health information regardless of what the field labels say.

Hashing does not break the second condition. A hashed email is a stable pseudonym computed the same way by both parties precisely so it can be matched. Treat it as an identifier, because that is the job it was hired for.

Events Are Countable, and That Cuts Both Ways

Event-level granularity is what makes modern advertising work. It is also what makes exposure enumerable. A record system has one disclosure event when it is breached. A tracking implementation has one per action, per visitor, per session, continuously, for as long as the tag has been live.

Two practical consequences follow. First, discovery is straightforward for the other side. Ad platform reporting shows event volumes by name and date. Audience definitions show what was targetable. Conversion action lists sit in the account. None of that requires access to your codebase. Second, the exposure is retrospective in a way most teams do not model. Removing a pixel today stops new events. It does nothing about events already delivered, already used to build audiences, and already retained by the recipient under its own policies.

That asymmetry is why the "we'll clean it up next quarter" posture is more expensive than it looks. Every week of delay is not a week of risk, it is a permanent addition to a count. The wider enforcement pattern, and how quickly it has moved from settlements to litigated claims with civil penalties, is laid out in our pixel lawsuit and settlement tracker.

Re-Scoping Your Audit Around Events

Most healthcare tracking audits are organized by page or by vendor. Both miss things. Pages miss events fired by single-page app routing, by scroll and timer triggers, and by third-party widgets. Vendors miss the fact that the same leaky parameter usually goes to every destination at once.

Organize by event instead. The deliverable is a single inventory with one row per distinct event name per destination, and for each row: what triggers it, which pages it fires on, every field it carries, which of those fields is clinically meaningful, which identifiers travel with it, and what marketing decision would break if it were removed. That last column is the one that ends arguments. A surprising share of healthcare events exist because someone enabled a default, not because a decision depends on them.

Three places to look first, because they are where inventories usually turn up surprises:

• Intake and quiz flows. Multi-step forms often fire a step-completion event per screen, and the screens are named after what they ask. See where telehealth intake forms leak.
• Automatic and enhanced event detection. Platform features that infer events from button text and form fields will happily transmit the label of a button that says the condition out loud.
• Analytics alongside advertising. An analytics property configured to forward audiences to an ad account turns every measured event into an advertising event. Our note on whether GA4 fits healthcare covers that path.

Consent does not dissolve the problem either, though it changes its shape. A cookie banner is a permission mechanism, not a redaction mechanism, and consenting to analytics is not the same as authorizing disclosure of health information. That distinction is worked through in consent management versus HIPAA authorization.

Frequently Asked Questions

Is a page view really considered health information?

It can be. A page view carries a URL, and on a condition-specific page that URL states the subject. Combined with an identifier the recipient can resolve to a person, the FTC's theory in this complaint treats that combination as a disclosure of sensitive health information. Whether a court agrees is an open question, but the pleading assumes it.

What if the URL has no condition in it?

Better, and not sufficient. The condition can still ride in the page title, the referrer, the content category, a product SKU, a custom event name, or a conversion action label. Clean the path and then check the other four.

Do we have to remove events entirely to be safe?

No. The goal is to transmit the fact that a conversion happened without transmitting what it was about. A generic event name, a value, and an identifier that supports attribution can be enough for optimization. The clinical context is the part that has to stop at your boundary.

How is this different from a data breach?

A breach is unauthorized access to stored data. This theory concerns intentional, engineered transmission of data you chose to send, in ordinary operation, to a commercial recipient. That is why it is pled as deception and unfairness rather than as a security failure, and why "our systems were never compromised" is not responsive to it.

Where should a small practice start?

Open your browser network tab on the three pages that matter most, read every outbound request field by field, and write down anything that names a condition or a medication. That hour usually produces the first real finding, and our PHI leakage audit guide covers what to do next.

This article reflects the public record as of July 2026. The allegations described 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 intends to defend the case.

If your event inventory does not exist yet, building it is the highest-value week your marketing and engineering teams can spend right now. Curve was built to make the result safe by default, sanitizing every event server-side before egress, configuring each ad destination on its own terms, and offering a BAA for the arrangement. See how it works at curvecompliance.com.