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

Одна из наиболее популярных идей, появившаяся в индустрии разработки в последние годы, — это концепция Minimum Viable Product, сокращенно MVP. В двух словах, это стратегия разработки минимального по функциональности продукта, позволяющего получить обратную связь от пользователей. Но можно ли переносить эту концепцию в сферу мобильных приложений и если нет, то есть ли альтернатива? Мы в Alconost ^[1] перевели отличную статью, отвечающую на этот вопрос. Всем, кто имеет дело с мобильной разработкой — читать обязательно.

Мой опыт показывает, что в мире мобильных freemium-приложений стратегия минимально жизнеспособного продукта ^[2] не всегда применима — эта концепция не лучшим образом переносится на мобильные платформы. Ведь разрабатывалась для веба — платформы, позволяющей мгновенное и универсальное распространение версий продукта. На мобильных же платформах это невозможно. Кроме того, из-за разного качества мобильных девайсов “железо” сильнее, чем в вебе, влияет на ощущения пользователей от приложения на мобильных платформах (особенно в игровой сфере).

Разработчикам мобильных приложений не стоит тратить время на то, чтобы изучать влияние каждого изменения в продукте по отдельности. Почему? Из-за разнообразия устройств, из-за необходимости скачивать новые версии (что приводит к большому количеству активных версий одновременно), из-за задержки между загрузкой и публикацией в некоторых сторах. Внедрять в продукт изменения по одному неразумно — пользователи просто разбегутся из-за постоянных скачиваний все новых и новых обновлений. А чтобы замерить влияние таких изменений, готовьтесь много дней ждать публикации нового релиза.

Чтобы методология минимально жизнеспособного продукта работала для мобайла, разработчики должны быть знакомы с портфелем показателей, дающих более правдивое представление о продукте. Это минимальные показатели эффективности (minimum viable metrics) — минимальный набор приоритетных показателей, которые отслеживаются с момента запуска MVP и постоянно улучшаются с каждой стратегической, пусть и небыстрой, итерацией. Модель минимальных показателей эффективности встраивает аналитику в концепцию и стратегию развития продукта, а также включает минимальную аналитику в требования к запуску.

Для мобильных приложений существует четыре группы показателей, включая те, которые говорят о минимальной эффективности: удержание пользователей, монетизация, вовлечение и виральность. Как по мне, удержание пользователей — это важнейшая группа показателей. Приоритетность оставшихся может меняться в зависимости от типа разрабатываемого приложения. Я уверен, что приоритезация того, что планируется сделать в пределах итерации, должна быть гибкой и основываться на текущих показателях. Приоритет стоит отдавать вопросам, обеспечивающим наилучший ROI (возврат инвестиций).

Показатели удержания пользователей

1.1. Удержание на 1—7 день, 14 день, 28 день, 90 день и 365 день
Когда я говорю «N-й день», я подразумеваю процент пользователей, вернувшихся в приложение на N-й день. Например, удержание на 1-й день на уровне 50% означает, что 50% пользователей вернулись в приложение на следующий день после его установки.

Как я уже писал, я считаю удержание пользователей важнейшим показателем ^[3] (точнее, группой показателей) для отслеживания мобильными разработчиками по двум причинам:

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

2) удержание пользователей отражает их «удовлетворенность»: это показатель того, насколько хорошо ваше приложение отрабатывает свой основной сценарий использования. Нет смысла пытаться улучшать другие показатели при низком удержании пользователей.

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

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

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

1.2. Активные пользователи за день (DAU)
Количество людей, которые пользуются приложением в определенный день.

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

2. Показатели монетизации

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

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

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

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

3. Показатели вовлеченности

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

3.2. Среднее и медианное количество сессий
Отслеживается и визуализируется так же, как и продолжительность сессий.

4. Показатели виральности

4.1. K-фактор
Это среднее количество дополнительных пользователей, которых приводит каждый пользователь. Для приложений это подсчитать очень тяжело, поскольку мобильные платформы не учитывают почти никаких данных об источниках захода в магазин приложений. Но мне кажется, что оценка К-фактора важна, потому что виральность увеличивает окупаемость платного привлечения пользователей ^[5].

Если приложение интегрировано в социальную платформу вроде Twitter или Facebook (как, наверное, и должно быть в соответствующих случаях), отслеживание «социальных» приглашений — простая задача. В этой статье ^[6] описаны некоторые упущенные возможности при запуске и в стратегии раннего развития Vine, которые не должен упускать ни один менеджер проектов разработки мобильных приложений.

Как «продать» минимальные показатели эффективности

Самой трудоемкой частью внедрения этих метрик в среду разработки MVP может оказаться внутренняя «продажа» идеи. Она может быть непопулярным предложением в небольших командах, которые опасаются корпоративной бюрократии, тормозящей творческий процесс и размывающей видение самых прорывных приложений.

Но я по-прежнему верю: лучшим ответом будет то, что методы можно (и нужно) разрушить, как и вертикали продуктов. Методология «бережливого стартапа» эффективна в случае веба, но требует доработки для использования на мобильных платформах, учитывая фундаментальные отличия между платформами. Разработка приложений для мобильных устройств требует больше полагаться на данные и меньше — на интуицию при проектировании.

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

Автор: alconost

Источник ^[9]