Customer List Uploads Are a Health Privacy Risk: The Vector Most Marketers Never Audit

Almost every healthcare privacy audit stops at the browser. Teams scan for tags, read the network tab, check the tag manager, tighten the consent banner, and declare the site clean. Then someone in the growth team exports a customer file and uploads it to an ad platform, and none of that work applies.

The Federal Trade Commission's complaint against Hims & Hers Health, Inc. puts this vector in writing. Paragraph 76 alleges that the company uploaded customer lists to Snap in order to match users to Snapchat accounts. That is not a pixel, not a tag, and not something a browser extension could ever have detected. It is a file. Curve is a HIPAA-compliant conversion tracking platform that governs what identity data may leave your systems for an ad platform, so audiences and conversion signal can be built without exporting health context along with them.

The complaint 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. Nothing in it has been proven. 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 76 alleges customer list uploads to Snap for account matching, a vector entirely separate from the pixel and server-side allegations elsewhere in the complaint.
• List uploads bypass cookie banners, browser tracking prevention, ad blockers, and every site-scanning tool, because they never touch a browser.
• Hashing identifiers before upload is not anonymization. It is a matching protocol, deliberately designed so the recipient can re-identify the person.
• The file contents are often the smaller problem. The segment definition is the disclosure, because a list is defined by why those people are on it.
• Lookalike and similar-audience expansion propagates that definition into a model you cannot inspect or recall.
• Auditing this means auditing people, permissions, and schedules, not code. Start with the audience list inside each ad account.

Three Architectures, One Theory

Read across the tracking allegations and a pattern emerges. Paragraph 67 describes sharing through "Events," defined as the actions of website visitors, and identifies two distinct vectors reaching Meta. Paragraph 70 names both the Meta Pixel and the Conversions API, the latter described accurately as a direct server-to-server connection. Paragraph 77 lists other integrations, including two labeled explicitly as server-to-server. And paragraph 76 adds list uploads.

Browser tags, server APIs, offline file transfers. Three architectures with nothing technical in common, pled together as routes by which the same allegedly sensitive information reached ad platforms. The theory does not care how the data traveled. It cares that it arrived, that it was attributable to real people, and that its arrival sat awkwardly beside published promises that conditions would be treated "privately" (paragraph 66).

That is inconvenient for the way most compliance programs are scoped. Pixel remediation has a natural owner and a natural artifact, usually a tag inventory. List uploads have neither. They are frequently performed by a person, by hand, from a laptop, into a web interface, on a cadence nobody documented.

Why This Vector Stays Invisible

Consider what a list upload does not do. It does not load a script. It does not set a cookie or generate a network request from any visitor's browser. It does not appear in a tag manager container. It is not blocked by tracking prevention, is not visible to an ad blocker, and will not show up in any automated scan of your website, which means the entire category of tooling that found the first wave of pixel problems is blind to it.

Then consider who touches it. A performance marketer building a retargeting segment. An agency with access to your ad account. A CRM administrator who enabled an audience sync integration two years ago and has not looked at it since. A reverse ETL job pushing a warehouse table into an advertising destination on a nightly schedule. In most organizations, at least one of these exists and nobody in legal or compliance knows about it.

The result is a data flow with no owner, no review, and no expiry. Put plainly: if you cannot answer "which audiences exist in our ad accounts, who created them, and what defined membership," you do not know what you have disclosed.

How List Matching Actually Works

The mechanics are similar across platforms, whether the feature is called Custom Audiences, Customer Match, or audience match. You supply a file of identifiers, typically email addresses and phone numbers, sometimes names, addresses, dates of birth, or your own customer IDs. The platform normalizes each value, lowercasing and trimming email addresses and converting phone numbers to a standard international format. It hashes them, conventionally with SHA-256. It compares those hashes against hashes of the identifiers in its own account database. Where they match, the person becomes a member of your audience.

You can perform the hashing yourself before upload, and platforms encourage it. This is genuinely useful: it means a raw email list is not sitting in a browser upload or an intermediary system in plain text. It is a real security improvement. It is not, however, a privacy transformation, and conflating the two is the mistake at the center of this whole topic.

How Curve Handles Audience and Identity Data

Curve's design assumption is that identity leaving your systems is the event worth controlling, whichever pipe it uses. Conversion events are collected first-party and sanitized on Curve infrastructure before egress, so the identifiers that reach a destination are the minimum an ad platform needs for attribution and never carry the clinical context that made the interaction sensitive. Each destination is configured on its own terms, because the fields Google Ads needs for a conversion upload are not the fields Meta needs for a Conversions API call, and a single undifferentiated pipeline is how surplus fields travel. A Business Associate Agreement is available. The practical effect is that measurement and optimization keep working while the export of health context stops being a thing an individual can do by accident on a Tuesday afternoon.

Hashing Is a Matching Protocol, Not Anonymization

A hash is a one-way function, and that fact does a lot of unearned work in compliance conversations. Three properties matter here.

• It is deterministic and unsalted by necessity. The whole point is that your hash of an address equals the platform's hash of the same address. A salt would break matching, so there is no salt. The same input always produces the same output, forever, for everyone.
• The input space is small. Every possible ten-digit phone number is ten billion values, which is trivially enumerable on ordinary hardware. Email addresses are not enumerable in the same way, but any party already holding a large address list can hash it and check for hits, which is precisely what the receiving platform does by design.
• The recipient is chosen for its ability to re-identify. You are not hashing to prevent identification. You are hashing to enable identification by one specific counterparty that holds the corresponding pre-images for hundreds of millions of accounts. Success is measured by match rate, which is a direct measure of how many people were re-identified.

Under HIPAA's framework this is pseudonymization, not de-identification. Nothing in the Safe Harbor method treats a hashed direct identifier as removed, because a code derived from the identifier is still a link back to the individual. Treat a hashed email as an email that is inconvenient to read.

The Segment Definition Is the Disclosure

Here is the part that reorients most people's thinking. Argue about the file contents all you like. The more serious exposure is usually the reason the file exists.

Suppose an audience contains nothing but hashed email addresses, no condition column, no notes, nothing clinical in any field. Now suppose that audience was built by querying customers who purchased a particular medication, or who completed an intake for a particular condition, or who booked a specific specialty appointment. Membership in that audience is the health information. The platform does not need a diagnosis field, because you told it the diagnosis when you told it who belongs.

This is why paragraph 74 of the complaint focuses on specificity. 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." Audience precision is the observable artifact. A regulator or plaintiff does not need to read your CSV. They can look at what you were able to target and reason backward.

Two aggravating factors follow from the same logic. Audience names travel with the audience, so a segment labeled after a condition or drug states the sensitive fact in plain text inside an ad account that agencies and contractors may access. And lookalike or similar-audience expansion takes a condition-defined seed and builds a model from it, which propagates the definition into a system you cannot inspect, cannot audit, and cannot meaningfully recall. Our guide to building healthcare lookalikes from in-market signals instead of patient files covers the alternatives that do not require a seed list of real patients.

Every Consent Control You Have Is Bypassed

Consent tooling operates in the browser. It governs whether scripts load, whether cookies are written, and whether events fire. A list upload originates in your CRM, warehouse, or laptop and is transmitted from your infrastructure to the platform's API. No banner is consulted, because there is no browser session to consult it in.

Work through who ends up in such a file. Customers who declined tracking on the site. Customers who deleted their cookies, used a private window, or browsed on a device with tracking prevention enabled. Customers who transacted before your consent banner was installed. Customers who submitted a Global Privacy Control signal. In every one of those cases, the browser-side control worked exactly as designed and the person was uploaded anyway. That is a difficult fact pattern to explain, because it looks less like a technical gap and more like a control being routed around. The underlying distinction between consenting to cookies and authorizing a disclosure of health information is worked through in consent management versus HIPAA authorization.

How to Actually Audit This

This audit is organizational rather than technical, and it moves fast because the evidence is sitting in interfaces your team already logs into.

• Open the audience manager in every ad account you control, including agency-managed and partner accounts. List every audience, its name, its size, its creation date, its source type, and its creator. Names alone will usually produce the first finding.
• Separate customer file audiences from website audiences. Anything sourced from a file or an integration is in scope for this review even if it looks dormant.
• Trace each one to a query. Someone defined membership. Find the segment logic, the saved report, or the SQL. If the definition references a condition, medication, procedure, or specialty, you have found a disclosure.
• Inventory the automated paths. CRM audience sync integrations, customer data platforms, reverse ETL jobs, and marketing automation connectors. Check what field mapping each one uses and when it last ran. Scheduled syncs are the ones nobody remembers.
• Check offline conversion uploads separately. These carry an identifier plus a conversion action name plus often a value, and the conversion action name is frequently the most descriptive string in your entire stack. See enhanced conversions without PHI leakage for the safe shape.
• Review who holds upload permission in each platform, and revoke it for anyone who does not need it. Then write down the approval step that must precede any future upload, because a control without a named owner is a wish.
• Confirm agreements. A Business Associate Agreement with your analytics vendor does not extend to an advertising platform receiving a file, and a signed BAA is a floor rather than a program. See why a BAA alone is not enough.

If browser-side work is also outstanding, run it in parallel using our PHI leakage audit guide. The two reviews find different problems, and finishing one says nothing about the other.

Frequently Asked Questions

Is uploading a customer list to an ad platform ever acceptable in healthcare?

The question is not the upload, it is what membership in the list reveals and what agreements govern the recipient. A list of everyone who subscribed to a general newsletter carries very different meaning from a list of everyone who filled a specific prescription. Where the segment definition encodes a condition, treatment, or care interaction, uploading it to a platform without appropriate authorization is the exposure regardless of how the file is formatted.

We hashed the emails ourselves. Does that change the analysis?

It improves security in transit and reduces the blast radius if a file is mishandled, both of which are worth doing. It does not change the privacy analysis, because the receiving platform hashes its own database identically and matches. Re-identification by the recipient is the intended outcome of the process, not a failure of it.

What about lookalike audiences? We never upload the seed to anyone else.

You uploaded the seed to the platform, which is the party that matters. The platform then builds a model from it. The seed list is a disclosure at the moment of upload, and the model is a derivative you cannot inspect or retract. Build expansion audiences from in-market and interest signals rather than from patient-derived seeds.

Can we just delete the audiences and be done?

Deleting stops future use and is the right immediate step. It does not undo the original transmission, the matching that already occurred, or any derived models. Treat deletion as containment and handle the historical disclosure as its own question with counsel.

Nobody on our team has ever done this. How would we know?

Look rather than ask. Open each ad account's audience manager and read the list. Uploads performed by a departed employee, an agency, or an integration enabled during an onboarding call are common, and none of them will surface in a conversation because nobody involved thinks of it as a data transfer.

This article reflects the public record as of July 2026. The allegations described here 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 itself.

If your pixel audit came back clean, the audience manager is the next place to look, and it is usually a shorter list with bigger findings. Curve exists to keep identity and health context from leaving your systems in the first place, sanitizing events server-side before egress, configuring each destination separately, and offering a BAA. See how it works at curvecompliance.com.