On this pageJump to a section
On July 29, 2026, the FTC filed a complaint that every telehealth operator running Meta ads should read twice.
The Federal Trade Commission, the State of Utah and the State of California went after Hims & Hers. The core allegation is simple: health information from Hims customers allegedly ended up with advertising platforms, including Meta and Snap, through customer lists and website tracking technology. The same company allegedly told those customers their information was private.
These are allegations. The court will decide the case.
But you do not need a verdict to read the signal. The question regulators are now asking is not "did you run ads." It is "what did your ad stack learn about your patients."
If you run paid acquisition for a GLP-1, TRT, HRT or wellness clinic, this is your telehealth pixel compliance moment. Here is my view from inside the accounts.
What did the FTC allege against Hims & Hers?
The FTC alleges that Hims shared consumers' health information with advertising platforms in two ways: by uploading lists of certain customers, and through third-party tracking technologies on its website that transmitted user actions to Meta and Snap. The complaint also alleges deceptive privacy promises, charging consumers at intake without clear disclosure, and making cancellation difficult.
You can read the FTC announcement here.1
Notice the two mechanisms. Customer lists. Tracking technology.
Those are not exotic tools. They are the two tools almost every clinic I have looked at uses every single day.
Why does this matter if you are not Hims & Hers?
Because the mechanisms are the same at $50,000 a month and at $50 million a month. A national brand gets the headline. A regional clinic gets the same exposure with less legal budget to absorb it.
This is also not the first time. In 2023 the FTC took action against GoodRx and BetterHelp over health data shared with advertising platforms. The pattern is consistent. The enforcement keeps arriving, and it keeps landing on the plumbing, not the creative.
Here is the uncomfortable part.
Most clinic ad stacks were built for speed, not separation. Someone installed the pixel, turned on every recommended setting, named the events after the funnel, connected the CRM, and started scaling. It worked. Nobody went back to ask what Meta was actually receiving.
I have opened accounts where the event name alone told Meta the patient's treatment. That is not a tracking setup. That is a disclosure.
Where does health data leak in a telehealth ad stack?
Health data usually leaks through names, URLs, parameters and audiences, not through one obvious mistake. Each piece looks harmless alone. Combined with an identifier, it becomes a profile.
The leak points I check first:
Event names. "GLP1_Intake_Complete" or "TRT_Quiz_Submitted" tells the platform the treatment interest of the person who fired it.
Page URLs and query strings. A results page at /weight-loss/qualified?bmi=34 is data. So is a thank-you page that includes the medication in the path.
Custom parameters in the Conversions API. Server-side does not mean safe. If the payload carries a symptom, a product or an intake answer, it still arrives.
Customer lists and audiences. An uploaded list of "active semaglutide patients" or a lookalike seeded from it tells the platform who is in treatment. That is exactly the mechanism named in the complaint.
Automatic event detection. Meta can detect button clicks and form submissions on its own. On a clinic site, you need to know what it is picking up before it picks it up.
"HIPAA compliant" connectors. A vendor label does not change what lands on the other side. The destination matters more than the transport.
CRM stage names synced back to Meta. If your pipeline stages are named after conditions or drugs, and those stages feed optimization events, the stage name travels with them.
If any of those are true in your account, you do not have a reporting problem. You have an architecture problem.
What is an attribution firewall?
An attribution firewall is a deliberate boundary between what your ad platforms receive and what your clinical systems hold. Meta gets business outcomes. Your clinical layer keeps health context. Nothing crosses that line by default.
- Clinical layerSymptoms, eligibility, medication history, provider notes
- Firewall ruleOnly fields on the approved list leave the stack
- Advertising layerNeutral outcome events: a lead, a consult scheduled, a purchase
- Ad platformLearns from business outcomes only
I build it as three layers.
The advertising layer. Generic, outcome-level events only. A lead happened. A consult was scheduled. A purchase occurred with a value. Neutral event names. Neutral URLs. The minimum identifiers your counsel approves.
The clinical layer. Symptoms, eligibility answers, medication history, labs, provider notes, patient status. This lives in your clinical and intake systems and never feeds an ad platform, an audience or an optimization event.
The firewall rule. Every field that leaves your stack for an advertising destination is on an approved list. If it is not on the list, it does not leave. New fields require a review, not a guess.
That last rule is the one most teams skip. It is also the one that keeps you safe when someone on the team adds a new form field six months from now.
How do you keep Meta optimization performance without health data?
You keep performance by optimizing on clean outcomes and real revenue instead of on health context. The algorithm does not need to know why someone booked. It needs reliable signal that they did, and what that customer was worth.
This is where most operators get nervous. They assume privacy costs them performance.
In my experience the opposite is usually true. Clean, consistent, outcome-level signal trains the algorithm better than a messy stack of twenty custom events nobody maintains. I have written about what disciplined architecture does to cost per consult in GLP-1 consult calls for $11 and a 50% show rate, and about why demand is rarely the bottleneck in Telehealth Can't Scale Without AI-Led Operations.
I won't hand you my event map. That is the IP. But the principles are not secret:
- Optimize on scheduled consults and collected revenue, not on intake answers.
- Name every event after the business action, never the treatment.
- Keep URLs and page paths neutral at every step a pixel can see.
- Build audiences from outcomes your counsel has approved, never from treatment status.
- Reconcile platform numbers against your CRM and payment processor before you trust them.
When I see a clinic scale too fast without this foundation, it breaks somewhere else first. Usually operations. I broke down one of those collapses in How Scaling Broke a $500k/mo Telehealth Business in 18 Days. Compliance debt behaves the same way. It stays quiet until volume makes it loud.
A 30-minute telehealth pixel self-audit you can run this week
You can find most of the risk in half an hour with Events Manager, your site and your CRM open side by side. You are not fixing anything yet. You are building the list.
- Export every active event name in Events Manager. Flag any that reference a condition, drug, symptom or treatment.
- Click through your funnel as a patient. Write down every URL a pixel can see. Flag any path or query string with health context.
- Open one real Conversions API payload. Read every parameter. Flag anything beyond what your counsel approved.
- List every custom audience and its source. Flag any built from treatment status or patient lists.
- Check whether automatic event detection is on for each pixel and dataset.
- Read your CRM stage names. Flag any that would reveal health information if synced to an ad platform.
- Ask your vendors, in writing, exactly which fields they send to Meta and where.
If your list is empty, good. Document that you checked, and when.
If your list is not empty, do not panic and do not rip everything out on a Friday afternoon. Pausing tracking abruptly can wreck delivery. Prioritize by exposure, fix in order, and have counsel review it before and after.
This is not legal advice. I build revenue systems. Your attorney decides what is permitted for your specific clinic, your states and your data. Bring them this list.
The floor that lets you scale
I have spent years inside the accounts of clinics that grew fast. The ones still standing were rarely the ones with the cleverest ads. They were the ones whose systems could carry the weight.
Compliance is not a brake on growth. It is the floor you build growth on.
The operators who treat this as architecture now will spend the next year scaling. The ones who treat it as paperwork will spend it explaining.
If you run paid acquisition for a telehealth clinic and want a second set of eyes on your stack, start here.
Keep building.Ekai
Questions people ask
Is the Meta pixel safe to use on a telehealth website?
It can be part of a responsible setup, but only if what it sees is controlled. Meta's own business tools terms prohibit sending it sensitive health information. The pixel should only see neutral pages and fire neutral, outcome-level events, and your counsel should approve the configuration.
Does server-side tracking or the Conversions API make a clinic compliant?
No. Server-side changes how data travels, not what arrives. If a Conversions API payload carries a condition, medication or intake answer, the platform still receives it. Compliance depends on the fields you send, not the pipe you send them through.
What should telehealth conversion events be named?
Name events after the business action, such as Lead, Schedule or Purchase, never after the treatment, symptom or product category. A neutral name keeps optimization working without telling the platform why someone converted.
Can a clinic still build Meta custom audiences?
Only with care. The Hims & Hers complaint specifically alleges that customer lists shared health information. Avoid any audience whose membership implies a condition or treatment, and have counsel approve every list source before it is uploaded.
Did Hims & Hers lose the FTC case?
Not as of this writing. The FTC filed a complaint with Utah and California, and the FTC states that the case will be decided by the court. Treat it as a strong enforcement signal, not a final ruling.
Sources
- 1
