Forecasting active users

The building block of a cohort forecast is one multiplication:

expected active users of a cohort in month t = new users in the cohort × share of such a cohort still active at its age

Age is counted from the sign-up month, which is month 0. The share comes from a retention curve, the share of a cohort still active at each age, measured on older cohorts (Retention: day N, rolling or bracket covers the ways to measure it). At Halves, the 2025 cohorts give it month by month.

The key word is "such a cohort". Different kinds of cohorts keep users differently, and at Halves the season decides the kind. Summer cohorts are full of trip groups that settle the bill and leave: at month 3 a summer cohort keeps 30.67% of its users, a regular one 36.10%; by month 11 it's 16.99% against 26.27%.

June 2026 brought 12,904 new users, two-thirds through invites, many into trip groups. In September it's 3 months old, so 12,904 × 0.3067 ≈ 3,958 users are expected active. With the regular curve you'd expect 4,658, which is 700 too many from a single cohort.

A forecast of monthly active users built from cohorts follows the way users actually arrive and leave:

1. New users by sign-up month: actual numbers for past months, the plan for future ones.
2. A curve for each kind of cohort: label each month's cohort (at Halves, summer trip season or regular) and give it that kind's retention curve.
3. Each cohort's age in the target month: September 2026 is age 8 for January, 3 for June and 0 for September itself.
4. Each cohort's active users: its new users times its curve at that age. Month 0 is 1.0, because everyone who signs up uses the app that month.
5. The sum: all the cohorts plus one line for the users who joined before the forecast's first cohort (at Halves, everyone from 2025: 10,894 active in September).

The formula is MAU(t) = older users(t) + Σ new users(c) × r(t − c).

Each input can be argued about separately: the plan for new users, the curves, the season labels. A trend line through past MAU only extends the past.

With the inputs ready, a month's forecast is a sum of products. September 2026 at Halves:

• 2025 users: 10,894;
• January 4,646 × 0.2711 (age 8) = 1,259.5; February 5,106 × 0.2775 (7) = 1,416.9; March 5,395 × 0.2874 (6) = 1,550.5; April 5,504 × 0.3024 (5) = 1,664.4; May 5,987 × 0.3253 (4) = 1,947.6;
• June 12,904 × 0.3067 (3, summer) = 3,957.7; July 14,104 × 0.3829 (2, summer) = 5,400.4; August 14,879 × 0.5002 (1, summer) = 7,442.5;
• September 7,295 × 1.0 = 7,295.

Total ≈ 42,829, below August's 46,166, even though 7,295 people join in September.

Three slips are common: counting ages off by one (age is target month minus sign-up month, so the current month is age 0), using the regular curve for the summer cohorts, and forgetting the older users' line. Keep decimals in the products and round only the total.

Most forecasts that disappoint were too high, and the reasons are predictable.

• One curve for every cohort. If summer cohorts get the regular curve, every trip user is assumed to stay like a flatmate. At Halves that adds 1,166 users in September and 3,179 by December, and the error grows as the summer cohorts age.
• A straight trend line through recent MAU. January–June went from 18,644 to 34,365, but June's jump is mostly summer cohorts that will shrink. Extending the trend carries the peak into autumn, while the cohort forecast turns down in September.
• A plan for new users that is optimistic. The forecast is only as good as its sign-up plan; a missed plan means missed MAU.

Two things that do not bias it up: counting the current month's new users at 100% (month 0 is 1.0 by definition), and including the older users' line. Leaving that line out makes the forecast far too low, by 10,894 in September.

A quick test for any forecast: does it go down when the curves say users leave?

A forecast method can be checked before anyone sees the future: run it on months you already know. This is a backtest. Take the same inputs the forecast uses (new users by month, the curves, the older users' line) and rebuild past months as if they were unknown, then compare with the actual MAU.

At Halves, rebuilding January–June 2026 from the 2026 cohorts and the curves measured on 2025 cohorts lands within 3 users of actual MAU every month: February 20,305 against 20,304, May 25,702 against 25,704, June 34,365 against 34,365. That says the curves and the cohort sum describe how Halves users behave, at least in the first half-year.

What a backtest can't do: check the plan for new users, or a kind of cohort the past didn't contain. This year's summer cohorts are only a few weeks old, so whether they follow last summer's curve is still an assumption, and the note to the board should say so.

A smooth line or a forecast that "looks reasonable" is not a check. Only a comparison with real numbers is.

A scenario changes some inputs and leaves the rest. To find what it costs in users, you only need the cohorts that differ: everything else cancels out.

gap in month t = Σ over changed cohorts (missing new users × curve at the cohort's age in month t)

Halves "paid halved from September": the September–December cohorts are smaller. The missing users are half the paid sign-ups, and from October also the people those missing users would have invited, 0.31 each. In December:

• September 1,313 × 0.3610 (age 3) = 474.0;
• October 1,792 × 0.4158 (age 2) = 745.1;
• November 1,890 × 0.5003 (age 1) = 945.6;
• December 1,995 × 1.0 (age 0) = 1,995.

Gap ≈ 4,159 users, 9% of the plan's 46,081. That matches the difference of the two full forecasts (46,081 − 41,922), which is a good check.

Don't simply add up the missing sign-ups (6,990): many of those users would have left by December anyway.

Cutting acquisition doesn't remove a fixed number of users. It removes a slice from every cohort from the cut onwards, and each of those smaller cohorts stays smaller for the rest of its life. So the gap against the plan accumulates:

• every month adds a new smaller cohort on top of the earlier ones;
• the earlier smaller cohorts shrink with their curve but never catch up;
• with a viral product, the missing users also don't invite anyone, so from the next month the loss compounds.

Halves, paid halved from September: the gap is 1,313 users in September, 2,449 in October, 3,333 in November and 4,159 in December, and it keeps growing into the next year until the cut is reversed. Only then does the gap start to close, slowly, as the smaller cohorts age and retention flattens.

That's why a scenario is reported at a stated month, with the direction: "−4,159 in December and widening", not just "−1,313". The first month of a cut is its cheapest month.

A forecast prices a scenario in users: "halving paid acquisition costs 4,159 active users in December". It can't say whether that's a good trade, because users are not money and the budget saved is.

To decide, put both sides in the same unit:

• saved: the paid spend that won't happen, September to December;
• lost: the gross profit the missing users, paid and invited, would have earned by a stated age, read from cohort LTV curves as in The LTV curve.

If the lost users would pay back their cost slowly (the payback period from CAC, payback and ROI), the cut may be right even though MAU falls; if they pay back fast, it destroys value. Winter paid cohorts took four to five months, and paid-social CAC rose to $1.18 in June, so neither answer is obvious.

Don't reject a cut only because "9% fewer users" sounds bad, or approve it because MAU still rises.

How it fits together: new users × the right curve, summed and backtested, turns a plan into MAU and a scenario into users; then money decides. Next, Invites and viral growth.