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

Original author: Эрик Бенджамин Зойферт
  • Translation
Одна из наиболее популярных идей, появившаяся в индустрии разработки в последние годы, — это концепция Minimum Viable Product, сокращенно MVP. В двух словах, это стратегия разработки минимального по функциональности продукта, позволяющего получить обратную связь от пользователей. Но можно ли переносить эту концепцию в сферу мобильных приложений и если нет, то есть ли альтернатива? Мы в Alconost перевели отличную статью, отвечающую на этот вопрос. Всем, кто имеет дело с мобильной разработкой — читать обязательно.



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

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

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

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

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


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

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

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

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



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

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

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

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-фактор
Это среднее количество дополнительных пользователей, которых приводит каждый пользователь. Для приложений это подсчитать очень тяжело, поскольку мобильные платформы не учитывают почти никаких данных об источниках захода в магазин приложений. Но мне кажется, что оценка К-фактора важна, потому что виральность увеличивает окупаемость платного привлечения пользователей.

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

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


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

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

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


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com

Alconost
Localization in 70+ languages & video production

Comments 5

    +1
    Концепция MVP вообще плохо применимы для мобильных приложений.
    Тут приложение должно выглядеть как конфетка и делать 1 функцию хорошо.
    Поэтому надо реализовать 1 функцию и вложить побольше денег в дизайн, тогда будет вам успех
      0
      Абсолютный бред) Извините. Как связан MVP и деньги в дизайн? Парадигма MVP подразумевает поиск правильного набора функций для чёткого списка потребностей, конечно всё это под соусом модели для монетизации. Другими словами, делаем версию (вообще без дизайна) которая проверяет гипотезу, как только гипотеза подтверждена — делаем версию с дизайном.

      Известна масса мобильных продуктов с крутым дизайном и никаким выхлопом, нулевой целевой аудитории и полной бесполезностью. Так же как и мобильные приложения со невероятно совковым дизайном, но с абсолютно «китайской» аудиторией.

      Вам понравилось приложение Яндекс.Транспорт?
        0
        А что не так с Яндекс.Транспортом? По мне так довольно забавное приложение и может сэкономить время.
          +1
          Другими словами, делаем версию (вообще без дизайна) которая проверяет гипотезу, как только гипотеза подтверждена — делаем версию с дизайном.

          вы пробовали? я пробовал.

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

        Пожалуйста, посмотрите коротенькое видео Стива Бланка по этому поводу. MVP – Not a minimal product.

        + в цикле стэнфордский лекций How To Start Startup от Y Combinator, Питер Тиль также указывал на не совсем верное понимание концепции MVP. И в качестве примера приводит мысль, о том что стоимость MVP для сегмента enterprise — может достигнуть нескольких миллионов долларов. Продукт который делает одну фичу — это не MVP, должен быть цикл.

        Деление же подохов MVP на веб и мобайл также нахожу не совсем коректным. Достаточно посмотреть на мобильное приложение Yo :)

        Only users with full accounts can post comments. Log in, please.