A very common modelling error, and an easy one to check for in your own spreadsheet.
Most free-to-play revenue models run on a blended average. Average revenue per daily active user, applied to a projected active user base. Multiply forward, get revenue.
The trouble is that daily active users are not one population. They are two, and the two behave nothing like each other.
What the blend hides
In a typical free-to-play title, a small minority of players ever spend anything. So blended ARPDAU is an average across a group where most members contribute zero and a few contribute a great deal.
That average moves for two entirely different reasons, and the blend cannot tell them apart.
More people converted to payer. Genuinely good. More of your base is monetising.
The non-paying base shrank. Not good at all. Your denominator got smaller, so the average went up while the business got worse.
Both show as ARPDAU rising. A model built on the blend will read the second as success and forecast forward from it, which is how a title in decline produces an improving revenue projection right up until it does not.
The free calculator is a blended model on purpose, one ARPDAU on one curve, which makes it a fair place to watch this happen. Open it at its defaults with ARPDAU at $0.14 instead of $0.12 and nothing else changed, which is what extending a spreadsheet does with a new number. Payback improves from day 207 to day 156. If the rise came from non-payers leaving, nothing improved: revenue per install is where it was, and the forecast has booked 51 days of progress that does not exist. Those are the calculator's published defaults with one input changed, not a customer result.
The split that fixes it
Two separate questions, modelled separately.
Conversion to payer. What proportion of installs ever spend, and when does that conversion happen relative to install. This is largely a product property. It responds to onboarding, first-session design, offer placement and price architecture.
Payer retention and payer value. Once someone has spent, how long do they stay and what do they spend. This is a different population with a different retention curve — usually a much flatter one — and a different set of things that move it.
Run those separately and the model tells you something the blend cannot. That revenue is soft because conversion has dropped, which points at the product funnel. Or that conversion is fine and payer retention has deteriorated, which points at content cadence, economy balance or competitive pressure on your highest-value players.
Same headline number, two opposite diagnoses, two different teams who need to act.
Why payer retention deserves its own curve
The consequence people most often miss is on the retention side.
Payers retain very differently from the general base. Someone who has spent has demonstrated commitment, has sunk cost in progression, and frequently has purchased something that makes continued play more rewarding. Their curve is flatter and extends much further.
Apply a general retention curve to your revenue projection and you will systematically understate long-horizon revenue, because you are decaying your paying population at the rate of a population that mostly never cared.
Apply an optimistic single curve to compensate and you will overstate active users, which corrupts everything downstream that depends on the size of the base — including organic install generation, if you model it properly.
There is no single curve that is right for both. That is the point.
The check you can run today
Open your model and find where revenue is calculated. Ask three questions.
Is there a single ARPDAU figure applied to a single active user projection? If so, the two populations are blended.
Is there one retention curve? If so, your payers are decaying at the rate of your non-payers.
When ARPDAU moves in your historicals, can you tell whether conversion moved or the base shrank? If not, you cannot interpret your own trend line, and every forecast built from it inherits that ambiguity.
Most models fail at least two of these. It is not a sign of a careless team. It is what happens when a model is built quickly, works well enough at first, and then gets extended rather than rebuilt.
What it costs to fix
Less than people expect, if you have the data. Conversion to payer and payer retention are both directly observable in any analytics stack. The work is restructuring the model to carry two populations forward rather than one, which is a spreadsheet problem rather than a data problem.
If you do not have the data — pre-launch, or a soft launch too small to produce a stable payer cohort — the honest answer is to start from fitted values for your genre and monetisation model, and replace them as your own numbers arrive. That is still better than a blend, because at least the structure is right and you know which input you are borrowing.
Running it
Kadar models conversion to payer separately from retention by construction, with cohorts tracked forward day by day rather than blended into a monthly average. Where you have no data yet, it ships defaults across five genres and three monetisation models, fitted from observed data where that exists and labelled where it does not, so a pre-launch title still starts from a credible structure.
Run your own numbers in the free calculator. No sign up.