- PVSM.RU - https://www.pvsm.ru -

Показатели удержания Flurry: очень важные и очень непонятные

Flurry [1] уже стала мастхевом для тех мобильных разработчиков, которые понимают важность анализа пользовательского поведения. Однако в тех метриках Flurry, которые касаются удержания пользователей, сориентироваться не так-то легко: тут и return rate, и rolling retention, и static retention… в общем, как говорит народная мудрость, без ста грамм не разобраться. Поправим — не разобраться без этой статьи, которую мы в Alconost [2] отыскали и перевели специально для Хабра. А понимать, что к чему в показателях удержания пользователей, жизненно важно: иначе вы рискуете потерять и пользователей, и деньги на их привлечение, и радужные перспективы развития вашего приложения или игры.

Показатели удержания Flurry: очень важные и очень непонятные - 1

Дьявол в деталях

Удержание пользователей (retention) — самый важный показатель, на который опираются все остальные элементы хорошо работающей бизнес-модели freemium.

Не верите мне? Сверьтесь с отменным Минимумом показателей эффективности [3] Эрика Зойферта, чтобы сориентироваться в теме.

Как поясняет Эрик, удержание пользователей позволяет остальным трем столпам freemium-модели — вовлечению, виральности и монетизации — работать в принципе, хотя бы теоретически. Следовательно, без надлежащих показателей удержания вся конструкция распадается.

Удержание пользователей — важнейший показатель для разработчиков и издателей при запуске freemium-игры или приложения. Его изучают в мельчайших подробностях при «мягком запуске» игры в отдельной стране.

Тщательнейшим образом показатель удержания пользователей изучает руководство разработчиков и издателей freemium-игр, а также венчурные инвесторы и менеджеры продуктов. Это очень важный показатель для условно-бесплатного продукта.

Простыми словами показатель удержания пользователей, в котором так заинтересована отрасль, определяется как «процент пользователей, которые возвращаются в вашу игру на N-ный день после первого использования приложения» и известен также как «удержание на N-ный день».

Анализируя показатели, обычно принимают значения за 1, 7 и 30 день как основу для подсчета продолжительности пользования приложением и в итоге дохода с пользователя, если добавить в уравнение монетизацию.

В мире freemium-игр для мобильных телефонов и планшетов минимальные показатели удержания пользователей ожидаются на таких уровнях:

  • День 1: не менее 30% (предпочтительно 40%) пользователей, загрузивших игру в день 0, возвращаются в игру.
  • День 7: не менее 15% (предпочтительно 20%) пользователей, загрузивших игру в день 0, возвращаются в игру.
  • День 30: не менее 8% (предпочтительно 10%) пользователей, загрузивших игру в день 0, возвращаются в игру.

При этом большая часть отрасли не в курсе, что Flurry не отображает удержание пользователей в таком понимании. Вместо этого Flurry показывает нечто, называемое «скользящим удержанием» [4] (rolling retention).

Flurry определяет «скользящее удержание» как долю пользователей, которые вернулись в ваше приложение на N-ный или любой следующий за N-ным день после первого использования приложения.

На первый взгляд, разница неочевидна и несущественна, но стоит копнуть чуть глубже — и выясняется, что она критична.

Проще говоря, «скользящее удержание» не имеет вообще никакого отношения к нашему предыдущему определению удержания. На самом деле метрика rolling retention показывает величину, обратную показателю оттока пользователей (стопроцентный rolling retention = ваш churn).

Суть проблемы

Отток (churn) определяется как количество пользователей, покинувших вашу игру «навсегда».

Обычно, хоть и не всегда, разработчики и издатели мобильных игр называют показатели «скользящего удержания» Flurry «удержанием на N-ный день», которым они не являются. И тогда эти показатели становятся особенно проблемными для них по нескольким причинам:

  • Эти показатели всегда будут выше для игры (или соответствующего приложения), которая на рынке уже давно.
  • Чем дольше приложение установлено на пользовательском устройстве, тем больше вероятность, что пользователь снова запустит его. Когда это происходит, такой пользователь учитывается в числе удержанных за весь период времени — я видел не такие уж давние приложения, для которых «скользящее удержание» Flurry отображает 90% удержания на 30 день. Ах, если бы…
  • Эти показатели дают очень ограниченную информацию об истинной природе качества или пользовательской базы игры или приложения.
  • Инди-разработчики не понимают настоящего значения показателей «скользящего удержания» и принимают основанные на них некомпетентные решения. Либо тратят дополнительное время в циклах разработки на внедрение других аналитических инструментов, поскольку в итоге осознают, что Flurry показывает им не то, что нужно.
  • Венчурные инвесторы и менеджеры продуктов не понимают настоящего значения показателей «скользящего удержания» и принимают основанные на них некомпетентные решения о вложении денег. (Господа инвесторы, обратите внимание, пожалуйста!)
  • Издателям время от времени показывают отличные показатели удержания представленных разработчиками приложений и игр, которые абсолютно бесполезны для принятия компетентных решений.

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

А как вы работаете с показателем удержания пользователей?

Автор: alconost

Источник [5]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/mobile-development/80100

Ссылки в тексте:

[1] Flurry: http://www.flurry.com/

[2] Alconost: http://alconost.com/?utm_source=habrahabr&utm_medium=article&utm_campaign=translation&utm_content=retention_flurry

[3] Минимумом показателей эффективности: http://mobiledevmemo.com/minimum-viable-metrics/

[4] «скользящим удержанием»: http://support.flurry.com/index.php?title=Analytics/Overview/Lexicon/Lifecycle

[5] Источник: http://habrahabr.ru/post/248295/