Every performance team has had this call. Nothing changed on the account — same creative, same budget, same audiences — and yet last Tuesday the cost per acquisition doubled, and the conversion column went quiet. The client wants to know what you broke.

The instinct is to work the account: pause the losing ad sets, refresh creative, widen the audience, rebuild the funnel. Sometimes that is the answer. But there is a failure mode that looks exactly like account fatigue and does not respond to any of it, because the problem is not in the account at all. It is attached to the client’s website.

The failure that hides in plain sight

Meta applies data-sharing restrictions to websites whose subject matter falls into categories it treats as sensitive. Health and wellness are the obvious ones. So are dental and aesthetic clinics, supplements, therapy and mental-health practices, faith-based organizations, and a wide band of financial services — lending, insurance, debt advice, crypto.

The important detail, and the one that derails most diagnoses: the restriction attaches to the domain, not to the pixel, not to the ad account, and not to the business manager. Spin up a fresh pixel and the new pixel is restricted too. Move the campaign to a different ad account and it is restricted there as well. The one thing every attempted fix has in common is the website it points at.

Timing makes it harder to spot. A site can run for years without trouble and then get reclassified after a content refresh, a new service page, or a blog that drifted into a sensitive subject. Because nothing changed in the ad account, nobody thinks to look outside it.

There is also no email. Nobody tells the agency. The first signal is usually a quiet notice in Events Manager saying certain standard events are blocked — sitting in a panel nobody opens during a normal week.

Why the usual playbook produces nothing

When a domain is restricted, a subset of events stops being usable for optimization and attribution. Purchase, Lead, CompleteRegistration — the events the campaigns are actually bidding on — are the ones that go. What remains is often enough traffic-level signal to make the account look alive, which is precisely why this gets misread as fatigue.

Now watch what the standard remedies do. New creative still gets delivered against an optimization signal that is not arriving. A widened audience still cannot be modeled, because lookalikes and retargeting pools are built from event data that has stopped flowing. A rebuilt funnel produces conversions the pixel records and Meta discards. You can spend a full quarter iterating and see nothing, because every lever you are pulling sits downstream of a gate that is closed.

Five checks that separate a restriction from a break

Before you touch the campaign structure, spend twenty minutes here.

1. Open Events Manager and read the notices. A restricted domain usually announces itself in plain language. A broken pixel does not; it simply stops reporting.
2. Compare event volume against site analytics. If your analytics platform still shows purchases at the usual rate while Meta shows a fraction of them, the tracking is firing, and the data is being dropped somewhere after the browser.
3. Check whether the drop is selective. A technical break tends to take everything down at once. A restriction is surgical: PageView and ViewContent survive while the conversion events disappear.
4. Test the pixel in isolation. Load the site with the pixel helper and confirm the events fire client-side. If they fire cleanly and still never appear in reporting, the problem is not implementation, and no amount of re-tagging will change it.
5. Look at what the site is about, not what the client sells. Categorization runs on page content. A physiotherapy clinic that sells nothing can be restricted; an e-commerce store whose blog covers supplements can be restricted on the strength of the blog alone.

The server-side detour

At this point somebody suggests the Conversions API, and the logic seems airtight: if the browser layer is the problem, send events from the server and bypass it.

It does not work, and it is worth understanding why before you bill a client for the implementation. The Conversions API changes the transport, not the identity of the sender. Every event payload still carries the source URL, and that URL still names the domain Meta classified. A server-side event from a restricted domain is dropped on the same rule as a browser event from it.

This one costs agencies real money, because the build looks successful from the inside. Teams ship a full server-side implementation, watch the events arrive in the diagnostics panel with a healthy match quality score, and conclude the fix landed — while the campaigns keep optimizing on nothing. If you want the mechanics in detail, this breakdown of why the Conversions API alone won’t fix a blocked domain is the clearest write-up I have found.

What to tell the client

Say it early and say it plainly: this is not a penalty, it is a classification, and it is not the client’s fault or yours. It reflects the category the website falls into, not anything anyone did wrong. Clients who hear “restriction” think “ban” and start bracing for an appeal process that does not exist in the form they imagine.

Then set the expectation that this is a website-level problem with a website-level solution, and that campaign work is paused rather than failing. Nothing erodes an account relationship faster than three months of invoices against a lever that was never connected.

The takeaway for agencies

Add a domain check to your onboarding. It costs almost nothing, and it changes how you price and forecast an account. If a prospect operates in a restricted category, you want to know before you set the CPA target, not after the first month’s report. It also changes the conversation you have at pitch stage, from promising a CPA you cannot control to explaining a constraint the previous agency probably never diagnosed.

And when an established account goes quiet overnight with nothing changed on your side, resist the pull of the account. The signal was fine last week. Something outside it changed. Check the domain first — it is a twenty-minute diagnosis that saves a quarter.