LTV forecasts for apps: check the assumptions

Can you trust an app LTV forecast enough to increase acquisition spending? Start by checking what the number includes. A precise output can still depend on weak assumptions. This guide helps product and growth teams review those assumptions before using a forecast.

1. Name the decision and time window

Lifetime value, or LTV, estimates the value a customer generates over time. A forecast needs a stated horizon. A 90-day revenue estimate and a three-year estimate answer different questions. Neither tells you when cash returns unless you examine the timing.

Write the decision above your model: “Can this channel recover acquisition cost within 90 days?” Then use the same window for revenue and acquisition comparisons. Keep observed revenue separate from revenue that the model predicts. Label the date where observation ends.

2. Make the revenue definition consistent

Check whether your input means revenue per install, active user, or paying customer. These denominators are not interchangeable. A payer-only average cannot represent every acquired user unless you also account for the share who pay.

Revenue is also different from contribution after variable costs. Record how you treat refunds, platform fees, payment fees, and delivery costs. Avoid subtracting a cost twice. If your calculator reports revenue LTV, label it as revenue rather than profit.

3. Work through a small example

Consider a hypothetical group of 1,000 installs. Suppose you expect $3,000 in total revenue within 90 days. Revenue per install is $3.00. If variable costs total $900, contribution before acquisition is $2,100, or $2.10 per install.

At $2.40 acquisition cost per install, the group costs $2,400 to acquire. Revenue exceeds that cost, but contribution falls $300 short. This example excludes fixed costs and is not a client result. Its purpose is to show why definitions change a spending decision.

4. Check who the forecast represents

A blended average can hide different groups. Compare users from the same acquisition period, channel, and product experience where your sample allows. Do not transfer a forecast from loyal existing customers to a new paid audience without checking the difference.

Ask whether a price change, promotion, or new onboarding flow changed behavior. Record those changes beside the forecast. If a group is too small to support a separate estimate, show that limit rather than presenting an unstable number as precise.

5. Test the assumption that changes the decision

Build a base case and a downside case. Change one uncertain input first, such as later retention or revenue per active user. Keep the units consistent. Then combine plausible adverse changes to understand how much room the plan has.

Use the retention and LTV calculator to explore how retention and revenue assumptions affect your forecast. Save the inputs alongside the output. A scenario is a planning tool, not evidence that those users will behave as predicted.

If a small input change reverses the decision, reduce the commitment or collect more evidence. If the decision stays useful across plausible cases, document why. Do not choose a downside case merely because it makes the budget look safe.

6. Compare forecasts with later results

Keep a dated copy of each forecast. When the same group reaches the chosen horizon, compare the estimate with observed revenue. Check whether errors cluster around a channel, season, or product change. Revise the assumption responsible for the miss.

A reviewable forecast should state its population, horizon, revenue definition, observed period, and uncertain inputs. Bring those five facts to your next growth review. They make the discussion more useful than a single lifetime-value number.

Further reading: AppsFlyer explains predictive lifetime value. The worked example and review checklist above are illustrative guidance.