Your App Event Isn't Eligible for AEO: The Four Reasons Why

There is a particular flavor of frustration reserved for app developers trying to set up App Event Optimization. The event fires. You can see it in your logs. You asked for ATT permission before the paywall like everyone said to. And Meta still refuses to let you optimize toward it, with an explanation that amounts to a shrug. The good news is that AEO eligibility is a checklist, not a mystery, and nearly every failure comes down to one of four things.

What AEO actually needs

App Event Optimization asks Meta to find people likely to perform a specific in-app action, which means Meta needs three things to be true simultaneously. The event must arrive at Meta as a registered app event. Each instance must be attributable to a person Meta can recognize. And the event must occur often enough to be learnable. Your SDK logs only prove the first third of that, which is why "but I can see it firing" is such a common and misleading reassurance.

Reason 1: the event isn't registered where Meta looks

Firing an event through the SDK is not the same as Meta having it registered as an app event available for optimization. Check Events Manager, open your app's data source, and look at the events list. If your subscription event isn't listed there with recent activity, nothing downstream will work.

Common causes: the event was logged with a custom name that hasn't been mapped to anything Meta recognizes; the SDK is initialized but auto-logging and manual events are going to a different app ID than the one attached to your ad account; or the app in Business Manager isn't properly linked as an asset to the account running the campaign. That last one is quietly common after agency handoffs and account restructures.

Also worth knowing: standard events (like Subscribe or StartTrial) get first-class treatment in the optimization picker, while purely custom events may need extra steps before they're selectable. If you're logging something like "sub_success", mapping it to a standard event name is often the fastest fix. The same principle applies on the web side, as covered in Events Manager diagnostics that matter.

Reason 2: the event arrives without usable identity

This is the failure that fools the most people, because everything looks healthy: events flow, counts climb, and optimization still isn't available or performs terribly when it is. The issue is that Meta received the event but couldn't tie it to anyone.

On iOS, if a user denies ATT, you can't pass the advertising identifier, and attribution has to route through Meta's aggregated measurement rather than person-level matching. That's expected and unavoidable. What's avoidable is sending nothing else. Even without IDFA, you can improve matchability by sending hashed customer information with the event when the user has an account: hashed email, hashed phone, an external ID you control. If your subscription event carries no identity at all, it lands as an anonymous count, which is nearly useless for finding similar people.

The quick diagnostic: in Events Manager, look at the event's match quality or matched-events indicators. A healthy volume with near-zero matching is the signature of this problem.

Reason 3: not enough volume to optimize

Meta won't offer optimization toward an event it can't learn from, and subscription events on a young app are often genuinely rare. If you're generating a handful of subscriptions a week, the system may hide or effectively ignore that optimization goal.

The standard fix is to optimize one step up the funnel where volume exists — trial starts, registration completion, or a meaningful activation event — while continuing to send subscription events so Meta still learns who eventually pays. This is exactly the volume-versus-depth tradeoff covered in the conversions-per-week rule, and app campaigns feel it more acutely because install-to-purchase funnels are long.

One nuance specific to apps: value optimization and AEO have separate volume expectations, and value optimization is hungrier. If you're being blocked from value-based bidding rather than AEO generally, volume is almost certainly the reason.

Reason 4: the app or account configuration isn't complete

A cluster of setup requirements can individually block eligibility, and they're unglamorous enough that people skip them:

• The app must be live and properly configured in the developer dashboard, with the platform (iOS/Android) set up and the app ID matching the one the SDK reports.
• The app must be added as an asset in Business Manager and shared with the ad account running campaigns.
• For iOS, SKAdNetwork and Advanced App Measurement settings have to be configured, and your event needs to be mapped in the conversion-schema if you want it usable for iOS campaigns.
• If you use a mobile measurement partner (AppsFlyer, Adjust, Branch), events may route through them, and the mapping on their side decides what Meta ultimately sees. A missing mapping there looks identical to a missing event.

A diagnostic sequence that finds it in 20 minutes

1. Events Manager first, logs second.Open the app data source and confirm your event appears with activity in the last 24 hours. If it doesn't, stop: this is a delivery problem, and no amount of campaign configuration fixes it.
2. Check the app ID in the event detailsagainst the app ID linked to your ad account. Mismatches here explain a surprising share of "the event exists but I can't select it" cases.
3. Inspect identity. Are you sending hashed user data with the event? Is match quality non-trivial? If matching is near zero, fix that before touching campaign settings.
4. Count weekly volume. Under roughly 10 a week, plan on optimizing higher in the funnel regardless of what the interface offers.
5. Verify MMP mappingif you use one, since that's where events silently get renamed or dropped.

The iOS versus Android split, and why it confuses everyone

A detail that produces a lot of wasted debugging: the same event can be perfectly eligible on Android and effectively unusable on iOS, because iOS campaigns route through SKAdNetwork and Meta's aggregated measurement rather than person-level attribution. On iOS, the number of distinct conversion events you can optimize toward is limited by the conversion schema you configure, and events not included in that schema simply aren't available regardless of how healthy they look in Events Manager.

So before concluding your event is broken, check which platform you're trying to optimize for. If Android campaigns can select the event and iOS campaigns can't, nothing is wrong with your SDK implementation — you have a schema configuration task, not a tracking bug. Teams routinely spend days re-instrumenting an event that was firing correctly the whole time.

The related trap is reporting comparison. iOS results arrive delayed and partly modeled, so an iOS campaign will look worse than an Android one for the same real performance, especially in the first few days. Comparing them side by side and concluding iOS tracking is "broken" is one of the most common misreads in app advertising.

Why ATT isn't the whole story

The advice to request ATT permission before showing your paywall is genuinely good — consent meaningfully improves attribution quality for the users who grant it. But it gets treated as a magic switch, and it isn't. ATT governs whether you may use the device advertising identifier. It does not register your event, it does not attach hashed customer data, it does not generate volume, and it does not link your app to your ad account. Teams spend weeks optimizing their consent prompt while the actual blocker is an app ID mismatch or an event that never carried identity. The wider context of what iOS changed, and what it didn't, is in iOS ATT and Meta tracking.

Sending app events server-side

Worth knowing that the SDK isn't your only option. Meta supports a Conversions API for App Events, which lets your backend report the subscription directly rather than relying on the client to fire it. For subscription businesses this is often the better architecture, for a practical reason: the moment money actually changes hands is a server event. Your payment processor tells your backend that a trial converted or a renewal succeeded, and the app may not even be open when it happens.

Reporting from the server also fixes a category of quiet data loss. Client-side events are missed when the app is killed mid-flow, when the network drops between purchase and logging, or when a user completes payment through the App Store outside your session. Server events don't care about any of that. The tradeoff is that you must supply identity yourself — external ID, hashed email, and where available the advertising identifier — and you have to deduplicate against any client-side event covering the same action, the same discipline described in fixing duplicate events. Most mature app setups end up running both, with dedup, rather than choosing one.

After it works

Once AEO is running, the app-side stack has the same long-term weakness as every other tracking setup: it degrades silently. SDK upgrades change event behavior. A release renames an event. A paywall redesign moves where the event fires. An MMP mapping gets edited. None of it errors, and the first symptom is usually cost per subscription drifting upward over several weeks while the team tests creative looking for a cause that isn't there.

The habit worth building is small: after every app release, spend five minutes in Events Manager confirming your optimization event still arrives at the expected volume with the expected match quality. Releases are the moment app tracking breaks, the same way theme updates are that moment on the web. Check at the moment of change and you'll catch nearly everything before it costs you a quarter.