How to Calculate App Revenue: The Formula, and Where It Breaks

App revenue reduces to one line: paying users multiplied by what each one pays, minus the store's cut. Everything else is a refinement of those three numbers.

The formula fits on a napkin. Estimates still land wildly apart, for two reasons. Two of the three inputs are assumptions rather than measurements. And the third, the store's commission, is rarely the flat 30 percent most people plug in.

• In-app purchases and subscriptions: paying users, times average revenue per paying user, times one minus the store commission.
• Advertising: impressions times eCPM, divided by 1,000. The store takes none of it.
• The commission is 15 or 30 percent, and the gap between them is worth more than most pricing experiments.
• Price is the sensitive input, and the only one that can change today without shipping code.

Two engines, two different formulas

Most apps earn through one of two mechanisms, and mixing them into a single formula is the most common way an estimate goes wrong. Purchases run through the store's billing system and are taxed by it. Advertising does not run through the store at all.

The purchase formula

Net revenue = MAU × conversion × ARPPU × (1 − commission)

MAU         active users in the period
conversion  share of those users who pay
ARPPU       average revenue per paying user
commission  the store's share: 0.15 or 0.30

A worked example, and it is an illustration rather than a benchmark. An app with 50,000 monthly active users, 3 percent of whom subscribe at $9.99 a month, grosses roughly $14,985 a month. At the standard 30 percent commission the developer keeps about $10,490. On the reduced 15 percent rate the same app keeps about $12,737.

That commission tier is worth 21 percent of net revenue. Keeping 85 percent instead of 70 percent is a 1.21x multiple on everything the app earns, with no change to the product, the price, or a single line of code.

The advertising formula

Ad revenue = impressions × eCPM ÷ 1,000

eCPM  effective earnings per 1,000 impressions
      normally quoted net of the ad network's share

Take 20,000 daily active users seeing 4 ad impressions each. That is 2.4 million impressions in a 30 day month. At an $8 eCPM the app earns roughly $19,200, and Apple and Google take none of it, because no purchase passed through their billing systems.

This is the detail that trips up hybrid apps. Ad income and purchase income cannot be summed and then reduced by 30 percent. The commission applies only to the purchase side. Anyone running hybrid monetization should model the two streams separately and add them at the end.

The commission is not one number

The 30 percent figure is the headline rate, and a large share of developers never pay it.

Two apps with identical users, identical prices and identical conversion can differ by 21 percent in net revenue purely on which row they sit in. Any calculation that hard-codes 30 percent is wrong for most of the market. The full picture of what each platform charges, including when a web checkout starts to make sense, is in the comparison of Stripe and app store fees.

Where the formula breaks

The napkin version holds up for scale. Ask it for precision and it fails in four predictable places.

• Tax comes out first. In many storefronts the store removes local VAT or GST before calculating its commission, so the number the percentage applies to is smaller than the gross figure in the dashboard. Check a real payout statement rather than assuming.
• Refunds are not modeled. Gross revenue includes purchases that will later be reversed, and the store's commission on a refunded purchase is not always returned.
• Country mix changes everything. A paying user in the United States and a paying user in a low-ARPU market are the same row in a spreadsheet and very different amounts of money. A single global ARPPU hides that.
• Churn eats the subscription number. ARPPU for a subscription business is not the sticker price. It is the sticker price multiplied by how many months the average subscriber stays, which is a function of trial conversion and retention, not pricing.

This is also why two commercial estimators can look at the same app and disagree by a wide margin. They are not guessing the price, which is public. They are guessing conversion and country mix, and those assumptions compound.

Which input moves the number most

Run the sensitivity and a clear order appears. Raise price by 10 percent and, if conversion holds, gross revenue rises by 10 percent. Raise conversion by 10 percent and it does the same. The two are arithmetically equivalent and operationally nothing alike.

Conversion is a product problem. It takes an onboarding rebuild, a paywall test, a retention campaign, and a release cycle to find out whether it worked. Price is a field in App Store Connect. It changes this afternoon, it can be changed per country, and the effect shows up in the next payout.

That asymmetry is the practical reason revenue models tend to be more useful as pricing tools than as forecasting tools. The model tells you what a price change is worth before you make it. To forecast your own app's next twelve months from your real user, churn and price numbers, the app revenue estimator does that arithmetic directly.

Five checks before quoting a revenue number

• State whether it is gross or net. A number without a commission assumption is not a revenue figure, it is a press release.
• Name the commission rate you used. If it was 30 percent, justify why the app is not on the 15 percent tier.
• Separate ads from purchases. Never apply a store cut to ad income.
• Show the country mix, or admit there isn't one. A global ARPPU with no geographic weighting is an average of things that are not comparable.
• Sanity-check against price. Price is the one input in the whole model that is public and exact. If the revenue estimate implies a price the app does not charge, the estimate is wrong.

Frequently asked questions

What is the formula for app revenue?

For purchases and subscriptions: active users multiplied by the share who pay, multiplied by average revenue per paying user, multiplied by one minus the store commission. For advertising: impressions multiplied by eCPM, divided by 1,000. Apps that do both should calculate the two separately and add them.

Do the app stores take a cut of ad revenue?

No. Apple and Google take a commission on purchases processed through their billing systems. Advertising revenue is paid by the ad network directly to the developer and carries no store commission.

Is the App Store commission always 30 percent?

No, and assuming so is the single most common error in these calculations. Developers earning under $1 million a year qualify for 15 percent, and subscriptions drop to 15 percent after twelve months of a paid subscriber's tenure. Google Play applies 15 percent to subscriptions from day one.

How accurate is an app revenue calculator?

For your own app, as accurate as the inputs, because the users, churn and price are measured rather than modeled. For someone else's app, the price is exact and everything else is an assumption, so the output is a range rather than a figure.

What moves app revenue the most?

Price and paying conversion move it identically in arithmetic. Price moves it faster in practice, because it can be changed per country without a product release.

The input worth checking first

Every term in the formula is an estimate except one. Price is public, exact, and set per country, and it is usually the term carrying the least attention. The Mirava Index shows what comparable apps charge in each market, which turns the shakiest assumption in a revenue model into the firmest one.

So before refining a conversion rate to the second decimal, the cheaper question is worth asking first: does the price in each market reflect what that market will pay?