Facebook SDK ATE True Status Rate stuck at 0%? Here is what it actually means

You open Meta Events Manager, look at your app, and see it. ATE True Status Rate: 0%. Or worse, no rate displayed at all. You just moved your purchase events over to RevenueCat and the Conversions API, your trials are not attributing to ads, and now this metric is sitting at zero. Obviously the two are connected and obviously you broke something.

Almost certainly you did not. This is the single most misread number in Meta app tracking, and the panic it causes sends people digging through SDK config for days while the actual attribution problem sits somewhere else entirely.

Here is what that number is, why it goes blank the moment you do the right thing, and how to tell whether you have a real problem.

What ATE True Status Rate actually measures

ATE stands for Advertiser Tracking Enabled. It is the flag your app sends Meta saying whether a given user granted permission on the iOS App Tracking Transparency prompt.

The True Status Rate is a simple fraction. Meta takes the number of devices where that flag came in as true, and divides it by the number of devices it received any ATE status from at all. It recalculates daily.

So it is not a measure of your tracking health. It is a measure of how many of your users tapped Allow, out of the ones you told Meta about. Two very different things, and the name does a bad job of saying so.

Why it reads 0% or blank after you move to RevenueCat

This is the part that is buried in Meta’s own help docs and almost never mentioned in the forum threads where people ask about it.

Meta only displays the ATE True Status Rate for app activity that arrives from the Facebook SDK. It does not display it for events that arrive through the App Events API, through the Conversions API, or through a mobile measurement partner.

Read that again, because it explains the whole thing. When you set up RevenueCat properly, you deliberately stop the Meta SDK from logging purchases and you let RevenueCat send those events server side instead. That is the correct setup. It is what the integration is for. But it also means Meta is no longer receiving those purchase events from the SDK, so it has no SDK-reported ATE status to build the rate from, so the rate goes blank or falls to zero.

The metric did not detect a problem. The metric lost its data source, because you moved your events to a better one.

If you followed a proper RevenueCat to Meta setup and turned off FacebookAutoLogAppEventsEnabled, a blank or zero ATE rate is close to expected behaviour. It is a reporting artifact of the architecture you chose on purpose.

The trap: two unrelated problems that look like one

Here is why this wastes so much of people’s time. Two things usually happen in the same week:

You move purchases to RevenueCat and CAPI.
Your ATE True Status Rate goes to zero, and your trials are not attributing to ads.

Because they happen together, everyone assumes the zero is causing the attribution gap. It is not. The zero is a display quirk. The attribution gap is real, and it has its own separate causes.

Chasing the ATE number will not fix your attribution, because the ATE number was never the thing standing in the way. You can spend a fortnight reinstalling the SDK and get nowhere.

What to check instead, in order

If trials are not attributing, work this list rather than the ATE display.

1. Check the flag format you are sending. In the Conversions API, advertiser_tracking_enabled has to be sent as 0 or 1, not as a boolean true or false. Sending the boolean throws an out of range error and the event gets rejected or degraded. This one is quietly common and easy to miss because the event still looks like it left.

2. Confirm the events are actually landing and matching. Open Events Manager and look at the events themselves, not the ATE panel. Are your trial and purchase events arriving? What is the event match quality on them? Low match quality, not ATE, is what usually kills attribution. Meta needs identifiers it can match to a user, and server side events only carry what you pass them.

3. Turn on Automatic Advanced Matching. Under your app settings in Events Manager. It gives Meta more to match on, which is exactly what you need once you are sending server side.

4. Make sure you did not double instrument. If the Meta SDK is still auto logging purchases while RevenueCat is also sending them, you get double counting and messy dedup. FacebookAutoLogAppEventsEnabled should be false, but keep activateApp() firing so Meta still sees installs and sessions. Losing that call is a genuine own goal and it does break things.

5. Accept that iOS attribution has a hard ceiling. Most iOS users decline the ATT prompt. That means deterministic matching is unavailable for the majority of them no matter how clean your setup is, and Meta falls back to SKAdNetwork, which is delayed, aggregated and modelled. A meaningful share of your trials will never attribute to an ad in Ads Manager. That is the platform, not your integration.

6. Check your attribution window against your funnel. A trial that starts today and converts in fourteen days is often outside the window Meta credits. The event fires, Meta just does not tie it to the ad. This is one of the main reasons RevenueCat and Ads Manager never show the same revenue.

When a 0% rate genuinely is a problem

To be fair to the metric, there is one case where it matters.

If you are still relying on the Facebook SDK to log your app events, and you have not moved to a server side setup, then the SDK should be reporting ATE status and a flat zero is worth investigating. In that situation it usually points at the SDK not being initialised properly, the ATT prompt never actually being presented, or the flag not being set after the user responds.

So the question to ask yourself first is simply: where are my events coming from? If the answer is RevenueCat and the Conversions API, stop looking at ATE. If the answer is still the SDK, then a zero is a real signal.

What actually moves your numbers

Once you stop chasing the display quirk, the work that matters is the same work that always mattered. Get your real paid events, trial conversions, initial purchases and renewals flowing into Meta from RevenueCat. Optimise campaigns on those paid events rather than on installs or trial starts. Give Meta as much matchable information as you legitimately can. Then judge performance on whether your cost to acquire a genuinely paying subscriber sits below what that subscriber is worth, which you can sanity check with the LTV to CAC calculator in a couple of minutes.

If you are also weighing which event to optimise for while you sort this out, that decision matters more than the ATE panel ever will, and it is covered in trial starts versus purchases.

Bottom line

A 0% or blank ATE True Status Rate after moving to RevenueCat is usually not a bug and usually not your attribution problem. Meta only builds that metric from Facebook SDK activity, so routing your purchases server side through the Conversions API is exactly what makes it disappear. The metric went quiet because you took its data away, on purpose, for good reasons.

Your trials failing to attribute is a separate issue. Look at the flag format, event match quality, advanced matching, double instrumentation and your attribution window. That list is where the fix lives. The ATE panel is a distraction dressed up as a diagnostic.

If your events are firing, your dashboards disagree, and you cannot tell which numbers are broken and which are just iOS being iOS, that is exactly what I untangle on a teardown call. I will look at what is actually reaching Meta, how well it is matching, and whether your campaigns are optimising toward real subscribers or toward the cheapest event you happened to leave switched on.