Реальный LTV и Retention Rate: как считать, а не рисовать в отчёте

Реальный LTV и Retention Rate: как считать, а не рисовать в отчёте

Если смотреть только на первый депозит, кампания почти всегда выглядит «здоровой». Но реальный LTV считается по когорте: дата первого конверсии, затем выручка по окнам 7/14/30/60 дней и дальше по хвосту. Без этого вы смешиваете быстрых и долгих пользователей, а значит искажаете юнит-экономику.

Базовая схема:
— строим cohort table по `user_id` и `first_event_date`;
— считаем `revenue` по каждому окну;
— LTV = `SUM(revenue) / COUNT(distinct users)` внутри когорты;
— отдельно считаем `gross` и `net`, если есть refunds, chargeback и postback-расхождения.

Retention Rate — это не «сколько вернулось в кабинет», а доля пользователей, у которых был повторный целевой event в периоде. Формула простая: `retention = retained_users / cohort_size * 100%`. Смотрите retention не только D7/D30, но и кривую удержания: если падение резкое после первого окна, проблема обычно в онбординге, оффере или качестве преленда.

Практика: сравнивайте LTV с CAC только на одинаковом горизонте. Если CAC считается по дню, а LTV — по 60-дневному хвосту, получите ложный профит. В нормальной ETL-схеме это решается через партиционирование по дате когорты и пересчёт всех окон из сырых логов, без ручной правки таблиц.

Пока нет когорты, нет LTV. Пока нет LTV, вы не понимаете, где именно течет профит? Данные не врут, в отличие от байеров.