Your ads are approved and delivering. But Purchase disappeared from the optimization dropdown, your custom conversions read as unavailable, and the audiences you built on Add to Cart stopped refreshing. Nothing got rejected, so nothing tells you what happened. What happened is that a category label landed on your domain and the dataset attached to it, and nearly every page you will find about removing it was written by a company selling tracking software, which is why they all stop at the pixel.
The label is on your domain, not on your ads
Meta classifies businesses by what they sell, separately from reviewing what they say. The health and wellness classification is the data side of that. It attaches to a business and its verified domain, then flows down to the dataset receiving events from that domain. Your creative never enters into it, which is why you can sit in Ads Manager with a green Active status and still lose half the machinery underneath it.
What you lose is specific. The events Meta treats as sensitive stop being available for optimization, custom audiences, custom conversions and value based bidding. Purchase, Add to Cart, Initiate Checkout and Lead are the usual casualties. Delivery keeps running on whatever is left, normally Landing Page View, View Content or link clicks. Reporting thins out in the same week, so the breakdowns you normally use to decide what to cut get less useful at the exact point you are making cuts.
There are 2 systems here and 2 different reviewers. The one that rejects an ad reads your creative and your landing page. The one that applies this label reads the category of goods you sell. Fixing the first has no effect on the second, and that is the most expensive misunderstanding in this area, because operators spend weeks rewriting copy for a problem copy did not cause.
Confirm which system you are in, in 5 minutes
Before you change anything, prove what you are looking at. Every check below uses data already sitting in your account, and the answer changes what you do for the next month.
- Open Events Manager, select the dataset, and read the notice at the top of the overview. A classified dataset carries a category notice there. If it names health and wellness, the label is live and everything else follows from it.
- Open any ad set and drop down the conversion event list. If Purchase is greyed out or missing while other events stay selectable, the constraint is on the dataset, not on your campaign settings.
- Open Custom Conversions. The ones built on a restricted event show as unavailable rather than throwing an error. They did not break, they were withdrawn.
- Open Account Quality and look for rejections and restrictions. If there are none and your ads are still spending, stop reading ad policy. Nothing you write in the ad will move this.
- Check who holds the domain verification. If the domain is verified inside a portfolio that is not yours, you cannot read the dataset notice or submit anything about it, which is a separate problem set out in how the pixel and domain verification fit together.
The 5 fixes that do nothing
Each of these gets recommended in forums every week. None of them touches the label, because none of them changes the thing the label is attached to.
- A new pixel or a new dataset. The classification is keyed to the business and the domain sending the events. Create a fresh dataset, point it at the same verified domain, and it inherits the same treatment as soon as traffic starts arriving.
- Moving to the Conversions API. Server side sending changes how the event reaches Meta, not what the event is or which domain produced it. A restricted Purchase sent from your server is still a restricted Purchase.
- Renaming events, or building a custom conversion with a neutral name. The restriction applies to what the event represents on a classified domain. A Purchase relabelled as Step 4 is still the purchase of a supplement.
- A new ad account, or an entire new Business Manager. This is the costly one, because it feels like progress and it eats a week. The new account still has to point at the same verified domain to run the offer, and the moment it does, it is advertising a classified business.
- Rewriting ad copy and adding disclaimers to the site. That is the fix for a rejection. You will get better ads out of it. You will not get Purchase back.
Why the review request rarely lifts it, and when it does
There is a request review flow in the product and you should use it once. What it asks, in effect, is whether the classification is accurate. If you sell supplements, sleep aids, weight support, hormone support or anything a normal person would file under wellness, the answer is that it is accurate, and the review confirms the label rather than removing it.
It gets lifted when the classification is factually wrong about what the business sells. Software companies with wellness sounding names, fitness apparel brands, gyms, equipment sellers and agencies whose clients are supplement brands all get caught by classification that reads the site copy rather than the checkout. If that is you, submit once with the strongest evidence of what you actually sell: the catalog, the product pages, the checkout, the merchant of record on the receipt. Send the whole case the first time, because firing the same request again every 2 weeks adds no weight to it.
If you genuinely sell health products, treat the label as a standing constraint on that domain and build around it. That is not defeatism. It is the only planning assumption that does not cost you a quarter.
What it costs you, in numbers already in your account
The restriction does not stop you selling. It moves what the algorithm is allowed to optimize toward, from the event you get paid on to a proxy for it. The cost is the gap between those 2 events, and you can size it before you decide anything.
Take your cost per proxy event and call it C. Take the share of proxy events that turn into purchases and call it R. Effective cost per purchase is C divided by R. The trap is that R is not your historical site wide rate. When the bidder was buying purchases it selected for people who finish checkouts. Once it is buying View Content, it selects for people who look at things, and a real slice of those people were never going to pay. R for the traffic you buy afterwards runs below R for the traffic you bought before, and that gap is the actual bill.
The second input is volume. Meta's own documentation puts the exit from the learning phase at about 50 optimization events per ad set in 7 days. That threshold decides which of 3 situations you are in, and the right answer flips between them.
- Fewer than 50 purchases a week per ad set. You were already under the threshold on Purchase, so a proxy that fires several times more often is not a downgrade. Here the restriction can genuinely steady delivery, and the work is making the proxy mean something: a variant selection, a scroll depth event, a checkout step only a serious buyer reaches.
- Past 50 purchases a week per ad set but not by a wide margin. This is the band that hurts. You had enough signal to optimize on the event that pays and you have been moved to one that does not, without the volume to rebuild the link statistically. Expect a rise in cost per purchase that no creative change explains, and stop blaming the creative for it.
- Comfortably clear of it. You have the volume to stop relying on the platform for truth. Judge ad sets on your own order data, run scheduled holdouts, and treat the reported number as a relative signal between ad sets in the same week. That is more work, and it is the only path that gets more accurate over time instead of less.
What the label carries with it and what it does not
Get this wrong in either direction and you pay twice: you either rebuild infrastructure that was never affected, or you spend a week standing up a new stack that lands under the same constraint on day 1. Here is what moves with the label.
- It carries to the verified domain. The domain is the anchor and everything else hangs off it.
- It carries to any dataset receiving events from that domain, whenever the dataset was created and whichever portfolio holds it.
- It carries to custom conversions and custom audiences built on the restricted events, which is why they read as unavailable rather than empty.
- It carries to any ad account pointed at that domain, including one you opened this morning or rented this afternoon.
- It does not carry, by itself, to a different business on its own domain, with its own verification, its own dataset and its own checkout.
The line between separation and circumvention
That last bullet is the whole answer and it comes with a boundary you should not blur. A genuinely separate offer standing on its own domain from launch is ordinary architecture, and most operators running more than 1 offer already work that way for reasons that have nothing to do with policy.
A copy of the same store on a second domain, sharing the catalog, the pixel, the payment method and the fulfilment, is the same business wearing a second name. Domain verification, dataset matching and payment matching exist to notice exactly that. Treating a data classification as something to hide from is how a measurement problem becomes an enforcement problem, and the enforcement version is far harder to unwind than the label you started with. The wider constraints on these verticals, including the ones that do get creative disapproved, sit in the guide to running restricted offers without tripping review, and the patterns behind the enforcement side are covered in what actually gets Meta accounts disabled.
Build the separation before you need it
The reason this catches people flat is that the label arrives after the business is already consolidated. 1 domain, 1 dataset, every offer running on it, every ad account pointed at it. That single classification then applies to everything you sell, including the products it was never really about.
The trade off is real and you should hear it before the upside. Separate domains mean separate verification, separate datasets, separate warm up, and learning that does not pool across offers. You will spend more in the first 2 weeks of every launch and you will have more surfaces to keep straight. Against that, 1 classification, 1 policy strike or 1 account loss stops taking the whole portfolio down with it. Run a single offer on a single account and the split is not worth the overhead. Run several and it usually is, and the people who get hurt worst are the ones who consolidated to save admin work.
Whichever way you go, the assets underneath decide how much of this you control. Whether the ad account is yours or someone else's, what matters is what you hold when the relationship ends: admin on the dataset, admin on the domain verification, the catalog, and the audiences you paid to build. Ask for those 4 by name, then check that what a documented handover actually includes matches what you were told, because a promise that access will be provided is not a commitment to anything.
Keep the account question separate from the data question. An account carrying real spend history behaves differently in a restricted vertical from one opened yesterday, and that shows up in the first week rather than the first month. But an account provisioned for a restricted vertical does not remove a classification sitting on your domain, and a provider who implies otherwise is selling the wrong fix. A flat monthly rate, rather than a cut of every dollar you spend, makes standby capacity cheap enough to hold before you need it, which is the only moment it is worth anything. It does not make a label disappear.
- Confirm it is the data label and not a rejection, using the 5 checks above. That is 5 minutes and it decides everything after it.
- Submit the review request once, with the catalog and checkout as evidence, and only if the classification is factually wrong about what you sell.
- Pick the best proxy event available and make it mean something. A step only a serious buyer reaches beats a page view every time.
- Move judgement off the platform. Your order data is the truth and the reported number becomes a relative signal.
- Launch the next offer on its own domain and its own dataset from day 1, not after a label lands on it.