CPI vs CPA for Apps: Which Installs Actually Stay?

CPI vs CPA for apps: what is the difference?

CPI (cost per install) means you pay each time someone installs and opens your app. CPA (cost per action) means you pay only when a user reaches a later event you choose, such as finishing the tutorial, registering, or making a first purchase. CPI is cheaper per result and faster to scale, but you carry the risk that users leave on day one. CPA costs more per result, but the seller only gets paid for users who got far enough to matter, so it usually buys installs that stay.

Neither model is cheaper by default. To choose, work out what each costs per retained user and per paying user.

CPI and CPA in app marketing

In app marketing, CPI is the price of one install, usually counted when the app is opened for the first time. What is CPI? covers how installs are counted and how to calculate your maximum CPI. CPA is the wider family: the action can be any event your tracking records. CPI is technically a CPA where the action is the install, but app marketers almost always use “CPA” for an event after the install. What is CPA? explains the formula and its variants.

This article is about the pricing model, the deal you sign. If you bought impressions or clicks instead, what your installs really cost is your effective cost per install (eCPI).

CPI vs CPA side by side

For how both compare with paying per impression or per click, see CPM vs CPC vs CPA.

Who carries the risk in each model

Every pricing model answers one question: if the user turns out to be worthless, who loses the money?

• Under CPI, you do. The seller has done its job the moment the app opens. If 90% of those users never return, you still paid for all of them.
• Under CPA, the seller does. The network or channel pays for the impressions, clicks, and installs that never reach your event. It only earns on users who get there.

Risk has a price, so a CPA is always higher than a CPI for the same app. The real question is whether it is more expensive per user you actually want.

CPA adds one risk of its own: measurement. The event is now an invoice line, so if your tracking misses events the seller stops sending traffic, and if it double counts you overpay. Pay only for confirmed results explains how a postback from your own server keeps both sides looking at the same number.

How networks and platforms optimize for each

Ad networks and offer channels

A network decides where to send traffic by what it earns per user it sends. Under CPI, it earns the full price on every install, so it is rewarded for finding the cheapest installs, whether or not those users stay. Under CPA, it earns only when users reach your event, so its real income per install is the CPA times the share of installs that reach the event.

Network income per install on a CPA deal = CPA x install-to-event rate

That line explains most CPA campaigns that “do not deliver”. A $2.00 CPA for an event only 10% of installs reach earns the network $0.20 per install. If other advertisers pay it $0.50 per install, your offer gets little traffic. Set the CPA from the real event rate.

Self-serve platforms: Google, Apple, and Meta

Self-serve platforms mostly sell auctions with automated bidding toward a target, not a fixed price per result. Their official help pages, checked on October 20, 2026, describe it this way:

• Google App campaigns. Google’s help page Choose a bid strategy for your App campaign lists a target cost per install (tCPI) and Maximize conversions for install campaigns, a target cost per action (tCPA) for in-app actions, and target ROAS for value. Google says each target “aims to deliver” conversions at the set target, so it is an average the system aims for, not a guaranteed price. Google’s best practices for App campaigns recommend a budget of at least 50 times the bid for tCPI and at least 10 times the bid for tCPA, and advise against targeting more than one in-app action unless the actions are equal in value.
• Apple Ads (formerly Apple Search Ads). Apple’s help page on setting and adjusting bids says you only pay when your ad is shown and a tap occurs, and your max CPT (cost per tap) bid is a ceiling. In Maximize Conversions campaigns, Apple’s best practices page describes target CPA as “the ideal amount you want to spend per install”, met on average over a week, and says CPA caps will soon be unavailable. Note that on Apple Ads, “CPA” means cost per install, not a deeper event, and you still pay per tap.
• Meta app ads. Meta’s developer guide Optimize your app ad describes optimizing for app installs to maximize reach, for an app event to reach “people most likely to take the action you specify”, or for value. It adds that you can only optimize for one app event at a time.

The practical difference: with a self-serve target you still carry part of the risk, because a missed target or a learning period is billed to you. With a true CPA deal, paid only for events your server confirms, users who stop before the event cost you nothing.

The math: cost per retained user and cost per payer

To compare a CPI deal with a CPA deal, put both on the same two scales:

Cost per retained user = spend / users still active on day 7 (or day 30)
Cost per payer = spend / users who made at least one purchase

Here is the same $1,000 spent four ways.

What the table shows:

• The cheapest install was the most expensive user. The $0.30 source cost the most per retained user and per payer.
• A shallow CPA can beat CPI on both scales. The tutorial deal cost 2.5 times more per result than the standard CPI but less per day 7 user and per payer.
• A deep CPA wins on payers but loses on volume. The purchase deal bought the cheapest payers but very few active users. If your app earns mostly from ads, those are the wrong people to optimize for.

The CPA deals also bring users you never pay for, those who install but stop before the event. They are not counted here, so the CPA rows are slightly better than they look.

Turning a CPI into a CPA you can compare

You can convert any CPI into the cost of reaching an event by dividing by the share of installs that reach it:

Cost per event on a CPI deal = CPI / install-to-event rate

If you pay $0.50 per install and 25% of those users finish the tutorial, each tutorial costs you $2.00. A CPA offer of $1.25 for the same event is cheaper per completed tutorial, as long as the users are of the same quality. The CPI calculator and the cost per result calculator do these sums with your own numbers, and CAC vs CPA vs LTV shows how to work out what each user is worth.

When CPI fits and when CPA fits

Choose CPI when

• You are launching. You need volume quickly, for store ranking or to learn which events predict revenue.
• Your app earns from ads. Every active user earns something, so a broad top of funnel matters more than a few payers.
• Your event tracking is not ready. CPA depends on events you can report reliably. Until then, buy installs and measure retention by source.

Choose CPA when

• Quality matters more than volume. Subscription, finance, and mid-core game apps often earn from a small share of users, and a CPA on a deeper event pays only for people who got that far.
• You need budget control. With a fixed CPA, a budget turns into a known number of results, and a source that sends low-quality users simply costs nothing.
• You know which event predicts value. Pick the earliest event that separates users who stay from users who leave.
• The traffic is rewarded. Users who install for a reward need a goal that makes them try the app properly. Rewarded user acquisition covers this in depth, and incentivized installs and Google Play policy covers the rules.

Hybrid approaches

Many app marketers do not choose one model. They combine them:

• CPI with event-based optimization. You still run install campaigns, but tell the platform which event matters. Meta’s app event optimization and Google’s tCPA are both versions of this: the platform buys installs, but aims them at users likely to reach your event.
• Multi-step CPA. Instead of one event, the offer has several steps, each with its own payout: for example a small payout for finishing the tutorial, a larger one for reaching level 10, and another for a first purchase. The seller is paid early enough to keep sending traffic, and you pay more only as users prove more value. Multi-event offers explains how to price each step.
• CPI for testing, CPA for scaling. Buy installs in a few countries first, find the event that best predicts retention and revenue, then move the budget to a CPA on that event.

Fraud exposure under each model

Fraud follows the payout. Under CPI, the install is the payout, so the install is what gets faked or stolen:

• Click injection, which AppsFlyer’s glossary describes as an Android-specific fraud where a junk app on the device fires a click just before an install finishes, so a fraudulent source gets credit for an organic install or one another network drove.
• SDK spoofing, which AppsFlyer’s glossary describes as fraud that fakes installs and in-app events on real devices, so advertisers pay for installs that never happened.
• Click spamming and device farms, fake clicks or racks of phones installing apps again and again.

Click injection and SDK spoofing explained goes deeper into both.

CPA raises the bar, because fraud must fake a later event too, but SDK spoofing can fake in-app events, and real users can do the minimum and leave. Three habits protect a CPA budget: confirm events on your own server rather than trusting a client-side signal, validate purchases against store receipts before you report them, and choose events that take real use of the app to reach. Ad fraud and bot traffic lists the warning signs to watch in your data.

Frequently asked questions