Минимальные Жизнеспособные Метрики для мобильных приложений

Мой опыт показывает, что для фримиум приложений принцип Минимально Жизнеспособного Продукта (Minimum Viable Product, MVP) в качестве продуктовой стратегии уважают, но чаще от него отказываются, так как концепция не подходит для мобильных платформ. Подход MVP был создан для платформ (веб), которые позволяют мгновенную и универсальную дистрибуцию итераций, что невозможно на мобильных платформах. И железо играет большую роль в опыте пользователя на мобильных устройствах (особенно в играх), чем в веб, так как качество аппаратов очень разнится.

Так как же MVP-подход может быть скорректирован с учетом этих платформенных особенностей? На мобильных устройствах выделение изменений в метриках, вызванных теми или иными индивидуальными изменениями в продукте, нецелесообразно, в связи с разнообразием аппаратов, необходимостью установки пользователями новой версии (что приводит к тому, что в один период времени может работать сразу несколько версий приложений) и задержкой между размещением и доступностью в некоторых магазинах приложений. Внедрение одного изменения в продукт и распространение его не является целесообразным – пользователи будут и так постоянно загружать приложение и на то, чтобы измерить влияние этого изменения могут уйти многие дни, вплоть до публикации нового релиза.

Для того, чтобы MVP-методология работала в мобайле, разработчики должны все время оставаться в курсе всего широкого набора метрик, который говорит правду об их продукте. Это так называемые Минимально Жизнеспособные Метрики (Minimal Viable Metrics, MVM): минимальный набор главных показателей, которые отслеживаются с запуска MVP и непрерывно улучшаются через стратегические, хотя и более медленные итерации. MVM-модель встраивает аналитику в продуктовую стратегию и дорожную карту, утверждая минимальные данные в качестве требований для запуска.

На мобильных я делю метрики, составляющие Minimum Viable Metrics, на четыре большие категории: Возвраты, Монетизация, Вовлечение и Виральность. Хотя я думаю, что возвраты являются самой важной группой метрик, приоритеты других групп должны изменяться в зависимости от типа разрабатываемого приложения. Я считаю, что расстановка приоритетов в программе итераций – т.е. то, что должно отрабатываться в итерации в зависимости от текущих показателей – должно происходить по гибкой модели и приоритеты для параметров должны расставляться на основании ROI, как самого значимого параметра.

Другими словами продюсер/продакт-менеджер должен использовать количественную основу для вычисления, для текущего этапа, 1) того, какие метрики можно улучшить в грядущей итерации, и 2) какую прибыль эти планируемые улучшения принесут. Затем график итераций следует выстроить на основании этих данных.

Кодекс Freemium — подборка статей о всех аспектах монетизации бесплатных приложений. App2Top.ru и AppTractor.ru готовят его русскую версию.

Метрики Возвратов

Возвраты в День 1-7, День 14, День 28, День 90 и День 365

Когда я говорю «День Х», то я понимаю под этим процент пользователей, которые вернулись в приложение на День Х. Например, уровень возвратов в День 1 равный 50% означает, что 50% пользователей вернулись в приложение через день, после установки.

Как я уже писал ранее, я считаю возвраты наиболее важной метрикой (или, скорее, группой метрик), которые следует отслеживать разработчикам. Этому есть две причины: 1) возвраты позволяют подсчитать предполагаемой «время жизни» для формулы Lifetime Customer Value, а понимание этой метрики (или, по крайней мере, попытки реалистично ее оценить), единственный способ провести ROI-положительное приобретение пользователей; 2) возвраты означают «восхищение» пользователей, это измерение того, насколько ваше приложение соответствует их запросам и основным вариантам использования. Нет никакого смысла пытаться улучшить другие метрики, если возвраты низки.

Я рассчитываю возвраты по факту – вычисляю День Х по отношению к тому дню, когда пользователь зарегистрировался. Так что если 100 пользователей присоединились сегодня, 50 вернулось завтра, а 40 послезавтра, то возвраты для Дня 1 и Дня 2 будут 50% и 40% соответственно. В этом смысле метрика «ретроспективна». Такой подход делает отслеживание улучшений в новых итерациях (или будущих запусков) проще, так как разработчик может отслеживать может точно узнать как удержание изменилось в определенный момент времени.

Я отслеживаю возвраты в День 28 вместо Дня 30, так как День 28 укладывается в еженедельный цикл использования, что может иногда раскрыть интересные факты о днях неделях. Я использую все метрики возвратов на одной диаграмме в качестве линейных графиков, но могу их по отдельности включать и выключать. Я также ориентирую метрики от сегодняшнего дня, так как ось Х приближается к текущему дню слева и самая большая метрика упадет до 0 (так как вычислить, например, возвраты в День 7 для вчера невозможно).

Я обсудил стратегии улучшения возвратов в этой статье, но на в общем виде я полагаю, что большие возвраты достигаются при помощи качества общения и глубины на начальных стадиях использования приложения, создания повторяемой, увлекательной петли на средних стадиях и предоставления достаточно контента для удовлетворения самых восторженных пользователей на последних.

Daily Active Users

Количество активных пользователей за день. Количество людей, которые используют приложения в данный день.

Daily New Users

Количество новых пользователей. Количество людей, которые установили и открыли приложение в данный день.

Метрики монетизации

Доход

Я отслеживаю доход ежедневно и разделяю выручку от встроенных покупок и доход от рекламы. Я представляю их в качестве линейных графиков с накоплением.

Average Revenue per User

Средний доход на пользователя. Я получаю данные ежедневно и вычисляю его как дневной доход, поделенный на количество игроков (DAU). Отслеживая ARPU по дням, мы получаем еще одну распространённую метрику ARPDAU, но, очевидно, эти две метрики расходятся, когда ARPU вычисляется на более длительном периоде времени.

Average Revenue per Paying User

Средний доход на платящего пользователя. Я вычисляю его также, как и ARPU и делю общий доход на количество пользователей, сделавших покупку в приложении.

Уровень конверсии

Отслеживается на ежедневной основе, процент пользователей, сделавших покупку. Я не учитываю рекламу, уровень конверсии касается только встроенных покупок.

Метрики вовлеченности

Средняя и медианная длинна сессии

Я отслеживаю медианную длину сессии, так как я предпочитаю не удалять значения >3 сигма из набора данных – снижение/увеличение средней длины сессии хороший показатель изменения вовлеченности «сильных пользователей». Эти данные отслеживаются каждый день.

Среднее и медианное количество сессий

Отслеживается и визуализируется так же, как и длинна.

Метрики виральности

K-фактор

K-фактор это среднее количество дополнительных людей, которых приводит пользователь в приложение. Его очень сложно подсчитать для приложений, так как мобильные платформы не могут указать источник захода пользователя в магазин. Но я думаю, что K-фактор важен, так как виральность увеличивает ROI платного приобретения пользователей. Ранее я уже изложил стратегию для оценки K-фактора и опубликовал модель.

Если приложение интегрируется с социальными платформами, типа Twitter или Facebook, отследить социальные приглашения довольно просто. Эта статья рассказывает о некоторых упущенных моментах в запуске Vine/стратегии раннего роста, которых менеджерам не стоит повторять.

Продавая Minimum Viable Metrics

Наиболее обременительным аспектом интеграции метрик в платформу MVP-разработки может стать «продажа» идеи внутри компании – она может стать непопулярной в маленьких командах, боящихся бюрократии «больших компаний», препятствующей креативным процессам и разрушающей подлинно прорывные приложения.

Лучшим ответом на это, я полагаю, будет просто объяснение того, что гибкая методология разработки эффективна для веб, но требует перенастройки для внедрения в мобильной сфере, в силу фундаментальных различий этих платформ. Мобильная разработка должна в большой степени полагаться на данные и менее на интуицию.

Смысл этого поста – стать отправной точкой для внедрения аналитики в мобильный MVP. С этой целью я также создал этот шаблон панели управления (исходники) для предоставления некоторых визуальных подсказок в области компоновки и графиков. Все данные случайны, но вставить ваши данные вы можете, просто заменив функции в шаблоне.