Lesson Goal

In Lesson 9 you grouped players into segments and designed fair offers for each.

In this lesson you will:

• Build a simple LTV model based on your real data, not wishful thinking.
• Create a revenue forecast that ties together installs, conversion, ARPPU, and retention.
• Learn a few red flags that warn you when your spreadsheet is lying to you.

By the end, you will have a one-page, conservative forecast you can use to plan scope, marketing spend, and live ops investment.

Step 1 – Define the Questions Your Model Must Answer

Before touching numbers, decide what you actually need the model for.

Common questions:

• Can this game realistically pay for its own development within a certain time window?
• How much can we spend on user acquisition per player or per install?
• How many active players do we need to support one developer, or a small team?

Pick one or two primary questions and write them in plain language.
Your model should stay as small as possible while still answering these.

Mini-task:
Write a short paragraph that starts with:
“We are building this LTV model to decide whether we can safely …” and fill in your main decision (for example, “spend on ads”, “hire a part-time artist”, “add a second project”).

Step 2 – Collect Inputs from Data You Already Have

A useful LTV model does not need dozens of parameters. Start with:

• Installs (per day or per month).
• D1, D7, D30 retention (or whatever you have so far).
• Conversion rate to payer (overall and, if possible, per segment).
• Average revenue per paying user (ARPPU) for each key segment.

Use ranges, not single heroic numbers:

• Conversion: 1–3% (or your measured range).
• ARPPU: low/medium/high based on your data so far.
• Retention: current values, plus a slightly improved target you think is realistic.

If you do not have real data yet, copy conservative benchmarks from similar games and label them clearly as assumptions.

Mini-task:
Create a small table (spreadsheet or notebook) with four columns: metric, current value, target value, and source (data, benchmark, or guess).

Step 3 – Build a Tiny LTV Formula You Can Explain Out Loud

Start with a simple structure such as:

• LTV = paying_users_per_install × ARPPU_over_90_days

Where:

• paying_users_per_install = install_count × conversion_rate / install_count = conversion_rate
• ARPPU_over_90_days comes from your data or a conservative estimate.

If you have retention curves, you can refine this by:

• Estimating days played per user over 30–90 days.
• Estimating how often they see or buy offers in that window.

The key is not mathematical perfection; it is having a short chain of logic you can describe in one paragraph.

Mini-task:
Write your LTV formula on one line. Under it, add one bullet per variable explaining, in one sentence, how you get that number.

Step 4 – Forecast Revenue Scenarios (Low, Base, High)

Next, plug your LTV into a few install scenarios.

For each scenario, specify:

• Installs per month (for example, 1k, 5k, 20k).
• LTV per player (low, base, high).
• Resulting monthly revenue = installs × LTV.

Create three scenarios:

• Conservative – lower installs and lower LTV (what happens if things underperform).
• Expected – your current best guess.
• Optimistic – only slightly better than expected, not a fantasy.

Avoid multiplying your best numbers together (best installs, best LTV, best retention); that is how you create misleading “hockey stick” charts.

Mini-task:
Fill out a three-row table: scenario name, installs per month, LTV, and resulting revenue. Highlight the conservative row in bold; treat this as your planning baseline.

Step 5 – Connect Segments to Your LTV Model

Now bring back the segments from Lesson 9.

For each key segment, estimate:

• Share of total players (for example, 60% new and engaged non-spenders, 30% occasional spenders, 10% strong supporters).
• Conversion rate and ARPPU specific to that segment.

You can then express overall LTV as:

• overall_LTV = Σ(segment_share × segment_LTV)

Where segment_LTV is based on segment-specific conversion and ARPPU.

This helps you see:

• How much you rely on long-term supporters versus broad light spenders.
• Where improvements (for example, better starter offers, safer tests) could move the needle most.

Mini-task:
Pick two segments and estimate a simple segment_LTV for each. Then compute a rough overall LTV using the weighted sum formula above.

Step 6 – Run a Sanity Check and Stress Test

Before you trust any numbers, try to break them.

Ask:

• Are we assuming too many payers compared to similar games?
• Are we assuming too much spend per payer without strong evidence?
• If installs drop by half, can the game still survive on the conservative scenario?

Stress tests to run:

• Cut installs and conversion by 25–50% and see if the project is still viable.
• Reduce ARPPU to the low end of your observed range.
• Increase infrastructure or tool costs slightly and see how much runway you lose.

If the game only looks healthy under the optimistic case, you do not have a reliable business yet; you have a risky experiment.

Mini-task:
Apply a “half installs, minus 25% LTV” stress test to your expected scenario. Write down what you would change in scope, marketing, or live ops if that stress case became reality.

Step 7 – Turn the Model into a Living Document

Your first model is not a contract; it is a living document you should revisit.

Decide:

• How often you will update inputs (for example, every month or after big events).
• Which KPIs trigger a course correction (for example, retention below a certain threshold, or ARPPU far from expectations).
• Who on the team is responsible for maintaining the model and communicating changes.

Store it somewhere visible (shared doc, repo, or task board) and link it from your live ops roadmap in Lesson 7.

Mini-task:
Add a recurring calendar reminder (for example, every four weeks) to refresh your LTV model with the latest data and adjust your roadmap if needed.

FAQ – Common Questions About LTV and Forecasts

“Do we need a very complex model?”
No. For most indie teams, a small, transparent model you understand is better than a huge one nobody trusts.

“What if we have almost no data yet?”
Use conservative benchmarks, label them as assumptions, and update them as soon as you have early player data.

“Can we use this model to justify big ad spend?”
Only if the conservative case still looks safe. Treat paid acquisition as something you ramp up slowly while watching retention and LTV.

Your Checklist Before Moving On

Before the next lesson, make sure you have:

• A clear statement of why you are building this LTV model.
• A short list of input metrics with current and target values.
• A simple LTV formula you can explain in one paragraph.
• Three revenue scenarios (conservative, expected, optimistic) with monthly revenue estimates.
• A first pass at segment-based LTV, even if rough.
• A written stress test outcome and notes on what you would change if the conservative case became reality.
• A plan to update this model regularly as part of your live ops and business reviews.

With this in place, your monetization decisions become grounded in numbers you understand, not just hope.
In later lessons, you will connect these forecasts to platform rules, taxes, and store fees so you can see what actually reaches your studio’s bank account.