Meta Switched Off Your Conversions API and Didn't Tell You

An advertiser posted a set of numbers recently that is worth studying, because almost everyone would misdiagnose it. His account had been stable for four months, scaling steadily, fresh creative weekly. Then over a single weekend his CPM fell by roughly two thirds, his CTR fell from around 2-3% to half a percent, and sales went to zero. Every new ad set and campaign he launched to escape it behaved exactly the same way. Meta had disabled his Conversions API. No email, no banner in Ads Manager, and the campaigns ran the whole time.

Why that combination of metrics is the tell

Sit with the pattern for a second, because it is genuinely strange on first reading.

Cheap impressions normally mean good news. You have found an audience nobody else is bidding hard for. Expensive impressions with a strong click rate mean you are in a competitive auction and winning it. But cheap impressions alongside a collapsing click rate is not a version of either.

It is not a creative problem, because creative problems raise your costs rather than lowering them. A tired ad has to be shown to more people to get the same result, which pushes CPM up, not down. And it was not an audience problem, because he changed the audience repeatedly and the pattern followed him every time.

Here is what actually happens. Once the conversion signal is gone, the delivery system has no idea who is likely to buy. So it stops competing for the people who do, and starts buying whatever impressions are cheapest, because with nothing to optimise toward, cheap is the only objective it can still satisfy. The low CPM was not a discount. It was the delivery system giving up.

If you remember one thing from this article, remember that combination: CPM and CTR falling together while conversions disappear is a signal-loss pattern, not a creative one. The instinct in the moment is to blame the creative and start testing, and that instinct costs you the week.

Why launching new campaigns makes it worse

The natural response to a dead account is to build something new. Fresh campaign, fresh ad sets, fresh creative, escape whatever curse has settled on the old ones.

When the dataset is the problem, every new ad set is born into the same signal vacuum. It inherits the same broken delivery, produces the same cheap junk impressions, and fails in the same way. Which then looks like confirmation that the problem really was creative fatigue, because surely if it were something structural the brand-new campaign would work.

That reasoning is backwards, and it is why this particular failure can eat a full week. Each attempted fix generates evidence for the wrong diagnosis.

Why a dataset gets disabled

Meta can restrict or disable a dataset for several reasons, and most of them are not misconduct:

• A data-quality flag, for example events arriving with malformed parameters, implausible values, or personally identifiable information sent in a field that expected a hash.
• A policy or category flag, where the dataset is judged to be sending events from a sensitive category. This catches plenty of legitimate businesses in health, finance and similar verticals.
• An expired or revoked access token, which is not strictly a disablement but produces an identical outcome: the events stop arriving.
• A business verification or asset permission change, often triggered by an unrelated admin action such as somebody leaving the Business Manager.

The notification, when there is one, typically lands in Business Support Home or an account-level notifications area rather than in front of the person managing campaigns. There is no alert in Ads Manager, which is the only screen most media buyers open in a given day.

What to do in the first hour

1. Open Events Manager and look at event volume by day. Not Ads Manager. Events Manager shows events received; Ads Manager shows conversions attributed. If event volume fell off a cliff on a specific day, you have found both the problem and its start date, and that date is the most useful fact you will gather.
2. Check the dataset's status and its diagnostics tab. Restrictions, warnings and data-quality flags surface here rather than anywhere you normally work.
3. Check Business Support Home for notifications. This is where the explanation usually is, and almost nobody checks it routinely.
4. Verify your access token is still valid. Tokens expire, and an expired token produces silence rather than an error your team will see.
5. Do not restructure the account. Whatever you build while the signal is missing will fail for the same reason, and you will have destroyed your historical structure for nothing.

The seven-day window, which is time critical

This is the part most people miss, and it expires.

Meta accepts server-side events with a historical event_time going back roughly seven days. So if your outage started last Saturday and it is now Thursday, the orders from Saturday onward are still in your backend and can still be sent through the Conversions API with their original timestamps and event IDs. Some of that lost signal is recoverable.

The oldest day falls out of the window first, so this is worth doing immediately rather than after you have finished diagnosing. A day spent investigating is a day of recoverable conversions permanently lost.

Two details matter when you do it. Send the true original event time, not the upload time, or you will distort your attribution windows. And keep your event IDs consistent with whatever the browser sent at the time, so deduplication still works and you do not solve an undercount by creating a double count. The mechanics are in fixing duplicate events between pixel and CAPI.

After you switch it back on

Do not judge anything for several days. The model has to relearn who converts, and your first days back will look worse than the account really is. Resist the temptation to read that as evidence the fix did not work, and resist making other changes at the same time, because you will not be able to attribute the recovery to anything.

Expect a genuine recovery period rather than an instant return to previous performance. Delivery spent the outage learning from a misleading picture of your customer, and unwinding that takes longer than the outage itself did. This is the same dynamic covered in recovering after a tracking outage, which applies to Meta with the platform names changed.

Reducing the odds of being flagged at all

You cannot make a dataset restriction impossible, but a good deal of what triggers data-quality flags is self-inflicted and avoidable. Worth auditing your integration against these, because each one is a known trigger:

• Never send personal data in a field that expects a hash. Email, phone and name fields must arrive hashed, and hashed correctly: lowercased, trimmed, and normalised before hashing. A plaintext email arriving in a hashed field is one of the fastest routes to a flag, and it happens most often when somebody adds a new integration in a hurry.
• Keep values plausible. Purchase values in the wrong currency, values of zero on a purchase event, or test values of 999999 sitting in production data all read as quality problems. If you sell in multiple currencies, send the currency field properly rather than converting everything to one and hoping.
• Keep test traffic out of the production dataset. Use the test event tooling rather than firing real-looking events from a staging environment. Synthetic purchase volume that never corresponds to real orders is exactly the pattern automated quality checks look for.
• Do not send events for categories you should not be sending. Health, finance and similar verticals have specific restrictions on what can be reported. This catches legitimate businesses regularly, usually because a generic ecommerce integration was installed without anyone reviewing what it sends.
• Keep credentials and asset permissions tidy. Tokens generated under a personal account rather than a system user break when that person leaves, changes their password, or has their access revoked. A system user token owned by the business is more boring and much more durable.

None of this is glamorous, and all of it is cheaper than a week of dead delivery. Most of it can be checked in an afternoon and then left alone for a year.

Making sure you find out faster next time

The uncomfortable fact underneath this whole story is that nothing errored. A platform switched off the most important measurement integration in the account, the campaigns kept spending, the dashboard kept rendering plausible numbers, and the only way to discover it was to go and look.

There is no alert for this in the place you work, so the defence has to be a habit rather than a notification. The cheapest version is one comparison, checked on a schedule:

• Events received against orders recorded. Take conversions arriving in Events Manager for a period and compare them to what your backend actually recorded. You are not looking for the numbers to match, because they never will. You are looking for the relationship between them to stay roughly constant.
• Match quality and deduplication rate. Both degrade gradually when something upstream changes, and both are visible in Events Manager without any extra tooling. Context in improving event match quality.
• Business Support Home, occasionally. It is where the platform tells you things it considers important and you do not.

A weekly check would have caught the account described at the top of this article on the Saturday rather than six days later, inside the recovery window instead of at the edge of it. The check takes a few minutes. The outage cost a week of spend, a week of learning, and a week of believing the creative had stopped working.

That asymmetry is the whole argument. Tracking almost never breaks loudly, which means the cost of any given failure is set less by the failure itself than by how long it takes anyone to notice.