Anastasia Nikolaeva

Financial modeling

Mobile app financial model: subscriptions, ads and in-app purchases

A step-by-step financial model for app acquisition, active users and three monetization streams—with a worked month from the original workbook and the assumptions founders should test.

Originally published on the previous websiteUpdated

Updated with new workbook captures, a worked revenue example and clearer guidance on retention, ad delivery, store fees and costs.

Start with active users, not a revenue growth rate

An app can earn from subscriptions, advertising and in-app purchases, but none of those streams is simply a percentage of downloads. First forecast how people discover the app, install it, become active and return. Then define which active users are eligible to subscribe, see ads or buy something in the app.

The three streams can coexist, but they do not suit every product equally. A subscription needs continuing value; advertising needs usable inventory and demand from advertisers; in-app purchases need something worth buying more than once or at a clear moment of need. A financial model should make each claim testable.

Calculation logic

Organic + paid + referral installs → active users → subscribers, ad impressions and purchases → revenue → costs and cash

1. Forecast organic, paid and referral installs separately

The workbook starts with 100 organic installs in the launch month and assumes 10% monthly growth, subject to an upper limit. Organic discovery is not automatically free: content, app-store optimization, partnerships and brand work may require spending even if they do not have a neat cost per install.

Paid acquisition starts with a $5,000 monthly budget and an illustrative $3.50 cost per install (CPI). That yields about 1,429 paid installs in May. The model can change the budget at roadmap milestones and reduce the assumed CPI over time, but neither improvement should be treated as guaranteed.

Calculation logic

Paid installs = paid acquisition budget ÷ cost per install

New installs = organic + paid + referral installs

Mobile app model · workbook extract

The organic and paid acquisition inputs are illustrative assumptions, not measured campaign results. Referrals and activation are modeled separately.

Referrals depend on people who were active in the preceding month. With no prior active users at launch, May has no referral installs; they begin to appear in June. If an incentive is paid per successful referral, include its cost. Keep attributed installs separate so the same person is not counted in both a paid and a referral channel.

CPI measures an install, not a retained user or a paying customer. Check the costs of activating and retaining people before using it as evidence of attractive acquisition economics.

2. Convert installs into monthly active users

In May, 100 organic installs plus approximately 1,429 paid installs become about 1,529 new installs. The model applies 95% activation to reach roughly 1,452 new monthly active users (MAU). The launch month has no opening active users, so the closing MAU is also about 1,452.

Calculation logic

New MAU = new installs × activation rate

Closing MAU = opening MAU + new MAU − lost MAU

Launch and following month in the workbook (rounded users)
MetricMay 2025June 2025
Organic installs100110
Paid installs1,4291,473
Referral installs0145
Total new installs1,5291,728
New active users1,4521,642
Lost active users01,147
Closing MAU1,4521,947

The workbook begins with a 20% month-to-month retention assumption for the existing active base and increases that rate gradually, with a cap. That is a demanding assumption to examine: 20% retention means roughly four out of five of the previous month's active users do not remain active in the next month. A larger inflow of installs can hide that loss in the total MAU line.

Once the app has data, compare this simple roll-forward with cohorts: how many users return after their first week or month, how behavior differs by channel, and whether the users who see ads behave like those who pay. Define an active user consistently; an install, an account and a monthly active user are not interchangeable.

3. Model subscribers, churn and store deductions

A subscription forecast needs an eligible audience, conversion, price, renewals and cancellations. In the workbook, new subscribers are calculated as 4% of closing MAU each month. May's 1,452 active users produce 58 subscribers after rounding. The illustration charges $19 per month and applies 15% monthly subscriber churn to the opening subscriber base.

Mobile app model · workbook extract

Subscription inputs are distinct from app-user retention. The 15% store deduction shown here is an example assumption, not a universal current rate.
Calculation logic

Closing subscribers = opening subscribers + new subscribers − lost subscribers

Net subscription revenue = billable subscribers × price − applicable store deductions

May has no opening subscribers, so 58 closing subscribers at $19 produce $1,102 gross subscription billings. The workbook's illustrative 15% blended store deduction is $165.30, leaving $936.70 in its net subscription revenue line.

This simplified forecast bills the closing subscriber count for a full month and calculates new conversion from total MAU, not only eligible non-subscribers. For a real product, distinguish trials, first payments, renewals, refunds and upgrades; cap new conversions to the eligible population. Annual prepayments also create different cash and revenue timing.

Check your actual store, product and country terms in Apple's subscription guidance and Google Play's fee documentation; the rates in this workbook are only scenario inputs.

Google Play's current service-fee guidance is here.

4. Tie advertising to delivered impressions

Advertising revenue depends on actual opportunities to show an ad, not simply the number of downloads. The illustrative workbook assumes 30 engaged sessions per active user per month, five minutes per session and two ad impressions per minute. That produces 300 modeled impressions per active user each month.

Mobile app model · workbook extract

The workbook uses a $5 CPM and a 0% ad-platform fee in this scenario. The 300-impression assumption is especially important to validate.
Calculation logic

Modeled impressions = ad-eligible MAU × sessions × minutes per session × impressions per minute

Ad revenue = delivered impressions ÷ 1,000 × effective CPM

For May, the workbook applies 300 impressions to all approximately 1,452 MAU, producing about 435,643 impressions. At an illustrative $5 per thousand and no assumed platform fee, that is $2,178.21 in ad revenue. Ten ads per five-minute session is a heavy ad load for many product experiences; test it against actual placements, engagement and retention.

AdMob distinguishes requests, matched ads and displayed impressions in its reporting; use your own delivered-impression and eCPM data when available.

5. Forecast purchasers, orders and item mix

For in-app purchases (IAP), separate the share of active users who buy from how much each buyer spends. The workbook assumes that 2% of active users who are not subscribers make a purchase. It gives two example items a $35 and $25 price and a 20%/80% sales mix, yielding a $27 average item price.

Mobile app model · workbook extract

Item prices and mix determine the $27 average item price; two one-item orders give $54 gross monthly spend per purchasing user.
Calculation logic

Purchasers = eligible MAU × purchase conversion

Gross IAP revenue = purchasers × orders per purchaser × items per order × weighted item price

May's 1,452 MAU less 58 subscribers leave about 1,394 non-subscribers. Two percent, rounded, gives 28 purchasers; two one-item orders at an average $27 produce $1,512 gross IAP billings. With the workbook's illustrative 30% store deduction, the net IAP revenue is $1,058.40.

The model deliberately excludes subscribers from the purchasing pool. If your paid members can also purchase add-ons, model that as a distinct eligible segment rather than assuming they never buy. Test purchase frequency with cohorts and real order data; repeat purchases cannot be inferred from initial conversion alone.

6. Compare revenue with acquisition and delivery costs

The three streams meet in the same monthly forecast, but they do not carry the same evidence or cost structure. May's modeled net revenue, after the specific store and ad-platform deductions assumed above, is:

May 2025: illustrative monthly app revenue
Revenue streamWorkbook calculationNet revenue
Subscriptions58 × $19 − 15% store deduction$936.70
AdvertisingUnrounded impressions ÷ 1,000 × $5 CPM$2,178.21
In-app purchases28 buyers × $54 − 30% store deduction$1,058.40
TotalSum of the three streams$4,173.31

Change one assumption at a time to see which decision moves: lower retention, fewer ad impressions, weaker purchase conversion, a different store-fee mix or a delayed campaign. Track contribution after the costs needed to serve users, and follow cash separately from recognized revenue. Do not use a CPI, a revenue-per-user figure or a blended LTV/CAC ratio without checking its audience, period and included costs.

What the model should help you decide

Choose the stream that fits what users value and how they actually use the app. If a subscription removes ads, reflect that trade-off in both forecasts. If in-app purchases can coexist with subscriptions, define the overlap. Treat store deductions, refunds and delivery costs as part of the economics rather than a footnote.

Before increasing acquisition spend, validate activation, month-to-month retention, delivered ad impressions and willingness to pay with small tests. Then compare actuals with the model monthly and update the assumptions that changed. The useful output is not a single five-year revenue line: it is a clearer choice about pricing, product experience, spending and how much cash is needed to reach the next milestone.

Model your app's actual economics

Need to compare monetization choices, acquisition spending or the cash required to reach launch and growth milestones? Tell me about your app and the decisions the model should support.

Discuss your financial model