Как спрогнозировать количество пользователей приложения
Во время активного развития технологий все более известными становятся такие термины как Artificial Intelligence, Machine Learning, Data Mining и Data Science. Основная задача данных технологий в бизнесе - научиться понимать поведение клиента в постоянно меняющихся условиях. Ведь если мы знаем как поведёт себя клиент в будущем, мы можем наилучшим образом спланировать и провести маркетинговые активности.
Математические алгоритмы машинного обучения работают с большими объёмами данных и находят даже скрытые закономерности поведения клиентов. Эти закономерности не видны менеджерам и, более того, иногда даже сами клиенты о них не подозревают (уже классический пример: случай с компанией Target).
В этой статье мы рассмотрим один из подходов, который используется в системе искусственного интеллекта eSputnik Intelligence.
Данный подход основывается на нескольких идеях:
- понимание шаблонов поведения пользователей
- уменьшение уровня беспокойства клиентов
- увеличение продолжительности жизни клиентов
- предотвращение выгорания базы клиентов
- эффективное использование акционных предложений
Вы узнаете как увеличить результативность писем и при этом сократить общее количество отправляемых писем более чем на 30%.
1. Формальная постановка задачи
Алгоритмы распознавания шаблонов с обучением предполагают наличие исторической информации (т.н. "учителя"), позволяющей построить модели статистической связи x → y, где
- y ∈ Y, Y - наблюдаемые действия пользователя (responses) или моделируемой случайной величины
- x ∈ X, X - множество переменных (predictors), с помощью которых предполагается объяснить изменчивость переменной y
Большинство моделей с учителем устроены таким образом, что их можно записать в виде
y = f(x, β) + ε, где:
- f - математическая функция, выбранная из некоторого произвольного семейства
- β - вектор параметров этой функции
- ε - ошибки модели, которые обычно сгенерированы несмещенным, некоррелированным случайным процессом
В ходе построения модели по фиксированным выборочным значениям y минимизируется некоторая функция остатков Q(y, β). В результате, находят β̂ - вектор с оптимальными оценками параметров модели.
Варьируя вид функций f и Q, можно получать разные модели, из которых предпочтение отдается наиболее эффективным - т.е. моделям, которые дают несмещенные, точные и надежные прогнозы отклика y.
2. Подготовка данных
Следует помнить о том, что любой статистический метод будет хорош настолько, насколько качественными являются входные данные для обучения модели (англ. "garbage in - garbage out!" или "хлам на входе - хлам на выходе"). Без затраты усилий на подготовку обучающей выборки (фильтрация, трансформация, удаление пропущенных значений, создание производных переменных и т.д.) и понимания моделируемого процесса чудес не случается.
2.1. Моделирование исходных данных
На практике, перед построением модели, необходимо собрать и проанализировать любую доступную информацию. Например, тип рассылки, активность на сайте, транзакции, пол, возраст, семейное положение, индивидуальные предпочтения и т.д.
Но, для простоты изложения, рассмотрим общий случай, и смоделируем простой набор данных, который включает:
- ContactID - id пользователя
- Date - время получения письма
- Response - метка конверсии (0 - нет, 1 - да)
Причем данные должны быть наиболее приближенные к поведению реальных пользователей. В наших данных, будут пользователи, которые: совершенно не читают письма, читают редко, читают почти всё. Учтём также, что некоторые из пользователей читаю письма с определённой периодичностью, а некоторые - от случая к случаю.
Сперва подключим необходимые пакеты, и зададим функции:
library(data.table)
library(dplyr)
library(lubridate)
repeat_last maxgap
if (any(exceed)) ind = sort(c(ind[exceed] + 1, ind))
rep_times = diff(c(ind, length(x) + 1))
>
>
x = rep(x[ind], times = rep_times)
if (!forward) x = rev(x)
x
>
Вот так выглядят данные, которые мы сформировали:
| ContactID | Date | Response | |
|---|---|---|---|
| 1: | 45 | 2017-05-30 22:22:49 | 0 |
| 2: | 5 | 2017-02-14 18:35:40 | 0 |
| 3: | 42 | 2017-03-10 17:31:10 | 0 |
| 4: | 44 | 2017-06-04 14:49:50 | 0 |
| 5: | 89 | 2017-05-17 03:59:05 | 0 |
| 6: | 27 | 2017-04-18 08:30:45 | 0 |
| 7: | 79 | 2017-01-24 07:39:52 | 0 |
| 8: | 74 | 2017-03-14 01:20:03 | 0 |
| 9: | 134 | 2017-05-15 00:25:07 | 1 |
| 10: | 199 | 2017-05-01 16:14:43 | 0 |
| . | . | . | . |
| 100000: | 151 | 2017-01-07 04:08:03 | 0 |
Исключим информацию о пользователях, которые совершенно не активны. На практике с такими пользователями необходимо работать персонализированно. К примеру, разрабатывать методы их реактивации.
Activ % group_by(ContactID) %>%
summarise(IsActive = ifelse(sum(Response) == 0,
yes = 0, no = 1)) %>%
filter(IsActive == 1)
Эффективный email-маркетинг с eSputnik
2.2. Агрегирование информации по каждому пользователю
Важно понимать, что до того как мы узнаём реакцию пользователя на очередное письмо, мы знаем лишь предыдущую историю его поведения. Утверждение очевидное, но на это можно не обратить внимание при формировании переменных для обучения.
Сформируем множество переменных X - посчитаем для каждого пользователя, на момент получения очередного письма в истории, следующие показатели:
- количество полученных/прочтенных писем
- количество полученных/прочтенных писем по будням
- количество полученных/прочтенных писем по выходным
Activ[, Day := wday(Date, label = T)]
Activ[, DayType := ifelse(Day %in% c("Sat", "Sun"),
yes = "Weekend", no = "Weekday")]
Activ[, Day := NULL]
Activ[, Delivered := .N, by = list(ContactID, Date)]
Activ[, Delivered := cumsum(Delivered), by = list(ContactID)]
Activ[Response == 1, Opened := .N, by = list(ContactID, Response, Date)]
Activ[is.na(Opened), Opened := 0]
Activ[, Opened := cumsum(Opened), by = list(ContactID)]
Activ[, Opened := shiftUp(Opened, 1), by = list(ContactID)]
Activ[, Delivered := shiftUp(Delivered, 1), by = list(ContactID)]
Activ[, DeliveredByDayType := .N,
by = list(ContactID, DayType, Date)]
Activ[, DeliveredByDayType := cumsum(DeliveredByDayType),
by = list(ContactID, DayType)]
Activ[Response == 1, OpenedByDayType := .N,
by = list(ContactID, Response, Date)]
Activ[is.na(OpenedByDayType), OpenedByDayType := 0]
Activ[, OpenedByDayType := cumsum(OpenedByDayType),
by = list(ContactID, DayType)]
Activ[, OpenedByDayType := shiftUp(OpenedByDayType, 1),
by = list(ContactID, DayType)]
Activ[, DeliveredByDayType := shiftUp(DeliveredByDayType, 1),
by = list(ContactID)]
Activ[, OpenRate := Opened / Delivered]
Activ[, OpenRateByDayType := OpenedByDayType / DeliveredByDayType]
- процент открытия писем
- процент открытия писем по будням/выходным
Activ[, OpenRateByDayType := OpenedByDayType / DeliveredByDayType]
- дата последнего получения письма
- дата последнего прочтения письма
- время от последнего полученного письма
- время от последнего прочтения письма
units = "days"),
by = ContactID]
Activ[, RecentlyOpened := difftime(Date, LastOpened,
units = "days"),
by = ContactID]
Activ[, RecentlyDelivery := as.numeric(RecentlyDelivery)]
Activ[, RecentlyOpened := as.numeric(RecentlyOpened)]
- нормированные показатели:
- среднее количество писем получаемых пользователем в неделю
- среднее количество писем открываемых пользователем в неделю
- время до последнего полученного письма относительно времени существования пользователя в системе
- время до последнего прочтения письма относительно времени существования пользователя в системе
Activ[, OpenedNormed := Opened / LifeTime]
Activ[, RecentlyDeliveryNormed := RecentlyDelivery / LifeTime]
Activ[, RecentlyOpenedNormed := RecentlyOpened / LifeTime]- бинарные показатели активности за выбранные периоды (0 - нет, 1 - да):
- активен за последние 5 дней
- активен за последние 10 дней
- активен за последние 15 дней
Переменная отклика Y принимает два значения (уже задана в исходных данных):
- 0, если пользователь не прочитал письмо;
- 1, если пользователь прочитал письмо.
Удалим вспомогательные данные:
Activ[, CreatedDate := NULL]
Activ[, LastDelivered := NULL]
Activ[, LastOpened := NULL]
Activ[, Delivered := NULL]
Activ[, Opened := NULL]
Activ[, Date := NULL]
Activ[, DeliveredByDayType := NULL]
Activ[, OpenedByDayType := NULL]
Activ[, ContactID := NULL]
Activ[, RecentlyDelivery := NULL]
Activ[, RecentlyOpened := NULL]Отлично, данные для обучения модели готовы. Построим модель предсказания значения переменной отклика y при заданном значении параметров xi ∈ X, i = .
Другими словами, модель будет отвечать на такой вопрос: прочтет пользователь очередное письмо или нет? Если прочтет - отправляем письмо. Если нет - ожидаем от модели сигнала к отправке.
Соответственно, наша задача сводится к задаче бинарной классификации - классифицируем переменную y всего двумя значениям 0 либо 1 (где 0 - нет, не прочтет; 1 - да, прочтет).
Кстати, мы сформировали переменные только для примера. Возможно, некоторые из них неинформативные. В одной из последующих статей мы рассмотрим тему анализа значимости переменных.
3. Выбор и обучение модели
Один из ключевых моментов с которым исследователь сталкивается при разработке статистической модели изучаемого явления, заключается в выборе оптимального для конкретного случая алгоритма извлечения закономерностей.
Не вдаваясь в описание существующих алгоритмов машинного обучения, можно сказать, что многие из них довольно сложные. Естественно, сложные алгоритмы контринтуитивны и тяжело интерпретируемы. Но, исследования показывают, что простые методы (на примере классификаторов) при решении практических задач часто превосходят более сложные алгоритмы.
Для нашей задачи в качестве математической функции f возьмём функцию логистической регрессии, а в качестве функции остатков Q - логистическую функцию максимального правдоподобия (чисто интуитивно, функция Q помогает найти такие значения параметров β̂ при которых предсказанные вероятности отклика Ŷ наиболее близки к действительным значениям отклика Y).
Итеративное взаимодействие функций f и Q подберёт оптимальные параметры функции f для описания поведения откликов Y, через переменные X.
3.1. Разделение данных на обучающую и тестовую выборки
При построении модели, необходимо проверить её точность. Поэтому, разделим наши данные на две части: обучающую (80%) и проверочную (20%).
3.2. Обучение модели на выборке для обучения
Воспользуемся средствами пакета stats для обучения моделей.
3.3. Предсказание результатов для тестовой выборки
При оценке параметра y модель вычисляет вероятность прочтения письма, а не конкретное значение 0 либо 1. То есть мы получаем значение ŷ из интервала [0, 1].
Имея вероятности прочтения письма, необходимо определиться при каком пороге вероятности (так называемый параметр Threshold) мы будем относить пользователя к группе 0 либо 1. Сейчас, в качестве порогового значения, возьмем параметр threshold равным 0.09.
Поступим следующим образом:
- если ŷ ≤ threshold, тогда Response = 0,
- если ŷ > threshold, тогда Response = 1;
Техология выбора порога вероятности описана в теме управления рисками при фильтрации email-рассылок.
4. Анализ точности модели
Сравним результаты прогноза модели с реальными данными.
Получаем таблицу сопряженности действительных и предсказанных значений отклика на тестовой выборке.
We send email to those users for whom we have Predicted = 1, and do not send email to those users who have Predicted = 0.
Мы отправляем письмо тем пользователям, для которых имеем Прогноз = 1. Пользователям у которых Прогноз = 0, письмо не отправляем.
5. Анализ результатов
- Мы сократили количество отправленных писем на 14272 (18,24%)
- 13642 + 630 = 14272
- (13642+630) / (13642 + 630 +34967 + 29004) * 100 = 18,24%
- Точность прогноза отклика составляет 97,88%, т.е. мы потеряли всего 2,12% открытий
- (1 - 630 / (630 + 29004)) * 100 = 97,88%
Существенно ли это?
Это позволит не беспокоить пользователей без необходимости и предотвратить выгорание контактной базы.
К тому же, если пользователь реже получает письма, ему интереснее их читать. Также он более вероятно совершит целевое действие при получении очередного письма.
Заметим, что этот результат получен с использованием минимума информации. При добавлении в модель дополнительной информации, о которой мы говорили выше, эфективность модели увеличивается в несколько раз.
Сегодня существует так много платформ социальных сетей, где вы найдете так много создателей контента в самых разных областях. Как потребитель социальных сетей, количество подписчиков, которые у вас есть, может не представлять для вас интереса, но как создателю контента или как бизнесмену количество подписчиков, которые у вас есть, важно для вашего контента для охвата большей аудитории. Таким образом, задача прогнозирования подписчиков в социальных сетях очень важна для каждого создателя контента и каждого бизнеса, который полагается на социальные сети. Так что, если вы хотите узнать, как предсказать количество подписчиков в социальных сетях на следующий месяц, эта статья для вас. В этой статье я расскажу вам о задаче прогнозирования подписчиков в социальных сетях с помощью машинного обучения с использованием Python.
Прогнозирование подписчиков в социальных сетях
Чтобы спрогнозировать увеличение числа подписчиков, которых вы можете ожидать, вам нужен набор данных о ваших подписчиках в социальных сетях, который может показать вам действия людей в вашей учетной записи в социальных сетях, например:
Поэтому очень сложно найти такой набор данных среди наиболее распространенных платформ социальных сетей, таких как Facebook и Instagram, поскольку эти платформы не предоставляют никаких данных, связанных с вашими подписчиками. Итак, для задачи прогнозирования подписчиков в социальных сетях с помощью машинного обучения я собрал данные из своей учетной записи в социальной сети на Medium, платформе социальных сетей для авторов контента, блоггеров и исследователей. Вы можете использовать тот же процесс в своем наборе данных, независимо от того, получаете ли вы его из Medium, Instagram или любого другого приложения для социальных сетей, чтобы предсказать своих подписчиков в социальных сетях. Для практики вы можете использовать тот же набор данных, что и я.
Прогнозирование подписчиков в социальных сетях с использованием Python
Я начну задачу прогнозирования подписчиков в социальных сетях с машинного обучения, импортировав необходимые библиотеки Python и набор данных, которые я собрал о моих подписчиках из Medium:
В 7-й строке приведенного выше кода я удалил последнюю строку набора данных, поскольку она содержит данные за этот месяц. Теперь я посмотрю, сколько подписчиков я набирал каждый месяц на своей учетной записи с тех пор, как присоединился к этой платформе социальных сетей:
![]()
Теперь давайте посмотрим на общее количество подписчиков, которые у меня появляются каждый месяц:
![]()
![]()
Теперь я буду использовать библиотеку autots в Python, которая является одной из лучших библиотек науки о данных для прогнозирования временных рядов. Если вы никогда раньше не использовали эту библиотеку, вы можете легко установить ее в своей системе с помощью команды pip:
Вот как мы можем предсказать рост числа подписчиков, которых мы можем ожидать в течение следующих четырех месяцев:
Резюме
Вот как вы можете предсказать рост числа ваших подписчиков в любой социальной сети. Как потребитель социальных сетей, количество подписчиков, которые у вас есть, может не представлять для вас интереса, но как создателю контента или как бизнесмену количество подписчиков, которые у вас есть, важно для вашего контента для охвата большей аудитории. Надеюсь, вам понравилась эта статья о задаче прогнозирования подписчиков в социальных сетях с помощью машинного обучения с использованием Python. Не стесняйтесь задавать свои ценные вопросы в разделе комментариев ниже.
Инструкция от менеджера продуктов компании-разработчика «Мануфактура» Дмитрия Провоторова и технического директора приложения Meinestadt Андрея Есаулова.
В ноябре 2016 года, отвечая на вопрос руководства компании «Стоит ли инвестировать в развитие мобильного приложения?», мы создали калькулятор KPI. Это фреймворк, который позволяет определить основные точки приложения усилий для growth hacking и спрогнозировать результаты, которых можно добиться с его помощью.
Итогом стало не только получение средств на предстоящий год работы над продуктом, но и успешный запуск приложения в апреле 2017 года. Мы сумели спрогнозировать некоторые из показателей эффективности с точностью до сотых, более того — «взломать» часть из них, показав двукратный или трёхкратный рост.
В этой статье опишем три простых шага, которые за 45 минут помогут самостоятельно смоделировать ключевые показатели вашего приложения, основываясь на опыте, приобретённом нами в процессе разработки модели. Для удобства расчетов мы разместили фреймворк в открытом доступе.
Нужно вооружиться математическими знаниями и составить формулу, которая описывает, каким образом мобильный продукт участвует в бизнес-процессах компании, которая им владеет. В большинстве случаев это, конечно, влияние на доход.
В самом простом приближении формула месячного дохода будет выглядеть так:
Доход = Количество посетителей * Конверсия в действие * Доход с действияДля приложения СМИ, которое зарабатывает на рекламе, формула месячного дохода будет выглядеть так:
Доход = Количество активных пользователей * Количество рекламы, которую видит средний пользователь * Стоимость показа рекламыДля приложения, зарабатывающего на партнёрских отчислениях с покупок, которые совершают пользователи приложения (это могут быть продажи книг или одежды):
Доход = Количество активных пользователей * Конверсию в покупателей * Средний чек покупки * Процент партнёрского отчисленияДля приложения с подписной моделью распространения контента (обучающие курсы или публицистика):
Доход = (Количество подписавшихся ранее + Новые подписчики - Отписавшиеся) * Стоимость месячной подпискиАртефакт по завершении первого шага: формула дохода, формализующая ключевые показатели (мы все называем их KPI), которые играют судьбоносную роль для вашего мобильного приложения. Как видите, для её составления нам достаточно салфетки, ручки и логики.
На предыдущем шаге вы выделили ключевые показатели, от которых зависит успех мобильного продукта. Теперь нужно понять, в каких пределах они могут изменяться и к чему приводят эти изменения — то есть как сильно они влияют на успех. Иногда для этого достаточно и салфетки, но базовые знания Excel (Google Tables или Numbers) помогут быть более эффективным в расчётах.
Можно начать с простой таблицы с 13 колонками: в первой — перечень показателей, а в остальных двенадцати — их значения от месяца к месяцу. Таким образом мы получим прогноз изменений на первый год жизни продукта после его запуска.
Для того чтобы сделать прогноз более точным, количество строк должно увеличиться, а таблица — стать сложнее. Но не говорите сразу «Это слишком сложно для меня»: важно просто начать, сами не заметите, как начнёте удивляться сложностям своих расчетов.
Разбейте таблицу на два больших блока. В первом — расчет MAU (Monthly Active Users, месячная активная аудитория). В большинстве расчетов MAU играет основополагающую роль и состоит из New Installs (новых установок) и Retention (возвратов пользователей из предыдущих месяцев).
New Installs зависит от числа пользователей, которых вы привлекаете ежемесячно нативно через поиск в магазинах приложений, через рекламные кампании или вирально. Во втором блоке — расчёт дохода, который зависит от размера вашей активной месячной аудитории. Формула у вас уже есть.
Вы можете создать свой собственный шаблон для подобных расчётов или воспользоваться готовыми — в сети есть несколько вариантов для разных типов проектов: (созданный нами mKPI.calc для мобильных приложений, дэшборд Кристофа Янца для стартапов или коллекция идей для создания дэшборда по цифровому маркетингу от Klipfolio).
В шаблоне mKPI.calc у каждого параметра в столбце KPI есть его описание, рекомендации по граничным условиям и примеры заполнения для разных продуктов — это может служить помощником на раннем этапе.
В таблице визуально выделите KPI. На их росте (или даже «взломе», приводящем к взрывному росту) будет фокусироваться ваша команда. Спрогнозируйте изменение этих показателей от месяца к месяцу и следите, как меняется доход с приложения. Вашей задачей станет обеспечение этого роста.
Откуда брать показатели для таблицы:
- Данные из систем аналитики вашего продукта (нативная аналитика Apple и Google, Google Analytics, Fabric, Localytics и другие сервисы аналитики), если он уже запущен.
- Экспертиза клиента (для заказной разработки) или инвестора (для стартапа).
- Используйте свой опыт в мобильных приложениях и опыт других команд (коллекционируйте опубликованные кейсы).
- Не забывайте про открытые данные (Statista, Similarweb, «Яндекс.Исследования»).
В первую очередь поймите, что ситуация, в которую вы попали, намного лучше той, в которой вы бы оказались, не имея на руках прогноза. Сейчас вы можете найти причины ошибки и увеличить вашу экспертизу — прогнозы в будущем станут более точными. Это поможет на следующем этапе скорректировать стратегию роста и привести мобильный продукт к успеху.
Артефакт по завершении второго шага: заполненная таблица с прогнозом изменений KPI.
Ещё на предыдущем шаге вы, скорее всего, поняли, что найти такое сочетание параметров, которое сделает успех желанным, очень непросто. Мало кто захочет вкладываться в приложение ради выручки в $10 тысяч в год. А вот показатель в $1 млн может служить очень сильным мотиватором. Тем более вы уже будете знать, каких значений KPI нужно достичь, чтобы его приблизить.
На третьем шаге нужно не только убедиться в том, что вы нашли тот набор параметров, который поможет пройти через точку безубыточности, но и подумать, как можно кардинально изменить ситуацию в случае, если видите, что она получается «среднестатистической» и неинтересной для команды, клиента или инвестора.
Здесь нужно быть особенно внимательным к тем идеям, что будут приходить в голову — именно они могут помочь «взломать» систему и найти возможности взрывного роста.
Какие выводы можно сделать, экспериментируя с параметрами:
- Единственная возможность получить экспоненциальную «клюшку» на графике роста дохода с мобильного приложения — это вирусное привлечение новых пользователей.
- Значение MAU слишком большое, и такой аудитории можно достичь только через локализацию продукта на другие языки и распространение в других странах.
- Фокус на возвратах пользователей в приложение (Retention) увеличивает доход до 20%.
- Вторая платформа (например, Android, если было только приложение на iOS) удваивает доход. Третья — утраивает. При условии, если на них удастся получить такой же MAU.
Итог — чёткое представление, на чём нужно фокусироваться на текущей стадии развития мобильного приложения. Сформируйте дорожную карту (roadmap) развития продукта: какие функциональности пойдут в MVP, а какие будут выпущены в следующих обновлениях. Дорожная карта поможет составить требования на проектирование, дизайн, разработку и тестирование. И станет опорой в диалоге с заказчиком или инвестором.
Артефакт по завершении третьего шага: дорожная карта развития мобильного приложения, имеющая основание на формуле дохода и влиянии на него KPI.
В 2020-м году общее число мобильных приложений на рынке достигло 5 млн, а количество скачиваний превысило 31 млрд. Карантин вызвал резкий скачок спроса, но постепенно рынок возвращается к обычному состоянию. Как измерять показатели в новых условиях? Глава Mobi-Soft Дмитрий Простов собрал ключевые метрики, полезные приемы и технологии, которые помогут разработчикам и фаундерам оценить эффективность приложения.
генеральный директор Mobi-Soft
Судя по свежей статистике, в 2020-м рынок приложений установит новый рекорд – в первую очередь это касается мобильных игр, мессенджеров и сервисов для видеоконференций. Пользователи тратят все больше времени и денег на приложения.
В первом квартале 2020-го года число приложений на базе Android достигло 2,56 млн, а на базе iOS – 1,85 млн. Всего, по данным Statista, пользователям доступны 5,4 млн мобильных программ. Параллельно растет число скачиваний. За первый квартал только в Google Play этот показатель вырос до 22,5 млрд, а в App Store – до 9 млрд. Главным драйвером роста в 2020-м стал карантин: пользователи массово устанавливали мессенджеры, качали игры, смотрели сериалы, общались в Zoom и заказывали еду через приложения.
Насколько эти цифры показательны – уже другой вопрос. Мы в Mobi-Soft занимаемся мобильной разработкой уже 8 лет и за это время поняли, что популярные метрики часто не отражают реальную картину и показывают только краткосрочные тренды. В то же время появляются новые нестандартные способы изучать аудиторию и конкурентов, а заодно оценивать эффективность мобильных продуктов. Разберемся, какие приемы уже устарели, а на что, наоборот, полезно обратить внимание.
Устарело: метрики тщеславия
«Они поднимают настроение, но не дают понимание того, куда и зачем двигаться», – так описывал метрики тщеславия предприниматель и венчурный инвестор Эрик Рис, автор концепции Lean Startup. Он справедливо отмечал, что этот показатель раздувает эго руководства и помогает пиарить продукт. «Тщеславные метрики» радуют акционеров и заказчиков, но редко приводят к измеримым бизнес-результатам или конкретным решениям.
17–19 декабря, Онлайн, Беcплатно
Часто показатели подчиняются сезонности или сиюминутным трендам. Например, карантин спровоцировал взрывной рост Netflix и Zoom. Ситуативная популярность принесла компаниям успех, но сохранят ли они те же показатели в долгосрочной перспективе – большой вопрос.
Метрики тщеславия зациклены на росте – больше всегда значит лучше, а как это влияет на бизнес, уже не так важно. В мобильной разработке самая популярная метрика тщеславия – это количество скачиваний приложения.
Этот показатель не привязан к другим величинам, он плохо отражает внутреннюю динамику и не дает ценных инсайтов. Например, вы придумали новое приложение для учета финансов и его устанавливают чаще, чем мобильный продукт конкурента. Первая версия – вы молодец и ваш сервис лучше. Но есть и вторая версия – возможно, у вашего конкурента меньше «новичков», зато более лояльная аудитория, которая годами пользуется приложением?
Многие клиенты часто интересуются охватом аудитории (reach). Особенно эту метрику любят сотрудники маркетингового отдела – с помощью охватов они демонстрируют, насколько эффективно работают. Показатель действительно может порадовать начальство, но на бизнес-решения он влиять не должен.
Reach часто путают с Impressions – показами контента, например, в App Store. Охват отражает число уникальных пользователей, которые видели ваше приложение, а Impressions подразумевает только показы контента в ленте – видели его пользователи или нет, уже другой вопрос. Учитывайте, что отображение продукта еще не говорит о его популярности.
Еще одна популярная метрика тщеславия – это средняя выручка в расчете на одного пользователя (ARPU). Обычно для этого делят общую выручку на число активных пользователей за конкретный период. Это в целом эффективная метрика, но все же не совершенная. Она дает усредненную картину и исходит из того, что все активные пользователи приносят одинаковую выручку и стабильно пользуются приложением в течение заданного периода. Но по статистике, половины выручки обычно приносят всего 0,15% юзеров. При этом менее 40% использует приложение больше месяца.
Используйте ARPU в привязке к когортам. Вы получите больше ценной информации, если сгруппируете пользователей на основании отдельных признаков и получите данные по каждой мелкой группе.
Конечно, полностью отказываться от метрик тщеславия не получится хотя бы потому, что они просты для понимания. Если вы работаете как студия, то клиентам обязательно понадобятся эти показатели. Но постарайтесь извлечь из них максимум пользы.
- Сравнивайте свои метрики с метриками конкурентов за тот же период. Вы находитесь в одинаковых условиях и важно знать, как справляются с вызовами приложения из той же категории, какие тактики они используют и какой результат получают. Сравнивайте показатели с учетом временных, сезонных трендов. Для этого подойдут сервисы AppAnnie, AppMagic и Appsflyer.
- Всегда учитывайте контекст. Число скачиваний само по себе ни о чем не говорит, а вот этот показатель в сравнении с объемом трафика на странице приложения в App Store – уже интересная метрика. Она отражает эффективность описания и скриншотов. То же касается других количественных характеристик. Например, для инвестиционного приложения сессия пользователя продолжительностью 90 секунд – это хороший показатель. А вот для стримингового сервиса – не очень.
- Сопоставляйте показатель скачиваний с показателем удалений. Если программу часто качают, но тут же удаляют, возможно, вы напрасно тратите деньги на продвижение.
- Вместо абсолютной величины используйте соотношения. Так, количество скачиваний ничего не скажет о вашем бизнесе, зато поможет рассчитать стоимость одной установки приложения (CPI), а уже на основе CPI можно рассчитать стоимость привлечения пользователя CAC (CPI + конверсия первичного пользователя в активного клиента).
- Собирайте только те данные, которые действительно будут полезны. Не каждый ивент стоит того, чтобы его документировать и анализировать.
Актуально всегда: базовые метрики
Актуальность метрик зависит от продукта и стадии его разработки, но есть пара базовых показателей, которые в 2020-м году максимально важно. Полезные KPI отражают реальную картину и обычно расстраивают разработчиков и фаундеров – результаты всегда кажутся недостаточно хорошими. Поэтому над улучшением этих показателей упорно работают даже популярные сервисы и соцсети.
Пожизненная ценность клиента (LTV)
Пожизненная ценность клиента (LTV) показывает, сколько выручки принесет среднестатистический пользователь за все время использования продукта. Эта метрика соединяет в себе сразу несколько факторов, в том числе затраты на рекламу и привлечение клиентов, конверсию и монетизацию приложения.
Именно LTV помогает понять, где у компании есть провалы, а где, наоборот, дела идут хорошо. Пожизненная ценность показывает, во сколько бизнесу обходится приобретение и потеря одного клиента. А главное, помогает прогнозировать будущее и примерно оценивать шансы продукта на успех. Одним словом, LTV определяет жизнеспособность продукта.
LTV соотносится со стоимостью привлечения среднестатистического клиента (CAC), но ценность всегда должна быть выше стоимости привлечения – желательно, хотя бы в три раза, а в идеале – в 7-8 раз. Если вы тратите на привлечение одного клиента $1, а он приносит вам $1 – очевидно, что это нежизнеспособная модель. В случаях, когда установки приложения уже считаются ключевым действием, LTV должен превосходить CPI. Также доказать жизнеспособность продукта можно при сравнении LTV и CPA (стоимость одного целевого действия) – первый показатель должен превосходить второй (LTV > CPA).
Показатель LTV легко встретить в большинство систем аналитики, а при самостоятельном расчете воспользоваться формулой: LTV = ARPU + 1/Churn, где ARPU – это средняя выручка в расчете на одного пользователя, а Churn – коэффициент оттока.
Введение в мобильную разработку для Android: с каких языков начать изучение?Коэффициент удержания (Retention Rate)
Коэффициент удержания показывает, как часто пользователи возвращаются к приложению после установки. Retention дает понять, сформировалась ли у людей привычка пользоваться сервисом. От этого показателя в наибольшей степени зависит успех бизнеса, перспективы монетизации и роста. Достаточно увеличить показатель удержания на 5%, чтобы прибыльность приложения выросла на 75%.
Сейчас в сторах насчитывается больше 5 млн мобильных приложений, поэтому разработчикам приходится отчаянно конкурировать за внимание аудитории. По данным Localytics, каждый пятый пользователь открывает программу только один раз после скачивания и больше к ней не возвращается.
Как раз поэтому Retention – одна из самых важных метрик в 2020-м, к увеличению которой стремятся даже такие рекордсмены, как TikTok. Еще в 2019 году аналитики выяснили, что популярное приложение вкладывает миллиарды долларов в рекламу, но при этом не может удержать новичков. Например, год назад только 26% пользователей продолжали заходить в TikTok спустя неделю после установки приложения. Для сравнения, у FB этот показатель – 45%, а у Instagram – 44%.
Существуют разные методы подсчета и фреймворки повышения коэффициента – единой формулы не существует. Например, классический Retention рассчитывается так: число пользователей, которые открыли приложение на N-день после 0 дня делится на число пользователей, которые впервые воспользовались приложением на день 0.
Нормы тоже зависят от продукта и категории. Например, в своей книге «Hooked. На крючке» журналист и инвестор Нир Эяль предлагает следующие нормативы Retention:
- Коэффициент 1-го дня – 50%
- Коэффициент 7-го дня — 25-30%
- Коэффициент 30-го дня — 10-15%
Опять же, на ориентиры влияет категория. Сейчас наша студия работает над приложением для доставки еды, и средний коэффициент для этой категории в мире составляет 15% (1 день), 9% (7 дней) и 4% (30 дней). Это нормально, поскольку люди не заказывают еду каждый день и в целом 48% пользователей обращается к доставке 1-2 раза за три месяца.
Как увеличить коэффициент удержания:
- Главное правило – делать продукты, которыми люди захотят пользоваться регулярно, а лучше каждый день
- Максимально упростить онбординг пользователей
- Добавить персонализацию
- Использовать геймификацию
- Не бояться экспериментов (мемы, эмодзи, минимум скучных шаблонов)
- Настроить пуш-уведомления: не злоупотреблять вниманием, учитывать интересы клиента, делать рассылки в периоды активности пользователей.
Полезные подходы
Тепловые карты
Лучший способ узнать, как миллионы пользователей используют мобильное приложение, – это тепловые карты (heatmaps). Они показывают, как человек взаимодействует с интерфейсом, какие жесты используют (тэп, скролл, зум), на что кликает. Тепловые карты можно составлять с помощью сервисов app и UX-аналитики. Они помогают определить точки концентрация трафика и, например, расположить призыв к действию так, чтобы повысить конверсию.
ИИ-аналитика
Машинное обучение уже давно применяют в сфере мобильной разработки. Алгоритмы помогают тестировать приложения (например, XCUITest для iOS и Espresso для Android), исследовать аудиторию и настраивать персонализацию, оптимизировать поисковую выдачу и эффективнее вовлекать пользователей. С их помощью легко настраивать и оптимизировать маркетинговую активность.
Главное преимущество ИИ-инструментов для аналитики – это возможность строить комплексные модели и составлять прогнозы, даже если недостает каких-то данных. Например, можно спрогнозировать нагрузку на приложение в периоды пикового спроса.
В большинстве ИИ-сервисов нет ничего революционного – например, они просто сравнивают показатели двух приложений или сопоставляют ключевые метрики за конкретные периоды. Но зато не нужно настраивать параметры вручную – алгоритмы избавляют разработчиков и аналитиков от рутинной работы.
В нашей практике, ИИ-аналитика не раз помогала улучшать показатели. Например, мы сравнили конверсию страницы описания приложения с конверсией у конкурентов. Стало понятно, что страницу нужно переработать. В результате наши метрики выросли. Без ИИ мы вряд ли обратили бы внимание на проблему.
Поведенческая аналитика
Главный тренд последних лет – это не только оптимизация, но и объединение данных из разных источников с помощью Product Intelligence-сервисов. Они помогают получать ценные инсайты о поведении пользователей на основе поведенческого анализа и совершенствовать продукт при участии всей команды, включая разработчиков, продакт- и проджект-менеджеров.
В основе принципа поведенческой аналитики лежит не вопрос «как?», а вопрос «почему?». Например, вы можете узнать, почему клиент не завершил покупку в приложении, почему определенная группа пользователей не совершает нужное действие и какие действия помогут разбудить «спящих» пользователей.
Ответы так или иначе связаны с совершенствованием клиентского опыта и пути – именно от этого зависит успех любого продукта, в том числе мобильного приложения.
![]()
Срок жизни мобильного приложения зависит от любви пользователей. Чем сильнее любовь, тем дольше приложение востребовано, и тем больше создатели на нем заработают. Для анализа поведения пользователей собирайте статистику, переводите ее в метрики и анализируйте их. Это позволит понять слабые места продукта и своевременно провести корректировку функций или интерфейса. Выберите подходящий сервис аналитики для мобильных приложений. Самые популярные: Google Analytics, AppMetrica от Яндекс, AppAnnie, Flurry и Mixpanel.
Мобильная аналитика бывает трех видов: продуктовая, анализ трафика и аналитика из магазинов приложений. Они собирают разные данные и используют каждая свои показатели. Сегодня мы рассмотрим продуктовую аналитику и покажем, как с ее помощью найти ответ на злободневные вопросы.
Популярно ли приложение?
Чтобы это узнать, смотрите на общее количество пользователей и на количество новых пользователей. Это два показателя: Total Users и New Users. Показатели рассчитываются на заданную дату, поэтому анализируйте динамику их прироста. Для привлечения New Users используйте рекламу и маркетинговые активности. Следите, чтобы приток новых пользователей покрывал отток (Churn Rate), иначе приложение останется без аудитории.
Любой бизнес держится на постоянных клиентах, поэтому регулярно анализируйте трафик - активных пользователей мобильного приложения. Это показатели DAU — количество посетителей за день, WAU — за неделю и MAU — за месяц. В подсчете участвуют только уникальные пользователи, повторные визиты не считаются. Если человек ежедневно использует приложение, его считают каждый день для DAU и один раз для WAU или MAU. Для рекламной монетизации наиболее важна метрика DAU, с помощью которой рекламодатели принимают решение об эффективности размещения рекламы. Придумывайте идеи, чтобы пользователи заходили каждый день.
Популярность мобильных игр оценивают с помощью метрики Users Online. Она фиксирует количество пользователей, находящихся в приложении одновременно и демонстрирует интерес к игре в целом. Метрика полезна и для других типов приложений. Она покажет время максимальной нагрузки на сервер и определит, когда рассылать push-уведомления.
Когда бить тревогу?
- Приток новых пользователей ниже оттока — New Users < Churn Rate.
- Показатели DAU и MAU равнозначны, значит, подавляющее число пользователей — «однодневки».
- Users Online превышает максимальную нагрузку на сервер.
Как узнать, довольны ли пользователи?
Для этого используйте две группы метрик: Retention и Activity. Показатели Retention считают количество вернувшихся пользователей и динамику их изменения. Как правило, смотрят долю вернувшихся на следующий день (1-day retention), через неделю (7-day retention) и через месяц (30-day retention). В группу Activity входят показатели Users Online, Sessions, Average Sessions Length и Life Time.
Если пользователи довольны опытом взаимодействия с приложением, они вернутся снова. Поэтому отслеживайте метрики 1-day и 30-day retention. Если 1-day retention низкий, вероятнее всего, в приложении есть проблемы: огрехи в юзабилити, неудобство интерфейса или непродуманные пользовательские сценарии. Метрика 30-day retention показывает долю пользователей, которые обычно становятся ядром лояльной аудитории.
Гипотетически метрики day retention могут быть равны 100%. Это может случится, если все пользователи, которые скачали приложение, остались верны ему навечно. Но на практике это невозможно, поэтому добивайтесь, чтобы показатели росли в динамике. Для этого отслеживайте Retention Dynamics. Найдите все скачки на графике и попробуйте понять, с чем они связаны: сезонность, реклама, специфические закономерности и др.
Отдельно следите за Sticky Factor — показателем регулярности посещений. Он рассчитывается как соотношение DAU к MAU. Чем выше значение, тем чаще пользователи в среднем заходят в приложение. Если Sticky Factor ниже 3%, пользователи заходят в приложение реже одного раза в месяц. Стремитесь к значению 50%.
Чтобы узнать, как часто пользователи заходят в приложение, разделите общее количество посещений (Sessions) на показатель DAU. Идеальные показатели зависят от типа приложения. Например, для длительных мобильных игр отличным значением будет 2 сессии в день, для коротких игр — 4-5 сессий в день.
Считайте среднюю продолжительность одной сессии — Average Sessions Length. Значения также разнятся по видам приложений. Желательно, чтобы для игр или чтения показатель был большим, а для сервисов вызова такси или заказа еды — низким. При рекламной монетизации стремитесь к максимальному показателю — 30 минут.
Каждый пользователь приложения имеет свой Life Time, т.е. срок жизни от установки до удаления приложения или последнего посещения. Считайте метрику для узких сегментов, чтобы понять поведение аудитории и увеличить срок использования: платящие и неплатящие пользователи, игроки, дошедшие до заданного уровня, и др. Разрабатывайте пользовательские сценарии и запускайте спецпредложения, чтобы удержать пользователей в конце типового Life Time.
Когда бить тревогу?
- Низкие показатели day retention.
- Retention Dynamics имеет отрицательный рост.
- Sticky Factor меньше 3%.
- Снижение Life Time.
Сколько денег приносит?
Доходы от мобильного приложения считают в виде общей выручки (Gross) и в виде выручки, очищенной от комиссий магазинов приложений (Revenue). Gross — это суммарный объем платежей за весь срок существования приложения. Для расчета Revenue вычтите платежи магазинам из значения Gross.
Еще рассчитывают Average Check — средний доход на одну транзакцию. Для расчета разделите значение Gross на количество транзакций, и вы получите средний чек. Если каждый платящий пользователь платил всего один раз, то метрики Average Check и ARPU будут совпадать.
Доход на каждого пользователя рассчитывается показателями ARPU и ARPPU. Показатель ARPU (Average Revenue Per User) — это средний доход на одного пользователя. Показатель ARPPU (Average Revenue Per Paying User) — это средний доход на одного платящего пользователя. Обе метрики считают за выбранный период. Дополнительно рекомендуем посчитать показатели отдельно для каждого среза целевой аудитории: для новых пользователей, для постоянных, для пользователей с разным Life Time.
Когда приложение платное, показатели ARPU и ARPPU будут равны. Если повышать цены, то метрика ARPPU будет расти, а ARPU — падать. Если снизить цены, показатель ARPPU упадет, потому что пользователи станут платить меньше. Но показатель ARPU вырастет, потому что контент начнут покупать неплатящие пользователи.
Когда бить тревогу?
- Gross и Revenue существенно меньше запланированных в бизнес-плане.
- ARPU и ARPPU существенно ниже средних по отрасли.
Выгодно ли приложение?
Если не брать в расчет затраты бизнеса, быстро оценить рентабельность мобильного приложения позволяют метрики CPI и LTV. Первый показатель — это Cost per Install, т.е. средняя стоимость установки приложения. Для его расчета разделите общие расходы на рекламу и маркетинг на количество установок за весь период работы приложения. Показатель LTV (Lifetime Value) показывает средний доход, который приносит один пользователь за все время использования продукта. Для его расчета перемножьте показатели ARPU и Life Time. Метрика показывает общую доходность приложения.
Следите, чтобы затраты на установку приложения всегда были ниже дохода, который приносит один пользователь. Чем дольше пользователь работает с приложением, тем выше доход он принесет разработчикам. Если приложение монетизируется только за счет показа рекламы, то один пользователь должен приносить 10$ за год. Это примерно 10-12 минут посещения приложения ежедневно.
Когда бить тревогу?
- Показатель CPI ниже ARPU;
- Показатель CPI ниже LTV.
Сможет ли принести больше денег?
Проанализируйте, сколько уже пользователей покупали платный контент или опции. Для этого смотрите на Paying Users, Paying Share и Paying Conversion. Первый показатель — количество платящих пользователей. Второй — доля платящих пользователей от общего количества активных пользователей. Третий — доля платящих пользователей от общего числа всех новых пользователей. Все показатели считаются за выбранный период.
Обратите внимание на динамику изменений Paying-метрик. Если показатель Paying Share низкий или падает, значит, платный контент не интересен. Стимулируйте пользователей совершать покупки: вводите новые платные опции, запускайте скидки, продавайте подсказки. Найдите на графике сильные скачки конверсий и разберитесь, что повлияло на резкий рост. Когда найдете причину или закономерность, внедрите это в стратегию монетизации.
Каждая оплата пользователя фиксируется сервисом статистики: кто оплатил, когда и сколько. На основании данных для анализа доступны метрики Transactions и Transactions by User. Первая метрика — это общее количество платежей за выбранный период. Вторая — среднее количество платежей на одного пользователя.
Чтобы высчитать Transactions by User разделите общий объем транзакций на значение Paying Users. Показатели транзакции демонстрируют, насколько пользователи вообще готовы платить. Если значение Transactions by User больше 1, пользователи совершают более одной покупки. Если меньше, то покупки в приложении происходят редко.
Когда бить тревогу?
- Paying-метрики сильно снижаются.
- Transactions падает.
- Transactions by User меньше 1.
Запомните
На успешность мобильного приложения влияет множество факторов. Если сегодня дела идут прекрасно, завтра все может стать по-другому. Выйдут новые конкуренты, магазины приложений изменят правила или поменяются предпочтения пользователей. Поэтому постоянно держите руку на пульсе и отслеживайте динамику показателей. Для этого установите сервис аналитики и проводите анализ каждую неделю.
Подборка
Тем, кто интересуется мобильными приложениями, рекомендуем другие статьи в блоге по теме:
Читайте также:
