Как стать автором
Обновить
1051.99
OTUS
Цифровые навыки от ведущих экспертов

Софтланч продукта с использованием метрик минимальной жизнеспособности

Время на прочтение4 мин
Количество просмотров1.2K
Автор оригинала: Eric Benjamin Seufert

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

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

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

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

Чтобы извлечь максимум пользы из софтланча, разработчикам нужно собирать и анализировать данные, которые будут генерировать пользователи. Несколько месяцев назад я определил то, что назвал метриками минимальной жизнеспособности (Minimum Viable Metrics) — базовый набор метрик, необходимых для оценки успеха free-to-play игры. Задействуя в софтланче метрики минимальной жизнеспособности, разработчик получает возможность основывать решения о продукте на наборе реальных поведенческих данных, а не только на своей интуиции.

Одно из достаточно серьезных затруднений, с которым некоторые разработчики могут столкнуться во время софтланча — это грамотная интерпретация отслеживаемых метрик. Метрики минимальной жизнеспособности должны рассматриваться в комплексе, тогда вы сможете делать правильные выводы о состоянии и потенциале free-to-play проекта; концентрация лишь на показателях дохода или ретеншене не дает достаточного контекста для адекватной оценки потенциала игры.

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

Метрики минимальной жизнеспособности состоят можно разделить на четыре группы: ретеншн (Retention), вовлеченность (Engagement), виральность (Virality) и монетизация (Monetization). Каждая группа состоит из набора специализированных метрик, а весь портфель, анализируемый на ежедневной основе, должен предоставить разработчику картину того, как на игру реагируют пользователи, и, что более полезно, как она развивается.

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

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

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

Группа метрик монетизации должна отслеживать контрольные показатели доходов высокого уровня, такие как средний доход на одного активного пользователя в день (ARPDAU), средний доход на пользователя (ARPU) и средний доход на платящего пользователя (ARPPU), а также распределение приобретаемого каталога: первые покупки пользователей, самые популярные покупки и доля общего дохода, которую представляет каждый элемент в каталоге.

Сосредоточившись на базовом наборе метрик для софтланча, разработчик может обойти многие потенциальные проблемы, с которыми можно столкнуться при полномасштабном релизе продукта, который не был тщательно проверен на реальных игроках. Free-to-play в значительной степени зависит от принятия решений на основе получаемых данных и быстрых итераций продукта: направляя разработку на основе метрик минимальной жизнеспособности в софтланче, разработчик избавляет себя от множества неизвестных переменных, которые неминуемо преследуют игры, выпущенные на мировой рынок, прежде чем они были подвергнуты суровой проверке реальными пользователями App Store или Google Play.


Завтра состоится бесплатный открытый урок по теме «LTV. North star метрика игрового проекта». На основе игровых проектов разберем понятие Life Time Value на составляющие, научимся правильно считать LTV несколькими способами: от самого простого к самому сложному и точному. Регистрируйтесь по ссылке.

Теги:
Хабы:
Всего голосов 6: ↑6 и ↓0+6
Комментарии0

Публикации

Информация

Сайт
otus.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
OTUS