<b>Почему LTV часто “растёт” на дашборде, но не в кассе приложения</b>

<b>Почему LTV часто “растёт” на дашборде, но не в кассе приложения</b>

LTV ломается не в одной точке, а на связке: цена входа, конверсия в trial/покупку, удержание после оплаты и доля возвратов. Если один слой проседает, красивый средний LTV маскирует проблему.

Проверяйте монетизацию по цепочке:
— paywall view → CTA click → purchase start → paid
— trial start → trial-to-paid
— day 1/7/30 retention у платящих
— refund rate и churn по когортам
Если считать только revenue / installs, можно переоценить эффект любого теста.

Самые частые рычаги:
— убрать лишний выбор тарифа на первом экране
— показать ценность до цены, а не наоборот
— разделить free и paid сценарии по intent
— не смешивать в одной когорте органику, paid и re-engagement
Иначе вы оптимизируете не LTV, а шум в данных.

Для A/B теста смотрите не только uplift по выручке, но и перенос эффекта на 14–30 дней: ранний прирост часто исчезает, если пострадало удержание. В подписках особенно важно считать не “первую оплату”, а суммарную выручку на пользователя по когорте.

LTV растёт там, где каждая ступень воронки измеряется отдельно и не конфликтует с остальными. Если хотите быстрый приём — начните с разреза по когортам платящих, а потом ищите, какой именно экран или триггер съедает будущую выручку.