The X (Twitter) Pixel and Health Information: Named in the FTC's Hims and Hers Complaint

The X pixel, still known to most marketing teams as the Twitter pixel, appears in paragraph 77 of the FTC's complaint against Hims & Hers Health, Inc., filed in late July 2026 in the Northern District of California as case 3:26-cv-7871. It sits among trackers the FTC alleges were placed on Hims platforms, alongside Bing, Google Ads, Criteo, Pinterest, Reddit, TikTok, The Trade Desk and StackAdapt. What makes X different is not how its tracking works. It is who was watching it. In a great many healthcare stacks the X pixel is a leftover: installed for a campaign that ran years ago, paused when budget moved elsewhere, never removed from the tag manager.

Curve is a HIPAA-compliant conversion tracking platform that lets healthcare advertisers measure paid campaigns across every ad network they use, including X, without sending protected health information to the ad platform. That matters here because the fix for an orphaned tracker is not only deletion. It is having one governed path for conversion data so no team can quietly add a fourteenth one.

Everything in the complaint is an allegation. Nothing has been proven, the case is being litigated rather than settled, and Hims has denied the allegations, stating that its privacy policy makes clear that users may choose how their data is used and that it intends to defend the case.

The Short Version

• X (formerly Twitter) is named in paragraph 77 of the FTC's July 2026 complaint against Hims & Hers, among pixels allegedly placed on Hims platforms that shared Events, defined in paragraph 67 as the actions of website visitors.
• The X pixel is a single universal website tag that fires page views automatically and reports named conversion events. It also supports a click identifier, twclid, and customer list uploads for audience matching.
• Legacy and orphaned pixels are their own risk category. A paused ad account does not stop a pixel firing, and whoever installed it has often left.
• Server-side does not fix this. Paragraph 70 describes server-to-server tracking accurately and pleads it as a violation vector anyway.
• The audit question is not which pixels you run. It is which pixels are on the page, which is a longer list.
• Hims denies the allegations and intends to defend. No court has ruled.

Why an Ad Platform Most Health Brands Stopped Using Is in a 2026 Federal Complaint

The structure of the allegations matters more than any single tracker. Paragraph 66 quotes marketing language Hims published about being "100% online, private, and secure," about treating conditions "privately," about being "totally private" and "discreet." Paragraph 67 defines the mechanism: sharing occurred through Events, meaning the actions of website visitors. Paragraph 77 is the catch-all list, and X is in it. The theory is not platform-specific. The FTC is not alleging that X did anything wrong. It is alleging that a company promising discretion about erectile dysfunction, hair loss, mental health and weight management medications routed visitor behavior on those product pages to a long roster of advertising companies. X is on that roster because it was on the page.

That is why the orphaned pixel deserves its own treatment. A tag that fires but has no owner produces the same data flow as a tag under active management, with none of the oversight. Nobody reviews its event configuration, nobody notices when a new landing page inherits it, nobody asks whether it should have been removed when the campaign ended. If a plaintiff's expert loads your condition pages and captures outbound requests, an abandoned tracker looks identical to a deliberate one.

How X Conversion Tracking Actually Works

One tag, many events

X consolidated its tracking into a single Universal Website Tag. It loads one JavaScript file from X's ad domain, initializes with a short base-36 pixel identifier, and from then on reports page views without further configuration. Conversion events layer on top, each keyed to an event identifier created in the X Ads interface and fired on the relevant page or through a tag manager trigger.

Two properties matter for healthcare. First, the base tag is automatic: once present sitewide, every URL a visitor loads is reported, including condition pages, symptom quizzes, intake steps and post-consultation confirmations. There is no per-page opt-in. Second, event identifiers are opaque. An event called tw-abcde-fghij tells a reviewer nothing, while teams routinely name the same conversion descriptively in the platform interface, which is how a label like "ED Consult Started" ends up sitting in an ad account.

Parameters and the payload question

Conversion events on X accept an optional parameter object designed for commerce values: a value, a currency, an item count, a content identifier, and optionally hashed contact fields for matching. Nothing in that schema requires health data. Exposure comes from what marketers put in it and from what rides along automatically.

The referring URL and the current page URL travel with the request as a matter of course, and that is where healthcare leakage usually lives. A URL like /treatments/hair-loss/finasteride/checkout carries a diagnosis-adjacent inference in the path itself, and query strings on intake and scheduling flows frequently carry more. The pattern described in medical intake form tracking leak points repeats on nearly every platform in the complaint.

twclid and the click-level join

X appends a click identifier, twclid, to landing page URLs from paid clicks. Like gclid, fbclid and msclkid, it exists for deterministic attribution: the platform recognizes its own identifier when it returns on a conversion and joins that conversion to the ad and account that produced it. That join is what makes the conversion useful for optimization, and also what makes it identifying in a regulatory sense. A conversion tied to a click identifier is not aggregate. It is one person, resolvable to an account on the platform side.

Customer lists and the server-side path

X also supports audience building from uploaded customer lists with hashed emails, and it offers a server-side conversion API. Hashing does not remove identity, it obscures the string while preserving the match. The server-side path is no refuge either: describing Meta's Conversions API in paragraph 70, the complaint acknowledges that it works 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 described server-side tracking correctly and pled it anyway, the most consequential technical sentence in the filing. See why server-side tracking alone is not HIPAA compliance.

How Curve Handles Legacy and Orphaned Trackers

Curve replaces the direct browser-to-platform connection with a single first-party collection endpoint. Events are captured once, sanitized on Curve's server before any egress, then forwarded to each configured destination through that platform's server-side API. Protected health information never reaches the ad platform, because redaction happens before the outbound request is built rather than inside a tag a marketer can reconfigure. Destinations are enabled explicitly per platform, so X either has a configured destination or receives nothing at all, and a BAA is available for the processing Curve performs. The governance benefit is structural: with exactly one path from site to ad platform, an orphaned tag stops being a data flow and becomes a broken tag, which is a much easier problem.

The Orphaned Pixel Problem

Ask a healthcare marketing team which ad platforms they use and you get a short, confident answer: Google, Meta, maybe Bing. Load their condition pages with a network inspector open and you typically find between eight and twenty distinct third-party requests. The gap between those two numbers is the problem.

Pausing a campaign does not pause the pixel

An ad account can be paused, drained of budget, or even closed, and the pixel on your website will keep loading, keep firing page views, and keep transmitting URLs. The tracker lives in your tag manager and your site templates, and its lifecycle is independent of whether you are spending money on the platform. A Twitter pixel installed for a 2021 brand campaign is, in 2026, still reporting every visit to your weight management landing page to a company you no longer do business with.

Nobody owns what nobody runs

Active trackers have an owner. Someone checks whether Meta conversions are matching, whether Google Ads is receiving the right conversion action, whether the numbers reconcile with the CRM. Legacy trackers have no such person. The agency that installed the X tag lost the account, the growth marketer who set up the Criteo tag moved on, and the container has forty-one tags, eleven of which nobody left can explain.

So nothing about the orphaned tag is ever reviewed, while its exposure quietly grows: new landing page templates inherit sitewide tags automatically, and when a condition page gets a more descriptive URL for SEO reasons, that URL starts flowing to every tracker on the page.

The categories of orphan

• The paused campaign tracker. Ran for a quarter, never removed. X, Pinterest, Reddit and Criteo are the common examples.
• The agency inheritance. Installed by a prior vendor, sometimes still pointed at that agency's own pixel identifier rather than yours.
• The pilot nobody cleaned up. A programmatic or retargeting test run under a demand-side platform contract that has since lapsed.
• The template ghost. A hardcoded script tag in a theme file rather than the tag manager, which is why container audits miss it.
• The duplicated container. A second tag container loaded by a landing page tool or scheduling embed, carrying tags the main audit never sees.

Finding the Trackers Nobody Remembers Installing

An inventory is the first deliverable, and it has to come from observed network traffic rather than from a list of accounts.

1. Open your highest-risk pages in a clean browser profile with the network panel recording. That means condition pages, symptom quizzes, intake forms and scheduling confirmations, not the homepage.
2. Record every distinct third-party host receiving a request, including requests that fire on interaction and form submission rather than on load.
3. Capture the full request for each. The domain tells you the vendor, the query string and payload tell you what left.
4. Repeat inside embedded tools: chat widgets, scheduling iframes, patient portals and landing page builders each load their own scripts.
5. Reconcile the observed list against your active advertising relationships. Everything in the gap is an orphan.
6. Check page templates and theme files directly for hardcoded tags, which never appear in a tag manager export.

Our pixel audit guide for identifying PHI leakage covers the request-level analysis in depth, and the 14-point audit scorecard gives you a way to rank findings rather than producing an undifferentiated list.

What to Do When You Find an X Pixel on a Health Site

Removal is usually correct for a genuinely abandoned tracker, and it should be fast. But removal alone leaves two questions unanswered, and both matter more than the tag itself.

First, what did it send, and for how long? Tag manager version history will tell you when it was published, and server logs can approximate the page views it observed. That determines whether you have a notification analysis to run, which is a question for counsel rather than for marketing. Second, is there a contract? Ad platform terms of service are not business associate agreements, and standard terms typically prohibit sending health information rather than accepting responsibility for it, so a tracker transmitting condition-level URLs from a covered entity's site leaves you in a worse contractual position than technical one. See why a BAA alone is not enough under the Security Rule.

If the platform is one you actually want to advertise on, do not simply reinstall the tag with better intentions. Route the conversion through a sanitized server-side path so the decision about what leaves your infrastructure is made once rather than in fifteen separate tag configurations, as described in HIPAA-compliant conversion tracking setup.

One piece of context is worth keeping in view. The FTC resolved GoodRx and BetterHelp administratively in 2023; this matter is being litigated, with civil penalties sought and two states as co-plaintiffs. The trajectory is tracked in our healthcare pixel lawsuit and settlement tracker. Hims denies the allegations, says its privacy policy makes clear that users may choose how their data is used, and intends to defend the case.

Frequently Asked Questions

Is the X or Twitter pixel HIPAA compliant?

No advertising pixel is HIPAA compliant on its own, and X does not offer a business associate agreement for its advertising products. The tag is not inherently unlawful to use, but a covered entity cannot lawfully transmit protected health information to it, and a sitewide universal tag on condition pages transmits URLs carrying health inferences by default. Compliance depends on what leaves your site, not on which vendor receives it.

We stopped advertising on Twitter years ago. Do we still have exposure?

Possibly, and this is the central point of the article. A paused or closed ad account does not stop a pixel loading and firing. If the universal website tag is still in your tag manager or page templates, it is still reporting page views. Check your live pages with a network inspector, not your ad account.

Does removing the pixel resolve the problem?

Removal stops future transmission, which is necessary but not sufficient. You still need to determine what was transmitted and over what period, whether any of it was protected health information, and whether your privacy representations matched what happened. Those are questions for counsel, with the technical inventory in hand.

Would using X's server-side conversion API instead have been safer?

Not by itself. Paragraph 70 describes Meta's server-side Conversions API accurately and pleads it as a sharing vector regardless, and paragraph 77 separately flags Google Ads S2S and TikTok s2s. Server-side moves the transmission point from the browser to your server. It does not change what is in the payload. Protection comes from sanitizing the event before egress, a separate decision from where the request originates.

Should we scope tags away from clinical pages?

Yes, as an intermediate step. A tracker on a careers page carries very different risk from the same tracker on a page about erectile dysfunction treatment. Sitewide is a default, not a requirement, and restricting advertising tags to non-clinical surfaces buys time while you build a compliant conversion path for the clinical ones.

This article reflects the public record as of July 2026, based on the redacted complaint e-filed on ftc.gov. Hims & Hers has denied the allegations and intends to defend the case, and no court has made any finding.

If your audit turns up trackers you cannot account for, the harder problem is the platforms you actually want to keep using. Curve gives healthcare advertisers one governed path from site to ad platform, with sanitization before egress and a BAA covering the processing, so conversion data keeps flowing without protected health information leaving your infrastructure. See how it works at curvecompliance.com.