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

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

LTV без когорт — это средняя температура по кабинету. Если вы смешали новых, возвращённых и «спящих» пользователей в одну таблицу, модель врёт уже на старте. Для долгих кампаний нужен разрез: cohort_date, first_purchase_date, recency, repeat_count. Иначе вы не поймёте, где окупается трафик, а где просто растянут хвост выплат.

Retention считайте не по аккаунту, а по событию. Формула простая: retained_users / cohort_users за N-й день, неделю или цикл покупки. Смотрите не только D1/D7/D30, а весь ряд, потому что у офферов с длинным решением первая покупка часто не отражает реальную ценность. Проверяем сходимость дельты в трекере и кабинете, иначе retention из BI и retention из сырых логов будут жить разной жизнью.

Реальный LTV — это не выручка на пользователя, а маржа после всех утечек: refunds, chargeback, fee, invalid traffic, бонусы, логистика, саппорт. Формула: sum(net_revenue) / users_in_cohort. Если хотите прогноз, берите только закрытые когорты и аппроксимируйте хвост через survival curve или rolling average повторных покупок. Всё, что не автоматизировано — это потенциальный убыток.

Проверка качества данных обязательна: дедупликация по user_id и order_id, единая timezone, одинаковая логика атрибуции, контроль пропусков postback. Если одна и та же покупка попала в два источника, LTV растёт фальшиво, а retention превращается в мусорный сигнал.

Если воронка длинная, считайте когорты отдельно и обновляйте модель только из чистых событий. Данные не врут, в отличие от байеров.