Two mechanisms, and only one of them required a decision
On July 29, 2026, the Federal Trade Commission, joined by the State of Utah and Los Angeles County, filed a complaint in the Northern District of California against Hims & Hers Health, Inc. The complaint alleges that the company shared consumers' sensitive health information with third-party advertising platforms.
Two things before we go further. These are allegations in a filed complaint. The case has not been decided, nothing here is a finding of fact, and we are not going to speculate about the outcome. Nor is this legal advice. What follows is a technical reading of the mechanisms the complaint describes, because one of them is sitting in a great many websites that have nothing to do with healthcare.
The complaint describes two distinct routes by which data allegedly reached advertising companies, and the difference between them is the reason we are writing this.
The first is customer lists segmented by health condition or treatment type, shared directly with ad platforms for targeting. Whatever you think about it, it is a series of deliberate acts. Someone built the segment. Someone exported it. Someone connected the account and pushed the upload. There is a person at every step, and every step is a decision that could have gone the other way.
The second is different in kind. It describes third-party tracking pixels and SDKs embedded on the site that automatically transmitted user actions to advertising companies, disclosing information about consumers' interactions with health-related content and services.
Nobody uploaded anything in the second mechanism. No list was built. No export ran. That is a correctly installed tag doing exactly what a correctly installed tag does.
Which means it is not really a healthcare problem. It is a URL problem, and it does not care what industry you are in.
Your URLs are sentences about your visitors
Here is what leaves the browser on an ordinary page view, before anyone configures a single custom event. The full page location including path and query string. The page title. The referring URL. Whatever click identifiers came in on the link. The cookie or storage identifier that ties this visit to previous ones and, through the platform's own graph, frequently to a person.
None of that is a setting. It is the payload. You do not switch it on and there is nothing to switch off. The tag's job is to report what page was viewed, and the page is identified by its URL.
So the question is not whether your tags send your page paths. They do. The question is what your page paths say.
Look at these the way a data broker would:
/treatment/<condition>says this person is looking into a condition./apply/<hardship-program>says this person may be in financial distress./practice-areas/<legal-matter>says this person has a legal problem of a particular kind./services/<immigration-status>says something about this person's status./support/<group>says this person identifies with, or is seeking help related to, that group.
Every one of those is a sentence about the reader, and it travels attached to an identifier. Your information architecture team wrote those paths to be readable and good for SEO, which they are. They were not writing a disclosure. But that is what the URL becomes the moment a third-party tag reports it.
Healthcare is the obvious case. It is not the only one. Financial services, legal services, immigration, addiction and recovery, fertility, HR and benefits portals, advocacy organizations, and any B2C site with a "help me with my specific situation" section all have this shape. If your URL structure describes something a visitor would not announce in a crowded room, the structure is the exposure.
The URL-structure audit, and why almost nobody has done it
This is the part you can act on today, and it is unglamorous enough that it usually gets skipped.
- Pull your top page paths by traffic. Any analytics platform will produce this in a minute. Take enough rows to cover the long tail of your templated sections, not just the first twenty.
- Read every path and mark the ones that describe the visitor. Not what the page is about, what the visit implies about the person. A pricing page describes your product. A condition page describes your reader.
- Group the marked ones by template. They will almost always come from a handful of dynamic routes, which is good news, because it means the fix is at the template level rather than page by page.
- Write it down as a list. That marked list is your actual risk surface. It is also, notably, the thing you would be asked to produce.
Most teams have never produced this list. Not through negligence. It is nobody's job. The SEO team owns URL structure, the analytics team owns the tags, the privacy team owns the policy, and the question "what do our URLs disclose about our visitors" sits in the gap between all three.
The events nobody configured
Page views are the floor. Modern measurement platforms ship with automatic collection turned on, and it captures a great deal more than a page view.
- Enhanced measurement. Scroll depth, outbound clicks, site search terms, file downloads, video engagement. On by default in the setup wizard, and the site search term in particular is free text the visitor typed.
- Form interaction tracking. Form starts and submissions, captured automatically, including on forms whose very existence is sensitive. The event says which form, and which form is often the whole story.
- Advertising platform automatic events. Several ad pixels attempt to infer and report standard events from page content and button labels without any configuration from you.
- Session replay and heatmaps. If any of these are installed, the default is to record. Masking rules exist and are usually left at defaults, and defaults do not know which of your fields are sensitive.
The common thread: in every case the default is to collect and send. You do not opt in to these. You opt out of them, if you know they exist.
Two more leaks that ride along
Even teams that clean up their paths often miss these two, because both are attached to the page rather than to the tag.
The page title. It travels with the event just like the URL does. A site can have a perfectly anonymous path and a <title> tag that spells out in plain language exactly what the anonymized path was hiding. Titles are written by content teams to be descriptive and to rank, and descriptive is the problem.
Query strings. Search parameters, filter parameters, and form state routinely carry free text the visitor typed. A site search for a condition, a symptom, a debt amount, or a case type lands in the URL as ?q= and goes out with the page location. So does anything a helpful developer appended for debugging, and occasionally an identifier that was never supposed to be in a URL at all.
The timing problem your CMP dashboard cannot see
Suppose you have all of this gated behind consent. Good. Now check when the gate closes.
A tag that fires on page load, before the consent layer has finished initializing and resolving the visitor's state, has effectively no consent layer. The request has already left. Whatever the banner decides half a second later applies to the next request, not that one. And the first request is the page view, which is the one carrying the path, the title, and the query string.
This is a race condition, not a configuration error, which is why it survives careful reviews. The consent platform's own dashboard reports that consent management is active and that categories are configured. It has no view into what fired before it woke up. Everything looks correct from inside the tool, and the only way to see the problem is to watch the network requests in order, in a clean session. We wrote about the general shape of this in Is Your Consent Banner Actually Blocking Anything?, and about the difference between a banner and enforcement in Cookie Banner vs. Consent Tool.
One more timing trap worth naming: if any part of your funnel runs on a different domain, the consent record from your main site cannot be read there at all. That is a separate mechanism with the same result, and it is covered in Your Checkout Is on a Different Domain.
The remediation ladder, cheapest first
You do not need to do all of these, and you should not start at the bottom. Work down the list until the risk on your marked pages is acceptable.
- Redact or generalize the sensitive path segment before it reaches the measurement layer. Rewrite the page location your tags report so
/treatment/<condition>is reported as/treatment/detail. You lose per-page granularity in reporting on those templates and keep the traffic count. That trade is usually easy once someone states it out loud. - Do the same for page titles. Same principle, separate field, frequently forgotten.
- Strip query parameters. Allow-list the ones you actually need for attribution and drop the rest rather than block-listing the ones you have thought of. New parameters appear without warning; an allow-list fails closed.
- Restrict which destinations receive events on marked pages. Your own analytics and your advertising platforms are not the same risk. On the marked templates, decide deliberately which tags fire at all, rather than firing everything everywhere by default.
- Gate on consent-resolved, not on page-load. Fix the race. Tags on marked pages should wait for an explicit signal that consent state is known, not fire optimistically and hope the banner catches up.
- Route through a server you control. Only after the above. Server-side tagging is the place to enforce redaction you can prove, because the transformation happens somewhere with logs and change control instead of in a browser you do not own. It is real work, though. See Server-Side Tagging: Is It Worth the Investment? before committing to it.
The first three are configuration changes that a competent tag manager owner can make in an afternoon. Start there.
The deliverable is the inventory
Set aside the case, which will take its own course and which we are not going to predict. The useful question it raises for everyone else is a simple one, and you can ask it in your next meeting.
Can we produce a document listing every tag on our site, every destination it sends to, every page it fires on, and what fields it carries?
Most organizations cannot. Not a stale spreadsheet, not a screenshot of the tag manager, an accurate current inventory. The tag list exists in one place, the page list in another, the consent configuration in a third, and nothing joins them. Which means nobody can currently answer, from documentation, what leaves the site and from where.
That document is worth building on its own merits. It makes every one of the fixes above assignable, it makes drift detectable, and it happens to be the thing you would be asked for. Confirm your own obligations with your counsel. Build the inventory regardless.
Can't produce that document today? Book a Privacy Audit or ask about Managed Privacy. We produce the inventory: every tag, every destination, every page it fires on.