В отчёте сравнили LTV когорты пользователей января и когорты ноября на конец ноября и сделали вывод, что ноябрь 'хуже'. В чём ключевая проблема такого вывода?
AКогорты имеют разный горизонт наблюдения: ноябрьская ещё не успела накопить
LTV, сравнивать нужно на одинаковом горизонте или моделироватьB
LTV нельзя считать по когортам, его можно считать только по всей базеCЕсли
ARPU не меняется, то LTV обязан быть одинаковым всегдаDРазницы нет: сравнение корректно при любом горизонте
Правильный ответ.
LTV растёт со временем, поэтому сравнение когорт требует одинакового горизонта и одинаковых правил окна.Разбор
Январская когорта имела месяцы, чтобы накопить платежи, а ноябрьская — всего несколько недель, поэтому прямое сравнение на одну дату почти всегда смещено. Корректнее сравнивать LTV на одинаковом возрасте когорты (например, LTV на 30-й день) или строить кривые когорт. Иначе вы можете принять неверные решения по pricing или paywall, думая, что новые пользователи стали хуже. Этот принцип критичен для продуктовой аналитики монетизации.
Проверь себя · 1/3разбор после ответа
После изменения
pricing конверсия в оплату (conversion to paid) упала, но ARPU вырос. Какое объяснение наиболее вероятно?Ещё вопросы по теме «Монетизация и юнит-экономика»
- В freemium-приложении вы хотите понять, сколько в среднем приносит один платящий пользователь за месяц. Какая метрика отвечает на этот вопрос?
- Как корректнее считать месячный `ARPU` в модели freemium, где платит только часть аудитории?
- Вы тестируете новый `paywall` и хотите измерить `conversion to paid` именно из просмотра `paywall`. Что должно быть в знаменателе?
- Как лучше всего интерпретировать `LTV` в продукте с подпиской?
- После изменения `pricing` конверсия в оплату (`conversion to paid`) упала, но `ARPU` вырос. Какое объяснение наиболее вероятно?
- Все вопросы по «Монетизация и юнит-экономика» →