A top-down approach when you have no data to go on

For years I did what everyone does.

I opened the spreadsheet, typed in retention curves, guessed at ARPDAU, and then watched the whole thing wobble around depending on which numbers I’d pulled out of thin air that day. You can make it look precise, even sensible. You can colour-code the cells, add confidence ranges, throw in a sensitivity table. But if the inputs are guesses, the outputs are theatre.

What bothered me was not even the inaccuracy. It was the way those models steer the conversation.

You end up debating D30 retention before you have a product. You argue about ARPDAU as if it’s a lever you can pull on day one. You spend hours talking in metrics that mean something to an analyst in soft launch, but not much to a designer trying to build a game worth returning to.

Retention and ARPDAU are not bad metrics. They are just the wrong place to start when you have no data, and when the team needs targets that feel concrete.

That’s what pushed me to build a different kind of forecasting tool, and why it took me so long to finish it. It’s now live here

Most forecasting spreadsheets I’ve seen are some variation on this:

• D1 / D7 / D30 retention
• DAU modelled from installs and retention
• ARPDAU multiplied by DAU to get revenue

Once you have a live game, that approach can be genuinely useful. During soft launch you can ask “if D30 improves by 20%, what happens?” and the model can tell you something actionable. The problem is the early stage, when the game is still mostly intention.

In early development those numbers vary wildly by genre, audience, platform, country mix, creative, onboarding, meta, monetisation, and the simple fact you have not shipped anything yet. So you guess. Then you guess again, because the first guess feels too optimistic. Then someone else guesses and it becomes a negotiation.

Uncertain variables multiply. A model built on ten guesses is not ten times riskier, it’s worse than that. Each assumption stacks on top of the last until you can get almost any answer you want. And if a spreadsheet can give you any answer, it will eventually be used to justify the answer someone already wanted.

At some point I realised I kept wanting the same thing from forecasting in the early stage: a small number of targets a team can actually hold in their head.

Designers rarely think in ARPDAU. Even product people struggle to make it feel real before launch. But revenue per user, or better, revenue per paying user, can be broken down in a way that maps to real behaviour. You can talk about low, mid, and high spenders. You can talk about what percentage of players you expect to ever pay. You can talk about what the game is for, and what it needs to deliver, rather than what you hope the curve will look like.

So this tool starts higher up the chain and works downwards. It uses a top-down approach, based on third-party benchmarks:

• revenue per download from comparable live titles (a practical proxy for ARPU or LTV)
• CPI benchmarks for the kind of game you’re building

That gets you to a basic commercial picture with fewer moving parts. You are still making assumptions, but you are making fewer of them. More importantly, you can point at where they came from, and you can adjust them without pretending you’re “predicting” anything.

When I built the model, I used AppMagic as a source for revenue-per-download benchmarks. Unfortunately it no longer provides revenue-per-download (RpD) on the free tier. If you don’t have access to AppMagic or Sensor Tower, you’ll need to use estimates or benchmarks from other sources and treat them as assumptions rather than facts. The sheet still works fine. You’re just choosing the best RpD input you can justify.

Here’s the link to the model again. It’s a read-only Google Sheet, so you’ll need to copy or download it to make changes. Then tweak the assumptions and see what shape of the business drops out. It’s not designed to be the final answer. It’s a starting point that trades false precision for clarity: fewer moving parts, fewer stacked assumptions, and targets that are easier to communicate and build around.

If you want to talk about customising it for a specific project – genre, market, UA plan, monetisation design, the whole messy reality of an actual business case – do get in touch.