A clinic client called me last month, a week away from turning Meta off for good. Their numbers had fallen off a cliff and nobody could tell them why. The pixel was installed correctly. Events were firing. Every check their previous agency ran came back “working.”
Then I opened Events Manager and there it was: their Purchase event, greyed out, marked restricted. Everything else looked fine. But the one event their entire business runs on had been quietly switched off from optimisation — and they’d been burning budget for weeks without knowing.
If you run a health, wellness, supplement, or clinic brand on Meta, this is one of the most common and most expensive problems you’ll hit. So let me explain what’s actually happening and how I fix it.
What a restriction actually does to your spend
Here’s the part most people misunderstand, because on the surface nothing looks broken.
When Meta restricts an event, the pixel still fires. The events still reach Meta. Data still shows up. What changes is that Meta refuses to use that event for optimisation and attribution. It’s received, then ignored.
So your campaigns keep running. Smart Bidding keeps bidding. But the algorithm that’s supposed to find your buyers now has no conversion signal to learn from. You’re paying for clicks and impressions with the feedback loop cut. The system is flying blind, and your cost per result climbs while you wonder what went wrong with your creative or your audiences — when the real problem is that Meta stopped listening to your most important event.
That’s why the slide is so confusing. Nothing “breaks.” It just quietly stops working, and the damage shows up as rising costs a couple of weeks later.
Why health and clinic brands get hit
Meta’s automated systems scan more than your pixel. They read three things together: the data in your events, the copy on your landing pages, and the product descriptions in your catalog feed. They’re looking for terms tied to sensitive categories — health conditions, medical claims, hormones, supplements, weight loss, and so on.
When the system finds those terms, it doesn’t usually ban the whole pixel. It restricts specific event types — and it tends to go straight for Purchase, because that’s the one carrying the most sensitive intent signal.
For a clinic or a health brand, this is a minefield. A product literally named after what it treats. A landing page making a mild, honest health claim. A catalog description using the category keyword customers actually search for. Any of these can be enough. And the frustrating part is that plenty of the businesses getting caught are entirely legitimate — they’re tripping an automated keyword filter, not running a scam.
Why support tickets rarely fix it
The instinct is to open a support case and ask Meta to lift the restriction. I’ve watched clients lose weeks to that, cycling through templated replies while their spend keeps bleeding. Even when it works, it doesn’t stop it happening again the next time the scanner re-reads your data.
The restriction is a symptom. The cause is what you’re sending Meta and what your public-facing content says. You fix the cause by controlling both — and this is where server-side tracking earns its place.
The real fix: control what Meta receives
Client-side tracking sends Meta whatever the browser picks up — including product names and content parameters stuffed with the exact keywords that flag you. You have almost no control over it. That’s the core problem.
Server-side tracking flips that. With a server-side GTM setup, every event passes through a server you control before it reaches Meta. You decide exactly what leaves. And that changes everything about this situation:
You send a clean, compliant Purchase event. Instead of forwarding a product name like “Testosterone Support Protocol” into the content_name parameter where the scanner reads it, you send a neutral, structured event — the purchase, the value, the currency, a generic identifier — without the sensitive strings that trip the filter.
You stop sending health data you were never meant to send. Meta’s own terms prohibit sending sensitive health information through their business tools. Server-side is how you strip that data out at the server, before it ever reaches Meta. Doing this isn’t a workaround — it’s the compliant way you were always supposed to handle it, and most client-side setups quietly break that rule without anyone noticing.
You keep your signal quality. Because you control the payload, you can still send properly hashed customer data, keep your event deduplication clean with a shared event_id, and maintain a strong Event Match Quality score. You lose the restricted keywords, not the optimisation signal.
The result is that legitimate conversions start counting again, Smart Bidding gets its feedback loop back, and your campaigns can learn.
The honest part: this is not a loophole
I need to be straight about this, because it matters. Server-side tracking is not a cloak for products that genuinely violate Meta’s policies. If your landing page makes claims Meta prohibits, or your catalog or your actual offer breaks their health rules, that content still needs fixing. Moving the tracking server-side won’t hide a real policy problem, and anyone selling it that way is going to get their clients into trouble.
What server-side does is give control back to legitimate businesses that are getting false-flagged by an automated keyword filter, and stop the quiet leakage of sensitive data that shouldn’t be going to Meta in the first place. Nine times out of ten with the clinics I work with, that’s exactly the situation — a real business, a real product, caught by a scanner reading a word out of context. The full fix is usually server-side control of the data plus a cleanup of any page or catalog copy that’s genuinely stepping over the line.
How I approach it
When a health or clinic client comes to me with restricted events, the sequence is roughly this:
Move conversion tracking server-side through a server-side GTM container, so every event to Meta is one I control. Rebuild the Purchase event as a clean, compliant payload — no sensitive keywords in the parameters, hashed customer data for matching, deterministic event_id for deduplication. Strip out any health or sensitive data that shouldn’t reach Meta at all. Then review the landing pages and catalog feed for the copy that’s actually triggering the automated flags, and fix what genuinely needs fixing. Finally, give the account time to re-evaluate with the clean signal flowing.
Done properly, the Purchase event comes back into optimisation, the feedback loop reconnects, and the campaigns stop guessing.
Mistakes to avoid
- Assuming the pixel is broken. It isn’t. It’s firing and being ignored. Check whether the event is restricted before you rebuild anything.
- Only opening support tickets. You can’t argue your way out of an automated content flag. Fix what you send and what your pages say.
- Treating server-side as a way to hide a real policy violation. It’s control and compliance, not evasion. Genuine policy issues still need fixing.
- Sending sensitive health data to Meta at all. Their terms prohibit it. Strip it server-side — this is best practice regardless of restrictions.
- Rebuilding the payload but leaving restricted keywords in the parameters. The whole point is to stop feeding the scanner the terms. Sanitise
content_nameand product identifiers. - Forgetting deduplication and match quality. A clean event still needs a shared
event_idand hashed identifiers, or you trade a restriction problem for a data-loss one.
The takeaway
If your Meta Purchase events are restricted, your pixel isn’t the problem and your campaigns aren’t underperforming for the reasons you think. Meta is receiving your data and refusing to use it, and your spend is running with no signal underneath it. The way out isn’t a support ticket — it’s taking control of exactly what you send Meta, sending clean and compliant conversion data server-side, and fixing any content that genuinely trips their rules.
For health, wellness, and clinic brands especially, this is the difference between an account that quietly bleeds budget and one that can actually optimise. It’s the exact problem I fix — if your events are restricted and you’re not sure what set it off, that’s a good place for us to start.