App Promotion Objective

Before anything optimizes, the app has to be connected through the Meta SDK or a mobile measurement partner such as AppsFlyer, Adjust, Branch, or Singular, and the events you want to bid toward, install, registration, purchase, subscription start, and so on, need to be flowing back and ranked in Events Manager's app event priority list. That priority list matters because on iOS, Apple's SKAdNetwork framework only returns a limited number of postbacks per install, so Meta has to pick which single event, among everything you track, gets attributed when a user does several things in a row; the priority order you set determines that choice.

iOS and Android report very differently as a direct result of Apple's App Tracking Transparency framework. Android generally reports user-level events close to real time. iOS, for anyone who has not granted tracking permission, which is most users, routes through SKAdNetwork instead: aggregated, modeled, and delayed by a conversion-value timer window rather than reported instantly per user. Ads Manager labels iOS results as SKAdNetwork-reported versus directly attributed, and the two figures are not meant to reconcile with each other or with Android's.

You can run App Promotion manually, choosing a single optimization event and audience yourself, or through Advantage+ app campaigns, which automate creative combination testing and delivery the same way Advantage+ Shopping Campaigns do for ecommerce. Manual App Promotion earns its place when you need to isolate a platform, since iOS and Android reporting diverge enough that blending spend across both muddies the read on either, test one optimization event against another, or run a distinct re-engagement campaign aimed at a custom audience of existing app users rather than net-new installers.

Value optimization, bidding toward predicted purchase or subscription value rather than raw event count, is available here too, but it needs real volume behind it to work; pointed at a deep, rare event with thin weekly data, it behaves like any Meta bid strategy starved of signal, unstable and unpredictable cost per result. That is the mechanical reason the standard advice is to start optimizing toward install or a shallow early event and only move to a deeper event once volume supports it, not because deep-event optimization is broken, but because the algorithm needs enough weekly examples of the event to find a pattern.

Ads under this objective also support deep linking and deferred deep linking: someone who already has the app gets sent straight to a specific product or screen instead of the app's home page, and someone who does not have it yet gets routed through the install flow before landing on that same screen post-install. Getting this wired correctly through the SDK matters disproportionately for re-engagement campaigns aimed at a custom audience of existing users, where the entire point is pulling a lapsed user back to a specific piece of content rather than just reopening the app to its default screen.

In reporting, expect the iOS and Android splits to look nothing alike even from the same ad set, and do not average them into one blended cost-per-install as though they are measuring the same thing. Read Android's cost per install or cost per event against your own account history since it is the more complete number, and treat iOS's SKAdNetwork figures directionally, as a floor shaped by attribution loss and reporting delay, rather than as a true count of what happened.