Как считать LTV в SaaS: три модели под разные решения

Зачем вообще считать LTV

LTV показывает верхнюю границу: сколько бизнес может потратить на привлечение и удержание клиента и все еще заработать. Пока вы не знаете, сколько клиент приносит за срок, вы не знаете, сколько за него можно заплатить, - и размер бюджета на маркетинг приходится задавать наугад.

Отсюда простая проверка на пользу: если посчитанный LTV не меняет ни одного решения, вы посчитали его зря.

Какие решения зависят от LTV

LTV нужен не сам по себе, а под конкретные вопросы бизнеса:

• Можно ли масштабировать платный трафик? Выдержит ли экономика, если налить в канал больше бюджета.
• Окупается ли CAC и за какой срок? За сколько месяцев клиент возвращает стоимость своего привлечения.
• Какие каналы и сегменты самые ценные? Куда перекладывать деньги, а что резать.
• Сколько вкладывать в удержание и онбординг? Верхняя граница расходов на то, чтобы клиент не ушел.
• Куда двигать цену и упаковку? Какие тарифы и апселлы поднимают LTV, а не только выручку.

Это разные вопросы, и под них нужен разный LTV, а не одно общее число.

Почему одного LTV не существует

«Чему равен наш LTV» - вопрос без ответа, пока не заданы три вещи:

• направление - считаем факт (что клиент уже принес) или прогноз (что принесет);
• горизонт - за 6, 12 или 24 месяца;
• сегмент - вся база, один канал или одна когорта.

Меняете любую ось - меняется число. Инвестору нужен исторический факт по всей базе, перформанс-маркетингу - прогноз по свежей когорте канала, решению о ставке - прибыль от следующего клиента. Одно «среднее по базе», подставленное во все три решения, - классический способ отмасштабировать канал, который в отдельности убыточен. Поэтому правильный вопрос звучит не «какая формула правильная», а «какая модель LTV подходит под это решение».

Три модели LTV

Практично держать в голове три модели. Они отвечают на разные вопросы, и путать их дорого.

Модель	Что измеряет	Куда смотрит	Под решение
Исторический	Прибыль, которую когорта уже принесла	Назад	Отчетность, факт юнит-экономики
Прогнозный	Ожидаемую прибыль на горизонте по ранним сигналам	Вперед	Масштабирование, свежие когорты
Маржинальный	Прибыль от одного дополнительного клиента	Вперед	Ставки в конкретном канале

Исторический точен, но описывает прошлое - по нему нельзя судить о тех, кто пришел вчера.

Прогнозный достраивает кривую по первым месяцам: решение принимают сегодня, а данные дозреют через год.

Маржинальный отвечает не «сколько стоит средний клиент», а «сколько принесет следующий». По мере масштабирования вы выкупаете все более дорогой и менее качественный трафик, поэтому предельный клиент обычно приносит меньше среднего - и именно маржинальный LTV, а не blended-среднее, решает, поднимать ли ставки.

Как выбирать модель под решение

Главное правило: модель LTV выбирают от решения, а не наоборот. Разберем три частых вопроса.

Окупается ли CAC?

Нужен LTV на марже и на горизонте окупаемости, по когорте - исторический для зрелых, прогнозный для свежих. Критерия два: CAC payback (за сколько месяцев накопленная прибыль отбивает CAC) и отношение LTV : CAC - рыночный ориентир около 3 : 1.

Можно ли масштабировать платный канал?

Здесь blended-LTV обманет. Нужен прогнозный и маржинальный LTV по когорте именно этого канала. Средний по базе легко покажет «плюс», пока маржинальный клиент канала уже уходит в минус. Смотрите на предельного клиента и его окупаемость, а не на среднее по всем источникам.

Какие сегменты самые ценные?

Один LTV на всех прячет ответ. Разрежьте LTV по каналам, тарифам и гео на одном горизонте и сравнивайте одинаковое с одинаковым. Деньги перекладывают в сегменты с лучшим LTV : CAC, а не с самой большой выручкой.

Общее правило на все случаи:

• направление (назад или вперед) = характер решения;
• горизонт = срок, на котором вы готовы финансировать окупаемость;
• сегмент = тот, по которому принимаете решение.

Пример: как неправильная модель греет убыточный канал

Продукт: подписка $100 в месяц, маржа 85%, месячный churn 4%, есть expansion. Наивная модель: 1 / 0,04 = 25 месяцев жизни, LTV = 100 × 25 × 0,85 ≈ $2 125. При CAC $600 отношение LTV : CAC ≈ 3,5 - «масштабируем».

Но $2 125 описывает несуществующего клиента: платит ровно $100, никогда не апгрейдится, уходит строго по расписанию и не возвращается. На реальных данных:

• у выживших чек со временем растет - expansion тянет LTV вверх;
• часть даунгрейдит - contraction тянет вниз;
• 4% - это среднее: в первый месяц churn может быть 8-10%, а к году - 1-2%;
• когорта платного канала живет не так, как органика, а именно ее вы и масштабируете.

Возьмете blended $2 125 - и нальете бюджет в канал, где маржинальный клиент отбивается за 14 месяцев вместо обещанных 7. Формула не соврала в арифметике - вы выбрали не ту модель под решение о масштабировании.

Как это считать на практике

Под все три модели нужна одна основа - когортная кривая на марже. Обычно ее считают не вручную в таблицах, а в пайплайне.

Сначала прибыль, а не выручка: из выручки вычитают переменные расходы (серверы, эквайринг, поддержку, онбординг), а постоянные - зарплаты, аренду - не трогают. Дальше по когортам: каждого клиента привязывают к месяцу первой оплаты и считают накопленную прибыль по «возрасту».

Стек бывает разным, но логика одна. Например, на связке Stripe → BigQuery или Snowflake → dbt → BI: биллинг и продуктовые события выгружают в хранилище (например, через Fivetran или Airbyte), а трансформации раскладывают расчет на слои - revenue → cohorts → ltv. Дальше - как это выглядит в SQL (пример на BigQuery).

Месячная прибыль на клиента:

-- stg_revenue: выручка и маржа по клиенту и месяцу
with invoices as (
  select
    customer_id,
    date_trunc(created_at, month)   as month,
    sum(amount_paid) / 100.0        as revenue      -- центы в доллары
  from stripe.invoices
  where status = 'paid'
  group by 1, 2
)
select
  customer_id,
  month,
  revenue,
  revenue * 0.85 as gross_profit                    -- маржа; лучше из cost-модели, не константой
from invoices

Привязка к когорте и «возрасту»:

-- ltv_cohorts: клиент, его когорта и месяцев с момента старта
with first_pay as (
  select customer_id, min(month) as cohort_month
  from stg_revenue
  group by 1
)
select
  r.customer_id,
  f.cohort_month,
  date_diff(r.month, f.cohort_month, month) as months_since_signup,
  r.gross_profit
from stg_revenue r
join first_pay f using (customer_id)

Кривая LTV - накопленная прибыль по когортам:

select
  cohort_month,
  months_since_signup,
  sum(gross_profit) as cohort_profit,
  sum(sum(gross_profit)) over (
    partition by cohort_month
    order by months_since_signup
  ) as cumulative_profit
from ltv_cohorts
group by 1, 2

Разделите cumulative_profit на размер когорты - получите LTV(N) для каждого «возраста». На этой кривой и стоят все решения выше. Важная тонкость: у молодых когорт правые точки пустые, данные еще не накопились. Не сравнивайте LTV за 24 месяца у зрелой когорты и у той, что прожила три, - вторая занижена просто потому, что не дожила.

Ошибки, которые ломают решения

• Blended-LTV на решение о канале. Среднее прячет убыточные каналы за счет золотых - и вы масштабируете минус.
• Выручка вместо маржи. Без переменных расходов LTV завышен, а вслед за ним раздуваются бюджеты.
• Исторический LTV под форвардное решение. Судите о вчерашних клиентах по позавчерашним; для будущего нужен прогноз.
• Недозревшие когорты в сравнении. Молодой канал выглядит «хуже» не потому, что хуже, а потому что не дожил.
• Бесконечный горизонт. 1 / churn уводит в бесконечность; решают на сроке, который реально видно.
• Константная маржа. × 0.85 в SQL - заглушка вместо настоящей себестоимости обслуживания.
• Рассинхрон с финансами. Возвраты, прорейт и неуспешные платежи не сходятся с P&L - дашборд врет красиво.

С чего начать

Начните не с формулы, а с решения: что вы сделаете по результату - масштабируете канал, измените ставку, вложитесь в удержание. Под него выберите модель (исторический, прогнозный или маржинальный), горизонт и сегмент. Дальше - маржа вместо выручки, когорты вместо среднего, один пайплайн вместо ручных выгрузок. Формула ARPU / churn годится для грубой прикидки, но не для решения, за которым стоят деньги.