Cost Per Install

What CPI measures

Cost per install is the average advertising cost behind one attributed app install:

CPI = App acquisition spend ÷ Attributed installs

Two usages share the name. As a pricing model, CPI means paying networks per install delivered — common in affiliate-style and incentivized inventory. As a metric, it's the realized average cost regardless of how the buying was priced (CPM and CPC buys still produce an effective CPI). The metric usage dominates modern UA, since the big platforms price by auction and optimize toward installs or downstream events.

The word attributed is load-bearing. Install counts come from an MMP's ruleset — windows, last-click priority, view-through treatment, and on iOS the aggregate logic of SKAdNetwork. Change the rules and CPI changes with no change in reality. Comparing CPIs across channels is meaningful only when the attribution settings match.

What sits behind a CPI difference

CPI varies enormously and mostly legitimately, by:

• Platform and geography. iOS users in tier-one markets cost multiples of Android users in emerging markets — tracking both ability to pay and auction competition.
• Category and competition. Casual games with broad appeal see low CPIs; fintech and social apps competing for narrow audiences pay heavily.
• Channel and inventory type. Rewarded and incentivized placements deliver cheap installs with weak intent; search-driven installs from Apple Ads cost more and convert deeper.
• Creative and store conversion. Half of CPI is the store page: paid traffic converts through the same listing organic traffic does, so ASO improvements cut effective CPI across every channel simultaneously.
• Targeting depth. Optimizing toward in-app events rather than raw installs raises CPI by design — the algorithm skips cheap, low-intent users on purpose.

CPI's structural limitation

CPI prices the door, not what walks through it. Channels reliably differ several-fold in post-install behavior, and the cheap end of the CPI range is systematically the worst: incentivized installs that never open the app twice, fraud-inflated traffic, broad low-intent inventory. Optimizing acquisition on CPI alone therefore selects for exactly the users you don't want.

The repair is pairing CPI with downstream value:

Payback condition: LTV (over horizon) > CPI + variable costs

Practical operationalization: track cost per retained user (D7 or D30) and cost per first conversion event alongside raw CPI, and judge channels on LTV-to-CPI ratio at a defined horizon rather than CPI rank. A $4 CPI channel whose users retain at twice the rate of a $2 channel is the cheaper channel.

Fraud belongs in this calculus: install farms, click injection, and SDK spoofing all manufacture installs that look real and cost real money. MMP fraud filtering (AppsFlyer, Adjust) plus skepticism toward too-cheap-to-be-true sources is the working defense — anomalously low CPI with flat retention curves is the classic signature.

Managing CPI in practice

1. Define the unit consistently. One attribution ruleset across channels (the MMP's), documented windows, stated treatment of view-through and re-attribution.
2. Segment before reacting. Blended CPI moves whenever mix shifts; per-channel, per-geo, per-campaign CPI is where signal lives.
3. Optimize toward events, not installs, once volume allows. Event-optimized campaigns raise nominal CPI and usually lower cost per valuable user — the number that matters.
4. Work the conversion side. Store-page tests and creative refresh lower CPI at constant bids; they're often cheaper than auction improvements.
5. Set CPI ceilings from LTV, not from benchmarks. Public CPI averages describe other apps' economics; your ceiling is your modeled payback.
6. Watch lag and learning effects. New campaigns and fresh creative run expensive during learning phases; judge after stabilization, not on day two.

Common mistakes

• Choosing channels by CPI alone. The ranking inverts once retention and monetization enter; cheap installs are frequently expensive users.
• Ignoring install fraud. Unfiltered networks can deliver large fractions of fake installs — paying for them is bad; optimizing toward them is worse.
• Comparing different attribution windows. A channel measured on 30-day click+view will always look more efficient than one on 7-day click; the comparison is broken, not the channel.
• Letting incentivized traffic blend in. Rewarded installs have their uses (burst campaigns, chart pushes), but averaged into core UA reporting they make everything look cheaper than it is.
• Treating iOS SKAdNetwork CPIs as user-level truth. Threshold-gated, delayed, aggregate data needs wider error bars and slower decisions than the dashboard's precision implies.

FAQ

What's a good CPI? Whatever your LTV supports at your required payback horizon — the only universal answer. Cross-app benchmarks mostly encode category, platform, and geography mix; an acceptable CPI for a subscription app would bankrupt a hypercasual game.

Why did my CPI jump? In rough order of frequency: creative fatigue, learning-phase resets after edits, seasonality in auction pressure, mix shift toward expensive geos or placements, and event-optimization changes deliberately buying deeper users. Segment first; most jumps are composition, not catastrophe.

CPI or CPA for app campaigns? CPI for early-stage volume and creative testing; cost-per-event (CPA-style, on registration, trial, or purchase) as soon as event volume supports it. Mature UA treats installs as an intermediate metric, not the goal.

How does SKAdNetwork change CPI measurement? iOS installs arrive aggregated, delayed, and privacy-thresholded, so channel CPI on iOS is partially modeled. Practical adaptations: longer evaluation windows, conversion-value schemas designed around business priorities, and tolerance for bands rather than exact numbers.

Where does CPI fit in the full UA stack? As the acquisition-cost layer between auction metrics (CPM, CPC) and value metrics (retention cost, LTV/CPI). The app user acquisition path traces that chain end to end.