Cohort revenue forecasting estimates what a group of users acquired in the same period will earn by a future horizon such as D30, D90, or D365. It gives UA teams an earlier decision signal than waiting for every cohort to mature, but the forecast must remain visibly separate from observed revenue.

The purpose is not to produce a single impressive future number. It is to decide whether a campaign, country, creative, or media source is likely to reach a target ROAS or payback threshold while there is still time to change budget.

What is a cohort forecast?

A cohort groups users by a consistent acquisition definition, commonly install or conversion date. AppsFlyer describes cohort analysis as grouping app users by acquisition date and comparing lifecycle metrics such as revenue, ROI, and event conversion across dimensions including campaign and media source.

A forecast adds a future horizon. For a cohort acquired on August 1, the system may have actual revenue through D3 and estimate revenue at D30, D90, or D365. As actual observations arrive, the forecast should update and the predicted portion should shrink.

Every displayed number therefore needs three labels:

Cohort date: which users belong to the group.
Observation age: how much actual behavior is available.
Forecast horizon: the future point being estimated.

Without those labels, “ROAS” can refer to several incompatible values.

Actual, predicted, and blended values

Value	Meaning	Correct use
Actual revenue	Revenue observed and attributed so far	Financial reporting for the observed window
Predicted future revenue	Model estimate beyond observed behavior	Early budget and payback decisions
Forecast total	Observed revenue plus the predicted remaining amount	Expected outcome at a named horizon
Predicted ROAS	Forecast total divided by aligned spend	Comparing expected efficiency at the same horizon

The interface must not style or name predicted revenue as if it has already been earned. Forecast uncertainty generally falls as a cohort matures, but even a mature forecast is still an estimate until the horizon is observed.

What data should the model use?

Inputs depend on the business model and available consented data. Common signals include early revenue, purchases, subscription events, ad engagement, session behavior, retention, geography, platform, media source, campaign, and creative context.

More features do not automatically produce a better production forecast. Inputs must be available consistently at inference time, stable across app releases, and defined the same way in training and current data. A feature that silently changes meaning can create confident but biased output.

The pipeline should monitor:

Schema and event-definition changes.
Missing or delayed source data.
Changes in traffic mix.
New app versions or monetization mechanics.
Currency and timezone handling.
Training-serving skew.
Forecast error by horizon and business segment.

How should forecasts be backtested?

Backtesting simulates the decision the team would have made in the past. Train only on data available before the evaluation period, create predictions at the intended observation age, then compare them with revenue that later matured to the target horizon.

Randomly splitting user rows is often misleading because information from the future can leak into training. Time-based splits better reflect campaign changes, seasonality, new countries, and product updates.

Report more than one aggregate error number. A robust backtest includes:

Error by forecast horizon.
Bias: systematic overprediction or underprediction.
Error by country, platform, media source, and campaign type.
Error for large-spend cohorts separately from small cohorts.
Coverage and failure rates.
Performance across multiple time windows.

MAPE can be useful when actual values are meaningfully above zero, but it becomes unstable near zero. Pair it with absolute error, weighted error, and bias so small cohorts do not dominate the interpretation.

Turning a forecast into a budget decision

Define the decision rule before looking at the result. For example:

Increase budget only when predicted D90 ROAS exceeds the target, the cohort has reached the minimum observation age, forecast coverage is complete, and recent backtests for this market remain within the accepted error band.

This is stronger than scaling every cohort whose point estimate is above target. It incorporates data completeness and model reliability.

Use sensitivity ranges where the decision is close. If a small change in forecast error moves the campaign from profitable to unprofitable, the correct action may be to hold budget or gather more observations rather than treating the point estimate as certainty.

Lemon AI cohort prediction

Lemon AI combines observed cohort performance with per-user prediction to estimate revenue and ROAS through D365. The dashboard compares actual and predicted values by acquisition date, media source, campaign, creative, country, and platform while preserving the distinction between observed and forecast values.

Read Cohort Prediction for the product workflow, Reports and API for read-only access, and the methodology for backtesting, aggregation, data-quality, and limitation rules.

Cohort Revenue Forecasting for Mobile Apps