- PVSM.RU - https://www.pvsm.ru -
Итак, вы опубликовали в сторе своё первое приложение. Начались первые скачивания, и сейчас самое время начать снимать метрики, чтобы проанализировать их и выявить возможные слабые места. Аналитика — важнейший инструмент в мире мобильных приложений. Она позволяет понять психологию пользователя, понять, как он взаимодействует с мобильным приложением, и в результате поможет сделать ваше детище лучше и прибыльнее.
Метрик может быть очень много, и обычно их набор зависит от конкретного приложения. Но есть ряд основных показателей, которые необходимо отслеживать вне зависимости от характера и масштаба вашего проекта. К ним относятся:
Давайте разберем более детально каждый пункт.
Очень важная метрика, позволяющая понять эффективность того или иного рекламного канала. Можно достаточно просто отследить рекламный канал, принцип тот же, как и в случае с переходом на веб-сайт: в ссылку, ведущую в магазин приложений, вставляются специальные метки, уникальные для каждого из рекламных каналов. После установки приложение считывает эти метки и фиксирует источник. Далее этот источник отобразится в системе аналитики, которую вы используете.
Здесь используется целый ряд метрик. После того, как пользователь поставил и запустил приложение, он оценивает, нравится ли оно ему. Если нет, он его сразу удалит или закроет и забудет. А вот если приложение пришлось по душе, то через некоторое время человек снова его запустит.
Чтобы оценить привлекательность для пользователей, чаще всего снимаются метрики:
Вычисляется по формуле:
1DR = X1 / Z, где X1 — количество пользователей, запустивших приложение на следующий день, Z — общее количество установивших.
Вычисляется по формуле:
7DR = X7 / Z, где X7 — количество пользователей, запустивших приложение на седьмой день, Z — общее количество установивших.
Вычисляется по формуле:
28DR = X28 / Z, где X28 — количество пользователей, запустивших приложение на седьмой день, Z — общее количество установивших.
Все три метрики снимаются ежедневно, при каждом запуске приложения сравниваются текущая дата и дата установки. Анализ динамики изменения каждой из метрик позволит также понимать реакцию пользователей на те или иные изменения, вносимые вами в приложение. Например, уровень 1-day retention обычно свидетельствует о том, как пользователи реагируют на интерфейс вашего приложения. И если этот показатель начал снижаться, то в первую очередь необходимо проверить, что не так с интерфейсом.
Следующей важной ежедневно снимаемой метрикой является прирост количества новых пользователей. Причём рекомендуется отслеживать изменение этого параметра при проведении рекламных кампаний, размещении обзорных статей, заключении партнёрских соглашений и т.д. В этом случае метрика выступает в роли эффективности всех этих телодвижений. Целесообразно накладывать на график количества новых пользователей не только даты, но и время установок, что поможет точнее оценить роль принимаемых вами мер по продвижению и рекламе. Также часто бывает полезно оценивать динамику в зависимости от географического разделения пользователей, а также отдельно по разным пользовательским сегментам.
Если динамика прироста будет отрицательная, то необходимо активнее заняться продвижением и рекламой. Подробнее об этом мы расскажем в одной из будущих публикаций.
Итак, вам удалось добиться более-менее устойчивого прироста аудитории, проект тепло принят пользователями и набирает популярность. Пора задуматься о степени активности пользователей: сколько человек в день запускают ваше приложение? А в неделю? В месяц? Причём речь идёт именно об уникальных пользователях. На эти вопросы отвечают три метрики:
По сути, каждая из этих метрик вычисляется из одной общей базы данных, в которой накапливается статистика по всем запускам приложения. Уникальность пользователей можно определять, например, по присваиваемым ID или парам логин/пароль.
Также можно вычислять производную метрику Sticky Factor = DAU/WAU или DAU/MAU. Её название можно перевести как «степень липкости». Она характеризует регулярность использования вашего приложения в течение недели или месяца, то есть позволяет оценить, насколько людям нравится ваше приложение на основании частоты использования. Если все пользователи будут запускать программу каждый день, то DAU будет равен и WAU, и MAU, а их отношение будет равно 100%. Но так не бывает, и потому Sticky Factor позволяет оценить, насколько часто люди обращаются к вашему приложению в течение недели или месяца. Логично, что снижение этих показателей — неприятный сигнал, говорящий об охлаждении аудитории.
Сессия — это время, которое пользователь провел в мобильном приложении с момента запуска до окончания его использования. Применительно к сессиям снимается обычно две метрики:
ASL = T / N, где T — суммарная продолжительность сессий за период, N — общее количество сессий за тот же период.
Эта метрика может свидетельствовать о том, насколько интересно пользователю проводить время в приложении. То есть это косвенный критерий качества. Кроме того, если в вашем приложении есть платный контент, но с увеличением средней продолжительности сессии вырастает и вероятность того, что пользователь решит заплатить. В большинстве проектов платящие пользователи проводят в приложении больше времени, чем неплатящие.
Однако не стоит гнаться за высокими значениями этой метрики, потому что она сильно зависит от типа вашего приложения. Например, для игр данный показатель достаточно критичен, и чем он больше, тем лучше. А для приложений-виджетов или фитнес-трекеров данный показатель будет незначительным, поскольку по большей части они работают в фоновом режиме. Гораздо важнее знать, какие экраны в течение сессии посещал пользователь. Благодаря этой метрике вы можете определить наиболее интересные для пользователей разделы вашего приложения. А заодно и узнаете, какие можно вовсе убрать и в дальнейшем не заниматься их развитием.
Очень полезная метрика — на каком экране заканчивается сессия пользователя. Этот показатель важен, например, если у вас в приложении есть авторизация. Она зачастую отпугивает пользователей, особенно если приложение не дает посмотреть контент, а сначала требует логин и пароль. В этом случае сессия будет чаще всего обрываться на экране регистрации. Если вы добавите какой-то контент до авторизации, то благодаря этой метрике сразу увидите результат.
Другой пример: если у вас есть форма заказа товара, состоящая из 3-4 экранов, то эта метрика покажет, на каком шаге большинство пользователей покидает приложение. В качестве решения уменьшите количество шагов, оптимизируете их порядок или оформление.
Пытаясь поднять значения тех или иных метрик, очень часто приходится корректировать пользовательский интерфейс и менять функциональность программы. Оценить эффективность этих шагов можно с помощью A/B-тестирования [1] (тестирование в режиме реального времени, когда группе пользователей предлагается одна версия функциональности/контента, а остальным пользователей — другая версия). В нашем случае тестирование подразумевает выкатывание новой версии приложения с изменённым UI для некоторой контрольной группы пользователей. Остальные продолжают пользоваться текущей версией. И мы регистрируем, как контрольная группа реагирует на нововведения, снимая метрики взаимодействия с интерфейсом приложения: например, какая из двух кнопок даёт бо̒льшую конверсию в покупку, в каком месте лучше показать Apptimize [2], Optimizely [3], Mixpanel [4].
С помощью собранной статистики вы также сможете узнать, насколько востребованы те или иные функции приложения, какая часть пользователей взаимодействует с приложением без подключения к сети, и многое другое.
Это одна из самых интересных и важных групп метрик. Если вы планируете зарабатывать с помощью вашего приложения, то нужно уделить самое пристальное внимание регистрации этих метрик и контролю за динамикой их изменения.
Первое, что приходит в голову — общая сумма платежей за период, 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 множитель Lifetime должен быть кратен периоду, за который вычислен ARPU. Если вы взяли ARPU за месяц, то и Lifetime будет измеряться в месяцах, а не в днях или неделях. Скажем, если у вашего приложения месячный ARPU равен $5, а Lifetime составляет 3 месяца, то LTV = $5 * 3 = $15.
Эта метрика — один из краеугольных параметров для оценки эффективности вашего проекта. Если LTV меньше CPI, то проект убыточен безо всяких «если» и «давайте взглянем в другом разрезе»: вы потратили на привлечение пользователя больше, чем получили с него за всё время, что он пользовался вашим приложением. Поэтому LTV необходимо постоянно отслеживать и сразу реагировать на тенденцию к снижению этой метрики. Очевидно, что повысить LTV можно с помощью одного или обоих множителей, добившись увеличения средней прибыли с пользователя за период и/или увеличения средней продолжительности использования приложения. Например, можно уменьшить отток пользователей, повысив привлекательность приложения; снизить затраты на привлечение, выбрав более эффективные каналы; увеличить стоимость покупок, подняв цены и стимулируя потребность в платном контенте.
Напоследок хотим привести пример метрик для двух популярных игр: Mobile Strike и Clash of Clans. Приведены суммарные данные по версиям для Android и iOS в США. Если вы делаете мобильные игры, то можете ориентироваться на их метрики, как на топовые продукты в этом классе приложений:
Недельное количество уникальных активных пользователей (WAU):
Соотношение дневного и недельного количеств активных пользователей (DAU/WAU):
Ежедневная прибыль:
Матрица двух показателей — 30-day retention и частота использования в неделю — для разных категорий приложений по версии системы аналитики Flurry:
Их существует достаточно большое количество, но наибольшей популярностью у разработчиков мобильных приложений пользуются Google Analytics [5], Flurry [6]и App Annie [7]. На первое время вам будет более чем достаточно их возможностей. Все инструменты предлагают разработчикам SDK для iOS, Android и Windows Phone, которые легко интегрируются в готовый проект. Рассмотрим подробнее.
Google Analytics
Google Analytics [8] — очень мощный и совершенно бесплатный инструмент для снятия метрик и последующего анализа. Изначально он создавался для веб-приложений и сайтов различного уровня сложности, поэтому не очень удобен в использовании мобильными приложениями, однако с решением базовых задач справляется «на ура».
Мобильным разработчикам особенно интересен раздел «В режиме реального времени». Здесь можно в режиме онлайн посмотреть количество пользователей мобильного приложения, а также события, отслеживание которых вы настроите.
В целом Google Analytics больше всего подходит программистам и инди-разработчикам.
Flurry
Этот инструмент изначально создавался для мобильных приложений, поэтому с ними он удобнее в использовании. Как и Google Analytics, Flurry [6]бесплатен в использовании. Интерфейс не выглядит слишком нагромождённым, в этом явный плюс по сравнению с GA.
Во Flurry сделан упор на отслеживание поведения пользователя, поэтому большинство отчетов «из коробки» так или иначе связаны с этим направлением.
Этот инструмент больше подойдёт для маркетологов и аналитиков.
App Annie
У этого сервиса есть бесплатная базовая функциональность, которой достаточно для начинающих разработчиков. Но если вы захотите снимать более широкий набор метрик, то придётся заплатить [9]. Классический интерфейс: слева расположена панель навигации, а контент удобно скомпонован.
В целом этот сервис может быть одинаково полезен и разработчикам, а маркетологам с аналитиками.
Google Analytics и Flurry предоставляют весь необходимый базовый инструментарий для мониторинга мобильных приложений. Бесплатный функционал App Annie несколько ограничен, зато у них есть две платные программы с гораздо более широкими возможностями — для средних компаний и Enterprise.
Google Analytics | Flurry | App Annie | |
---|---|---|---|
Анализ источников загрузок | + | платно | |
Анализ пользователей | + | + | платно |
Анализ различных платформ | + | платно | |
Карта переходов | + | + | платно |
Анализ эффективности рекламы и привлечения | + | + | платно |
Анализ поведения пользователей | + | + | платно |
Финансовые показатели | + | + | платно |
Активные пользователи | + | + | платно |
Когортный анализ | + | + | платно |
Возможность создания панели с собственным набором отчётов | + | + | |
Топовые разработчики | + | ||
Топовые приложения по категориям и площадкам | + | ||
Revenue топовых приложений | платно | ||
Retention топовых приложений | платно | ||
Использование топовых приложений | платно | ||
Аудитория топовых приложений | платно | ||
Маркетинг топовых приложений | платно |
Аналитика мобильного приложения — очень важная часть жизненного цикла проекта. Для индивидуальных разработчиков и небольших студий жизненно необходимо держать руку на пульсе своих проектов, пестовать их и сразу же реагировать на негативные сигналы, проявляющиеся в ухудшении значений метрик, когда на старте и глобальных вехах проекта важен каждый час.
Описанные системы аналитики — лишь часть арсенала средств, облегчающих работу многих студий и самостоятельных разработчиков. Сегодня создание успешных приложений требует ускорения процесса разработки, использования удобных и функциональных инструментов. Исходя из этого мы и развиваем Scorocode, превращая его в полезный, а для кого-то и незаменимый инструмент разработки мобильных приложений.
Удачной вам разработки и высокого revenue.
Автор: Scorocode
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/google-analytics/179204
Ссылки в тексте:
[1] A/B-тестирования: https://ru.wikipedia.org/wiki/A/B-%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
[2] Apptimize: https://apptimize.com/
[3] Optimizely: https://www.optimizely.com/
[4] Mixpanel: https://mixpanel.com/
[5] Google Analytics: https://www.google.com/analytics/
[6] Flurry : https://dev.flurry.com/secure/loginPage.do
[7] App Annie: https://www.appannie.com/
[8] Google Analytics: https://www.google.com/intl/ru_ALL/analytics/index.html
[9] заплатить: https://www.appannie.com/pricing/#market-data
[10] Источник: https://habrahabr.ru/post/308438/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.