KLM-LOG Blog
Why Renaming Your Blocked Purchase Event Won't Save Your Telehealth Campaigns
November 1, 2026 · Joe · 4 min read
When Meta started blocking Purchase events for health and wellness advertisers, a piece of advice spread quickly. Rename the event. Send "Pur_1" instead of "Purchase" and "Check_1" instead of "InitiateCheckout," and the event is no longer on Meta's restricted list.
I understand why it's popular. It's fast, it sometimes works for a while, and when your best campaign stops optimizing, a fix you can ship in an afternoon looks great.
But renaming changes the label, not the data. For a telehealth brand, that's the part that matters.
What Meta actually changed
Starting in early 2025, Meta began sorting data sources (website domains and apps) into categories, including health and wellness, and restricting what each category can send and use for optimization. The restrictions come in levels. At the lighter level, URL parameters and custom parameters are limited. At the middle level, mid- and lower-funnel standard events like Purchase can't be used to optimize. At the full level, custom events are blocked too.
Three details about custom events matter here:
- In restricted categories, custom events have to be registered in Events Manager, or Meta drops them. New custom events stay blocked until they are reviewed and registered.
- Meta has said it detects and filters custom events that look potentially sensitive, regardless of the data source's restriction level.
- The rule for custom events is that they must not directly or indirectly share prohibited information.
That last line is the problem with renaming. When you register "Pur_1," you're confirming that the event doesn't share prohibited information. If it fires when someone buys a weight-loss prescription, carries the order value, and is sent from a domain Meta has already categorized as health and wellness, the name doesn't change what it reveals.
Why renaming is fragile
The data is the same. Meta doesn't need to read the event name to know what it means. An event that fires once per order, with a value equal to a subscription price, from a categorized health domain, is a purchase.
Meta's enforcement is moving toward the data, not the label. Meta has moved from asking advertisers not to send sensitive data toward scanning for it and disabling conversions and audiences it flags. An approach that depends on a name not being recognized depends on enforcement staying where it is today.
It leaves the risk with you. Meta's policy puts responsibility for custom events on the advertiser. If you register a disguised Purchase event, you're the one who told Meta it was fine. Considering the FTC's recent telehealth cases, that's not a position I'd want a client in.
When it breaks, it breaks during a sale. If a renamed event gets flagged, campaigns that depend on it degrade, and Meta has said new campaigns using flagged conversions will be blocked at setup. You find out when performance drops, which is usually the worst possible week.
What to do instead: design signals around business value
The better question isn't "how do I keep sending Purchase?" It's "what can I send that helps Meta find good customers without telling Meta anything about anyone's health?"
That leads to a different kind of event:
- Outcome events that aren't health facts. "Qualified," meaning someone completed a checkout step and met your business criteria, describes your funnel, not their condition.
- Values that describe the business, not the treatment. A projected lifetime value tier, or a rounded value band, gives Meta something to optimize toward without passing the exact price of a specific treatment.
- Clean context. No condition words in the event source URL, no product names in parameters, no quiz answers in custom data. The whole payload is checked, not just the name.
- Events from your backend, not the browser. Some of the best signals happen after the checkout: an order approved by a provider, a first refill. Those can be sent server-side once, with a generic name and a business value, and they're closer to revenue than anything in the browser.
It's slower to set up than a rename. It also holds up when Meta's enforcement improves, when a client's legal team asks what's being sent, and when someone compares the privacy policy with the data.
How Kalman approaches it
This is the problem I built Kalman to solve, so I'll be direct about how it works. Kalman maps your real business outcomes (for example, provider-approved orders) to neutral events like Qualified, attaches a projected value instead of a treatment price, and runs every outbound event through a filter that strips condition terms, product names and URL paths before anything reaches Meta. You can preview exactly what leaves for Meta before you turn delivery on.
If your client's Purchase event is blocked and the plan is to rename it, it's worth a look first. Start with a free scan of the site to see what's leaving it today.
This post is general information, not legal advice.