App Promotion vs Conversions Objective on Meta: Naming Update
In short: App promotion is a current objective for installs and in-app events. Conversions is retired naming from the pre-ODAX set, where website pixel events were optimized; that work now sits in Sales and Leads. Old guides that contrast app installs with Conversions are comparing a live objective against a renamed one.
By the AdFlint research team · Fact-checked against current Google and Meta platform behavior · Last reviewed July 2026
App Promotion Objective
Drives mobile app installs or in-app events on Meta, requiring an SDK or measurement partner to report those events back for optimization.
You connect the app, choose installs or an in-app event such as purchase or registration, and Meta optimizes across its placements, with Advantage+ app campaigns automating audience and creative. Mobile-first products use it as their main acquisition channel. The mistake is launching before events are wired up, leaving Meta optimizing on installs alone, which reliably buys users who never open the app again.
Full definitionConversions Objective (Legacy)
Pre-ODAX Meta objective name for optimizing toward pixel events, retired when objectives were consolidated and now covered by sales and leads.
Under Meta's older objective set, Conversions was what you selected to optimize toward a pixel or Conversions API event, sitting alongside Traffic and Engagement. The ODAX consolidation mapped it into Sales or Leads depending on the event, and existing campaigns were migrated. The term still appears in older guides and API references. Treat it as a naming legacy, not a capability missing from current accounts.
Full definitionSide by side.
The differences that actually change what happens in your account.
| App Promotion Objective | Conversions Objective (Legacy) | |
|---|---|---|
| Status today | Current objective. | Retired naming, mapped into Sales or Leads. |
| What it optimizes | Installs and post-install events. | A website pixel or Conversions API event. |
| Measurement | App SDK or measurement partner. | Pixel, and now Conversions API alongside it. |
| API naming | OUTCOME_APP_PROMOTION. | The older CONVERSIONS objective enum. |
| Current equivalent | Itself. | Sales for purchases, Leads for contact events. |
| Common confusion | Optimizing on installs alone and buying dead users. | Searching for an objective the account no longer lists. |
What actually separates them.
App promotion was never folded into the conversion tier, because app events run on a different measurement stack from website pixel events.
Old advice comparing installs against Conversions still holds if you read Conversions as Sales or Leads with a website conversion location.
The current Sales objective can select an app conversion location, an explicit choice the older objective set did not present the same way.
Legacy enums persist in exports and integrations, which makes historical app and web campaigns look like they came from different eras.
Both sides share the same underlying rule: optimize on the deepest event you can report reliably, not the cheapest one available.
Which one should you use?
Use App Promotion Objective when
- The app is the product and installs or activations are the constraint.
- Post-install events are reporting through your SDK or measurement partner.
- You want delivery finding people who use apps rather than people who click.
- Retention is the metric the campaign will be judged on.
Use Conversions Objective (Legacy) when
- Reading pre-consolidation documentation or agency material.
- Auditing historical website campaigns carrying the legacy label.
- Maintaining API integrations or dashboards exposing the old enum.
- Translating an old mobile-versus-web plan into the current objectives.
Common questions.
Was app promotion renamed in the consolidation too?
It kept its own place as a distinct objective, since app events are reported through an SDK or measurement partner rather than the pixel. What changed around it was the conversion tier, which became Sales and Leads. Old material comparing installs against Conversions needs only that half of its vocabulary updated.
Should app purchases run under Sales or app promotion?
If the constraint is acquiring new app users, use app promotion and optimize on the purchase event once it reports reliably. If the people you want already have the app, the Sales objective with an app conversion location targets them directly. Many app businesses run both against different audiences.
Why does my reporting still separate them oddly?
Because the two measurement stacks report independently and exports often retain legacy objective enums for historical rows. Installs and in-app events arrive from your SDK or measurement partner while website events arrive from the pixel and Conversions API, so reconciling them requires deliberate work rather than trust in a single dashboard.
Or stop choosing between them.
AdFlint picks the setting, writes the ads, and keeps optimizing inside the Google and Meta accounts you already own.
Related comparisons
- Leads Objective vs Sales Objective
- Sales Objective vs Traffic Objective
- Engagement Objective vs Sales Objective
- Awareness Objective vs Sales Objective
- App Promotion Objective vs Sales Objective
- Advantage+ Shopping Campaigns vs Sales Objective
- Manual Sales Campaigns vs Sales Objective
- Conversions Objective (Legacy) vs Sales Objective