19 метрик, о которых вы могли и не знать
Аналитика приложений в большинстве случаев сводится просто к мониторингу основных метрик: 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) считают не все. А меж тем это также отличный показатель регулярности входов. Тревор МакКалмонт приводит следующие эталонные значения этой величины:
Видим, что для игр с короткой сессией значение выше, а для игр с длинной сессией — ниже. Следовательно, мы можем говорить про ещё одну метрику — игровое время на одного пользователя в день (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, который характеризует уровень лояльности ваших пользователей к вам.
картинка отсюда
Надеемся, описанные нами метрики будут вам полезны. А если вы поделитесь информацией об этих метриках со своими друзьями, ваши Sticky Factor и Net Promoter Score станут близки к 100%;)
Обзор метрик мобильного приложения
Итак, вы опубликовали в сторе своё первое приложение. Начались первые скачивания, и сейчас самое время начать снимать метрики, чтобы проанализировать их и выявить возможные слабые места. Аналитика — важнейший инструмент в мире мобильных приложений. Она позволяет понять психологию пользователя, понять, как он взаимодействует с мобильным приложением, и в результате поможет сделать ваше детище лучше и прибыльнее.
Метрик может быть очень много, и обычно их набор зависит от конкретного приложения. Но есть ряд основных показателей, которые необходимо отслеживать вне зависимости от характера и масштаба вашего проекта. К ним относятся:
Источник установки приложения
Очень важная метрика, позволяющая понять эффективность того или иного рекламного канала. Можно достаточно просто отследить рекламный канал, принцип тот же, как и в случае с переходом на веб-сайт: в ссылку, ведущую в магазин приложений, вставляются специальные метки, уникальные для каждого из рекламных каналов. После установки приложение считывает эти метки и фиксирует источник. Далее этот источник отобразится в системе аналитики, которую вы используете.
Удержание пользователей
Здесь используется целый ряд метрик. После того, как пользователь поставил и запустил приложение, он оценивает, нравится ли оно ему. Если нет, он его сразу удалит или закроет и забудет. А вот если приложение пришлось по душе, то через некоторое время человек снова его запустит.
Чтобы оценить привлекательность для пользователей, чаще всего снимаются метрики:
Вычисляется по формуле:
1DR = X1 / Z, где X1 — количество пользователей, запустивших приложение на следующий день, Z — общее количество установивших.
Вычисляется по формуле:
7DR = X7 / Z, где X7 — количество пользователей, запустивших приложение на седьмой день, Z — общее количество установивших.
Вычисляется по формуле:
28DR = X28 / Z, где X28 — количество пользователей, запустивших приложение на седьмой день, Z — общее количество установивших.
Все три метрики снимаются ежедневно, при каждом запуске приложения сравниваются текущая дата и дата установки. Анализ динамики изменения каждой из метрик позволит также понимать реакцию пользователей на те или иные изменения, вносимые вами в приложение. Например, уровень 1-day retention обычно свидетельствует о том, как пользователи реагируют на интерфейс вашего приложения. И если этот показатель начал снижаться, то в первую очередь необходимо проверить, что не так с интерфейсом.
Следующей важной ежедневно снимаемой метрикой является прирост количества новых пользователей. Причём рекомендуется отслеживать изменение этого параметра при проведении рекламных кампаний, размещении обзорных статей, заключении партнёрских соглашений и т.д. В этом случае метрика выступает в роли эффективности всех этих телодвижений. Целесообразно накладывать на график количества новых пользователей не только даты, но и время установок, что поможет точнее оценить роль принимаемых вами мер по продвижению и рекламе. Также часто бывает полезно оценивать динамику в зависимости от географического разделения пользователей, а также отдельно по разным пользовательским сегментам.
Если динамика прироста будет отрицательная, то необходимо активнее заняться продвижением и рекламой. Подробнее об этом мы расскажем в одной из будущих публикаций.
Количество уникальных пользователей в течение определённого периода
Итак, вам удалось добиться более-менее устойчивого прироста аудитории, проект тепло принят пользователями и набирает популярность. Пора задуматься о степени активности пользователей: сколько человек в день запускают ваше приложение? А в неделю? В месяц? Причём речь идёт именно об уникальных пользователях. На эти вопросы отвечают три метрики:
Также можно вычислять производную метрику Sticky Factor = DAU/WAU или DAU/MAU. Её название можно перевести как «степень липкости». Она характеризует регулярность использования вашего приложения в течение недели или месяца, то есть позволяет оценить, насколько людям нравится ваше приложение на основании частоты использования. Если все пользователи будут запускать программу каждый день, то DAU будет равен и WAU, и MAU, а их отношение будет равно 100%. Но так не бывает, и потому Sticky Factor позволяет оценить, насколько часто люди обращаются к вашему приложению в течение недели или месяца. Логично, что снижение этих показателей — неприятный сигнал, говорящий об охлаждении аудитории.
Сессия
Сессия — это время, которое пользователь провел в мобильном приложении с момента запуска до окончания его использования. Применительно к сессиям снимается обычно две метрики:
ASL = T / N, где T — суммарная продолжительность сессий за период, N — общее количество сессий за тот же период.
Эта метрика может свидетельствовать о том, насколько интересно пользователю проводить время в приложении. То есть это косвенный критерий качества. Кроме того, если в вашем приложении есть платный контент, но с увеличением средней продолжительности сессии вырастает и вероятность того, что пользователь решит заплатить. В большинстве проектов платящие пользователи проводят в приложении больше времени, чем неплатящие.
Однако не стоит гнаться за высокими значениями этой метрики, потому что она сильно зависит от типа вашего приложения. Например, для игр данный показатель достаточно критичен, и чем он больше, тем лучше. А для приложений-виджетов или фитнес-трекеров данный показатель будет незначительным, поскольку по большей части они работают в фоновом режиме. Гораздо важнее знать, какие экраны в течение сессии посещал пользователь. Благодаря этой метрике вы можете определить наиболее интересные для пользователей разделы вашего приложения. А заодно и узнаете, какие можно вовсе убрать и в дальнейшем не заниматься их развитием.
Очень полезная метрика — на каком экране заканчивается сессия пользователя. Этот показатель важен, например, если у вас в приложении есть авторизация. Она зачастую отпугивает пользователей, особенно если приложение не дает посмотреть контент, а сначала требует логин и пароль. В этом случае сессия будет чаще всего обрываться на экране регистрации. Если вы добавите какой-то контент до авторизации, то благодаря этой метрике сразу увидите результат.
Другой пример: если у вас есть форма заказа товара, состоящая из 3-4 экранов, то эта метрика покажет, на каком шаге большинство пользователей покидает приложение. В качестве решения уменьшите количество шагов, оптимизируете их порядок или оформление.
Взаимодействия с элементами интерфейса
Пытаясь поднять значения тех или иных метрик, очень часто приходится корректировать пользовательский интерфейс и менять функциональность программы. Оценить эффективность этих шагов можно с помощью A/B-тестирования (тестирование в режиме реального времени, когда группе пользователей предлагается одна версия функциональности/контента, а остальным пользователей — другая версия). В нашем случае тестирование подразумевает выкатывание новой версии приложения с изменённым UI для некоторой контрольной группы пользователей. Остальные продолжают пользоваться текущей версией. И мы регистрируем, как контрольная группа реагирует на нововведения, снимая метрики взаимодействия с интерфейсом приложения: например, какая из двух кнопок даёт бо̒льшую конверсию в покупку, в каком месте лучше показать popup с просьбой оставить отзыв о приложении, и т.д. Также можно воспользоваться для проведения A/B-тестирования сторонними сервисами, например, Apptimize, Optimizely, Mixpanel.
С помощью собранной статистики вы также сможете узнать, насколько востребованы те или иные функции приложения, какая часть пользователей взаимодействует с приложением без подключения к сети, и многое другое.
Финансы
Это одна из самых интересных и важных групп метрик. Если вы планируете зарабатывать с помощью вашего приложения, то нужно уделить самое пристальное внимание регистрации этих метрик и контролю за динамикой их изменения.
Первое, что приходит в голову — общая сумма платежей за период, Gross. Однако имейте в виду, что это брутто-доход, из которого придётся ещё вычесть долю магазина, через который вы распространяете приложение. А вот после вычета мы получаем метрику Revenue, которая отражает сумму, поступающую на ваш счёт.
Допустим, само ваше приложение бесплатное, но часть контента доступна только за деньги — вы распространяете его по модели in-app purchases. Для развития приложения и увеличения дохода нам нужно знать, сколько уникальных пользователей платят в течение заданного периода. Например, сколько человек в месяц купили игровые жетоны, золотые снаряды, более мощные заклинания, доступ к расширенной аналитике, красивому оформлению или другие предлагаемые вами платные вкусности.
Следующая метрика является производной от предыдущей: какую долю составляют плательщики от общего количества уникальных пользователей (за период), Paying Share. Наш недостижимый идеал — 100%. Хотя в реальности всё обычно гораздо скромнее. Если этот показатель начинает падать, значит пользователи уже пресытились имеющимся платным контентом, и пора либо разнообразить его, либо поиграть со скидками. По последнему пункту существует много разных тактик. Например, можно давать скидки по выходным и в праздники. Можно создать ажиотаж, временно обрушив цены, а как только количество скачиваний существенно вырастет, снова вернуть цены на прежний уровень. Можно давать скидки по купонам, можно предлагать выполнить какой-то простой квест. Ещё вариант: «скидка первым 5 000 скачавших в ночь на Ивана Купалу». Если в вашем портфеле есть и другие приложения с платным контентом, то можно использовать пакетные скидки при скачивании двух и более ваших продуктов. В общем, вариантов использования скидок существует немало.
Помимо количества плательщиков нас интересует и удельное количество платежей на одного пользователя, Transactions by User. Эта метрика вычисляется по формуле:
TBU = T / PU, где T — общее количество платежей (транзакций) за какой-то период, PU (paying users) — общее количество плательщиков за тот же период.
Если TBU > 1, значит часть пользователей делали более одной покупки.
Следующие важные метрики ARPU и ARPPU:
ARPU = Gross / DAU, или Gross/WAU, или Gross/MAU.
ARPPU = Gross/PU, где PU — общее количество уникальных пользователей, заплативших за контент в приложении в течение какого-то периода.
Эта метрика позволяет оценить удельную прибыльность этого сегмента вашей аудитории. А динамика изменения ARPPU даёт нам сигнал об отношении плательщиков к ценам/качеству платного контента. К примеру, снижение цен приведёт к уменьшению ARPPU, но может поднять ARPU, так как могут начать покупать некоторые из пользователей, которых раньше не устраивал уровень цен. И в результате повысится эффективность проекта в целом. Но всё же это не лучший сценарий, куда лучше добиться одновременно роста обеих указанных метрик. Скажем, повысив заинтересованность аудитории с помощью нового или более качественного контента без снижения цен.
Зависимость изменения Paying Share и ARPPU:
Говоря о получаемой с пользователей прибыли нельзя забывать и о том, во сколько нам обходится их привлечение. В конце концов, первое должно быть больше второго, иначе какой во всём этом смысл? В качестве метрики здесь используется стоимость одной установки приложения (CPI, Cost per Install). Вычисляется по формуле:
CPI = A/I, где А — стоимость рекламы, продвижения и маркетинга, I — количество установок приложений.
Эту метрику можно вычислять как за всё время существования проекта, вычисляя текущую стоимость привлечения пользователя, так и за определённые периоды, определяя эффективность конкретных рекламных кампаний или мер по продвижению приложения.
И завершаем наш обзор метрикой LTV (Lifetime Value) — это удельная прибыльность пользователя на протяжении всего периода использования им приложения. Существует масса способов вычисления LTV, но для начала вы можете воспользоваться такой формулой:
LTV = ARPU * Lifetime, где Lifetime — это усреднённая продолжительность использования приложения начиная с первого запуска и кончая последним. Скажем, если пользователь впервые зашёл в приложение 1 января, а последний раз — 15 августа и больше им не пользовался, то для него Lifetime равен 7,5 месяцев. Просуммировав Lifetime для всех пользователей и разделив на их общее количество, мы получим среднее значение этой метрики, которое и будет использовано при расчёте LTV.
Эта метрика — один из краеугольных параметров для оценки эффективности вашего проекта. Если LTV меньше CPI, то проект убыточен безо всяких «если» и «давайте взглянем в другом разрезе»: вы потратили на привлечение пользователя больше, чем получили с него за всё время, что он пользовался вашим приложением. Поэтому LTV необходимо постоянно отслеживать и сразу реагировать на тенденцию к снижению этой метрики. Очевидно, что повысить LTV можно с помощью одного или обоих множителей, добившись увеличения средней прибыли с пользователя за период и/или увеличения средней продолжительности использования приложения. Например, можно уменьшить отток пользователей, повысив привлекательность приложения; снизить затраты на привлечение, выбрав более эффективные каналы; увеличить стоимость покупок, подняв цены и стимулируя потребность в платном контенте.
Напоследок хотим привести пример метрик для двух популярных игр: Mobile Strike и Clash of Clans. Приведены суммарные данные по версиям для Android и iOS в США. Если вы делаете мобильные игры, то можете ориентироваться на их метрики, как на топовые продукты в этом классе приложений:
Недельное количество уникальных активных пользователей (WAU):
Соотношение дневного и недельного количеств активных пользователей (DAU/WAU):
Матрица двух показателей — 30-day retention и частота использования в неделю — для разных категорий приложений по версии системы аналитики Flurry:
О системах аналитики
Их существует достаточно большое количество, но наибольшей популярностью у разработчиков мобильных приложений пользуются Google Analytics, Flurry и App Annie. На первое время вам будет более чем достаточно их возможностей. Все инструменты предлагают разработчикам SDK для iOS, Android и Windows Phone, которые легко интегрируются в готовый проект. Рассмотрим подробнее.
Google Analytics
Google Analytics — очень мощный и совершенно бесплатный инструмент для снятия метрик и последующего анализа. Изначально он создавался для веб-приложений и сайтов различного уровня сложности, поэтому не очень удобен в использовании мобильными приложениями, однако с решением базовых задач справляется «на ура».
Мобильным разработчикам особенно интересен раздел «В режиме реального времени». Здесь можно в режиме онлайн посмотреть количество пользователей мобильного приложения, а также события, отслеживание которых вы настроите.
В целом Google Analytics больше всего подходит программистам и инди-разработчикам.
Flurry
Этот инструмент изначально создавался для мобильных приложений, поэтому с ними он удобнее в использовании. Как и Google Analytics, Flurry бесплатен в использовании. Интерфейс не выглядит слишком нагромождённым, в этом явный плюс по сравнению с GA.
Во Flurry сделан упор на отслеживание поведения пользователя, поэтому большинство отчетов «из коробки» так или иначе связаны с этим направлением.
Этот инструмент больше подойдёт для маркетологов и аналитиков.
App Annie
У этого сервиса есть бесплатная базовая функциональность, которой достаточно для начинающих разработчиков. Но если вы захотите снимать более широкий набор метрик, то придётся заплатить. Классический интерфейс: слева расположена панель навигации, а контент удобно скомпонован.
В целом этот сервис может быть одинаково полезен и разработчикам, а маркетологам с аналитиками.
Google Analytics и Flurry предоставляют весь необходимый базовый инструментарий для мониторинга мобильных приложений. Бесплатный функционал App Annie несколько ограничен, зато у них есть две платные программы с гораздо более широкими возможностями — для средних компаний и Enterprise.
| Google Analytics | Flurry | App Annie | |
|---|---|---|---|
| Анализ источников загрузок | + | платно | |
| Анализ пользователей | + | + | платно |
| Анализ различных платформ | + | платно | |
| Карта переходов | + | + | платно |
| Анализ эффективности рекламы и привлечения | + | + | платно |
| Анализ поведения пользователей | + | + | платно |
| Финансовые показатели | + | + | платно |
| Активные пользователи | + | + | платно |
| Когортный анализ | + | + | платно |
| Возможность создания панели с собственным набором отчётов | + | + | |
| Топовые разработчики | + | ||
| Топовые приложения по категориям и площадкам | + | ||
| Revenue топовых приложений | платно | ||
| Retention топовых приложений | платно | ||
| Использование топовых приложений | платно | ||
| Аудитория топовых приложений | платно | ||
| Маркетинг топовых приложений | платно |
Резюме
Аналитика мобильного приложения — очень важная часть жизненного цикла проекта. Для индивидуальных разработчиков и небольших студий жизненно необходимо держать руку на пульсе своих проектов, пестовать их и сразу же реагировать на негативные сигналы, проявляющиеся в ухудшении значений метрик, когда на старте и глобальных вехах проекта важен каждый час.
Описанные системы аналитики — лишь часть арсенала средств, облегчающих работу многих студий и самостоятельных разработчиков. Сегодня создание успешных приложений требует ускорения процесса разработки, использования удобных и функциональных инструментов. Исходя из этого мы и развиваем Scorocode, превращая его в полезный, а для кого-то и незаменимый инструмент разработки мобильных приложений.