Если вы считаете LTV (Lifetime Value) через прибыль, даже валовую, а не через выручку - остановитесь. Прямо сейчас.

С этой ошибкой ваша юнит экономика это фикция. Когда я погружался в тему юнит экономики 4 года назад, я встречал это в 2 из 3 материалов. А позже видел, как это убивает продуктовую аналитику на практике.

Давайте разберёмся почему LTV - это всегда про выручку, и почему попытки улучшить формулу приводят к катастрофе.

LTV не суммированная прибыль.

Во-первых, давайте договоримся о терминах. В отличной бесплатной книге Сергея Трутненко «Юнит-экономика» сказано:

LTV - это ожидаемая средняя суммарная выручка, которую один клиент приносит компании за всё время взаимодействия с ней. Почему?

Потому что LTV - это вход в систему, а не выход. Это то, что клиент даёт бизнесу, а не то, что остаётся после всех издержек. Прибыль - это уже следующий уровень анализа, где мы вычитаем COGS, CAC, OPEX и прочее.

Если вы начнёте считать LTV через прибыль, вы получите получите ложную экономию.

Как это мешает аналитике?

1. Вы теряете связь с реальными денежными потоками. LTV нужен, чтобы понять: сколько денег клиент реально принесёт в кассу? А прибыль - это абстракция, которая зависит от ваших внутренних расходов. Сегодня вы сократили ФОТ и ваш LTV "вырос". Следующий логический шаг - можно позволить CAC выше, чтобы масштабировать юнит. Так вы и делаете. А спустя еще один шаг, осознаете, что если добрать ФОТ обратно, финмодель не сойдётся. Окей, допустим это пример не релевантен, так как ФОТ это fix cost. И некоторые учат, что LTV это именно валовая, агрегированная на средний юнит, прибыль. А не чистая. Тогда, допустим вы - завод бипок, поставщик меняется и COGS растёт на 20%. Значит ли это, что для сохранения прибыли, вы должны сократить CAC? Возможно. Значит ли это, что ваш клиент стал менее ценным, при условии, что вы еще можете экспериментировать? Конечно нет!

Почувствовали, как мы чуть было не убили суть юнит анализа? Ведь он в первую очередь закоючается в поиске точек кратного роста.

2. Вы не можете корректно сравнивать каналы и сегменты

Представьте: у вас два канала привлечения. Канал A: CAC = 500 ₽, LTV (в выручке) = 3000 ₽  →   LTV/CAC = 6 Канал B: CAC = 800 ₽, LTV (в выручке) = 4000 ₽ → LTV/CAC = 5

Кажется, "A" лучше. Но если вы начнёте вычитать переменные расходы (например, 1000 ₽ на поддержку), то:

LTV (в прибыли) для A = 2000 ₽ → LTV/CAC = 4 LTV (в прибыли) для B = 3000 ₽ → LTV/CAC = 3.75

И вы решите масштабировать A. А между тем B - более качественный трафик, который просто требует чуть больше ресурсов на обслуживание. Вы упустили стратегическую возможность.

3. Вы ломаете связь с AARRR

LTV - это результат этапа Revenue в AARRR. Он формируется из:

Среднего чека (ARPU)

Частоты покупок

Срока жизни клиента (Retention)

Если вы внезапно начнёте вычитать себестоимость или CAC, вы разорвёте цепочку. Вы больше не сможете сказать: «Мы увеличили retention на 10% → LTV вырос на X%». Потому что теперь LTV зависит ещё и от того, сколько вы платите за хостинг или техподдержку.

А без этой связи вы не сможете:

Оптимизировать activation

Настроить триггерные цепочки удержания

Проводить A/B-тесты, влияющие на lifetime

Вы просто потеряете управление продуктом.

Почему так делают? Психология улучшателей

Часто эту ошибку совершают самые ответственные продакты. Они думают: «Надо же сразу видеть, сколько чистого заработка приносит клиент!»

Это благие намерения. Но они приводят к путанице уровней анализа.

Правильный подход - многослойный: Уровень 1: LTV = выручка → показывает, сколько клиент даёт. Уровень 2: Contribution Margin = LTV - переменные расходы → показывает, сколько остаётся до покрытия постоянных затрат. Уровень 3: Net Profit = Contribution Margin - постоянные расходы → показывает итоговую прибыль.      Если вы смешаете 1 и 2 - вы не увидите, где именно теряется маржа. Может, проблема не в клиенте, а в дорогой поддержке? Или в логистике? А может, CAC вырос, а не LTV упал?