Аналитика приложений в большинстве случаев сводится просто к мониторингу основных метрик: DAU, MAU, WAU, ARPU, ARPPU и другие аббревиатуры. Базовые метрики аналитики — это как раз те 20% функционала аналитических систем, которые дают 80% результата. Но достаточно ли вам этих 80%?
Если нет, то наша статья для вас. Мы расскажем о некоторых метриках, которые тоже стоило бы иметь в виду, если вы хотите полностью понимать все процессы, которые происходят в вашем приложении.
Обзор основных метрик можно прочитать вот здесь.
Метрики привлечения пользователей / Acquisition Metrics
Итак, пользователи приходят в ваше приложение. (рекомендуем посмотреть вебинар на тему основных метрик привлечения пользователей)
Вы меряете количество новых пользователей (New Users), общее количество пользователей на ту или иную дату (Total Users). Вы замеряете цену привлечения пользователей (CPI), эффективность ваших инвестиций (ROI).
Но для того, чтобы поток трафика от партнёра начался, нужно сперва этого партнёра найти, подписать договор (согласования с юристами, зачастую небыстрые), интегрировать и обо всём договориться. То есть потратить как время, так и деньги: либо на зарплату своим сотрудникам, либо на разовый платёж партнёру (бывает и такое). Поэтому рекомендуем рассчитывать не только обычный CPI, но и эффективную стоимость привлечения пользователей (eCPI), которая включает в себя все сторонние затраты.
Соответственно, и ROI тогда лучше рассчитывать, ставя в знаменатель eCPI. Таким образом, вы получаете eROI. И может статься так, что на основании eCPI и eROI вы выберете совершенно других партнёров.
Удержание пользователей / Retention
Здесь обычно меряют классический retention за 1 день, 7 дней, 28 дней, 60 дней и так далее. Некоторые предпочитают скользящий (rolling) retention, в котором пользователь считается удержанным через, например, 7 дней, если он вернулся в приложение на седьмой день или позже.
Для более подробного знакомства с retention рекомендуем посмотреть наш вебинар “Everything about retention”
А меряете ли вы retention первой сессии? Исследуете ли вы FTUE (First Time User Experience)? А ведь первая сессия определяет почти всё. Вы будете удивлены, когда увидите, сколько пользователей покидает вас уже во время туториала.
И раз уж мы заговорили о туториале, рекомендуем замерять tutorial retention. В частности, для этого можно воспользоваться отчётом Tutorial Steps.
Это для вас каждый элемент в меню — это лишь элемент в меню, а для той массы новых пользователей, что приходит к вам каждый день, это точка бифуркации, в которой пользователи могут принять окончательное решение об уходе. Именно поэтому туториал можно и нужно делить на мельчайшие шаги, смотреть, на каких шагах уходят пользователи и оптимизировать эти узкие места. Оптимизировать свой 1-day retention нужно смолоду, а именно — с оптимизации туториала.
Также рекомендуем использовать такую метрику, как 28/1-retention (28-days retention делить на 1-day retention). Она получена из двух знакомых вам метрик, однако её использование поможет вам понять, сколько пользователей из тех, что остались активны через день, останутся активными и через 28 дней. Не исключено, что основная часть пользователей покидает вас уже на первый день, а те, кто остался, остаются с вами надолго (в этом случае 28/1-retention становится выше). В этом случае всё, что вам нужно сделать — это оптимизировать retention первого дня.
Это как переход от обычной вероятности к байесовской (надеемся, вы нас поняли сейчас).
Каких пользователей можно назвать активными? Обычно активными пользователями называют тех, кто был в приложении в течение последней недели (иногда двух недель). А каким становится пользователь после этого? Неактивным? Неправильно. Спящим. Если пользователь не входил в приложение в течение недели — это ещё не значит, что он к вам больше не вернётся. Дайте ему шанс и выделите спящих пользователей в отдельную категорию — dormant users. Границы определите сами: например, отсутствие входов в течение периода от недели до полугода. Спящих пользователей ещё можно вернуть, и чем меньше пользователь “спит”, тем выше шанс. Push-уведомления, deep-linking, интересные апдейты, регулярные задания и турниры вам в руки.
А если пользователь вдруг “просыпается” и возвращается в приложение, то таких пользователей можно назвать returning users, и теперь уж точно не стоит давать им уйти (ежедневные квесты, подарки за возвращение, индивидуальная настройка сложности уровней и так далее).
Метрики активности пользователей / Engagement metrics
Как правило, это метрики масштаба вашего приложения: DAU, WAU, MAU, Users Online. Иногда к ним же относят среднюю длину сессии и лайфтайм пользователя.
А если поделить DAU на MAU, то мы получим интересную метрику под названием Sticky Factor. Далее цитируем наш материал на App2Top:
Описываемое отношение говорит о регулярности пользовательских входов в течение месяца: чем регулярнее пользователи входят в приложение, тем выше «стики фактор».
Если предположить, что каждый пользователь входит в игру каждый день в течение месяца, то DAU = WAU = MAU, а следовательно, «стики фактор» равняется ста процентам. Но насколько это достижимо, и действительно ли этот показатель влияет на коммерческий успех игры?
Для ответа на этот вопрос мы в devtodev.com проанализировали порядка 100 мобильных игр и рассчитали средние значения «стики фактора» за первые три месяца 2015 года.
Среднее значение показателя составило 18%, при этом минимальное значение составило 4%, а максимальное — 37%.
Затем мы посчитали корреляцию между «стики фактором» и доходом. Корреляция составила 50-60% в зависимости от категории игры. Это говорит о том, что связь между «стики фактором» и доходом, безусловно, есть, однако она не настолько сильна, чтобы можно было говорить о том, что лишь отношение DAU к MAU влияет на доход.
Многие считают среднюю длину сессии. Но количество сессий на активного пользователя в день (Sessions/DAU) считают не все. А меж тем это также отличный показатель регулярности входов. Тревор МакКалмонт приводит следующие эталонные значения этой величины:
- хорошее значение — 3 сессии на пользователя в день;
- для игр с более длинной сессией (RPG, например) — 2 сессии;
- для игр с короткой сессией (казуалки, раннеры) — 4-5 сессий.
Видим, что для игр с короткой сессией значение выше, а для игр с длинной сессией — ниже. Следовательно, мы можем говорить про ещё одну метрику — игровое время на одного пользователя в день (Average Playing Time Per Day). Она позволяет абстрагироваться от средней длины сессии и количества сессий и отлично характеризует интерес пользователей к игре.
Рекомендуем также замерять Frequency by Day — частоту входов пользователей в зависимости от времени с их первого визита. Как правило, эта величина убывает. В каких-то случаях медленно, но верно, в каких-то стремительно с первого же дня. Правильное использование этой метрики позволит вам спрогнозировать будущий уход пользователя из игры, а найдя такого пользователя, мы уверены, вы сделаете всё, чтоб не дать ему покинуть ваш проект.
Монетизация / Monetization
Тут чаще всего меряют общий доход (Gross, Revenue) и средние величины: ARPU, ARPPU, Average Check.
Также замеряют количество и долю платящих: Paying Users, Paying Share, Paying Conversion.
А знаете ли вы, сколько пользователей из тех, кто сегодня совершил платёж, сделал это впервые? Рекомендуем использовать метрику New Paying Users. Вероятность совершения второго платежа после первого равна примерно 70% — 90%. А вероятность третьего платежа после второго уже выше. И чем дальше, тем выше будет эта вероятность. Следовательно, главное, что нужно сделать — это добиться от пользователя именно первого платежа. А дальше будет проще. И описываемая метрика поможет вам понять, сколько пользователей конвертируется в платящих в течение периода.
Мы уже говорили про важность изучения FTUE. А для целей монетизации столь же важно изучение и FTPUE (First Time Paying User Experience). Важно понять, что заставляет пользователей конвертироваться из неплатящих в платящих, за какой период происходит эта конвертация, после каких событий в игре, при каком балансе игровой валюты. В частности, следует смотреть на то, что купили пользователи, совершившие свой первый платёж — First-Selling Items. Они могут и отличаться от наиболее популярных предметов. Их функция именно в том, чтобы пользователь совершил свой первый платёж. Изучив, чем именно эти предметы смогли привлечь пользователя, вы сможете использовать этот опыт в различных акциях и учитывать при принятии монетизационных решений.
Также любопытна для рассмотрения конверсия внутриигрового магазина: количество покупок, делённое на количество открытий магазина. Это легко оценивается, если вы интегрируете кастомное событие открытия магазина. И эта метрика открывает вам путь к оптимизации магазина: возможно, стоит располагать предметы в другом порядке, изменить цены или попросту переписать описания и перерисовать иконки.
А вообще, экономику игры можно изучать долго. Существует множество методов, которые работают. Рекомендуем ознакомиться с нашим вебинаром по этой теме.
Социальные метрики / Social Metrics
Если пользователю нравится игра или любой другой продукт, он с радостью будет делиться информацией о ней, и вы получите обратную связь в виде бесплатного органического трафика.
Можно замерять количество приглашений, отправленных в среднем одним пользователем: Invites Sent. Это не так трудно измерить: нужно либо генерировать уникальную ссылку и считать их количество, либо просто встроить соответствующий кастомный ивент.
Для измерения влияния всех социальных факторов существует так называемый K-factor. Для веб-проектов он обычно рассчитывается как Invites Sent, умноженное на конверсию из приглашения в регистрацию. Для мобильных же проектов как правило трудно оценить количество пользователей, увидевших приглашение (приглашение генерируется как правило не в виде уникальной ссылки, а в виде поста в социальной сети), поэтому мы предлагаем следующую формулу:
K-factor = (New users по каналу Органика) / (DAU — New users)
О чём говорит K-factor? По сути, это среднее количество друзей, приглашённых одним активным пользователем. В частности, компания Wooga озвучила свой K-factor, он равен 0,92. Это означает, что один активный игрок приглашает в среднем 0,92 своего друга. То есть на 100 активных игроков в игру приходит 92 новых бесплатных игрока.
Также это означает, что Wooga может смело умножать LTV своего игрока на величину (1+0,92) и получать так называемый Social LTV, который будет почти в два раза больше. И Social LTV лучше характеризует сумму, которую приносит один игрок: он не только платит сам, но и приглашает своих друзей.
Для измерения лояльности пользователей также существует метрика, называемя Net Promoter Score. Чтобы рассчитать эту метрику, вам необходимо провести опрос среди своих пользователей. Попросите их оценить вероятность, с которой они могут поделиться информацией о вашем продукте со своими друзьями, по шкале от 0 до 10.
Те, кто ответил 9 или 10 — так называемые промоутеры (promoters) — самые верные ваши друзья. Они с радостью расскажут друзьям о продукте, который им нравится. Те же, кто поставил оценку от 0 до 6 (противники / detractors), оценивают вас низко и, наоборот, будут распространять негативную информацию о вашем продукте.
Вычитая процент детракторов из процента промоутеров, вы и получаете нужный вам Net Promoter Score, который характеризует уровень лояльности ваших пользователей к вам.
картинка отсюда
Две рекомендации по использованию Net Promoter Score:
- Проводите подобные опросы регулярно. Например, раз в 3 месяца. Тогда вы сможете оценить динамику пользовательской лояльности к вам и понять, верно ли вы движетесь.
- Всячески сегментируйте пользователей и оценивайте Net Promoter Score для каждого сегмента по отдельности. Так вы сможете больше понять о том, для кого вы делаете игру, кто ваши поклонники и противники. И на основании этого вы сможете принимать более точные решения в будущем.
Надеемся, описанные нами метрики будут вам полезны. А если вы поделитесь информацией об этих метриках со своими друзьями, ваши Sticky Factor и Net Promoter Score станут близки к 100%;)
AYA
Подскажите, а вот скриншот отчета Tutorial Steps — это откуда?
vsabirov
Как раз из нашего аналитического сервиса — devtodev.com
AYA
а, понял, спасибо за ответ! :)