Итак, в этой главе разбираем две важные концепции:
- Критическое (важное) событие (critical event)
- Как часто пользователи возвращаются к использованию продукта (product’s usage interval)
Что пригодится перед стартом:
- Проверьте инструментарий: Убедитесь в том, что ваша аналитика работает, и что вы отслеживаете действия пользователей. Проверьте аналитические инструменты, и еще раз пробегитесь по типам событий. Детали о том, как проводить аудит, вы можете найти в Приложении.
- Сделайте замеры базовых метрик: Убедитесь в том, что у вас есть представление о ваших пользователях и их поведении до внедрения Retention Lifecycle Framework. Сделайте замеры базовых метрик использования продукта и запишите их в таблице “Базовая диагностика продукта”. Вы можете периодически отслеживать эти метрики, чтобы видеть влияние retention-стратегии. В главе 4 мы подробно разбираем метрики и методы Продуктовой аналитики (Product Analysis Toolkit).
2.1 | Понимание критических (важных) событий
Критическое событие в продукте (critical event) и интервал использования (usage interval) помогают понять как проводить дальнейший анализ с использованием Retention Lifecycle Framework.
Что такое критическое событие (critical event) ?
Критическое событие — это действие, которое пользователи совершают при использовании продукта и которое тесно связано с ключевым ценностным предложением. Также критическое событие — это действие, к выполнению которого вы хотите подтолкнуть своих пользователей.
Когда вы измеряете Retention, критическое событие — это действие, после выполнения которого пользователь считается действительно активным (truly active) или удержанным (retained).
2.1.1 | Сколько может быть критических событий?
Хорошее эмпирическое правило — одно критическое событие на одно ценностное предложение продукта. Для большинства компаний это означает — единственное.
В редких случаях имеет смысл иметь несколько критических событий: Наиболее распространенным примером являются двусторонние маркетплейсы (two-sided marketplaces), в которых два разных товарных потока, например покупка и продажа. Пользователи таких продуктов обычно попадают в разные группы, поэтому есть смысл задать два критических события и анализировать эти группы пользователей по отдельности.
Например, у Uber есть две базы водителей и пассажиров; у Airbnb это хозяева жилья и съемщики; у Etsy покупатели и продавцы.
2.1.2 | Примеры критических событий
Пример 1: Критическое событие Airbnb
Если бы вы измеряли показатели Retention в Airbnb, вы бы стали считать удержанным пользователя, который открывает приложение и смотрит список жилья? Обычное открытие приложения не приносит Airbnb ни капли коммерческой ценности и не соответствует их цели получения прибыли.
Критическое событие Airbnb — это бронирование. Рост и успех компании зависят от владельцев жилья, размещающих его на Airbnb и пользователей, которые его бронируют.
Пример 2: Наши клиенты
Вот еще несколько примеров критических событий от наших клиентов. Заметьте, что каждое критическое событие тесно связано с основной ценностью, которую бизнес предоставляет своим пользователям.
| Компания | Что они делают (What They Do) | Критическое событие (Critical Event) |
|---|---|---|
| Mindfulness app | Самостоятельная медитация | Завершение процесса медитации |
| Lifestyle app | Найти и записаться на ближайшие занятия фитнесом | Записаться на занятие |
| Mobile game publisher | Мобильные MOBA-игры | Играть в игру |
Вывод: важно определить критическое событие
Чтобы определить критическое событие, надо задать себе несколько вопросов:
- Какое действие, по вашему мнению, должен совершать пользователь каждый раз при использовании продукта?
- Какие метрики важны для вас как компании? Каких показателей вы хотите в итоге достичь? Какие действия пользователя можно связать с этой метрикой?
- У вас разные продуктовые предложения? Если да, то какие? Каковы ваши метрики успеха для каждого из них?
2.2 | Определения интервала использования вашего продукта (product’s usage interval)
Вы не сможете сделать выводы о показателях Retention пока у вас нет понимания *интервала использования вашего продукта (product’s usage interval). Одни продукты сделаны для ежедневного использования, например, социальные сети, медиа, казуальные игры или приложения для повышения продуктивности. Другие, такие как on-demand, e-commerce и приложения для контроля расходов, будут использоваться ощутимо реже.
2.2.1 | Почему интервал использования продукта важен для Retention?
Предположим, что у вас есть приложение доставки еды из ресторанов. Ваша продуктовая интуиция говорит, что большая часть пользователей делает заказы примерно раз в неделю. Если вы посмотрите на процент пользователей, возвращающихся ежедневно, вы увидите что-то вроде этого:
Сильное падение после Дня 0, а затем ужасающе низкий процент возвращающихся в любой из следующих дней пользователей. Но эта кривая удержания плохо отражает здоровье вашего продукта; N-Day Retention показывает только долю активных в произвольный день пользователей. Эти цифры не будут большими, потому что большинство ваших пользователей не будут делать заказы каждый день.
Вместо этого вы должны следить за Retention по неделям. То есть доля возвращающихся пользователей в течение дней 1-7, 8-14, 15-21 и так далее.
Еженедельный retention в случае ниши доставки еды по сравнению с ежедневным дает гораздо объективнее показывает состояние вашего продукта, так как оно соответствует тому насколько часто пользователи естественным путем возвращаются к продукту.
Важный термин:
Интервал использования продукта (product usage interval ) — это ожидаемая частота использования людьми вашего продукта (ежедневно, еженедельно, ежемесячно и т.д.).
Чтобы точно рассчитать Retention на всех этапах Retention Lifecycle (подробнее об этом в Главе 3), нужно сначала определить как часто можно ожидать возвращения пользователей к продукту. Невыполнение этого требования может привести к некорректному пониманию метрики Retention и неправильной выдаче стратегий по ее улучшению.
2.2.2 | Применяем Interval Framework, чтобы узнать интервал использования вашего приложения
Эта инструкция из четырёх этапов использует имеющиеся данные о поведении пользователей, чтобы помочь вам точно определить интервал использования продукта.
- Определите всех пользователей, которые повторили критическое событие минимум дважды в течение определенного периода времени. Мы советуем 60 дней. Примечание: вам нужно выбрать период времени больше интервала использования. Для большинства продуктов достаточно 60-90 дней, так как интервалы использования редко превышают месяц. Это означает, что мы ожидаем выполнения пользователями критического события как минимум два раза за 60 дней.
- Проанализируйте сколько времени понадобилось пользователям на возвращение и выполнение критического события во второй раз.
- Постройте диаграмму изменения процента пользователей, повторивших критическое событие в разные промежутки времени. Это даст вам совокупную функцию распределения.
- Определите интервал времени, за который 80% пользователей повторили критическое событие. Это и есть интервал использования вашего продукта.
Давайте поместим эту инструкцию в контекст и рассмотрим на примере клиентов.
2.2.3 | Определение интервала использования в Amplitude
Какую бы платформу аналитики вы не использовали, описанные выше шаги помогут вам рассчитать интервал использования (usage interval). Просто следуйте инструкциям из воркшита в конце этой главы, чтобы выполнить эти шаги.
Если вы используете Amplitude, чтобы быстро определить интервал использования вашего продукта, можно просто включить вид Usage Interval в графике Retention Analysis.
Давайте рассмотрим пример одного из наших клиентов — приложение Mindfulness. Так как основная ценность этого приложения заключается в проведении пользователей через упражнения по управлению вниманием и медитации, критическое событие — это завершение сеанса медитации.
Команда пыталась понять как часто их действующие пользователи возвращаются к медитации. На графике Retention мы задаем событие “сеанс медитации завершен” и как первое и как повторное.
Далее кликните “Change to Usage Interval View”. Полученная кривая показывает сколько времени потребовалось людям из когорты “Current Users” на повторение критического события “Сеанс медитации завершен”. Определив точку перегиба этой кривой, вы можете приблизить интервал использования вашего продукта.
Например, изгиб графика происходит в районе 7 дней. Диаграмма показывает, что 62% действующих пользователей повторяли критическое событие завершения медитации в течение 7 дней. Можно сказать, что пользователи приложения могут возвращаться примерно раз в неделю для медитации, или то, что это приложение — продукт еженедельного использования.
Профессиональный совет:
За исключением редких случаев вроде софта для налоговой отчетности, для большинства предприятий интервал использования не превышает месяц. Если вы обнаружите, что ваш продукт исключение, не бойтесь адаптировать эту инструкцию по своему желанию.
Определение вашего интервала использования продукта (product usage interval) — важный этап в считывании базовых (начальных?) показателей текущей базы пользователей. Это отправная точка для анализа Retention в соответствии с Retention Lifecycle Framework.
Заполните таблицу в конце этой главы, чтобы определить ваш интервал использования продукта по этой инструкции.
Еще одна вещь…
Как мы сказали выше, определение вашего интервала использования (product usage interval) дает начало анализу Retention и вашим Retention-стратегиям.
Фреймворк отлично подходит для определения вашего интервала использования продукта количественным способом (так мы любим делать в Amplitude!). Но также важно приправить его своим продуктовым чутьем и тщательным исследованием пользователей. Качественный фидбек пользователей не менее, а может быть даже и более ценный, чем ваши количественные замеры.
2.3 | Итого
Эта глава закладывает фундамент для более глубокого анализа retention, который последует далее. Вложите немного времени на выполнение следующих действий из этой главы:
- Проверьте ваш инструментарий аналитики
- Организуйте вашу систему событий
- Определите ваше критическое событие/события
- Заполните таблицу “Определение вашего интервала использования продукта”
- Заполните таблицу “Начальная диагностика продукта”
2.4 | Таблица диагностики продукта
Определите ваше критическое событие продукта (скачать шаблон диагностики продукта):
| Описание метрики | Значение метрики | Заметки |
|---|---|---|
| Новые и активные пользователи (New & Active Users) | ||
| Новых пользователей в день за последние 30 дней | ||
| Активных пользователей в день за последние 30 дней | ||
| Проверка любых важных свойств пользователя вроде платформы, устройства или местоположения. Занести интересное в отметки. | ||
| Сессии (Sessions) | ||
| Средняя длительность сессии за последние 30 дней | ||
| Среднее количество сессий на пользователя за последние 30 дней | ||
| ТОП событий (Действия пользователя) | Top Events (User Actions) Список из ТОП-5 событий за последние 30 дней (по замерас счетчика) | ||
| Событие 1: | ||
| Событие 2: | ||
| Событие 3: | ||
| Событие 4: | ||
| Событие 5: | ||
| New User Retention Замер процента новых пользователей, возвращающихся за заданный период времени | ||
| День 1 | ||
| День 7 | ||
| День 30 | ||
| Неделя 1 | ||
| Месяц 1 | ||
| Воронки (Funnels) | ||
| Воронка онбординга (Onboarding Funnel): % конверсий за последние 30 дней | ||
| Воронка критического пути: % конверсии за последние 30 дней Если в вашем продукте есть важные воронки, например, последовательность оформления заказа или обновления, запишите ее тут | ||
| Пути пользователей (Common User Paths) | ||
| Самые частые последовательности событий после захода в продукт, напр. App Open > Song Played > Paylist Created > Song Added |