Meta health data restrictions: measuring telehealth ads without health data

Meta's health and wellness restrictions changed what a telehealth brand can send back to the ad platform. A pixel that used to fire a purchase event with the product name, the price and the page path now has parts of that payload filtered out, or the event dropped altogether, depending on how Meta has categorized the data source. Brands that treated the pixel as the source of truth for paid social watched their reported conversions fall with no change in actual sales, then spent weeks trying to get the old numbers back. The restriction and the privacy law behind it point the same way: send Meta a bare purchase signal with nothing about a condition, a drug or a page in it, and do the real measurement on the brand's own server, where the data already lives.

What Meta blocks, and why

Meta's Business Help Center says plainly that the platform does not want websites or apps sending sensitive information about people through its business tools. Its page on sensitive health information lists the categories it treats as sensitive: diseases and medical conditions, injuries, sexual and reproductive health, mental health and psychological states, types of medical devices and health trackers, and medical procedures, treatments and testing. Every vertical a white-label telehealth brand is likely to run sits somewhere on that list. A weight-loss program is a medical condition and a treatment. A TRT program is a condition, a lab test and a drug. Sexual health and mental health are named outright.

The enforcement is mechanical rather than manual. In Meta's words, "If Meta's signals filtering mechanism detects Business Tools data that it categorizes as potentially sensitive health-related data, the filtering mechanism is designed to prevent that data from being ingested into" its ads ranking and optimization systems. The filter runs on what the pixel and the Conversions API send: event names, parameters, URLs, custom data. It does not read the advertiser's intent. A checkout URL that contains the string "semaglutide" is health data to the filter whether or not the brand meant to send it.

The reason Meta built this is not mysterious. Pixels on hospital and clinic websites became the subject of class actions, regulators started treating ad-tech disclosures of health information as a privacy violation in their own right, and the platform decided it would rather lose optimization signal than hold the data. A telehealth brand that fights the filter is fighting Meta's own legal exposure, which is a losing position.

How the restriction levels work

Meta assigns each data source, meaning each pixel or dataset, to a category, and the category determines what passes through. Meta's public help pages document a level called "core setup" by name. Advertising trade press, including Search Engine Land, describes the system as three tiers: a core setup where a small set of standard events still reaches optimization with parameters stripped, a middle level with more removed, and a full restriction where lower-funnel events such as purchases and leads are blocked from optimization entirely. Meta has not published a public table of exactly which events and parameters survive at each level, so any tier chart from an agency or a tracking vendor is that vendor's reading of what they saw inside their clients' accounts. Treat it as a field report, not a specification.

Advertisers who have been through it report that the assigned category is visible in Events Manager, in the settings for the data source, and that there is a path to request a review if the assignment is wrong. A review can move a brand from a harsher level to a milder one when the category was a mistake. It will not move a prescription weight-loss brand out of the health category, because it is one.

The practical rule is to design for the strictest level and treat anything better as a bonus. An event design that works when Meta accepts only a bare Purchase event will keep working if Meta later tightens the filter. An event design that depends on custom parameters passing through will break on the next policy change, and the brand will not find out until the reporting dashboard goes quiet.

What can still be optimized

Upper-funnel objectives are unaffected. Reach, video views, engagement, link clicks and landing-page views do not depend on the pixel reporting anything about what happened after the click. Traffic campaigns run as they always did. The loss is concentrated in conversion campaigns that optimize toward a purchase or a lead, and in value-based bidding that needs a purchase amount attached to the event.

Within a conversion campaign, a standard Purchase event with no parameters is the signal most likely to survive at the milder levels, according to the same trade reports, and it is also the only signal the brand should have wanted to send. A Lead event fired when someone starts intake, before any medical question is asked, is a reasonable second signal as long as the event carries nothing about which program the person chose. Custom events named after conditions or products, ViewContent events with a content name, and any event with a URL parameter that reveals the vertical are the things to remove, whether or not the filter is currently dropping them.

Targeting shifts in the same direction. Custom audiences built from the practice's patient list are a HIPAA disclosure by the practice to an advertising company that has no business associate agreement with it, and no consent form fixes that. Lookalikes seeded from a storefront's pre-clinical customer list are a state-law question and a privacy-policy question rather than a HIPAA one, and many brands decide not to do it anyway. Broad targeting with the creative doing the segmentation is what most restricted health advertisers end up running.

What the privacy laws add

Three legal threads sit under Meta's policy, and it helps to keep them separate. The first is HIPAA. In December 2022, the HHS Office for Civil Rights published a bulletin on online tracking technologies that said, in effect, that a visitor's IP address combined with a page about a health condition could be protected health information even when the visitor had not logged in or become a patient. On June 20, 2024, a federal district court in the Northern District of Texas vacated that part of the bulletin, and HHS did not appeal. What the vacatur removed was the theory that an anonymous visitor reading about a condition is generating PHI. What it left in place is everything else: a pixel on an authenticated patient portal page, a checkout page tied to an account, or any page where the visitor is identifiable as a patient still transmits PHI if the page reveals treatment. The practice's obligations under the Privacy and Security Rules are unchanged, and the HIPAA obligations for brand operators guide walks through where the MSO sits in that.

The second thread is state law. Several states have passed consumer health data laws that reach companies HIPAA does not cover, including the brand entity in an MSO and friendly-PC structure. An MSO, the management services organization that owns the brand and the commerce side, is typically not a HIPAA covered entity for its own marketing data, so these laws are the ones that actually govern what the storefront sends to an ad platform. The definitions of health data in these laws are broad, and several include the inference that a person is seeking a specific kind of treatment. Which states, and what each requires, depends on where the brand's customers are, and the rules differ enough that a state-by-state check with counsel is the honest answer rather than a summary here.

The third thread is the FTC. The Commission has used its authority over unfair and deceptive practices against telehealth and health-app companies that shared user data with advertising platforms contrary to what their privacy policies said, and it has treated disclosure of health information for advertising as harmful on its own terms. The FTC does not need HIPAA to apply. It needs a privacy policy that says one thing and a pixel that does another.

Send Meta the fact that a sale happened and nothing about what was sold. Every law involved, and Meta's own filter, is satisfied by the same design.

An event design that stays clean

The design below assumes the strictest Meta level and the broadest state health-data definition at the same time.

• Use standard events only: PageView, Lead when intake begins, Purchase when an order is paid. No custom events, and no ViewContent with a content name or content ID that maps to a product.
• Strip parameters to value and currency on Purchase. No content_name, no content_category, no content_ids, no custom data that names a program, a drug, a dose or a provider.
• Keep condition words out of URLs. The pixel sends the page URL with every event, so checkout and thank-you paths should be neutral, such as /checkout and /order-confirmed, not /glp1-checkout. The same applies to query strings and UTM values the brand controls.
• Send the Purchase event from the storefront, which is the MSO's commerce system, at the moment the order is paid. Never from the clinical system, the EHR or anything the professional corporation operates. The purchase happens before a provider has reviewed anything, so the event carries no information about whether a prescription was written.
• Match on click and browser identifiers first. The fbc and fbp values and a shared event ID for deduplication give Meta enough to attribute the purchase. Hashed email and phone are a privacy-policy and state-law decision; if sent, they come from the storefront's customer record, never from the practice's patient record.
• Route the Conversions API through a gateway the brand controls, and confirm in writing what fields it forwards. If the gateway vendor can see anything that came from the clinical side, that vendor needs a business associate agreement, and the cleaner answer is to make sure it cannot.
• Keep a one-page data map listing every field that leaves the brand's domain to any ad platform, and review it whenever a campaign, a page or a vendor changes.

Meta will not sign a business associate agreement, which is the contract HIPAA requires before a covered entity shares PHI with a vendor. That single fact settles most arguments about what can go in the payload. If a field would need a BAA to leave the practice, it cannot go to Meta under any event name.

Measuring ads without the pixel

Once the pixel stops being the ledger, the brand needs its own. The mechanics are not exotic. On the landing page, capture the click identifier Meta appends to the URL, along with the UTM parameters, and store them in the visitor's session. When the visitor places an order, write those values onto the order record. Paid social acquisition cost is then spend divided by orders that carry a Meta click identifier, computed in the brand's database rather than read off Meta's dashboard. Meta's reported conversions become a directional check on the brand's own count, and when the two diverge, the brand's number is the one that ties to revenue.

Two supplements make the first-party count more honest. A post-purchase survey with a single question, asking where the customer first heard about the brand, catches the view-through and word-of-mouth cases the click identifier misses; the answers are noisy but stable over time. Geographic holdouts, where a region is left unadvertised for a few weeks and its order rate is compared with advertised regions, measure incrementality directly and do not depend on any platform reporting at all. Neither method sends a byte to Meta.

This is also where ownership of the data starts to matter operationally. On Tessic Health's platform the brand owns its storefront, its order records and its analytics, so the attribution ledger described here runs on records the brand controls rather than on what a platform reports back, and it leaves with the brand if the brand leaves. A setup where the operator cannot query its own orders by click identifier has no way to run this model, whatever the ad platform allows.

Google runs its own version of these constraints for health advertisers, and the approval process for Meta and Google Ads is a separate problem from measurement, but the event design above is the same one that keeps a brand on the right side of both platforms' policies once the account is approved.

Questions operators ask

Can the practice's clinical system send the Purchase event, since that is where the prescription is confirmed? No. The clinical system is operated by the professional corporation and everything in it is PHI. The storefront knows an order was paid; that is the only fact Meta needs, and it happens before any clinical decision.

Is a hashed email address still health data? Under HIPAA, hashing is not de-identification, so a hashed email that came from the practice's patient records is still PHI. A hashed email from the storefront's customer record, collected before intake, is consumer data governed by the privacy policy and state law, and the brand should decide about sending it on those terms. Many brands choose not to.

What about the reporting gap when campaigns are optimizing on fewer signals? Expect Meta's learning phase to take longer and its reported cost per result to look worse than the real number, because it is seeing fewer of the conversions. Run creative and audience decisions off the first-party ledger with a lag of a few days, and give conversion campaigns a bare Purchase event to learn from.