Every performance campaign starts with the same question, and most teams answer it too quickly: what event are you actually willing to pay for? Get that wrong and everything downstream — creative, traffic mix, publisher incentives, your own reporting — quietly optimizes toward the wrong outcome. Get it right and the campaign more or less manages itself.
CPI, CPA and CPS are not three prices for the same thing. They are three different contracts about where risk sits. Understanding that is the whole decision.
CPI: paying for the install
Cost per install pays out the moment a referred user installs and opens your app. It is the simplest model to run, the easiest to forecast, and the fastest way to put real volume through a campaign. For a new title that needs a install base before its own data means anything, that speed matters more than efficiency.
The catch is that an install is a weak signal of intent. You are paying for someone who tapped a button, not someone who found value. On CPI the risk of a low-quality user sits entirely with you, the advertiser — the publisher has already been paid. That is why CPI campaigns live or die on fraud filtering and post-install measurement rather than on the rate you negotiated.
CPI is usually the right call when:
- You are launching and need a install base before cohort data becomes meaningful.
- Your app monetizes on ads, where sheer active-user volume is the revenue driver.
- You are testing a new geo and want a cheap read on whether the creative and store listing land at all.
- Your category has a short path from install to value — casual and hyper-casual games, utilities, content apps.
If you run CPI, insist that every install is attributed by your own MMP and that you can see sub-publisher breakdowns. A blended CPI that looks excellent is often two or three sources subsidising a pile of junk. The number to watch is not CPI but the ratio of installs to your first meaningful in-app event, segmented by source.
CPA: paying for the action that matters
Cost per action moves the payout trigger past the install to an event you actually care about: a completed tutorial, a card added, a KYC check passed, a first order placed. The rate per unit is higher — often several times higher — because the publisher is now carrying the risk of the users who install and never convert.
That risk transfer is the point. On CPA, a publisher sending unengaged traffic simply does not get paid, so the incentive to find genuinely interested users is structural rather than contractual. In practice, CPA campaigns clean themselves up faster than CPI campaigns policed by a fraud team.
The cost is complexity. CPA only works if the event is instrumented correctly, fires reliably, and cannot be gamed. An event that can be triggered by a script is an event you will be billed for. Before launching CPA, confirm three things: the event is server-side validated, the postback reaches your network within a window everyone agrees on, and there is a holdback period for reversals.
CPA suits fintech, subscription apps, and anything where the install is a formality and the real threshold is further in. It is also the honest model for mature apps: once you know your funnel, paying for installs you can already predict will churn is a choice, not a necessity.
CPS: paying out of revenue
Cost per sale pays a share of a completed transaction — a flat fee per order or a percentage of order value. It is the default across e-commerce and marketplaces, and it is the only model where your acquisition cost cannot structurally exceed your revenue on that transaction.
That makes CPS the safest model on paper and the hardest to scale in practice. Publishers know exactly what it means: they carry all the risk, from click through to checkout, and get paid only if the user pulls out a card. Good CPS publishers are therefore selective, and the ones who will run your offer at volume are usually the ones with genuine commercial audiences — comparison sites, cashback, content with buying intent.
If you run CPS, the variables that matter are attribution window and order-value tiering. A seven-day window on a category people research for a month will systematically under-credit your best partners, and they will quietly deprioritise you for an advertiser who does the maths properly.
The models nobody mentions: CPL and CPR
Two more models sit between the big three and are frequently the correct answer. Cost per lead pays on a qualified form fill, demo request or pre-approval — standard where a sales team takes over after the handoff. Cost per registration pays on a completed account signup with verification, not just an app open, and is common in gaming and fintech where real value sits behind an account.
CPR in particular is underused. For apps where registration is the genuine commitment point, it gives you most of the quality protection of CPA with a far simpler event to instrument and dispute.
How to actually choose
Work backwards from your unit economics rather than forwards from your budget. Find the earliest event in your funnel that reliably predicts lifetime value, and pay for that. If installs predict nothing, do not buy installs. If a first deposit predicts everything, buy first deposits and accept the higher unit price, because you are buying a smaller number of users who are worth something.
The right model is the earliest event in your funnel that still predicts revenue. Everything before it is volume; everything after it is unnecessarily expensive.
The practical answer is often a hybrid. Open on CPI to build volume and gather cohort data, then move the best-performing sources onto a CPA or CPR structure once you know which post-install event separates a good user from a bad one. Blended, this typically lands somewhere between the two rates while delivering closer to CPA quality — which is exactly the outcome you want.
Whichever model you land on, the non-negotiable is that your own MMP confirms the billable event. Across AppGro's 250+ campaigns and 25+ GEOs, the campaigns that hold their efficiency over months are the ones where advertiser, network and publisher are all reading the same number from the same source. Every argument about performance is really an argument about measurement.
If you are not sure which model fits your funnel, that is a solvable problem — it takes a conversation about your event data, not a rate card.