Многие из вас слышали про когортный анализ, а кто-то даже его проводил. Но не все понимают как его использовать для управлением обновлениями.
Как мы уже ранее разобрали — когорты это группы аудитории с привязкой к какому-то временному интервалу. Например к месяцу установки приложения. Период лучше выбирать исходя из длительности спринта разработки. Спринт, по классическому определению, завершается релизом, а значит каждая когорта будет стартовать с какой-то своей версии продукта.
Что мы хотим отслеживать? Часто в когортный анализ засовывают метрики роста, типа MAU, но на практике это применимо, разве что, в маркетинговом анализе. Мы же сейчас поговорим о продуктовом.
Немного лирического отступления — у каждого приложения есть какая-то задача, которая ведёт к верхнеуровневым целям (например, заработать денег). Этой задачей обычно является формирование привычки пользоваться приложением у юзера и, как следствие, мотивировать его совершать много последовательных платежей.
Давай разберём эту задачу на составные продуктовые шаги:
Первым шагом после установки может быть прохождение онбординга ➡️ Потом схватывание a-ha момента ➡️ Первая оплата ➡️ Последующая оплата.
Успешность этих шагов очень сильно привязана к UX (user experience), который даёт приложение. А именно UX нам и интересен в первую очередь, так как даже незначительные изменения в дизайне могут сильно упростить или усложнить жизнь юзеров.
Отслеживание этих шагов уже даст много информации — переделали онбординг, изменили главную страницу, сломали воронку — всё это быстро отслеживается на новой когорте.
В отличии от анализа метрик в динамике, когортный анализ помогает смотреть свежим взглядом на каждую новую версию продукта без привязки к истории. Вот на прошлой неделе всё было хорошо с прохождением каталога, а сейчас плохо — что сделали? Увеличили количество категорий. Окей, это нам не надо, откатываем.
Для полноты картины, в список метрик можно добавить продуктовый набор типа retention, ARPU, LTV или среднй чек.