In-App Purchase Revenue Calculator

In-app purchase revenue in this model depends on daily active users, the share of them buying, the average purchase value, how much repeat buying happens, and the store’s cut. Store fees are the one input that is set externally and they are neither uniform nor static. Apple’s small business programme applies a reduced commission of 15% on paid apps and in-app purchases for developers whose proceeds were up to one million US dollars in the prior calendar year. Google Play states that of the developers subject to a service fee, 99% qualify for 15% or less through its various programmes, and its published fee structure differs by region and by whether an install is new or existing. That variability is why the fee sits here as an input rather than a constant.

Working the loaded figures through: 50,000 daily active users at a 3% conversion rate gives 1,500 paying users a day, which over 30 days is 45,000 first purchases. The repeat rate then adds more. At the loaded 40%, repeat buyers contribute a further 36,000 purchases, bringing the month to 81,000. At 5 each that is 405,000 of gross revenue, from which a 30% store fee takes 121,500, leaving 283,500 net and 3,402,000 across a year.

The repeat figure deserves a note, because entering 40% does not add 40% to the purchase count. The model treats each repeat buyer as making two further purchases, so a 40% rate multiplies the base count by 1.80 rather than 1.40. Conversion rates and purchase values vary widely by genre and by market, and averages hide a long tail in which a small share of players accounts for a large share of spend, so an average value is a summary rather than a description of how anyone actually buys.

A worked example

With 50,000 daily active users, a 3% conversion rate, a 5 average purchase and a 40% repeat rate at a 30% store fee, the calculator returns 1,500 paying users a day, 405,000 of gross monthly revenue, 121,500 of store fees and 283,500 net, or 3,402,000 a year.

The repeat rate carries more weight than its label suggests. Because each repeat buyer is modelled as making two further purchases, the total purchase count is the base multiplied by one plus twice the rate: 1.00 at a 0% rate, 1.80 at 40%, 2.00 at 50% and 3.00 at 100%. Net monthly revenue moves with it, from 157,500 with no repeat buying to 283,500 at the loaded rate, 315,000 at 50% and 472,500 at 100%.

What moves the number most

Every calculation input is a simple multiplier, which means none of them dominates and any two changed by the same proportion produce the same answer. Doubling daily active users from 50,000 to 100,000, doubling the conversion rate from 3% to 6%, and doubling the average purchase value from 5 to 10 all return exactly the same 567,000 a month. The choice between growing an audience and improving conversion is a question about which is cheaper or more achievable, not about which the arithmetic rewards more.

The store fee is the exception in kind rather than in weight, because it is subtracted rather than multiplied in and because it is not under a developer’s control. Moving from 30% to 15% on the same gross revenue lifts net monthly revenue from 283,500 to 344,250, a difference of 60,750 a month and 729,000 across a year, without a single extra purchase.

The formula behind this

Paying users per day are daily active users multiplied by the conversion rate. First purchases in the month are that figure multiplied by 30. Repeat purchases are the first-purchase count multiplied by the repeat rate and then by two, reflecting the assumption that a repeat buyer makes two further purchases. Total purchases are the two added together, gross revenue is total purchases multiplied by the average value, and net revenue is gross less the store fee, with the annual figure at twelve times the monthly one.

Collapsing that gives the whole model in one line: net monthly revenue is daily active users, times the conversion rate, times 30, times one plus twice the repeat rate, times the average purchase value, times one minus the store fee. Every term is multiplicative, which is what makes the inputs interchangeable and the result so sensitive to compounding optimism across several of them at once.

What this doesn't capture

Averages are doing heavy lifting here. Spending in this category is famously concentrated, with a small share of payers accounting for a large share of revenue, so a single average purchase value describes the arithmetic rather than the population. A flat repeat rate applied to all payers has the same limitation: it substitutes one number for a distribution of behaviour that ranges from a single purchase to hundreds.

The month is treated as a flat 30 days with constant activity, so there is no seasonality, no live-event spike, no cohort ageing and no churn. Refunds and chargebacks are excluded, and both reverse revenue already counted. Store fees are entered as a single rate, whereas a title distributed on more than one platform faces different rates that also differ by region and by programme eligibility, so a multi-platform figure needs each store calculated separately and the net results added. Currency conversion, payment provider costs and any tax on the earnings all sit outside the model as well.