Devtodev Igrovyje Metriki Kniga

ИГРОВЫЕ
МЕТРИКИ
An ultimate product analytics platform for data-driven teams

w w w. d e v t o d e v. c o m
ВВЕДЕНИЕ
Привет! Вы читаете книгу «Игровые метрики» от платформы продуктовой
аналитики devtodev.
В ней мы объединили описание основных метрик игрового проекта, а также

базовых методов их анализа. Структура книги выстроена таким образом,
что она повторяет путь пользователя в проекте: от установки и первого
знакомства с продуктом до вовлечения и монетизации, и рассказывает,
какие метрики особенно важны на каждом из этих этапов.
К слову, быть разработчиком либо аналитиком именно игрового проекта,

чтобы ощутить пользу от этой книги, совсем необязательно. Эти метрики и
методы актуальны для большинства продуктов и будут понятны и полезны
любому специалисту, участвующему в их создании и разработке.
После прочтения этой книги вы сможете ответить на вопросы:
За какими метриками стоит следить в первую

очередь и как они влияют друг на друга?
Эффективно ли было сделанное изменение?
Как оценить эффективность источников трафика,

чтобы отказаться от неэффективных и убыточных?
Как найти «слабое» место в продукте?
Как проанализировать структуру аудитории и

поведение пользователей в проекте?
Мы уверены, что эта книга поможет вам познакомиться со всеми

метриками и понять, как их применять в ваших проектах.
ПРИЯТНОГО ЧТЕНИЯ!
ОГЛАВЛЕНИЕ
1. УСТАНОВКИ .................................................................... 5
1.1. Как увеличить количество установок 6
2. ПЕРВАЯ СЕССИЯ (First-Time User Experience) ...................... 10

2.1. Как можно улучшить FTUE 14
3. УДЕРЖАНИЕ (Retention) .................................................... 16

3.1. Виды удержания 21
3.2. Почему важно следить за удержанием и увеличивать его 25
3.3. Как можно улучшить удержание 27
4. LIFETIME ........................................................................... 29
4.1. Как рассчитать Lifetime 30
4.2. Как использовать Lifetime 34
5. АУДИТОРИЯ ПРОЕКТА: DAU / WAU / MAU ..................... 35
6. СРЕДНЯЯ ПРОДОЛЖИТЕЛЬНОСТЬ СЕССИИ .............. 44

(Average Session Length)
6.1. Какая должна быть продолжительность сессии 47
7. ИГРОВОЕ ВРЕМЯ (Total Daily Play Time) ............................... 49

7.1. Как можно использовать показатель Total Daily Play Time 52
8. ЛИПКОСТЬ (Sticky Factor) ................................................... 53

8.1. Как работает Sticky Factor 54
8.2. Как увеличить Sticky Factor 55

9. ВОРОНКИ (Funnels) ............................................................. 56
9.1. Как использовать воронки 58
10. КОНВЕРСИЯ В ПЛАТЕЖ (Paying Conversion) ...................... 60

10.1. Как анализировать конверсию 62
11. ПЛАТЯЩИЕ ПОЛЬЗОВАТЕЛИ (Paying Users) .................... 66

И ИХ ДОЛЯ ОТ ВСЕЙ АУДИТОРИИ (Paying Share)
11.1. Как сегментировать платящих игроков 69
12. RFM-АНАЛИЗ ................................................................... 77

12.1. Как выставлять баллы в RFM-анализе 78
12.2. Как использовать результаты анализа 84
13. ПОТРЕБИТЕЛЬСКАЯ КОРЗИНА (Consumer Basket) ............ 87

И СТРУКТУРА ПОКУПОК
13.1. Как анализировать покупки пользователей 88
13.2. Как использовать анализ потребительской корзины 91
14. СРЕДНИЙ ДОХОД С ПОЛЬЗОВАТЕЛЯ (ARPU) ................. 93

14.1. Как использовать ARPU 95
14.2. Как повысить ARPU 97
15. СРЕДНИЙ ДОХОД С ПЛАТЯЩЕГО ПОЛЬЗОВАТЕЛЯ .... 98

(ARPPU)
15.1. Зачем рассчитывать и контролировать ARPPU 100
16. НАКОПИТЕЛЬНЫЙ ДОХОД С ПОЛЬЗОВАТЕЛЯ ............ 103

(Cumulative ARPU)
16.1. Зачем рассчитывать Cumulative ARPU 105
17. LIFETIME VALUE ................................................................ 107
17.1. Зачем нужен LTV 109
17.2. Как вычислить Lifetime Value 111
17.3. Как увеличить LTV 114
18. ВОЗВРАТ ИНВЕСТИЦИЙ (ROI) ......................................... 115

18.1. Как еще можно оценить успешность инвестиций 120
19. ВИРАЛЬНОСТЬ (k-factor) .................................................. 124

19.1. Как рассчитать k-factor 125
19.2. Как увеличить k-factor 128
20. СОЦИАЛЬНЫЙ LTV (Social LTV) ......................................... 131
21. NET PROMOTER SCORE (NPS) .......................................... 133

21.1. Как рассчитать NPS 133
21.2. Особенности проведения опросов 136
21.3. Для чего нужен NPS 139
21.4. Другие типы опросов пользователей 139
22. ОТТОК (Churn Rate) ............................................................. 141

22.1. Где использовать Churn Rate 141
22.2. Что может стать причиной оттока пользователей 148
22.3. Как уменьшить отток 149
23. ЗАКЛЮЧЕНИЕ .................................................................. 150

1 УСТАНОВКИ
Начнем с одной из базовых метрик – количество установок приложения.
Безусловно, приятно смотреть на их активно растущий график. Но значит ли

это, что и доход продукта тоже начнет увеличиваться? Все ли установки
одинаково ценны и эффективны? Попробуем ответить на эти вопросы и
для начала рассмотрим три основных цикла, благодаря которым растет
количество скачиваний.
Очевидно, что чем больше пользователей скачивает приложение, тем лучше.

Конечно, главным образом, это выгодно с финансовой точки зрения, так как
чем больше пользователей в продукте, тем больше будет количество платящих
и, соответственно, доход.
Но кроме этого, рост количества скачиваний приводит к новым скачиваниям,

образуя таким образом цикл. Рассмотрим, как это происходит.
В первую очередь, количество загрузок влияет на положение приложения в

поисковой выдаче и в магазинах мобильных приложений. Соответственно,
чем больше скачиваний, тем выше позиция в топе и тем больше
пользователей видит приложение и скачивает его.
Второй цикл – это цикл виральности, когда пользователи делятся

информацией о продукте со своими друзьями, коллегами, знакомыми.
Поэтому чем больше в приложении пользователей, тем большему
количеству людей они расскажут о нем.
Чаще всего о виральности говорят в положительном ключе, поскольку,

фактически, это распространение информации о продукте. Но что именно
рассказывают пользователи о нем своим друзьям? Ведь важно, чтобы эта
информация была положительной.
5 An ultimate product analytics platform for data-driven teams www.devtodev.com

Поэтому стоит побеспокоиться о том, чтобы приложение производило
хорошее впечатление на всех пользователей, даже на тех, которые не платят, и
на тех, которые уходят. И надо постараться, чтобы информация о приложении
распространялась в большей степени положительная.
Все это можно измерить и проанализировать, например, используя показатели

k-factor и NPS, о которых мы поговорим в следующих разделах.
Есть еще один цикл – цикл привлечения – когда в результате покупки трафика
в приложении становится больше пользователей, что запускает описанные
выше циклы, и эти пользователи начинают платить, создавая таким образом
бюджет для последующей закупки трафика.
КАК УВЕЛИЧИТЬ КОЛИЧЕСТВО

УСТАНОВОК
Чтобы ответить на этот вопрос, сначала стоит сказать, что установки могут
быть двух типов: органические – это когда пользователи находят и скачивают
приложение напрямую из магазина, и платные – когда разработчик платит
за привлечение новых пользователей.
Исходя из этого, меры по увеличению числа тех или иных установок будут
отличаться.
Циклы, которые мы рассмотрели в начале раздела, в большей степени влияют

как раз на органические установки, так как приводят к тому, что пользователи
лучше находят и скачивают приложение в сторе.
Помимо них, на органические скачивания влияет комплекс мер, называемый

ASO (App Store Optimization), который отвечает за то, насколько привлекательно
выглядит страница приложения в магазине и насколько быстро пользователь
может ее найти.
www.devtodev.com An ultimate product analytics platform for data-driven teams 6

Работа по ASO заключается в подборе «говорящей» иконки и скриншотов,
лаконичного и содержательного описания, правильных ключевых слов и
названия, а также наличии локализаций для различных стран. Правильно
подобранные, эти элементы обеспечат хорошую «находимость» приложения
по релевантным запросам и рост количества установок.
Оптимизируя страницу приложения в App Store, не стоит забывать про

отзывы, которые оставляют пользователи продукта. Они также доступны
для просмотра в магазинах приложений и могут повлиять на решение
пользователя об установке. Отзывы - это часть работы команды поддержки
devtodev. Большим плюсом органических установок является то, что они
бесплатны для разработчика, если не считать работ по App Store Optimization.
По-иному работает платное привлечение. Здесь уже разработчик должен

заплатить за то, чтобы получить нового пользователя. Есть несколько типов
кампаний по закупке трафика, например, плата за показы, клики, установки.
У них всех есть свои плюсы и минусы, но объединяет их то, что любой
канал привлечения нужно тщательно анализировать, чтобы избежать трат
на неэффективные источники.

Далеко не каждая загрузка приложения положительно отражается на доходе,
поэтому крайне важно понимать, что за пользователь установил приложение,
особенно если речь идет про платный трафик.
Поэтому при привлечении пользователей стоит проанализировать следующие

базовые метрики:
● конверсия в регистрацию или покупку;
● выполнение самых важных действий в продукте (просмотр магазина,
прохождение туториала);
● retention уже с 1-го дня;
● ARPU;
● количество сессий на пользователя;
● время до совершения первого платежа и другие.

Эти метрики можно начинать отслеживать уже в первые дни после установки
приложения пользователем.
Чуть позже можно рассчитать такие показатели, как:
● накопительный ARPU
● LTV
● ROI.
Это нужно, чтобы однозначно определить эффективность канала привлечения

и оценить факт и сроки его окупаемости.
Важно отметить, что для сравнения различных каналов нужно использовать

когортный анализ. Это позволяет работать с кампаниями, запущенными в
разное время и имеющими разную продолжительность.
Кстати, стоит также вычислить процентный состав поступающего трафика:

какую долю составляют органические установки, а какую – платные.
| Доля платных и органических установок

Если органические установки составляют небольшой процент, а аудитория
увеличивается в основном за счет платных пользователей, стоит убедиться,
что платный трафик настолько качественный, что приносит больше денег и
быстро окупается. В противном случае такая ситуация довольно рискована для
продукта, так как он полностью зависит от платного привлечения, без которого
он не сможет самостоятельно расти и приносить доход. Помимо источника
установок, при анализе скачиваний можно использовать и другие варианты
сегментации и оценивать метрики пользователей по таким параметрам,
как страна, девайс, пол, возраст и так далее. Обычно пользователи разных
сегментов ведут себя в продукте по-разному, и их финансовые показатели
тоже отличаются.
| ARPU проекта с сегментацией по странам
Несмотря на кажущуюся простоту показателя загрузок, его можно

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

трафика, которое напрямую повлияет на доход приложения.

2 ПЕРВАЯ СЕССИЯ
(FIRST-TIME USER EXPERIENCE)
Первого впечатления о приложении может быть достаточно для принятия
решения о том, стоит ли продолжать им пользоваться. Поэтому задача
разработчика – сделать первую сессию максимально простой и понятной,
донести суть продукта, заинтересовать так, чтобы захотелось изучать
функционал дальше самостоятельно.
КАК УЛУЧШИТЬ ПЕРВУЮ СЕССИЮ?

ЧИТАЙТЕ ПОДРОБНОСТИ В ЭТОМ РАЗДЕЛЕ.

Опыт и впечатления, которые получает пользователь во время своей первой
сессии в приложении, называются аббревиатурой FTUE – first-time user
experience. Это комплексный показатель, который требует тщательного
анализа различных этапов пользовательского пути.
В первую очередь стоит обратить внимание на удержание (Retention) 0-го и

1-го дней.
Retention 0-го дня – это процент пользователей, которые заходили в

приложение второй раз спустя 0-24 часа после первого визита. Это именно те
люди, которые заинтересовались и решили продолжить изучать приложение,
причем уже в первые часы после первого запуска.
Retention 1-го дня – это доля пользователей, зашедших в приложение на

следующий день.
Наибольший отток пользователей происходит как раз в первый день. Это

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

| График метрики retention по дням с момента установки
Помочь в анализе оттока в первые дни может статистика прохождения

туториала. Это первое, с чем сталкивается пользователь в приложении.
На данном этапе совсем нежелательно терять пользователей, ведь они еще

даже не дошли до самого приложения и не попробовали что-то в нем сделать
самостоятельно.
К счастью, туториал довольно просто проанализировать. Если где-то

обнаружится отвал, то его можно быстро исправить, сохранив тем самым
пользователей в начале их пути.
Например, в devtodev можно интегрировать до 120 шагов туториала, чтобы

детально оценить каждый его этап.

| Статистика по прохождению шагов туториала. Скриншот из демо devtodev
Важно, чтобы за время первой сессии пользователь дошел до совершения

ценного целевого события – основного функционала приложения.
Иногда это называют "aha-момент". Это некий этап пользовательского

пути, на котором человек совершил действие, с большой долей вероятности
сохраняющее его в проекте.
Например, для Slack это 2000 отправленных сообщений, для Dropbox –

загруженный файл, для игры это может быть понимание человеком игрового
цикла и прохождение N уровней. А Zynga считает таким моментом в своих
продуктах возвращение пользователя на следующий день.
Aha-момент говорит о том, что пользователь разобрался в сути проекта,

а это повышает вероятность его возвращения.

Иными словами, в рамках первой сессии пользователь должен понять, зачем
ему открывать приложение снова. Если же за это время он не разберется с
продуктом, то вряд ли сделает еще одну попытку. Так что в первую сессию
нужно показать суть продукта и то, какие задачи он решает.
Для этого нужно максимально коротким путем провести пользователя к

совершению целевого действия. Здесь помогут воронки, построенные для
новых пользователей.
| Скриншот из демо devtodev. Пример воронки из 4-х шагов: от прохождения

туториала до совершения целевого действия.
Также можно изучить, какие действия совершают во время первой сессии

пользователи, которые вернулись в приложение на следующий день или
даже сделали платеж, а затем постараться провести новых пользователей
таким же путем.

Кстати, аналогичным образом можно исследовать FTPUE (First-Time Paying
Users Experience) – первую сессию с платежом, чтобы понять, что заставляет
пользователя что-то купить: какие действия он совершает перед тем, как
перейти в магазин и сделать покупку, как ведет себя в самом магазине, легко
ли ему сделать выбор, какой товар он покупает и сколько времени проходит
до совершения первого платежа.
КАК МОЖНО УЛУЧШИТЬ FTUE

● В первую очередь стоит хорошо протестировать приложение и
исправить все что может испортить впечатление пользователя от
продукта. Потому что если «старый» лояльный пользователь их стерпит
или напишет в техническую поддержку, то новый, скорее всего, получит
негативное впечатление.
● Во время первой сессии пользователь должен понять ключевые

функции продукта, поэтому навигацию в приложении стоит хорошо
продумать, чтобы пользователь понимал, куда он движется и зачем.
● Желательно, чтобы ничего не отвлекало пользователя от пути к цели

в приложении.
● Если возможно, стоит перенести регистрацию с первого запуска на

последующие этапы или открывать функционал постепенно.
● Ведя пользователя к базовому функционалу, стоит сделать акцент на

преимуществах над конкурентами.
● Если основной контент приложения платный, то стоит добавить

демо или какие-то примеры, демонстрирующее функционал, чтобы
пользователь понимал, за что ему предстоит платить.

От первой сессии пользователей и того, с чем они во время нее столкнутся,
зависит, останутся ли они в проекте, расскажут ли о приложении друзьям,
сколько и как быстро в итоге заплатят.
Более того, оптимизируя первую сессию, можно увеличить как удержание

нулевого/первого дня, так и удержание последующих дней.
Поэтому именно в этот момент стоит наиболее внимательно относиться к

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

3 УДЕРЖАНИЕ
(RETENTION)
Чтобы проект приносил доход, в нем должны быть платящие пользователи.

Платящие пользователи — это часть общей аудитории проекта. Чтобы набрать
эту аудиторию, новые пользователи должны заинтересоваться проектом и
возвращаться в него как можно чаще.
Эту «возвращаемость» определяет такая метрика как удержание (Retention).

Рассчитывается она для когорт в определенный день с момента установки
следующим образом:
Строго говоря, метрика показывает, какой процент пользователей зашел в

приложение на N-й день после его установки.
Рассмотрим пример: допустим, первого января 2021 года (01.01.2021) первый

раз приложение запустили 1 020 человек.
Далее смотрим, сколько из них заходили в приложение в последующие дни и

рассчитываем удержание по формуле, указанной выше.

Размер когорты - 1 020 пользователей
| Количество пользователей, вернувшихся в проект, и Retention в 1-28 дни

с момента установки
Чаще всего график удержания выглядит следующим образом:
| График метрики Retention по дням с момента установки
Наибольший отток пользователей происходит в первые дни после установки,

затем скорость падения Retention снижается, и те пользователи, которые
заходят в приложение на 20-30-й день, чаще всего остаются в нем надолго.

Удержание обычно отслеживают не каждый день после установки, а на 1-й,
7-й и 28-й дни. Традиционно хорошими показателями считаются:
● Удержание 1-го дня — 40%

Удержание 1-го дня говорит о первом впечатлении пользователя о проекте,

его реакции на интерфейс, об удобстве этого приложения и соответствии
ожиданиям и задачам.
Кроме того, удержание 1-го дня влияет на удержание последующих дней,

поэтому данному показателю стоит уделять большое внимание. В первый
день нужно добиться того, чтобы пользователь разобрался в продукте, понял
его ценность, суть и преимущества (это называется активацией).
Именно с активации начинается погружение пользователя в проект,

которое в идеале должно привести к совершению покупки.
Есть схема, ясно описывающая сценарий, по которому должен проходить
пользователь от установки до совершения платежа:
Чтобы эта цепочка сработала на практике, во время первой сессии нужно

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

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

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

дням, а по часам. Это значит, что удержание 1-го дня — это процент
пользователей, вернувшихся в продукт в период 24-48 часов с момента
установки.
| Retention 1-го дня, рассчитанный по 24-часовым интервалам. Скриншот из

демо devtodev.

Посмотрим, как изменение принципа расчета может повлиять на результат.
На временной шкале точками обозначены сессии пользователей.
| Сессии пользователя по календарным дням и 24-х часовым интервалам
Если считать удержание по календарным дням, то пользователь учтется

вернувшимся в 1, 2 и 4 дни с момента установки. Но если использовать расчет
по часам, то первые 2 сессии попадут в один день, и в итоге пользователь
учтется вернувшимся в 1 и 3 дни с момента установки.
Такой расчет имеет смысл, если пользователи рассредоточены по различным

часовым поясам и календарный день у них наступает с разницей в несколько
часов. В этом случае, например, прирост трафика в одной стране может
изменить показатели удержания первых дней.
Также этот метод позволяет рассчитывать еще одну метрику – удержание

нулевого дня. Эта метрика показывает процент пользователей, которые
заходят в продукт в тот же день, когда была совершена установка.
Стоит также сегментировать показатели удержания при анализе по

источникам трафика, стране, платформе и другим критериям, поскольку
поведение пользователей различных категорий может отличаться. Это
будет особенно полезно при оценке источников трафика для выявления
наиболее эффективного, потому что переходя из разных источников,
пользователи могут иметь разное представление о приложении.
Соответственно, у них могут быть разные ожидания. Это может сказаться на

показателях удержания, может быть сигналом к изменению аудитории,
которой отображается реклама, либо к изменению подачи продукта.
ВИДЫ УДЕРЖАНИЯ
Помимо классического варианта расчета Retention, выделяют еще четыре
разных подхода.
Повторяющееся удержание
(Rolling Retention)
Повторяющееся удержание N-го дня показывает процент пользователей,

которые вернулись в приложение в день N с момента установки или позже,
то есть, (N+m).
Например, в расчет Rolling Retention 14-го дня попадут и пользователь, который
зашел в приложение на 14-й день после установки, и пользователь, который
на 14-й день в игру не заходил, а зашел лишь на 30-й день.
Полное удержание
(Full Retention)
Полное удержание N-го дня показывает процент пользователей, которые

заходили в приложение каждый день до дня N.
Например, полное удержание 5-го дня – это процент пользователей, которые
заходили в приложение в 1-й, 2-й, 3-й, 4-й и 5-й дни с момента установки.
Возвратное удержание
(Return Retention)
Возвратное удержание N-го дня показывает процент пользователей, которые

вернулись хотя бы один раз за N дней.
Например, возвратное удержание 21-го дня будет учитывать каждого
человека, который зашел в приложение в любой день с 1-го по 21-й.

Диапазонное удержание
(Bracket-Dependent Return Retention)
Диапазонное удержание N-го дня является одним из вариантов возвратного
удержания. Как можно догадаться, оно учитывает пользователей, которые
вернулись в приложение в ограниченный период хотя бы один раз.
Для расчета этого удержания задается дополнительно к N параметр M,

который ограничивает временной диапазон для возврата пользователей.
В этом случае удержание рассчитывается как процент пользователей,
вернувшихся в приложение в промежуток M-N дней.
Например, диапазонное удержание с 14-й по 20-й день будет показывать

процент пользователей, которые запустили анализируемое приложение в
любой день этого периода.
Из всех описанных выше вариантов, наиболее часто на практике

используется повторяющееся удержание (Rolling Retention). Его формула
выглядит следующим образом:
Для начала рассмотрим на примере, как рассчитывается этот показатель.

Предположим, что у нас есть следующие данные о пользователях и их
сессиях (синим выделены дни, когда пользователи заходили в приложение,
а красным – дни с момента последнего визита, в которые не было заходов):

| Таблица с визитами пользователей в определенные дни с момента установки
Повторяющееся удержание N-го дня учитывает пользователей, которые

заходили в этот день или позже, а значит тех, чья ячейка в этот день закрашена
синим или белым.
После чего, как и с классическим удержанием, считается доля этих

пользователей от количества пользователей в когорте. Если сравнить эти два
вида удержания, то получится такая картина:
| Сравнение графиков классического и повторяющегося удержания

Повторяющееся удержание всегда больше классического (или хотя бы равно
ему), поскольку при его расчете учитываются пользователи, зашедшие не
только в один конкретный день, но и в последующие. Также график этого типа
убывает более плавно, чем в случае классического удержания.
И есть еще одна особенность, которая отличает повторяющееся удержание

от классического, делает его использование более сложным – это сам расчет.
Дело в том, что этот показатель нужно пересчитывать каждый день, так
как пользователь, который не заходил уже несколько дней и считается
ушедшим, может в какой-то момент воспользоваться приложением, что
повлияет на повторяющееся удержание всех предыдущих дней.
Например, пользователь заходил в приложение последний раз на 7-й день

с момента установки. Мы рассчитали показатель когорты за 25 дней, а этого
пользователя перестали учитывать после 7-го. После чего он зашел на 26-й
день, а это значит, что повторяющееся удержание с 8-го по 26-ой день
должно быть рассчитано заново с учетом этого пользователя.
Смысл использования повторяющегося удержания в том, чтобы учесть

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

не обязательно пользуются каждый день, например для игр, в которых
пользователь вынужден ждать долгое время, пока накопятся ресурсы или
построится объект.
Есть у этого параметра еще одна полезная особенность. Удержание в

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

Повторяющееся удержание определенного дня учитывает пользователей,
которые заходят и в последующие дни. Если пользователь не посчитался
вернувшимся, это значит, что и в последующие дни исследуемого периода
он не заходил.
Получается, что область под кривой – это вернувшиеся пользователи, которых

как раз показывает наша метрика, а область над кривой – отток – те, кто с
определенного дня больше не заходили в приложение.
| График повторяющегося удержания и оттока по дням с момента установки
ПОЧЕМУ ВАЖНО СЛЕДИТЬ ЗА

УДЕРЖАНИЕМ И УВЕЛИЧИВАТЬ ЕГО
Удержание влияет на размер аудитории
Хотите, чтобы аудитория становилась больше? Тогда отток пользователей из
продукта должен быть меньше притока.
В случае, когда в приложение постоянно приходят новые пользователи, но

не задерживаются надолго, у него никогда не будет стабильной аудитории.

Плюс, если аудитория проекта состоит в основном только из новых
пользователей, которые в скором времени покинут его, то маловероятно,
что проект будет успешно монетизироваться.
Удержание влияет на доход

Чем дольше пользователь в проекте, тем лояльнее он становится и больше
вероятность, что он совершит платеж. Если в продукте предусмотрены
небольшие, но постоянные платежи, то чем дольше пользователь будет
пользоваться продуктом, тем больше он этих платежей сделает. Плюс,
если ваша программа монетизируется с помощью рекламы, это значит,
что каждый заход приносит вам деньги. Чем дольше каждый пользователь
продолжает заходить к вам, тем лучше.
Этот показатель удобно сравнивать

для различных когорт
чтобы, например, оценить влияние изменений, сделанных в продукте, на
поведение пользователей.
| Классический Retention по дням с момента установки для разных когорт.

Скриншот из демо devtodev

Удержание используется для расчета Lifetime
и Lifetime Value
Эти метрики являются самыми важными для любого проекта, определяют
его успешность, позволяют выявлять самые эффективные каналы привлечения,
находить финансово привлекательные сегменты пользователей.
КАК МОЖНО УЛУЧШИТЬ УДЕРЖАНИЕ

● Как говорилось ранее, самая первая сессия во многом определяет
последующее поведение пользователя и именно в это время нужно
как можно быстрее донести до него суть приложения. Для этого
можно использовать туториал, который наглядно продемонстрирует
пользователю функционал продукта.
● Иногда, для того чтобы пользователи возвращались в проект, им

нужно напоминать о нем, используя различные уведомления: пуши,
почтовые сообщения и тому подобное.
● Бонусы и подарки, периодически получаемые пользователем в

процессе работы с приложением, могут способствовать его интересу
к продукту, влиять на желание снова в него зайти.
● Поддерживать интерес пользователя можно, постепенно открывая ему

новый контент, регулярно ставя ему цели и задачи.

● Способствовать вовлеченности может деление общего пути к цели на
этапы, чтобы пользователь ощущал прогресс и получал удовольствие
от достижения или выполнения каждого шага.
● Связь с социальными сетями и взаимодействие с друзьями в рамках

продукта создаст большую привязанность и заинтересованность.
● Еще увеличить удержание можно следующим способом: сначала

изучить поведение пользователей, которые остались в проекте (их
сессии, последовательность действий, использование функционала),
а затем провести этим путем новых пользователей.
Удержание – одна из самых важных метрик продукта, поскольку она

определяет размер аудитории и возможность роста компании, говорит
о первом впечатлении пользователя о продукте и определяет, сколько
в среднем времени он проведет в приложении, что напрямую влияет на
доход. Поэтому удержание – одна из тех метрик, на которую стоит обращать
особое внимание, постоянно контролировать и улучшать.
Повторяющееся удержание также характеризует интерес пользователей

к проекту, и показывает, когда они уже больше в него не вернутся, благодаря
чему позволяет рассчитать такие показатели, как отток и Lifetime.
Однако зачастую повторяющееся удержание может дезинформировать

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

внимание на оба вида удержания для принятия взвешенных решений.

4 LIFETIME
Иногда, обычно накануне нового года или в какой-нибудь из понедельников,
мы принимаем решение начать ходить в спортзал, покупаем абонементы и
начинаем усердно тренироваться.
Кому-то хватает одного занятия, чтобы после недели мышечной боли

забыть об этой затее, кто-то честно ходит один месяц, чтобы отработать
купленный абонемент, а кто-то втягивается и проводит вечера в спортзале
на протяжении нескольких лет.
С приложением ситуация абсолютно идентичная – далеко не все люди

используют его годами, большинство перестает пользоваться как только
пропадает интерес или потребность.
И это является показателем востребованности и заинтересованности

пользователей, а также гарантией их финансовой активности.
Существует метрика, которая характеризует этот процесс и показывает,

сколько в среднем времени пользователь активен в проекте – Lifetime,
или LT. Причем под активностью подразумеваются не ежедневные посещения,
а то количество времени, которое прошло между первым и последним
запуском приложения.
Обычно Lifetime рассчитывается для когорт, и чем больше времени с момента

установки проходит, тем меньше пользователей из этой когорты продолжают
использовать продукт.
Наибольший отток происходит, как правило, в первые дни. Выглядит это

следующим образом и представляет собой график метрики Retention:

| График Retention по дням с момента установки
КАК РАССЧИТЫВАТЬ LIFETIME

Для расчета Lifetime есть несколько вариантов. Пожалуй, самый точный, –
взять когорту пользователей, подождать пока все они перестанут заходить в
проект и посчитать, сколько в среднем пользователи проводят в проекте.
Например, в когорте 100 пользователей. Нам известно, столько дней они

провели в проекте перед тем как уйти:
| Количество пользователей и
количество дней, проведенное
ими в проекте

В этом случае их Lifetime составит 15,6 дней.
Но на практике такой метод чаще всего не применим, так как ждать придется
довольно долго и далеко не всегда можно сделать вывод по одной когорте.
Поэтому Lifetime обычно принято не считать, а именно оценивать, беря в
расчет какую-либо стороннюю информацию, в частности Retention.
Один из способов это сделать – считать «отвалившимися» тех пользователей,

которые не заходили в приложение 7, 14, 30 и более дней. Иными словами,
нужно определить критерий «невозврата» пользователей. Обычно таким
периодом является 1-2 недели бездействия.
Именно этот метод используется в devtodev, а сроком отвала считается 7 дней.
| График Lifetime. Скриншот из демо devtodev
Другой, чуть более сложный способ, – посчитать интеграл от функции

Retention, так как Lifetime является площадью под кривой Retention, либо
просто сложить все показатели Retention.
Для этого нужно знать значения Retention за несколько дней. Желательно,

чтобы число дней было как можно больше, поскольку от этого будет зависеть
точность рассчитанного Lifetime.

Например, у нас есть значения Retention за первые 28 дней. Сложив их, мы
получим значение Lifetime, которое равно 4,9.
| График и значения Retention по дням с момента установки
Стоит учитывать, что Lifetime – это средняя величина, она не говорит о том,
что большинство пользователей покидают проект через это количество дней.
В этом заключается польза этой метрики – она показывает общую ситуацию

по продукту в одной цифре.
Допустим, в ходе экспериментов получилось увеличить Retention первых

дней, но одновременно с этим метрика начала падать, начиная с 5-го дня.

| Сравнение Retention до и после изменений
Получив такой результат, довольно тяжело оценить эффективность

изменений – какой из Retention’ов сильнее влияет на проект, достаточно ли
роста Retention в начале, чтобы компенсировать более продолжительное
падение после пятого дня.
В то время как Lifetime может помочь сделать этот вывод, поскольку этот
показатель учитывает все значения Retention. И посчитав его для данного
примера, можно сделать вывод, что изменение положительно повлияло
на проект.
Также при работе с Lifetime стоит уделить внимание сегментации. Причем

сегментировать можно в двух направлениях: использовать стандартные
сегменты типа страны или девайса, или делить пользователей по времени,
которое они проводят в приложении – по самому Lifetime.
Иными словами, можно отдельно анализировать и оценивать поведение

пользователей, Lifetime которых меньше недели, или от недели до двух, от
двух до месяца и так далее. Вероятно, поведение таких сегментов будет
отличаться и, исследовав его для каждой группы, можно обнаружить
проблемные места в приложении и понять причину оттока.

КАК ИСПОЛЬЗОВАТЬ LIFETIME
Этот показатель говорит о том, через какое время пользователь покинет
продукт. Зная, когда это случится, можно попытаться внести некоторые
коррективы, чтобы продлить его пребывание в проекте: предложить скидку,
отправить пуш-уведомление, изменить что-то в приложении.
Кроме того, Lifetime тесно связан с другой метрикой – Lifetime Value,

которая показывает сколько денег приносит пользователь за время жизни в
проекте (Lifetime).
Поэтому, несмотря на то, что, на первый взгляд, Lifetime измеряется в днях и

не имеет финансовой составляющей, на доход она, тем не менее, влияет: ведь
чем больше Lifetime, тем дольше пользователь будет платить.
Это особенно важно для подписных продуктов, поскольку там каждый

подписанный пользователь будет периодически и стабильно приносить
доход компании.
Очевидно, что стоит работать над повышением этой метрики, так как чем
дольше пользователи живут в проекте, тем больше денег они в него принесут.

5 АУДИТОРИЯ ПРОЕКТА:
DAU / WAU / MAU
Ежедневно аудитория проекта пополняется новыми пользователями. Кто-то
из них быстро теряет интерес, кто-то иногда вспоминает о приложении, а
кто-то пользуется им регулярно.
И наверняка каждый день в приложение заходят представители всех

этих сегментов. В данном разделе мы и поговорим о них – активных
пользователях (Active Users).
Активные пользователи – это те, у кого была хотя бы одна сессия за

исследуемый промежуток времени. Эти промежутки могут быть разные, но
чаще всего исследуют дневную, недельную, а также месячную аудитории
проекта. И эти показатели имеют устоявшиеся названия:
● DAU – число уникальных пользователей в день (Daily Active Users);

● WAU – число уникальных пользователей в неделю (Weekly Active Users);
● MAU – число уникальных пользователей в месяц (Monthly Active Users).

При этом можно делать аналогичные расчеты и за любые другие периоды,
если они лучше отвечают требованиям компании. Например, подводя итоги
уходящего года, можно посчитать годовую аудиторию проекта и сравнить с
предыдущими годами, чтобы оценить динамику.

Стоит обратить внимание, что WAU за определенную неделю – это не сумма
DAU за 7 дней, так как речь идет об уникальных пользователях. Например,
один из них может зайти в приложение в понедельник и вторник, и он попадет
и в DAU понедельника, и в DAU вторника. Но в рамках недели (с понедельника
по воскресенье) он будет посчитан только один раз.

Аналогично и MAU не является суммой четырех WAU и тридцати DAU. С точки
зрения расчета, эти показатели не связаны между собой и рассчитываются
отдельно. Чтобы получше разобраться с этими показателями, посчитаем их
на примере.
Допустим, у нас есть данные о посещениях приложения различными

пользователями за 2 недели. При этом не имеет значения, сколько раз в день
заходил пользователь в проект, так как он все равно будет одним уникальным
посетителем:
| Таблица с визитами пользователей по дням.

Синим отмечены дни, когда пользователи заходили в приложение

Итак, сначала рассчитаем DAU для 1-го, 2-го, 5-го и 10-го дня. Для этого нужно
знать, сколько уникальных пользователей заходило в приложение в эти дни:
● DAU 1-го дня = 2 (пользователи 1 и 4);

● DAU 2-го дня = 3 (пользователи 2, 4, 5);
● DAU 3-го дня = 3 (пользователи 2, 3, 4);
● DAU 10-го дня = 0 (никто не заходил в приложение в этот день).
Далее посчитаем WAU

● в первую неделю
(с 1-го по 7-й дни) он равен 5 – все пользователи заходили в проект;
● во вторую неделю
(с 8-го по 14-й день) этот показатель уже 3 – первый и второй
пользователи не делали сессий.
Можно выбрать и произвольную неделю, например, с 3-го по 9-й день, и

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

полгода, и за другие временные промежутки.
В нашем примере участвовало всего 5 человек, а в реальном проекте это

будут тысячи, сотни тысяч, миллионы пользователей, которые ежедневно
посещают продукт. И то, как они заходят в приложение, говорит о его
стабильности, качестве и масштабе.
Кроме того, Active Users – это тот показатель, который имеет смысл
отслеживать в реальном времени, потому что если что-то сломается
в приложении или на сервере и пользователи не смогут воспользоваться
продуктом, это сразу же скажется на данной метрике. Для такого контроля
группировать пользователей можно уже не по дням, а по часам или даже
10-ти минутным интервалам.

Кстати, активные пользователи, которые в текущий момент находятся в
приложении, – это отдельная метрика, которая имеет свое название.
Чаще всего это Users Online, но можно встретить и такие аббревиатуры,

как CCU (Concurrent Users) – пользователи, находящиеся в приложении в
определенный момент, и PCCU (Peak Concurrent Users) – максимальное
количество пользователей, одновременно находящихся в приложении.
Упростить анализ изменений числа активных пользователей помогает

сегментация. Благодаря ей можно быстрее понять, за счет какого сегмента
пользователей происходит изменение показателя.
Вот несколько вариантов сегментации активной аудитории.

● По платежам:
• платящий / неплатящий,
• совершивший только 1 платеж / совершивший повторные
платежи.
● По сроку с момента установки:
• 1 день / 2-7 дней / 8-14 дней / 15-30 дней / 30-60 дней /
60+ дней.
● По регулярности заходов:
• каждый день / 4-6 раз в неделю / 1-2 раза в неделю /
раз в месяц и реже.
А также можно делить по странам, по девайсам, операционным системам,

по кастомному событию (то есть, делить всю аудиторию на пользователей,
выполнивших и не выполнивших то или иное действие).
Последний вариант сегментации можно использовать, если в приложении

есть какое-либо ключевое событие, важное для полноты опыта или создания
правильного первого впечатления о продукте (например, прохождение
обучения, N уровней в игре или заход в магазин).


Когда вы определите сегмент, в котором происходит уменьшение активных
пользователей, будет проще искать возможную причину проблемы.
Может случиться следующая ситуация:
| Динамика изменения активной аудитории по странам
Сначала начинает уменьшаться количество активных пользователей в

России, в то же время увеличивается количество посетителей из Японии
и они компенсируют падение в другой стране.
Если мы смотрим только на общий график DAU, то вряд ли заметим

какие-либо изменения. И только потом, когда количество активных
пользователей России упадет еще сильнее, мы увидим это на общем графике.
А между тем, уже пройдет достаточно много времени, которое можно
было бы использовать для поиска и устранения причины падения.
Еще одна статистическая аномалия, которая подтверждает важность

сегментации – это парадокс Симпсона. Ее проявление лучше всего
рассмотреть на примере.

Возьмем 4 страны из предыдущего примера и предположим, что конверсия
в покупку в них такая:
| Конверсии 4-х стран из новых пользователей в платящих
Далее посчитаем общую конверсию европейских и азиатских стран:
| Конверсии европейских и азиатских стран из предыдущей таблицы из новых

пользователей в платящих
И вот что получается:

● Конверсия в России
4,85% - больше, чем конверсия в Японии (4,44%);
● Конверсия в Великобритании
7,08% - больше, чем конверсия в Китае (6,98%);
● Общая конверсия европейских стран
5,79% - меньше, чем конверсия азиатских (6,45%).

Это еще раз говорит о том, что сегментация может дать совсем не такие
результаты, как общая статистика показателя.
Кстати, глядя на график DAU, вы не всегда можете явно определить тенденцию,

но группировка по неделям или по месяцам (преобразование графика в WAU и
MAU), делает ее более явной.
| Количество активных пользователей, сгруппированное по дням, неделям,

месяцам
Сама по себе метрика Active Users, безусловно, важна для проекта, но

кроме этого она также связана с другими финансовыми и поведенческими
метриками.
В первую очередь, на Active Users влияет количество новых пользователей

– чем их больше, и чем быстрее и стабильнее они приходят в проект, тем
быстрее растет аудитория.
Второй, не менее важный, показатель – Retention (удержание пользователей),

который говорит от том, как пользователи возвращаются в проект. Если
приводить в продукт новых пользователей, которые не будут в него
возвращаться, то они не пополнят аудиторию, а такое привлечение не даст
никакого эффекта. Важно заинтересовать пользователей продуктом, чтобы
они хотели вернуться. И чем их будет больше, тем больше будет активная
аудитория.

Небольшой пример:
| Влияние Retention на аудиторию проекта
Можно иметь хорошие показатели Retention в приложении, но при небольшом

количестве новых пользователей аудитория будет расти очень медленно. И
наоборот, если есть хороший приток новых пользователей и низкий Retention,
то большая их часть покинет проект, что также не увеличит аудиторию.
А чем больше аудитория проекта, тем больше среди нее потенциальных

плательщиков. Ведь именно в следующей последовательности пользователи
становятся платящими:

Кстати, важно, чтобы пользователь после совершения первого платежа
оставался активен в продукте, потому что это увеличит шансы на то, что
он совершит повторные покупки. Таким образом, Active Users прямо влияет
на доход:
Количество активных пользователей – один из важнейших показателей

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

и на скорость роста аудитории, ведь эта метрика является одним из самых
позитивных признаков активного развития продукта.

6 СРЕДНЯЯ ПРОДОЛЖИТЕЛЬ-
НОСТЬ СЕССИИ
(AVERAGE SESSION LENGTH)
Каждому разработчику хочется, чтобы пользователь задерживался в его
приложении как можно дольше поскольку считается, что это говорит о его
заинтересованности и вовлеченности. Однако:
● действительно ли хорошо надолго задерживать пользователей

в продукте?
● какими способами можно это оценить?

Давайте разбираться.
Метрика, которая используется для оценки продолжительности пребывания

пользователя в приложении, называется средняя продолжительность
сессии (Average Session Length) и рассчитывается по формуле:
Практически все аналитические сервисы рассчитывают этот показатель,

правда, везде он называется по-разному.
Можно встретить такие названия как Session Duration, Session Length или
Visit Duration.

И сам принцип расчета тоже зачастую сильно отличается в разных компаниях.
Какие-то сервисы считают сессией время активности приложения, когда
оно находится в фокусе (запущено и открыто на экране), другие находят
разницу между временем первого и последнего действия. Однако еще
одна особенность заключается в том, что сервисы по-разному работают
с прерываниями сессий. Сессии могут обрываться автоматически после
определенного времени неактивности, в случае закрытия приложения или
при потере фокуса.
| Динамика изменения средней продолжительности сессии.

Например, в аналитическом сервисе devtodev продолжительностью сессии

считается время активности приложения – когда оно находится в фокусе. Если
фокус теряется более чем на 10 минут, сессия считается завершенной.
Поэтому при использовании данной метрики стоит изучить документацию,

чтобы наверняка понимать, что она значит.
Еще один нюанс заключается в том, что эта метрика рассчитывается как
среднее арифметическое, а это значит, что она может быть искажена не
совсем корректными данными.

Допустим, большая часть пользователей проводит в приложении от 10 до 20
минут, но несколько пользователей зашли в него, отвлеклись на что-нибудь, и
их сессия в результате продлилась 45 минут.
Вот как изменится результат при наличии таких пользователей:
| Продолжительность сессий пользователей
Поэтому стоит иметь в виду, что экстремальные значения будут влиять на

итоговый результат.
Не лишним будет применить сегментацию к этим данным. Возможно, что

пользователи, пришедшие из разных источников или использующие разные
устройства, имеют разную продолжительность сессии. По всей вероятности,
и поведение, и их платежи в продукте будут отличаться.
| Динамика средней продолжительности сессий с сегментацией по

источникам трафика. Скриншот из демо devtodev

КАКАЯ ДОЛЖНА БЫТЬ
ПРОДОЛЖИТЕЛЬНОСТЬ СЕССИИ
Однозначного ответа на этот вопрос нет. Дело в том, что все приложения
довольно разные, как и их назначение. Исходя из этого, пользователи
проводят в них разное количество времени. Например, сессия в словаре
вряд ли будет длиться долго – пользователю нужно просто узнать значение
слова, а прослушивание музыки через приложение или работа в графическом
редакторе может затянуться на несколько часов. Поэтому сравнивать длины
сессий различных приложений не имеет смысла, но в рамках одного
жанра сравнение может быть уместным.
Часто можно встретить такую зависимость – чем больше сессий, тем они
короче, а если сессии у пользователей довольно длинные, то маловероятно,
что их будет много. В этом случае, скорее частота сессий будет говорить о
заинтересованности пользователя и привычке использовать приложение. Если
она действительно есть и пользователь каждую свободную минуту тянется к
приложению, то продолжительность сессии уже не играет такой важной роли.
Однако стоит оценивать продолжительность сессий с точки зрения здравого

смысла – если большая их часть имеют продолжительность, например, до
10 секунд, и за это время в приложении невозможно ничего успеть сделать,
то стоит подумать, что заставляет пользователей так быстро покидать его.
Вряд ли можно говорить о прямой тесной связи продолжительности сессий с

доходом. Однако какие-то выводы этот показатель все же позволяет сделать.
Например, если после релиза увеличилась продолжительность сессий, это

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

И если это так, и заинтересованность пользователей увеличилась, то это
значит, что и финансовые метрики скорее всего должны возрасти, а вместе с
ними и Retention.
| Динамика изменения средней продолжительности сессии

и Retention 1-го дня
Или наоборот, продолжительность сессии увеличилась, потому что новый

интерфейс стал менее понятен пользователям. Тогда это может сказаться на
тех же метриках, только уже в обратную сторону.
Выходит, что сама по себе средняя продолжительность сессий мало что

может сказать о продукте, если анализировать ее в отрыве от его жанра,
особенностей, а также других финансовых и поведенческих показателей и
метрик, которые более однозначно помогут оценить поведение пользователей
и их вовлеченность.
Тем не менее, изменение показателей этой метрики может быть хорошим

сигналом для анализа последних апдейтов и их влияния на продукт и
его метрики.

7 ИГРОВОЕ ВРЕМЯ
(TOTAL DAILY PLAY TIME)
Практически всегда разработчик заинтересован в том, чтобы пользователь
как можно чаще, дольше и больше пользовался его продуктом. Ведь чем
больше времени он в нем проведет, тем больше вероятность того, что он
заплатит или хотя бы станет заинтересован и лоялен к продукту.
Метрика, которая как раз отражает то, сколько времени проводит юзер в
продукте – это Total Daily Play Time. Рассчитывается она следующим образом:
Суммарную продолжительность всех сессий в день нужно разделить на

количество активных пользователей в этот день (DAU). В итоге мы узнаем,
сколько в среднем времени в день проводит пользователь в приложении.
Эта метрика похожа на среднюю продолжительность сессии, или Average

Session Length. Отличаются они знаменателем: у Average Session Length – это
количество сессий, а у Total Daily Play Time – количество пользователей.
Сравним эти две метрики на примере. Допустим, у нас есть информация о

пяти пользователях и продолжительности их сессий (в минутах).

Рассчитаем обе метрики по этим данным:
| Продолжительность сессий пользователей
● суммарная продолжительность всех сессий – 1:38:50

● количество сессий – 15
● количество пользователей – 5
● средняя продолжительность сессии (Average Session Length) – 06:35
● среднее время в игре (Total Daily Play Time) – 19:46

Несмотря на то, что итоговые показатели этих двух метрик довольно сильно
отличаются, сами значения зависят от одинаковых факторов (вроде жанра
игры), которые влияют на характер их использования.
Например, в приложении для чтения книг время, проводимое в нем, и средняя

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

него различные действия, совершаемые пользователем, чтобы узнать:
● сколько времени игроку требуется, чтобы пройти N уровней;

● сколько времени он потратил на прохождение того или иного уровня;

● через сколько минут/часов, проведенных в продукте, пользователь
совершил покупку;
● сколько часов или минут проходит между первой и второй покупками;
● сколько часов провел пользователь в приложении перед тем как уйти;
● сколько часов ему понадобилось, чтобы решить головоломку;
● и любые другие вопросы, которые позволят лучше понять поведение
пользователя в игре.
Вот так может выглядеть день пользователя в продукте:
| Действия пользователя в продукте в течение одних суток
Если бы мы считали метрики традиционным способом, то это были бы:

● 3 сессии;
● 1 покупка;
● 3 level up;
и все это в один день.
Подсчет только игрового времени позволяет более точно описать поведение

пользователя:
● 10,5 часов в день в игре;

● прохождение 1-го уровня через 4,5 часа в игре;
● прохождение 2-го уровня через 8 часов в игре;
● прохождение 3-го уровня через 9 часов в игре;
● покупка спустя 7 часов в игре.

КАК МОЖНО ИСПОЛЬЗОВАТЬ
ПОКАЗАТЕЛЬ TOTAL DAILY PLAY TIME
Зная, сколько времени пользователь проводит в продукте ежедневно, и что
он успевает за это время сделать, можно иначе планировать маркетинговые
активности – привязывать их не ко дню, а ко времени, проведенному в игре.
А проследив за пользователем в течение продолжительного периода, до

момента, когда он перестанет появляться в приложении, можно будет сказать,
что он «прожил» в продукте, например, не 50 дней, а 180 часов.
Как и другие поведенческие метрики, связанные с сессиями, Total Daily Play

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

8 ЛИПКОСТЬ
(STICKY FACTOR)
Каждый день в приложение заходят новые пользователи. Кто-то из них
больше никогда не воспользуется продуктом, а кто-то будет заходить каждый
день. И во многом от того, как они себя ведут в продукте, насколько им он им
интересен, зависит его доход, ведь чем лояльнее пользователи, тем они более
склонны к совершению платежей.
Заинтересованность, лояльность и степень вовлеченности пользователей

характеризуют несколько метрик, одна из которых – Sticky Factor (также
Stickiness Factor, или «липкость») – показатель, который позволяет оценить
регулярность посещений приложения и стабильность пользовательской базы.
Обычно он рассчитывается
как отношение количества
уникальных пользователей
в день к числу уникальных
пользователей в месяц.
Но бывает, что используют соотношение DAU к WAU.
| График Sticky Factor. Скриншот из демо devtodev

КАК РАБОТАЕТ STICKY FACTOR
Предположим, каждый день в приложение заходит 1000 уникальных
пользователей, то есть DAU проекта равен 1000. Если каждый день это
разные пользователи, то MAU в этом случае составит 30000 и Sticky factor
будет равен 1000/30000 = 3%. Это минимальное значение, которое может
принимать данная метрика, и говорит оно о том, что пользователи не
задерживаются в приложении. Вероятно, его удержание очень низкое и в нем
отсутствует пользовательская база, которая необходима для того, чтобы
генерировать доход.
Обратная ситуация – когда пользователи ежедневно используют продукт, и

при DAU 1000, MAU такого проекта тоже будет 1000, а Sticky factor – 100%.
Конечно, в реальности такой утопии не бывает, и этот показатель обычно
сильно зависит от жанра и назначения продукта. Например, для игр считается
хорошим Sticky factor около 20%, а для социальных сетей и меcсенджеров он
обычно около 50%.
Также Sticky factor показывает, с какой вероятностью новый привлеченный

пользователь останется в продукте, насколько хорошо продукт удерживает и
«цепляет» пользователей.
Этот показатель имеет смысл отслеживать в разные промежутки

времени для одного продукта, чтобы оценить, как сказались на
метрике определенные изменения, сравнивать для различных сегментов
пользователей, сравнивать его значение во время A/B-тестов, чтобы лучше
понимать, какие элементы влияют на заинтересованность пользователей.

КАК УВЕЛИЧИТЬ STICKY FACTOR
Для повышения Sticky Factor можно использовать такие же приемы, как
при работе с удержанием, потому что задача заключается в том, чтобы
заинтересовать пользователя продуктом и заставить человека пользоваться
им снова и снова.
Этому может содействовать:

● привлечение той целевой аудитории, которая изначально будет
ориентирована на предлагаемый продукт и его функционал;
● создание очень ценного и актуального контента, который заставит
пользователя возвращаться в проект снова и снова;
● удобный для пользователей интерфейс приложения и насыщенность
его полезными инструментами и фичами;
● социальный момент, когда в приложении есть чем поделиться, с кем
поделиться и обсудить;
● напоминания о продукте и интересных изменениях в нем (в виде email
или пуш-уведомлений).
Sticky Factor напрямую не связан с доходом, однако он характеризует

лояльность и активность аудитории, что, в свою очередь, влияет
на монетизацию и доход, так как чем стабильнее и заинтересованнее
пользовательская база, тем быстрее формируется и растет аудитория
продукта, а чем она больше, тем больше платежей совершают пользователи.
Плюс, как показывает опыт devtodev, существует корреляция между Sticky

Factor и доходом (она составляет около 50-60%).
Мы всегда помним (и вам советуем не забывать), что корреляция не означает

причинно-следственную связь, здесь же мы хотим просто сказать, что и
Sticky Factor, и монетизационные метрики являются сторонами одной
медали — пользовательской лояльности.

9 ВОРОНКИ
(FUNNELS)
Когда на сайт или в приложение приходит новый пользователь, хочется, чтобы
он совершил целевое действие – платеж, регистрацию, оформление заказа
или любой другой, ценный для разработчика шаг.
Но, во-первых, далеко не все из тех, кто попадает в продукт, совершают

это действие. Во-вторых, пользователи перед его совершением проходят
несколько промежуточных шагов, взаимодействуя с интерфейсом, нажимая
на различные кнопки, переключая разделы меню, переходя по ссылкам и
страницам, заполняя различные формы.
Для того, чтобы исследовать поведение пользователей в продукте, понять,

как они его видят, найти «слабые» места, выяснить, на каких шагах по пути
к цели они «отваливаются», и оптимизировать процессы внутри приложения
используется такой инструмент, как воронка конверсий (Conversion Funnel).
Воронка состоит из последовательности действий юзеров и показывает,

сколько уникальных пользователей совершили каждое из них: сколько человек
сделали первый шаг, сколько затем перешли на второй и так далее.

Таким образом воронка показывает конверсию между шагами (отношение
пользователей на шаге N к пользователям на шаге N-1), позволяет выявить
узкие места, где эта конверсия падает сильнее, чем на других шагах,
то есть в каком месте происходит самый большой отток пользователей.
Стоит еще раз отметить, что у воронки есть своя особенность. Несмотря
на то, что в основе ее лежат действия, совершаемые в продукте, строится
она по количеству уникальных пользователей, совершивших эти действия.

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

Вот пример одной из возможных последовательностей действий в воронке:
пользователь сперва открыл страницу приложения в магазине мобильных
приложений → скачал приложение → совершил первый платеж → совершил
второй платеж.
| Воронка пользовательских действий
Получив результат воронки, можно выявить слабые места с наименьшей

конверсией. В данном примере это совершение первого платежа после
загрузки приложения. Конверсия на этом шаге наиболее низкая – всего 4%.
Затем, выявив это место и поэкспериментировав, можно снова построить

воронку и посмотреть, как повлияли изменения на конверсию.

При анализе результатов воронки не лишним будет дополнительно посчитать
общую конверсию из первого шага в последний, поскольку в результате
экспериментов конверсия на одном шаге может вырасти, но при этом упасть
на последующих.
Это может, например, случиться из-за привлечения нецелевого трафика.
| Сравнение конверсий 2-х воронок
Поэтому при оптимизации шагов воронки стоит отслеживать конверсии всех

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

и сравнивать, например, как пользователи из разных стран или из разных
каналов проходят один и тот же путь.
КАК ИСПОЛЬЗОВАТЬ ВОРОНКИ

Исследовать с помощью воронки можно совершенно разные процессы в
продукте: от совершения покупки до прохождения туториала. И то, и то –
последовательности шагов, которые проходят далеко не все пользователи.

| Воронка из установки приложения в совершение платежа.
Также с помощью воронок можно оценивать эффективность email-рассылок,

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

путь пользователей к цели, повысить их заинтересованность в продукте,
предотвратить отток и тем самым повысить финансовые показатели проекта.

10 КОНВЕРСИЯ В ПЛАТЁЖ
(PAYING CONVERSION)
Довольно часто, обсуждая тот или иной проект, мы используем термин
«конверсия» (Conversion). При анализе продукта этому показателю
уделяется очень много внимания и разработчики стараются максимально
увеличить эту метрику.
Конверсия – это процент пользователей, совершивших какое-либо целевое

действие. Таким действием может быть нажатие кнопки «Регистрация»
на посадочной странице, переход по рекламной ссылке, или, например,
совершение платежа.
Как раз последний случай мы рассмотрим подробнее, так как именно он

является наиболее важным для проекта. И чаще всего, говоря «конверсия»,
имеют в виду именно «конверсию в платеж» (Paying Conversion).
Перед тем как вывести формулу для конверсии, отметим важную особенность
ее расчета. Она заключается в том, что этот показатель рассчитывается для
когорты, то есть для группы пользователей, установивших приложение в
определенный период.
Итак, конверсия в платеж – это процент пользователей, совершивших покупку,

из тех, кто установил приложение.

Конверсия оказывает прямое влияние на доход, который рассчитывается
по формуле:
Так что увеличивая этот показатель, вы увеличиваете количество

пользователей, которые совершают платежи, что приводит к росту дохода.
| Расчет дохода при разных значениях конверсии
Однако если увеличение конверсии происходит за счет снижения среднего

чека пользователя (или цены на продукт), то результат может получиться
отрицательный.
| Расчет дохода при разных значениях конверсии и ARPPU
Поэтому, экспериментируя с конверсией, стоит контролировать и другие

финансовые показатели.

Это довольно важный момент, на который стоит обращать внимание, особенно
при проведении акций в продукте, когда снижаются цены на товары. Далеко
не всегда снижение цен приводит к снижению дохода, но контролировать это
все же необходимо.
Помимо акций и скидок на конверсию могут влиять:

● дизайн продукта и отдельных его элементов;
● тексты заголовков и маркетинговых предложений;
● простота и понятность интерфейса;
● вовремя предлагаемые покупки;
● грамотные CTA-элементы;
● наличие положительных отзывов о продукте и многое другое.
Все это довольно индивидуально для каждого проекта, и то, что кратно
увеличивает конверсию в одном продукте, может не повлиять на конверсию
в другом, поэтому стоит экспериментировать, чтобы найти то, что сработает
именно у вас.
Анализ конверсии можно сделать еще глубже, если использовать некоторые

дополнительные подходы.
КАК АНАЛИЗИРОВАТЬ КОНВЕРСИЮ
Разделение платежей
Конверсию стоит считать не для всех платежей, а отдельно для первого и

повторных, что даст больше понимания о поведении пользователей в продукте.
В этом случае, конверсия в повторный платеж – это процент пользователей,
совершивших более одного платежа за анализируемый период. Причем
повторные платежи можно делить на 2-й, 3-й, N-й и рассчитывать конверсию
для каждого отдельно.

Важно следить за тем, чтобы пользователи, совершив первый платеж, не
останавливались на этом, а продолжали совершать и последующие покупки,
так как зачастую именно повторные платежи приносят больше всего дохода.
Не лишним будет узнать, в какой момент пользователи начинают платить –

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

влиять на них и планировать различные маркетинговые активности, повышая
вероятность совершения платежа.
| Распределение пользователей по времени с момента установки до соверше-

ния первого платежа. Скриншот из демо devtodev
Кроме того, если в приложении есть какие-то этапы, то стоит рассматривать

момент совершения первого (или любого другого) платежа в разрезе этих
стадий. Такая разбивка может быть актуальна для игровых приложений,
где есть уровни, а также образовательных продуктов или приложений для
фитнеса, где прогресс пользователя можно разделить на отдельные шаги.

| Распределение пользователей по уровням, на которых они совершают
первый платеж. Скриншот из демо devtodev
Сравнение когорт
Конверсия может рассчитывается для когорт, и эту особенность стоит

использовать, чтобы отслеживать ее изменения во времени для определенной
группы пользователей, а также сравнивать различные когорты между собой.
| Конверсия в покупку по дням с момента установки для разных когорт

Опять же, такой анализ оказывает огромную помощь при проведении
экспериментов – можно оценить, как повлияли изменения на конверсию
когорт, сформированных до и после этих изменений.
Есть еще одна метрика, похожая на конверсию, но, тем не менее, имеющая
другой смысл – это доля платящих (Paying Share).
Как видно, этот показатель отличается от конверсии знаменателем, который

рассчитывается от всей активной аудитории и не имеет привязки к дате
установки, а также не требует когортного анализа.
Подробнее эта метрика будет рассмотрена в следующем разделе.

11 ПЛАТЯЩИЕ
ПОЛЬЗОВАТЕЛИ (PAYING USERS)
И ИХ ДОЛЯ ОТ ВСЕЙ
АУДИТОРИИ (PAYING SHARE)
Самая любимая метрика всех разработчиков – это доход. Все они любят
наблюдать как его график растет вверх, и принимают срочные меры в случае
его падения.
Откуда берется доход? И почему его график так себя ведет — скачет то вверх,
то вниз? Все это происходит благодаря пользователям, причем не всем, а
тем, которые платят. Такая группа пользователей описывается метрикой
Paying Users.
Paying Users – это количественная метрика, которая равна числу платящих

пользователей за определенный период.
Чем больше таких пользователей в продукте, тем лучше. И, как правило,

пользовательские метрики платящих выше, чем показатели тех, кто не
платит. Например, удержание (Retention) платящих юзеров часто значительно
превосходит удержание неплатящих (иногда в несколько раз), и в проекте они
остаются намного дольше. Это логично: заплатив, пользователи проявляют
свою лояльность к продукту, мотивация вернуться у них сильнее – нужно
использовать то, за что было заплачено.
Отдельно, из общего количества платящих стоит выделять пользователей,

которые совершили свой первый платеж (New Paying Users), так как после
первого платежа обычно происходят повторные, которые зачастую приносят
большую часть дохода.

Поэтому, как мы говорили раньше, нужно внимательно следить, чтобы первые
платежи конвертировались в последующие.
Как увеличить количество платящих пользователей:

● добавить новый интересный для пользователей контент;
● поэкспериментировать с ценами на существующие товары;
● предложить пользователям скидку на какой-либо из товаров.
Но остался еще один открытый вопрос: как оценить динамику изменения

платящей аудитории?
Paying Users – это абсолютная величина, ее рост или падение зависит от разных
факторов. Далеко не всегда рост количества платящих пользователей
приводит к увеличению дохода (например, их число стало расти, но
уменьшилась сумма платежей).
Как понять, что их рост – это не результат наших действий, а следствие общего
роста аудитории?
Для дохода, как и других важных количественных показателей, существует

относительная метрика, которая показывает какой процент пользователей из
всей активной аудитории совершает платежи в продукте.
Для платящих пользователей это – доля от всей аудитории (Paying Share,

или Paying Users Rate).
Рассчитывается она по формуле:

Эта величина зависит от типа приложения, но зачастую она довольно
небольшая – около 1-2%. Считается, что медиана показателя Paying Users в
мобильных f2p-играх составляет 1% - то есть подавляющая часть аудитории
обычно предпочитает не платить. При анализе этих двух метрик стоит
обращать внимание на смежные показатели, например, на ARPPU, потому что
количество платящих может расти, а доход падать (если упадет средний чек
платящего).
| Расчет дохода при разных ARPPU и количестве платящих пользователей
Или упадет доля платящих, но за счет роста среднего чека на доходе это
скажется положительно.
| Расчет дохода при разных ARPPU и доле платящих пользователей

Сравнивать динамику изменения числа платящих пользователей и доли
платящих лучше относительно других показателей.
Например, если растет размер активной аудитории или количество новых

пользователей, а доля платящих неуклонно падает, то это может говорить о
нецелевом трафике.
| Графики платящих и новых пользователей

Платящие пользователи – самые ценные в проекте, но и они ведут себя по-
разному, поэтому, чтобы они и дальше способствовали росту дохода продукта
и оставались лояльны к нему, стоит внимательно их изучить и сделать их
пребывание в продукте и его использование максимально комфортным
и полезным. Для этого есть несколько подходов, которые мы рассмотрим в
следующем разделе.
КАК СЕГМЕНТИРОВАТЬ
ПЛАТЯЩИХ ИГРОКОВ
Как мы уже выяснили, аудитория любого проекта довольно разнообразна,
и если в продукте предусмотрены какие-либо платежи, очевидно, что в нем
будут присутствовать два типа пользователей: платящие и те, кто не совершил
ни одного платежа.

Зачастую поведение этих групп в продукте отличается не только по наличию
или отсутствию платежей, но и по другим поведенческим метрикам.

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

зависимости от суммы, которую они заплатили:
● whales (киты);
● dolphins (дельфины);
● minnows (пескари).
Мы в devtodev добавили ещё две категории – Grand Whales (гран-киты) и Grand

Dolphins (гран-дельфины) для лучшей детализации.
Киты – это пользователи, которые платят крупные суммы.

Чаще всего они составляют небольшой процент платящей аудитории, но
приносят большую долю дохода.
Дельфины совершают средние

по размеру платежи, а пескари
платят очень небольшие суммы
и их доля в общем доходе зачастую
настолько незначительная, что их
отсутствие не особо сказалось бы
на выручке проекта, но зато таких
пользователей больше всего среди
платящих.
| Сегментация пользователей
по размеру платежей

Есть несколько вариантов деления пользователей на эти типы. Первый
способ, который как раз используется в devtodev, – выделение квантилей,
то есть разделение значений выборки на несколько определенных частей.
Для этого пользователи сортируются по убыванию дохода, а затем выделяется

топовый 1% – это Grand Whales, затем 2-10% – Whales, от 11% до 25% – Grand
Dolphins и так далее.
| Доход и количество транзакций пользователей разных сегментов.


Вот пример того, как можно сделать такую сегментацию:
| Сегментация платящих пользователей методом выделения квантилей
Другой вариант – установить границы экспертным путем: решить, что те, кто
платят $1000 и больше – это киты, $100 – $999 это дельфины и так далее. Это
более простой вариант, который можно применить, если вы хорошо знаете
свое приложение и пользователей.
Как было сказано ранее, пользователи разных сегментов часто ведут себя
по-разному в приложении. Например, Retention китов обычно выше, чем
у других сегментов, но зато у них проходит больше времени с момента
установки до совершения платежа.

Тем не менее это именно тот сегмент, который обычно приносит большую
часть дохода. Поэтому важно иметь в продукте китов и стараться
поддерживать их активность, чтобы они его не покинули. Чтобы в проекте
были киты, можно создать, например, эксклюзивный контент, который был бы
им полезен и интересен, а заодно позволял потратить хорошую сумму денег.
Сегментация по количеству платежей

Вторая разновидность сегментации платящей аудитории – по количеству
совершенных платежей.
Здесь важнее деление на тех, кто совершил один платеж и тех, кто делал
повторные платежи, потому что вторые и приносят стабильный доход.
Вот так можно рассмотреть аудиторию с точки зрения совершаемых платежей:
| Распределение пользователей по количеству и сумме платежей.

Правда, желательно, чтобы пользователи концентрировались в правом

нижнем углу, поскольку это будет означать большое количество платежей на
крупные суммы.

Сегментация по времени совершения
платежа
Поведение пользователей также отличается временем, когда они совершают
свой первый платеж. Зная, как поступает большинство, можно планировать
акции на аудиторию, которая повела себя иначе.
| Распределение пользователей по времени с момента установки до

совершения первого платежа. Скриншот из демо devtodev
Например, если большая часть пользователей начинает платить в первый день

после установки приложения, то тех, кто этого не сделал, можно пытаться
дополнительно мотивировать на совершение платежа уже со второго их дня
в продукте.
Подчеркнем, что сегментация по времени совершения платежа рассматривает

новых пользователей (и в основном первые платежи) и говорит о скорости
их конвертации.
Отчет по этому параметру может свидетельствовать о том, что, к примеру,

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

Сегментация по времени с момента
установки
Данная сегментация описывает структуру дохода, отвечает на вопрос, какие
пользователи приносят большую его часть.
Отчет по этому параметру, к примеру, может дать информацию, что новички

составляют 2% в доходе, а основная его часть складывается из тех, кто
установил приложение 6 месяцев назад.
| Структура платящей аудитории по времени с момента установки
То есть, такой отчет позволяет понять, какие пользователи приносят

наибольший доход в проекте, а также за счет какого сегмента происходит
рост или падение дохода.
Это может быть полезным при планировании различных изменений и

экспериментов на определенный сегмент аудитории, а также при оценке
нового релиза: как именно он повлиял на тот или иной сегмент пользователей.

Например, может случиться так, что после релиза новые пользователи,
которые не видели приложение раньше, так и продолжат платить, а те, кто
уже давно в продукте, останутся недовольны изменениями и это негативно
скажется на доходе от этого сегмента.
Несмотря на то, что наиболее ценны для продукта пользователи, которые

платят и платят много, в нем важно иметь все сегменты пользователей,
поскольку вместе они создают общую экосистему, без которой невозможно
существование проекта как продукта.

12 RFM-АНАЛИЗ
Существует еще один инструмент сегментации платящих пользователей –
RFM-анализ. Он делит пользователей на определенные группы в зависимости
от давности (Recency), частоты (Frequency) и общей суммы (Monetary) их
платежей.
Обычно задача такого анализа – изучить поведение пользователей, то, как они
совершают платежи, чтобы сделать более релевантные предложения каждой
из выделенных групп, сформированных по трем критериям.
● Recency – разница между текущей датой и датой последнего платежа,

совершенного пользователем.
● Frequency – количество транзакций, которые сделал пользователь за
исследуемый промежуток времени.
● Monetary – сумма покупок пользователя за этот же исследуемый период.
Все эти три показателя рассчитываются отдельно для каждого пользователя

за выбранный период, после чего им должна быть дана оценка по каждому из
трех критериев.
Диапазон оценок может быть разный: 1-3, 1-4, 1-5 и так далее. Чем шире
диапазон, тем больше групп получится, и тем «чувствительнее» и точнее
будут показатели, но в то же время тем тяжелее будет с ними работать из-за
большого разнообразия комбинаций.

КАК ВЫСТАВЛЯТЬ БАЛЛЫ
В RFM-АНАЛИЗЕ
Для выставления баллов пользователям обычно применяется два метода:
Фиксированные диапазоны
В этом случае необходимо самостоятельно определить границы для каждого

из критериев, используя свой опыт работы с продуктом: определить, что
значит платеж, совершенный давно, недавно, на крупную сумму, на среднюю,
и так далее. Затем нужно присвоить пользователям соответствующие оценки.
Например, можно задать следующие рамки для параметров RFM:

Recency
A. Те пользователи, которые платили последний раз давно
(более 14-дней назад) получат 1 балл.
B. Те, которые платили 8-14 дней назад – 2 балла.
C. Те, которые платили последний раз недавно
(1-7 дней назад) получат 3 балла.
Frequency
A. Совершившие только 1 платеж за выбранный период получат 1 балл.
B. Пользователи, платившие со средней регулярностью и совершившие
2-3 платежа, – 2 балла.
C. Платившие часто и сделавшие более 3 платежей, – 3 балла.
Monetary
A. Те пользователи, которые заплатили $1-$10, получают 1 балл, так как
это минимальная сумма платежа в проекте.
B. Те, которые заплатили $11-$20, получат 2 балла.
C. Те, которые оставили в продукте более $20, получат 3 балла.

Фиксированные диапазоны
Второй метод определения границ – использование квантилей. Для этого
нужно упорядочить данные по одному из критериев, например, по количеству
платежей, а затем разделить пользователей либо на равные группы (например,
выделить 4 группы по 25% пользователей в каждой), либо выделить первые
10% пользователей и присвоить им максимальный балл как платящим много,
следующим 50% – 2 балла, и тем, кто платил совсем мало (40%) – 1 балл.
В этом случае границы определяются экспертно.
Попробуем использовать эти методы на примере и предположим, что у нас

есть следующие данные о пользователях:
| Данные о давности, количестве и сумме платежей пользователей

Вначале попробуем метод фиксированных диапазонов и в качестве границ
каждого измерения используем те, что были описаны выше. После чего,
исходя из этих значений, проставим оценку каждому пользователю.
| Выставление баллов пользователям методом фиксированных диапазонов
Теперь проставим баллы пользователям, используя квантили. Для этого нужно

упорядочить их по возрастанию одного из трех показателей и разделить
на равные части (пусть этих частей будет 3).

| Выставление баллов пользователям по критерию давности платежа
с помощью квантилей
Так нужно сделать по каждому показателю. В итоге мы получаем таблицу

с баллами.

| Выставление баллов пользователям с помощью квантилей
Когда оценки проставлены, этих пользователей можно сгруппировать в

определенные сегменты. В нашем примере используем первый вариант
выставления баллов, когда границы задавались экспертным путем.

| Деление пользователей на группы в зависимости от полученных баллов
И помимо количества пользователей в каждом сегменте, посчитаем доход

от них.
| Доход в выделенных группах пользователей

Из этой таблицы видно, что большее количество пользователей – те, кто
платили со средней регулярностью, мало и давно.
Такие пользователи, скорее всего, потеряны для проекта, но все же можно

попытаться их вернуть, связавшись каким-либо образом и предложив что-то,
что может быть им полезно и интересно в этот момент, сохранив тем самым
их в проекте.
КАК ИСПОЛЬЗОВАТЬ
РЕЗУЛЬТАТЫ АНАЛИЗА
Цель RFM-анализа и формирования сегментов заключается в том, чтобы,
в зависимости от платежного поведения пользователей, определенным
образом на них воздействовать: отправлять пуш- или email-уведомления,
предлагать бонусы, офферы и скидки, разблокировать контент и так далее.
Причем важно делать все это таргетированно с посылом, который будет
релевантен каждой отдельной группе.
В результате этих действий можно улучшить удержание, возвращая в проект

тех платящих пользователей, которые перестали быть активны, можно
повысить доход, конвертируя пользователей, совершивших один платеж,
предотвращая тем самым отток лояльных пользователей.

Вот несколько примеров сегментов, которые можно выделить в результате
RFM-анализа:
● Те, кто платил часто, много и недавно (R=3, F=3, M=3), – это самые
лояльные и активные пользователи, которых вам нужно беречь и
поддерживать их интерес к проекту;
● Их полная противоположность (R=1, F=1, M=1). Скорее всего, это уже
потерянные пользователи: они платили давно, мало и редко;

● Те, кто платил много и часто, но давно (R=1, F=2/3, M=2/3) – лояльные
пользователи на грани ухода. Как и предыдущую категорию, можно
попробовать вернуть их в проект, прислав пуш-уведомление или
предложив бонус или скидку;
● Тех, кто совершил недавно один платеж (R=3, F=1, M=X), стоит
мотивировать на совершение повторных платежей.
В анализе присутствуют 3 показателя, но стандартные графики или таблицы

обычно имеют 2 измерения, и чаще всего 2 из показателей совмещают.
Обычно это Frequency и Monetary или Frequency и Recency.
| Отчет RFM-анализ. Скриншот из демо devtodev
Здесь стоит отметить, что показатель monetary не всегда используется для

сегментации платящих пользователей. Одной из разновидностей такой
сегментации является RF-анализ, учитывающий только давность и частоту
платежей, уменьшая количество групп и упрощая восприятие результатов.

RFM-анализ – полезный инструмент сегментирования пользователей,
позволяющий проанализировать платящую аудиторию проекта, выявить
превалирующие сегменты, определить таким образом слабые места
в приложении, а также повысить показатели удержания, конверсию и
доход, взаимодействуя с каждым пользовательским сегментом наиболее
подходящим для него способом.

13 ПОТРЕБИТЕЛЬСКАЯ
КОРЗИНА (CONSUMER BASKET)
И СТРУКТУРА ПОКУПОК
В процессе использования приложения юзеры покупают разные товары,
чтобы, например, облегчить дальнейшее прохождение игры, получить доступ
к основному контенту или получить какой-то уникальный контент. Их выбор
в плане продуктов тоже может быть проанализирован. Настало время
поговорить о потребительской корзине (Consumer Basket) и покупках,
которые пользователи совершают во время игры, а также о возможных
вариантах их анализа.
Стоит отметить, что понятие «потребительская корзина» используется в

разных сферах (наиболее часто – в экономике). Оно означает набор товаров
и услуг, приобретаемых в среднем одним пользователем за определенный
промежуток времени.
Цели и методы анализа также отличаются в зависимости от сферы, и мы

рассмотрим как может выглядеть анализ для игровых проектов.
Допустим, в игру попали 1000 пользователей и в первый месяц они купили

следующие товары:
| Количество и стоимость покупок пользователей

Пересчитав эти покупки на одного пользователя, получается, что стоимость
его потребительской корзины в первый месяц – $20,25, а ее состав:
● кристаллы – 7,4 штуки;
● персонаж – 0,35 штуки;
● скин – 0,02 штуки.
КАК АНАЛИЗИРОВАТЬ ПОКУПКИ

ПОЛЬЗОВАТЕЛЕЙ
Состав и стоимость потребительской корзины можно корректировать
различными способами, поэтому недостаточно просто посчитать эти
показатели, важно отслеживать их изменение с течением времени.
Например, на состав и стоимость могут влиять акции и скидки на какие-либо
товары, или, наоборот, эксперименты по повышению цены, дополнительные
встречи с покупкой, изменение порядка товаров в магазине, визуальные
акценты на конкретных товарах, изменение сложности уровней или локаций
и так далее.
Также анализировать покупки пользователей стоит в разрезе уровней

и локаций. Для начала можно просто сравнить все купленные предметы по
популярности и посмотреть, в какой момент игры пользователи покупают те
или иные товары.
| Топ покупок по уровням. Скриншот из демо devtodev

После чего эти покупки можно сопоставить с количеством пользователей,
находящихся на этих же уровнях/локациях, и вычислить, сколько в среднем и
каких товаров покупает пользователь в данной точке игры.
Зная, какие товары у пользователя есть на определенном уровне, можно

понять, что и в какой момент наиболее востребовано, каких товаров/валюты
у пользователя в избытке, чего не хватает, и исходя из этого решать, какую
акцию и в какой момент запустить, на какой товар сделать скидку.
Например, если у пользователей к определенному уровню становится очень

мало игровой валюты, что чревато отвалом, есть смысл сделать акцию для
тех, кто дошел до этой части игры, чтобы удержать их и повысить интерес к
дальнейшему ее прохождению.
Еще один вариант анализа структуры покупок – это ABC/XYZ анализ. Его
задача заключается в том, чтобы выявить те товары, которые приносят
проекту больше всего прибыли, и затем увеличить их долю среди
покупаемых продуктов.
ABC/XYZ анализ состоит из 2-х частей.
● ABC-анализ распределяет товары на группы в зависимости от их

вклада в общий доход среди всех купленных товаров:
A. товары группы A приносят 80% дохода и составляют 20% в общем

объеме проданного товара;
B. товары группы B составляют 15% в доходе и 30% в общем объеме
проданного товара;
C. товары группы C составляют 5% в доходе и 50% в общем объеме
проданного товара.

| Деление товаров по доле в общем доходе (ABC-анализ)
● XYZ-анализ характеризует стабильность спроса по коэффициенту

вариации и точность прогнозирования:
A. группа X – товары с наиболее стабильным спросом, имеющие
коэффициент вариации меньше 10% и высокую степень
надежности прогноза;
B. группа Y – товары со средне-стабильным спросом, имеющие
коэффициент вариации от 10% до 25% и среднюю степень
надежности прогноза;
C. группа Z – товары, спрос на которые нестабилен, коэффициент
вариации составляет более 25% и точный прогноз сделать
невозможно.
| Деление товаров по стабильности спроса (XYZ-анализ)

После разделения всех товаров на ABC- и XYZ-группы, они объединяются в
одну таблицу следующим образом:
| Группы ABC/XYZ анализа
Товары, попавшие в AX, AY, BX – самые выгодные товары, так как имеют
стабильный спрос и приносят большую долю в доходе. А вот от тех, которые
попали в CZ, возможно стоит отказаться, потому что они обладают самыми
худшими характеристиками.
С товарами в группе CX и AZ стоит поработать, так как один из критериев

у них довольно хороший, и, исправив другой, можно относительно просто
перевести их в более выгодную категорию.
КАК ИСПОЛЬЗОВАТЬ АНАЛИЗ

ПОТРЕБИТЕЛЬСКОЙ КОРЗИНЫ
Часто задачей анализа покупок пользователей является выявление
комбинаций купленных товаров, особенно если речь идет не про игру, а
какой-либо онлайн или оффлайн магазин. В этом случае дополнительно стоит
проанализировать набор товаров, купленный юзером в рамках одной покупки.

После этого можно задаться вопросами, почему именно такой набор товаров
был приобретен, какая закономерность есть между этими наборами товаров,
с какой вероятностью пользователь, купивший товар A, купит товар B.
Зная наиболее популярные комбинации, можно менять расположение товаров

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

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

акции на смежные товары, пуш-уведомления, email-рассылки, чтобы тем
самым увеличить средний чек пользователя.

14 СРЕДНИЙ ДОХОД С
ПОЛЬЗОВАТЕЛЯ (ARPU)
Одним из наиболее важных и популярных монетизационных показателей
является ARPU. Именно его всегда используют для сравнения эффективности
проектов и именно этой метрикой обычно интересуются партнеры и инвесторы.
ARPU (Average Revenue Per User) – доход, который в среднем приносит один
пользователь приложения за какой-либо период времени.
Для расчета ARPU нужно доход за выбранный период разделить на

активную аудиторию:
Например, при аудитории 5000 пользователей, доход приложения составляет

$3000. Это значит, что в среднем один пользователь приносит $0,6 в проект.
ARPU = $3000/5000 = $0,6
Также часто можно встретить такую метрику как ARPDAU, или Average Revenue
Per Daily Active User. Это тот же самый ARPU, только рассчитанный за один
день, т.е. доход одного дня делится на количество активных пользователей в
этот день (DAU). Аналогично можно посчитать и ARPMAU (Average Revenue Per
Monthly Active User) – разделив месячный доход на MAU продукта.

ARPU является одним из ключевых показателей монетизационной
эффективности проекта и напрямую влияет на доход.
Соответственно, чем выше ARPU, тем больше будет доход приложения.

Отсюда также следует, что ARPU – это очень удобная метрика для оценки
изменений, сделанных в проекте, и различных экспериментов, так как она
учитывает и платящих, и неплатящих пользователей, и содержит в себе сразу
два дополнительных параметра, что значительно упрощает анализ.
ARPU в формуле выше — Average Revenue Per Paying User — средний доход от
одного платящего пользователя. Подробнее эта метрика будет рассмотрена
в следующем разделе. А пока на примере посмотрим, как рассчитываются
эти показатели.
Допустим, за выбранный период в приложение пришли 1000 пользователей,

100 из них совершили платеж на общую сумму $500.
Получается, что средний пользователь приносит $0,5.

ARPU = $500/1000 = $0,5
Из всей аудитории 100 пользователей что-то купили:
Paying share = 1000/100 = 10%
А средний чек платящих – $5
ARPPU = $500/100 = $5
Объединив Paying share и ARPPU, получаем:
ARPU = 10% * $5 = $0,5

КАК ИСПОЛЬЗОВАТЬ ARPU
Для анализа ценовых экспериментов
ARPU позволяет нам увидеть, насколько эффективно, например, мы повысили

цены на товары.
Допустим, продукт стоил $15 и при аудитории в 1500 человек, приносил

$1500, но мы решили поэкспериментировать и повысили цену до $17, что
привело к уменьшению аудитории до 1200 человек и выручки до $1400. На
первый взгляд кажется, что эксперимент не удался, но давайте посчитаем
доход на одного пользователя:
● ARPU до изменения цены: $1500/1500 = $1,00
● ARPU после изменения цены: $1400/1200 = $1,17
Не все так плохо, как показалось на первый взгляд. А если нам удастся
повысить количество пользователей до предыдущего значения, то вырастут
и наши доходы.
$1,17 * 1500 = $1755, против $1500, которые были до повышения цены.
Для анализа трафика
Допустим, теперь мы, вместо повышения цены, решили увеличить трафик,

чтобы увеличить наш доход. В результате, число пользователей выросло до
2000 человек, а выручка составила $1800.
Посчитаем ARPU:
● ARPU при старом уровне установок: $1500/1500 = $1,00
● ARPU после добавления трафика: $1800/2000 = $0,90

В итоге наши результаты показали, что в среднем пользователь теперь
приносит меньше дохода, а это может говорить о том, что трафик оказался не
совсем целевым.
Таким же образом можно сравнивать разные каналы трафика.
Для сравнения сегментов

Допустим, в вашем продукте есть несколько типов игроков, все ведут себя
и платят по-разному, и количество пользователей в каждой группе сильно
отличается. Чтобы понять, какой из этих сегментов наиболее лояльный и
прибыльный, можно сравнить их, используя ARPU.
В таблице, которую вы видите ниже, такой является группа пользователей,

установивших игру достаточно давно, но при этом новые пользователи также
приносят неплохой доход по сравнению с другими сегментами.
| Сравнение метрик различных сегментов пользователей
Сконцентрировавшись на этих группах пользователей и увеличивая в них

количество людей (особенно новичков), вы можете значительно повысить
общий доход продукта.

КАК ПОВЫСИТЬ ARPU
В первую очередь стоит обратить внимание на две метрики, которые входят в
состав формулы ARPU – это Paying Share и ARPPU.
Чем больше пользователей вы сможете сконвертировать в платеж, тем больше

будет ARPU и, соответственно, доход.
Чтобы увеличить ARPPU, можно проводить ценовые эксперименты, повышать

ценность продукта для пользователя, а также обращать внимание на
конверсию в повторные платежи. Кстати, исходя из опыта devtodev, можно
сказать, что чем больше платежей совершает пользователь, тем выше его
последующий платеж.
Также важно понимать, что простое увеличение цены, вероятно, хоть и

приведет к желаемому росту ARPPU, но далеко не факт, что вместе с ним
вырастет общий доход, потому что может сильно упасть доля платящих и
прибыль от платящих не компенсирует уменьшение их количества.

15 СРЕДНИЙ
ДОХОД С ПЛАТЯЩЕГО
ПОЛЬЗОВАТЕЛЯ (ARPPU)
Как можно было заметить, при рассмотрении ARPU часто фигурирует еще
один похожий на него показатель — ARPPU (Average Revenue Per Paying User)
— средний доход, который приносит пользователь, совершивший хотя бы
один платеж за определенный период времени. Он характеризует реакцию
платящих пользователей на ценность проекта.
Рассчитывается ARPPU по следующей формуле как отношение дохода к

количеству платящих пользователей:
При расчете ARPPU важно обращать внимание на исследуемый период.

Пользователи в течение месяца могут совершать повторные платежи, но
при этом месячный ARPPU не будет равен сумме дневных, так как делитель
(платящие пользователи за месяц) будет не суммой заплативших клиентов по
дням, а количеством уникальных платящих пользователей за месяц.
В отличие от ARPU эта метрика не учитывает пользователей, которые

ничего не заплатили: в расчет попадают только те, что совершили платеж.
Соответственно, значение ARPPU будет как минимум не меньше, чем ARPU
(хотя равенство между ними практически невозможно, поскольку оно
возникнет только если все активные пользователи приложения совершают
покупки). На практике же, ARPPU всегда значительно выше ARPU.

Как и ARPU, ARPPU оказывает прямое влияние на доход:
Ниже небольшой пример для сравнения этих двух метрик. Предположим, что
в нашем приложении 1000 пользователей.
Из них 100 совершили покупки, стоимость которых $2. Давайте посчитаем

все вышеописанные метрики:
● Paying Users = 100
● Revenue: 100*$2 = $200
● Paying Share = 100/1000 = 0,1 = 10%
● ARPU = $200/1000 = $0,2
● ARPPU = $200/100 = $2
Итак, мы получили наши показатели, но, допустим, нас не удовлетворяет

ARPPU, и мы решили работать над его повышением.
Самый простой способ это сделать – увеличить цены. Давайте посмотрим, к

чему это приведет.
Пусть цена нашего продукта стала $10 вместо $2. Однако, согласно закону
спроса, упадет и количество купивших данный товар.

Рассмотрим два варианта: когда товар за данную цену купили 20 человек и 10
человек. Рассчитаем аналогичные показатели:
| Влияние цены на метрики продукта
В первом варианте значительно упала доля платящих пользователей — с 10%

до 2%, однако вырос ARPPU, чего мы и добивались. Причем это никак не
повлияло на доход, чего нельзя сказать про второй вариант, где, кроме
возросшего ARPPU, ухудшились абсолютно все метрики.
Поэтому, работая с ARPPU, не забывайте следить за другими метриками,

поскольку его увеличение может привести к ухудшению иных показателей.
ЗАЧЕМ РАССЧИТЫВАТЬ И
КОНТРОЛИРОВАТЬ ARPPU
Дело в том, что ARPPU очень хорошо характеризует повторные платежи, так
как в случае их совершения, количество платящих не увеличивается, зато
растет доход. Пожалуй, это наиболее грамотный способ повысить метрику
ARPPU без ущерба для других показателей.

Рассмотрим это на примере. Добавим следующее условие к начальным
данным: пусть из 100 платящих, 50 пользователей совершили повторный
платеж, но уже на сумму $3.
Тогда метрики изменятся следующим образом:
● Paying Users = 100

● Revenue: $2*100 + $3*50 = $200 + $150 = $350
● Paying Share = 100/1000 = 0,1 = 10%
● ARPU = $350/1000 = $0,35
● ARPPU = $350/100 = $3,5
Из полученных результатов можно сделать простой вывод: повторные

платежи почти всегда приводят к росту всех основных показателей.
Поэтому стимулируйте ваших пользователей совершать повторный платеж.
В предыдущем разделе мы уже упоминали исследования, проведенные в

devtodev, в ходе которых обнаружилась взаимосвязь между количеством
платежей пользователя и суммой его последующего платежа: чем больше
пользователь платил в прошлом, тем дороже будет его будущая покупка.
Также обратим внимание на метрику, близкую к ARPPU, которая также

используются для оценки платежей платящих пользователей — Average
Check, или Revenue Per Transaction — средний чек, средняя стоимость
транзакции, или среднее арифметическое от всех совершенных платежей.
Отличие этой метрики от ARPPU в том, что она измеряет средний доход не
от одного платящего пользователя, а от одной транзакции, и не учитывает
количество пользователей, которые эти платежи совершили:

Отличие от ARPPU заключается в том, что если один платящий пользователь
совершит повторный платеж, то знаменатель в ARPPU (количество платящих)
не изменится, однако увеличится количество транзакций, и это повлияет на
размер среднего чека.
Давайте, опять же на нашем примере, попробуем найти различие между

ARPPU и средним чеком.
Снова предположим, что из наших 100 платящих пользователей, 50 совершили

повторный платеж на сумму $3. Тогда, как нам уже известно, ARPPU будет
равняться $3,5, в то время, как средний чек будет равен:
Т.е. доход нужно разделить не на количество платящих пользователей, а на

количество платежей, совершенных ими.

16 НАКОПИТЕЛЬНЫЙ
ДОХОД С ПОЛЬЗОВАТЕЛЯ
(CUMULATIVE ARPU)
Рассмотрим еще одну производную метрику от обычного ARPU, которая
будет очень полезна для оценки качества трафика и выбора оптимального
показателя CPI. Это накопительный ARPU (Cumulative ARPU, или CARPU).
Рассчитывается этот показатель точно так же, как и обычный ARPU —

делением дохода на аудиторию, а отличие его заключается в том, что он
рассчитывается не для всей аудитории, а исключительно для определенной
когорты пользователей, причем эта когорта формируется из пользователей,
которые установили приложение в определенный период (например, месяц,
неделя, день).
Еще одна особенность этой метрики в том, что она увеличивается каждый
день для одной когорты (не зря же она называется «накопительной»).
Рассмотрим вычисление этой метрики, опять же, на примере. Предположим,

мы решили исследовать пользователей, которые установили приложение
01.01.2021. Таковых было 1000. За первый день пользования, они совершили
покупки на $800, т.е. ARPU данной когорты за 1-ый день составил:
$800/1000 = $0,8.
На второй день некоторые из этих пользователей совершили покупки на

сумму $500, причем не важно, какое количество пользователей вернулось в
проект и сколько человек заплатили. Размер когорты, на который мы будем
делить доход, всегда 1000 пользователей. ARPU второго дня составит:
$500/1000 = $0,5.

Теперь мы уже можем посчитать накопительный ARPU. Для второго дня он
будет равен сумме ARPU 0 (день установки) и 1 дней т.е. $0,8 + $0,5 = $1,3
Таким образом, посчитаем оставшиеся дни и занесем результаты в таблицу.
| Накопительный ARPU когорты за 14 дней
Имея представление о вычислении CARPU, давайте выведем его формулу:
Накопительный ARPU N-го дня для определенной когорты равен доходу,

который принесла эта когорта за N дней, разделенному на количество
пользователей в этой когорте. Поскольку метрика накопительная, ее значение
всегда растет вверх, а график выглядит следующим образом:
| График накопительного ARPU

Однако ее рост может в какой-то момент остановиться. Это будет вызвано
тем, что пользователи когорты перестанут платить или пользоваться
продуктом вообще. В таком случае, график, достигнув определенного уровня,
перейдет в горизонтальную линию.
Этот уровень CARPU, когда метрика перестает увеличиваться, можно считать

Lifetime value (LTV или CLV) — средним доходом с одного пользователя за
все его время жизни в проекте.
ЗАЧЕМ РАССЧИТЫВАТЬ
CUMULATIVE ARPU
Зная накопительный ARPU проекта, вы будете знать, сколько денег принесет
пользователь на 7 или 30 день в приложении, или через 3 месяца. То есть вы
сможете рассчитывать, когда и какую сумму принесет вам новый пользователь
этой когорты.
Поскольку CARPU вычисляется для когорт, данный показатель позволяет

сравнивать их между собой, что особенно удобно, когда вы сделали какие-то
изменения в вашем приложении. Например, можно сравнить динамику
накопительного ARPU для когорты, которая установила приложение до того
как в нем были сделаны изменения, с теми, кто установил после, чтобы узнать,
как эти изменения повлияли на платежи пользователей.
| Сравнение накопительного ARPU трех когорт

Теперь вы знаете, как можно объективно оценить успешность своего продукта
и лояльность пользователей, а также сравнить различные источники трафика и
оценить эксперименты.
Но есть еще немало других интересных и полезных метрик, которые позволят

посмотреть на проект с разных сторон.

17 LIFETIME VALUE
В данном разделе речь пойдет об одной из важнейших финансовых метрик,
которая позволяет:
● оптимизировать затраты на привлечение пользователей;

● планировать доход на много месяцев вперед;
● оценивать эффективность каналов привлечения трафика;
● выделять наиболее финансово привлекательные сегменты
пользователей и многое другое.
Это Lifetime Value (или Customer Lifetime Value, CLV) – среднее количество
денег от одного пользователя за всю его «жизнь» в проекте.
Пожалуй, ни один другой показатель не сравнится с этой метрикой по

количеству вариантов расчета, различных нюансов и важности в оценке
финансовой эффективности продукта.
Фактически, LTV – это накопительный ARPU, о котором уже шла речь в

предыдущем разделе, достигнувший определенного неизменного значения.
То есть, это некий средний доход, который постепенно приносит в продукт

один пользователь.
График LTV выглядит так же, как график накопительного ARPU и для этого
показателя справедливы аналогичные утверждения – рассчитывается он для
когорт, а его график и значение со временем только растут.

| График Lifetime value
Причем вначале график растет довольно быстро, а затем рост замедляется и

со временем прекращается вовсе.
Такая тенденция связана с оттоком пользователей из приложения – вначале

в когорте находится много людей и они активно совершают покупки, а
затем большая часть пользователей покидает проект и вместе с их уходом
снижается прирост дохода.
LTV прямым образом влияет на доход, что и очевидно, так как чем больше
один пользователь приносит денег в проект, тем выше общий доход.
При работе с LTV имеет смысл анализировать этот показатель в разрезе

различных сегментов, поскольку пользователи ведут себя и платят
по-разному.

Например, можно выделять сегменты по странам, источникам трафика или
сегментировать в зависимости от выполнения определенных действий, таких
как прохождение обучения. Вероятно, и Lifetime Value всех этих сегментов
будет отличаться.
ЗАЧЕМ НУЖЕН LTV

Одним из наиболее частых способов применения этой метрики является
оценка покупаемого трафика. LTV дает понимание того, сколько один
пользователь заплатит за всю свою жизнь в проекте.
Поэтому, закупая трафик, стоит обратить внимание на то, что стоимость

привлечения пользователя (Customer Acquisition Cost, или CAC) должна быть
меньше, чем его LTV, иначе покупка такого трафика принесет только убытки.
Более того, используя Lifetime Value можно узнать, когда именно пользователь
окупит затраты на свое привлечение.
Это произойдет в тот момент, когда LTV станет равен CAC.
| График LTV и CAC

Если же пересечение линий произойдет через, например, два года пребывания
пользователя в проекте, то стоит подумать над целесообразностью покупки
такого трафика.
LTV можно считать верхней границей стоимости закупаемого трафика, но все-

таки довольно рискованно покупать его по цене, равной Lifetime Value. Поэтому
часто можно встретить рекомендацию придерживаться такого соотношения:
Выполнение данного соотношения говорит о жизнеспособности и

успешности продукта.
Еще один вариант использования Lifetime Value – это прогнозирование

выручки, особенно если предварительно рассчитать этот показатель для
разных сегментов.
Тогда, если известна структура аудитории и Lifetime Value каждого из

сегментов, можно рассчитывать выручку, которую каждый из них принесет
спустя определенное время.
Допустим, нам известен LTV пользователей, привлеченных за деньги и

пришедших органически. Тогда мы можем рассматривать, как повлияют
на доход эксперименты с трафиком: что будет, если увеличить количество
органических установок, открыв приложение для новой страны, или как
скажется на общем доходе сокращение платного трафика.

| Расчет дохода по LTV для разных вариантов с трафиком
КАК ВЫЧИСЛИТЬ LIFETIME VALUE

Способов расчета LTV существует очень много и это связано со множеством
факторов, о которых пойдет речь ниже.
В идеале, чтобы посчитать Lifetime Value, нужно взять когорту пользователей,

установивших приложение в определенный период, и проследить, как они
будут платить из месяца в месяц, а затем, когда в когорте не останется
пользователей из-за неизбежного оттока, весь доход, который они принесли,
разделить на количество пользователей в когорте.
Проблема этого метода заключается в том, что на такой расчет может

уйти большое количество времени, так как пользователи могут «жить» в
приложении долгое время (полгода, год и даже больше). Обычно ни у кого нет
столько времени, чтобы посчитать LTV.
Более того, за это время в приложении наверняка произойдут изменения, и

новые пользователи будут вести себя совсем не так, как пользователи той
когорты, за которой мы наблюдаем. Соответственно, и их Lifetime Value имеет
все шансы измениться.

И вся сложность расчета как раз заключается в том, что его нужно сделать
по имеющемуся небольшому количеству данных за короткий период, который
пользователь провел в приложении.
Поэтому все использующиеся на практике методы расчета не совсем точны и

имеют свои положительные и отрицательные стороны.
devtodev использует ML-модели для предcказания LTV с точностью около

90%. Но давайте рассмотрим еще несколько более традиционных методов.
Расчет по стандартной формуле
По ней довольно просто сделать расчет, подставив нужные значения в

формулу, но недостатки такого метода заключаются в том, что, во-первых,
сам Lifetime не имеет однозначного точного метода расчета и, так же как и
Lifetime Value, рассчитывается наперед по небольшому количеству данных.
Во-вторых, ARPU тоже постоянно меняется, а в формуле используется только
одно неизменное значение.
Через накопительный ARPU

Если известны значения накопительного ARPU за некоторый промежуток
времени, например, за 1-й, 7-й, 14-й, 30-й дни, то, используя математическую
аппроксимацию, можно достроить кривую на более продолжительный период,
пределом которой как раз и будет LTV.

| График LTV, построенный по нескольким известным значениям
накопительного ARPU с помощью аппроксимации
Это далеко не все методы расчета Lifetime Value и, возможно, не самые

простые, но это тот показатель, который все же стоит считать, потому что он
объединяет в себе наиболее важные метрики, учитывает как платящих, так и
неплатящих пользователей, и является одним из самых важных финансовых
показателей.
Зная LTV, можно понять, какой тип клиентов представляет наибольшую

ценность, как скоро окупятся затраты на их привлечение, какой доход мы
получим через полгода или год от новых пользователей, как изменится доход,
если увеличить Retention и многое другое.
Таким образом, Lifetime Value стимулирует работать над самыми важными

финансовыми и пользовательскими метриками и планировать бизнес на
более продолжительное время.

КАК УВЕЛИЧИТЬ LTV
Так как Lifetime Value – комплексный показатель, то повлиять на него напрямую
вряд ли получится.
Поэтому, чтобы максимизировать эту метрику, стоит обратить внимание на

показатели, которые наиболее сильно на нее влияют:
● сколько времени «живут» пользователи в проекте (Lifetime),

● как возвращаются (Retention) и сколько они в среднем платят (ARPU),
● что зависит от доли платящих (Paying Share) и их среднего чека (ARPPU).
Данные метрики наиболее тесно связаны с Lifetime Value и как раз и будут
рычагами влияния на этот показатель.

18 ВОЗВРАТ ИНВЕСТИЦИЙ
(ROI)
Когда мы совершаем какие-либо покупки, мы хотим как можно быстрее
получить от них результат. Приобретя машину, мы с комфортом начинаем
ездить на работу, купив новую PlayStation — получаем удовольствие
от любимой игры, нанимая фитнес-инструктора — ожидаем получить
подтянутое тело, а заплатив за ужин — вкусно поесть и весело провести
вечер с друзьями.

Аналогично, вкладывая деньги в какой-либо проект, инвестор хочет получить
выгоду от этого вложения, но только уже в денежном эквиваленте, и
желательно как можно быстрее.

Показателем того, как возвращаются вложенные деньги, является метрика
ROI (Return On Investment) – возврат инвестиций. Есть несколько вариантов
расчета этого показателя. Первый выглядит следующим образом:
Из полученного от вложений дохода вычитается сумма инвестиций и делится

на сумму инвестиций. В этом случае, если ROI > 0, то можно считать, что
вложенные инвестиции окупились.
Второй способ немного проще – полученный от вложений доход делится на

сумму вложений:

При таком расчете, соотношение ROI > 100% будет говорит об окупаемости.
Не менее важный вопрос после факта окупаемости, это ее срок – через какое
время вернутся вложенные средства. Поэтому, чтобы контролировать процесс
и скорость возврата инвестиций, ROI можно отслеживать уже в первую неделю
и считать его в 7-й, 14-й, 30-й, 60-й, 90-й и остальные дни.
В тот момент, когда полученный доход станет равен сумме вложений и ROI
будет равен 0 или 100% (в зависимости от способа расчета), их можно считать
окупившимися. А весь последующий доход, который будет приносить проект,
пойдет только в плюс.
Зная значения ROI в определенные дни, можно не только отслеживать, как

возвращаются средства, но и сравнивать окупаемость своих инвестиций в
различные проекты.
Допустим, у нас есть 2 проекта: в первый вложили $500, во второй $1000.

Теперь теперь давайте используем вторую формулу, чтобы посмотреть как
возвращаются потраченные деньги:
| Расчет ROI для двух проектов

| Графики возврата инвестиций двух проектов
Несмотря на то, что второй проект приносит больше денег, окупается быстрее
все равно первый.
Именно такой расчет ROI – в определенные дни – и позволяет сравнивать

разные проекты, даже если вложения были сделаны не одновременно. Если
учитывать только итоговый ROI, то можно ошибочно сравнить его показатель
для проекта, который «прожил» 30 дней с тем, который на рынке полгода.

Одним из частных случаев ROI является такой показатель как ROMI (Return
On Marketing Investment) – возврат инвестиций, вложенных в маркетинг.
Фактически это тот же самый показатель, который просто подчеркивает,
что ROI может использоваться применительно к маркетинговым кампаниям,
наравне с другими сферами.

Довольно частым использованием ROI в маркетинге является анализ
окупаемости вложений в трафик. В этом случае формулу можно немного
модифицировать и считать как LTV (Lifetime Value) за вычетом CPI (Сost Per
Install), деленное на CPI. То есть доход, который приносит пользователь за
всю свою «жизнь» в проекте, уменьшенный на стоимость привлечения этого
пользователя, делится на стоимость привлечения:
Или второй вариант формулы:
В этом случае ROI тоже может быть рассчитан в определенный день с момента
установки приложения пользователем, только вместо LTV в таком расчете
будет использоваться накопительный ARPU за нужный день.
или:

При анализе трафика не стоит останавливаться на одном лишь ROI,
поскольку помимо перечисленных выше метрик, можно получить еще больше
информации о пользователе – от среднего дохода до его поведенческих
характеристик, которые также помогут оценить насколько трафик
качественный и целевой, например:
● ARPU;
● Конверсия в регистрацию или покупку;
● Количество сессий, которое совершает один пользователь;
● Retention, который можно оценивать уже в первые дни смомента установки;
● Реализация определенных событий.
Все это поможет еще лучше понять, что за пользователи приходят в проект из
определенного канала.

Небольшой пример, в котором, в отличие от первого, мы учтем еще несколько
важных показателей.
Допустим, у нас снова два проекта с такими параметрами:
| Метрики двух проектов

Используя эти данные, можно посчитать не только ROI, но и ARPU – показатель,
который учитывает и платящих, и неплатящих пользователей, и размер
платежей, после чего второй проект выглядит еще более выгодным, так как
быстрее окупает вложенные инвестиции и привлекает пользователей, которые
в среднем платят больше.
| Сравнение ARPU и ROI двух проектов
КАК ЕЩЕ МОЖНО ОЦЕНИТЬ

УСПЕШНОСТЬ ИНВЕСТИЦИЙ
Существует еще два показателя, которые помогут оценить успешность
инвестиционного проекта – это NPV (Net Present Value, или чистый
дисконтированный доход) и IRR (Internal Rate of Return, или внутренняя
норма доходности). Рассмотрим их чуть подробнее.
Первый индикатор (NPV) позволяет учесть дисконтирование при расчете

потенциальной прибыли от проекта.
Net Present Value равен сумме всех поступлений, умноженной на коэффициент

дисконтирования:
Здесь r – ставка дисконтирования, t – временные интервалы, поступления

которых мы суммируем.

Для удачных вложений этот показатель будет больше 0, и чем он будет выше,
тем прибыльнее будет проект.
Рассчитаем его для двух проектов, которые были рассмотрены в самом первом
примере. Предположим, что ставка дисконтирования 10%, тогда для первого
месяца и первого проекта расчет будет выглядеть так:
Аналогично можно сделать расчет для всех остальных периодов:
| Расчет NPV для двух проектов
Просуммировав NPV с вложениями в проект, мы видим, что итоговый

показатель обоих проектов больше нуля, что говорит о том, что они оба
возместят инвестиции, но при этом первый выглядит более привлекательным,
так как его NPV выше, чем у второго проекта.

Теперь рассмотрим второй показатель – IRR. Он довольно тесно связан с NPV,
ведь это процентная ставка, при которой NPV равен нулю.

Поэтому все, что нужно сделать для расчета IRR – это приравнять к нулю
предыдущую формулу и вычислить процентную ставку.
Здесь r и есть искомый IRR.
IRR показывает, при какой процентной ставке полностью окупятся

вложенные инвестиции.
Рассчитать этот показатель можно в Excel с помощью, например, формулы

“ВСД” (“IRR”). Для этого в начало таблицы добавляется размер вложений со
знаком минус и ко всему ряду применяется указанная формула.

В нашем примере, для первого проекта IRR получился равен 54%, а для второго
19%, что также говорит о преимуществе первого проекта.

Всегда хочется получить обратный результат, вложив деньги, а еще лучше,
когда его можно измерить. Для финансовых вложений основной показатель
мы рассмотрели.
Хорош он тем, что одновременно учитывает и потраченные средства, и

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

19 ВИРАЛЬНОСТЬ
(K-FACTOR)
Иногда, когда нам нужно решить какой-либо вопрос, в котором мы не очень
компетентны, мы обращаемся за информацией к знакомым, у которых есть
опыт в нужной сфере.
И чаще всего приятели или коллеги советуют нам сервис/человека/

приложение, с которым они имели положительный опыт в решении нашего
вопроса. Ну а мы, последовав совету и получив качественную услугу, в свою
очередь расскажем об этом своим друзьям.
Этот процесс, когда пользователи делятся информацией о продукте со своим

кругом общения, называется виральностью.
| Распространение информации между пользователями
Распространение информации о приложении можно измерить. Характеризует

его такой показатель как k-фактор, который иногда называют «вирусным
коэффициентом» или «коэффициентом виральности».

КАК РАССЧИТАТЬ K-FACTOR
Для расчета k-фактор’а есть несколько вариантов. Все они довольно сильно
отличаются друг от друга, и в некоторые формулы входят параметры, которые
не всегда можно точно отследить.
Вот наиболее популярная формула, которую можно встретить чаще всего для
расчета коэффициента виральности:
Где Sent invites – это среднее количество приглашений, отправляемых

пользователем, а Conversion – конверсия из получения приглашения в
установку.
Тогда количество новых юзеров, которых пригласят уже действующие

пользователи проекта, можно рассчитать по формуле:
Например, каждый пользователь приложения пригласит двух своих друзей,

которые установят приложение с конверсией 10%, то есть только каждый
десятый из получивших приглашение установит приложение.
В этом случае:

Это значит, что каждые 1000 пользователей приведут в приложение еще
200 человек.
Но это не конец цикла. Приглашенные 200 пользователей могут позвать своих

друзей (200 * 0,2 = 40), а те, в свою очередь, тоже пригласят своих знакомых
(40 * 0,2 = 8), и так до бесконечности.
Получается, что количество привлеченных за счет виральности пользователей

в одном цикле можно посчитать так:
А количество пользователей на последующих циклах так:
И чем больше k-фактор, тем быстрее растет аудитория продукта.
Количество пользователей проекта также имеет значение, ведь именно они

будут распространять информацию о продукте. Поэтому чем их больше,
тем большему количеству людей они расскажут о вашем приложении
или игре.
Рассмотрим на примере, как значения k-factor влияют на характер

роста аудитории. Допустим, 5000 пользователей начинают распространять
информацию о продукте. Давайте посмотрим, сколько новых пользователей
окажется в проекте к концу десятого цикла при различных значениях k-factor:

| Рост аудитории при различных значениях k-factor
| Влияние k-factor на аудиторию проекта
Если k-фактор больше 1, то это приведет к самостоятельному росту аудитории

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

Это происходит из-за того, что в любом продукте есть неизбежный отток
пользователей, который должен быть компенсирован новыми привлеченными
пользователями.
Повышая виральность и k-фактор, это можно сделать бесплатно. В противном

случае, растить аудиторию придется за счет «платных» пользователей.
КАК УВЕЛИЧИТЬ K-FACTOR

Вот что можно сделать для того, чтобы повысить k-factor и увеличить
количество привлекаемых пользователей:
● предусмотреть возможность приглашать друзей и создать необходимые
условия и стимулы, например, совместное использование контента или
бонусы за приглашение друга;
● создавать качественный контент, который бы хотелось расшаривать;
● сделать легкодоступной возможность расшаривания;
● дать возможность пользователям делиться своими достижениями в
приложении через социальные сети, что может быть особенно актуально
в играх (например, победа на каком-либо уровне), фитнес-трекерах
(преодоление длинной дистанции), обучающих приложениях (изучение
5 000 иностранных слов).

Также имеет смысл сократить время, которое проходит с момента установки
приложения пользователем до установки приложения его другом.
Между этими двумя событиями проходит несколько стадий, которые влияют

на скорость распространения информации о продукте, и которые часто
называются виральным циклом.
Во время вирального цикла пользователь устанавливает приложение, затем

получает положительный опыт от его использования, рассказывает о продукте
другу, а друг, причем не каждый, устанавливает приложение.
Все это требует времени, тормозя рост продукта.

Теперь вернемся к формуле, которая была использована в самом начале для
расчета. В ней участвовали такие параметры, как отправленные приглашения
и конверсия из такого приглашения в установку.

Минус этого подхода в том, что далеко не всегда пользователи делятся
информацией о продукте посредством отправки приглашений, да уже и
не все приложения имеют такой функционал.
Рассказать о приложении можно и в личной беседе, и отправив ссылку

на приложение в мессенджере или социальных сетях. И такие действия
отследить невозможно, как и их конверсию. Поэтому данная формула имеет
очень много ограничений и ее использование вряд ли приведет к однозначно
точному расчету виральности.

Есть еще несколько вариантов расчета:
В этом случае, мы рассчитываем количество игроков, которых пригласили

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

от параметров, которые не всегда можно точно измерить.

Виральность — один из важнейших показателей проекта, который говорит
о его способности развиваться самостоятельно и без каких-либо затрат на
привлечение пользователей, характеризует скорость его роста, популярность
на рынке. Виральность можно спровоцировать искусственно, мотивируя
пользователей делиться информацией.
Однако, чтобы этот процесс был успешным, продукт все же должен быть
хорошим и нравиться пользователям. Пожалуй, только в этом случае можно
достигнуть высоких показателей k-factor, приблизив его к 1.

20 СОЦИАЛЬНЫЙ LTV
(SOCIAL LTV)
В данном разделе речь пойдет о довольно редко встречающейся, но тем не
менее интересной для анализа пользователей метрике – Social Lifetime Value,
или Social LTV.
Эта метрика существует не сама по себе, а объединяет две другие: Lifetime

Value - среднюю сумму, которую платит пользователь за все свое время
жизни в проекте, и k-factor - показатель виральности, который говорит о
том, сколько в среднем друзей/родственников/коллег или просто знакомых
приглашает в проект один пользователь.
Стоит еще раз отметить, что расчет обеих этих метрик имеет определенные
нюансы. Lifetime Value не рассчитывается по фактическим значениям, так как
для этого нужно было бы ждать, пока все пользователи когорты перестанут
заходить в проект, что долго и практически невозможно.
А сложность же измерения k-factor заключается в том, что непросто точно

отследить отправленные приглашения пользователей, ведь часть из них
происходит во время личного общения или через мессенджеры, а также
конверсию из полученного приглашения в установку.
Поэтому и для k-factor, и для LTV существует несколько подходов к расчету

и обычно разработчики выбирают наиболее подходящий именно для их
продукта.

Вернемся к Social Lifetime Value и предположим, что LTV и k-factor мы все-таки
посчитали. Получается, если пользователь привел своего друга в проект – это
значит, что ценность данного пользователя увеличивается: он не только сам
заплатил сумму, равную LTV, но и привел друга, который тоже что-то заплатит.
И эта его новая ценность с учетом платежей друга, и будет Social LTV.
Допустим, в среднем пользователь проводит в продукте 80 дней (Lifetime) и за

это время совершает платежи на общую сумму $23,6 – это и будет его Lifetime
Value. Используя эти данные, посчитаем Social LTV:
● Lifetime value = $23,6; k-factor = 0,6

● Social lifetime value = $23,6 * (1 + 0,6) = $37,8

Таким образом, истинная ценность клиента увеличивается.
При расчете k-factor можно использовать геометрическую прогрессию, чтобы

посчитать, скольких в свою очередь привлекут те, которых позвали в проект,
но для Social LTV обычно ограничиваются единоразовым вычислением.
Social LTV нечасто используется разработчиками, но она очень удобна тем,

что сочетает в себе и главный показатель качества проекта (LTV), и показатель
его виральности (k-factor). Поэтому отслеживание динамики этой метрики
позволит оценить как эффективность сделанных изменений, так и отношение
аудитории к ним.

21 NET PROMOTER SCORE
(NPS)
Когда разработчик создает свой продукт, он старается сделать его
полезным, удобным и востребованным для пользователей. А когда
пользователь становится лоялен к продукту, это увеличивает вероятность
совершения им платежа, а также того, что он оставит хороший отзыв и
порекомендует приложение друзьям.

И один из показателей, которым эту лояльность можно оценить, является
индекс потребительской лояльности – Net Promoter Score (NPS).
КАК РАССЧИТАТЬ NPS

Метрика эта не совсем тривиальная и для ее расчета нужно предварительно
провести опрос среди пользователей приложения.
Состоит он всего лишь из одного вопроса, формулировка которого всегда

одинаковая и не зависит ни от сферы, ни от типа продукта или услуги.
Звучит он так:
"How likely is it that you would recommend our company/product/service

to a friend or colleague? "
Какова вероятность того, что вы порекомендуете нашу компанию/товар/бренд
"своему другу/коллеге?"
Далее нужно предоставить пользователю возможность выбрать тот балл,

который соответствует этой вероятности (по шкале от 0 до 10).

Вот пример того как делает опрос Booking.com:
| Пример опроса NPS на Booking.com
На этом исследование NPS заканчивается, остается только обработать

результат. Для этого пользователей нужно сгруппировать в зависимости от
поставленной оценки:
● люди, которые поставили балл от 0 до 6 – это критики (detractors) —

неудовлетворенные пользователи, которые, скорее всего, оставят
негативный отзыв о продукте и не расскажут своим друзьям ничего
хорошего о нем;
● те, кто поставил от 7 до 8 баллов это нейтральные, равнодушные

пользователи (passives), которые в любой момент могут перестать
пользоваться продуктом и уйти к конкурентам;
● те, кто поставил 9 или 10 баллов – промоутеры (promoters) — лояльные

клиенты, фанаты продукта, которые обычно оставляют положительные
отзывы и распространяют только хорошую информацию о нем.

| Принцип разделения пользователей на группы
Далее, для того, чтобы рассчитать NPS, подставляем полученные значения

в формулу:
Сам расчет Net Promoter Score довольно простой. Допустим, пользователи

ответили следующим образом:
| Влияние k-factor на аудиторию проекта

Суммируем детракторов и промоутеров и высчитываем разницу между ними:
42% - 35% = 7% – это и есть индекс потребительской лояльности.

Значение NPS может быть не только положительным, но и отрицательным,
когда в проекте превалируют критики. Конечно, это не очень хорошая ситуация
для проекта, потому что в этом случае есть риск потерять аудиторию из-за
большого количества негативных отзывов со стороны критиков. В то время как
положительный NPS говорит о том, что у проекта много лояльных сторонников,
что повышает шансы на рост аудитории за счет виральности.

Иногда опрос NPS сопровождается дополнительным вопросом, который
позволяет лучше узнать, что именно нравится или не нравится пользователям
в продукте:
"What’s the most important reason for your score?"

"Какова основная причина, по которой вы поставили такую оценку?"
Ответ на него пользователь дает уже в свободной форме.
ОСОБЕННОСТИ ПРОВЕДЕНИЯ
ОПРОСОВ
Существует несколько нюансов, о которых нужно помнить при измерении NPS.
При проведении таких опросов стоит продумать наиболее подходящее

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

Если же, например, показывать форму опроса после совершения покупки,
то это сразу ограничит аудиторию, так как увидят его только платящие
пользователи. В этом случае есть вероятность, что оценка будет зависеть,
скорее, от удобства процесса покупки, нежели от продукта в целом.
Таким образом, место в приложении, где будет показан опрос, может повлиять
на оценку пользователя, поэтому стоит выбирать нейтральные моменты, когда
он не сосредоточен на каком-либо процессе внутри приложения.
Пожалуй, идеального места для такого опроса нет, но наиболее подходящее

лучше всего выберет сам разработчик, хорошо знающий свой проект и уже
знакомый с поведением пользователей в нем.
Второй момент, на который стоит обратить внимание – как часто проводить

подобный опрос.

Как и с «идеальным» местом, так и с частотой проведения опросов
однозначного ответа нет. Можно проводить его раз в месяц, квартал, полгода,
год – только при выборе этого срока стоит учитывать, как быстро обновляется
аудитория.

Дело в том, что пользователь, уже поучаствовавший в опросе, скорее всего,
не будет каждый месяц выставлять баллы.
Вероятно, что когда вы запустите опрос первый раз, примут участие в нем
совершенно разные пользователи – и те, кто в приложении давно, и «новички».
Через какое-то время аудитория проекта пополнится новыми пользователями,

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

| Изменение аудитории со временем
А в это время «старый» пользователь, который в прошлый раз поставил

9 баллов, уже не так доволен последними обновлениями, но N-й раз
участвовать в опросе не будет. И его мнение не будет учтено при расчете NPS.
Частично эту проблему поможет решить сегментация – если запускать
опрос только на определенную аудиторию. Или при анализе результатов
можно дополнительно учитывать, какой именно пользователь поставил
определенный балл.
Также существует мнение, что изначально в таком опросе будут принимать

участие более лояльные пользователи, заинтересованные в продукте.
Но, имея под рукой больше данных об опрошенных пользователях, можно
предположить так ли это, например, оценив продолжительность сессий,
частоту заходов и другие поведенческие метрики.
Выходит, что расчет лояльности через NPS имеет несколько недостатков,

делающих его не совсем точным.

ДЛЯ ЧЕГО НУЖЕН NPS
В первую очередь NPS поможет понять общий настрой аудитории –
какая группа пользователей преобладает в проекте, а также сделать вывод
о перспективе роста продукта. NPS можно легко сравнивать с другими
компаниями или с бенчмарками по отрасли. Это как раз один из немногих
показателей, для которого можно без труда найти эти бенчмарки в Интернете.
Сделав такое сравнение, можно понять, на каком уровне находится продукт
относительно конкурентов и на какой NPS стоит ориентироваться.
Замеряя Net Promoter Score через определенные промежутки времени,

можно оценивать, как сделанные в продукте изменения сказываются на
лояльности клиентов, в правильном ли направлении движется проект.
ДРУГИЕ ТИПЫ ОПРОСОВ

ПОЛЬЗОВАТЕЛЕЙ
Существует несколько аналогов NPS, но в их основе также лежит опрос
пользователей. Один из них – Customer Satisfaction Score (CSAT), где
пользователи должны по 5-балльной шкале (very unsatisfied / unsatisfied /
neutral / satisfied / very satisfied) ответить на вопрос:
How would you rate your overall satisfaction with the service you received?
Как бы вы оценили свою удовлетворенность оказанным сервисом?
После чего рассчитывается процент удовлетворенных пользователей – тех,

кто выбрал 4 или 5.
Еще один метод Customer Effort Score (CES). Он позволяет оценить,

сколько усилий требуется пользователям для решения своего вопроса при
использовании продукта. Он существует в двух вариантах.

В первом случае вопрос звучит так:
"How much effort did you personally have to put forth to handle your request?"
"Как много сил вы лично вложили, чтобы осуществить запрос?"
И ответ должен быть дан по 5-балльной шкале.

Вторая формулировка:
"The organization made it easy for me to handle my issue."

"Организация сделала так, что мне легко решить мою задачу."
И ответить нужно, выбрав из семи вариантов наиболее подходящий: Strongly

disagree, Disagree, Somewhat disagree, Neutral, Somewhat agree, Agree, Strongly
agree. Затем просто рассчитывается среднее арифметическое всех оценок.
Так как методика у всех этих опросов одинаковая, а отличается только

формулировка, то и некоторые минусы, такие как выбор оптимального места и
частоты, здесь тоже актуальны.
С точки зрения влияния уровня NPS на доход можно сказать, что не всегда
высокий NPS означает хороший уровень дохода приложения, но в то же
время, часто у успешных компаний довольно высокий NPS за счет большого
количества промоутеров среди пользователей.
Кроме того, стоит обратить внимание на то, что если пользователь ответил,
что он готов порекомендовать сервис, это не значит, что он это сделает, так
что рассчитывать на виральный рост, глядя на NPS, тоже не стоит.
Самый лучший способ повысить этот показатель – работать над продуктом,

улучшать его и прислушиваться к мнению своих пользователей.

22 ОТТОК (CHURN RATE)
Заключительный раздел будет посвящен тому, чем заканчивается «жизнь»
пользователя в продукте. То есть, тому моменту, когда по каким-то причинам
он перестает им пользоваться.
Churn Rate – это показатель оттока пользователей, одна из наиболее

важных продуктовых метрик, которая влияет не только на финансы, но и на
возможность роста компании. От нее зависит размер аудитории продукта,
и, соответственно, доход: ведь чем больше аудитория, тем больше в ней
платящих пользователей.
ГДЕ ИСПОЛЬЗОВАТЬ CHURN RATE

Churn Rate довольно часто используется как вспомогательная метрика для
расчета таких финансовых метрик, как Lifetime и Lifetime Value.
Однако она важна и сама по себе: если из приложения уходят пользователи

и этот отток не покрывается новыми пользователями, то аудитория проекта
будет постепенно уменьшаться.
| Влияние оттока на рост аудитории

Отток рассчитывается в пользователях – какое их количество покинули сервис.
И здесь важно определить, какого именно пользователя считать ушедшим –
который бездействовал 7, 14, 30 дней, несколько месяцев, или даже год?
Этот период выбирается индивидуально в зависимости от типа приложения.

Выбранный период сильно влияет на итоговый Churn Rate: чем меньше
выбранное время неактивности пользователя, тем быстрее будет реагировать
метрика на изменения, но и тем менее стабильной она будет.
Еще один вариант расчета Churn Rate, который в основном используется

для подписных сервисов – вычисление «отвалившихся» подписчиков. Такой
Churn Rate чаще всего рассчитывается в процентах по следующей формуле:
Например, в начале месяца было 200 подписчиков, и только 180 из них

продлили подписку на следующий месяц. Получается, что отток составил
10% ((200-180)/200*100%). При этом новые пользователи, подписавшиеся в
этот месяц, в расчете не учитываются.
Для приложений с подпиской такой отток обычно считают по месяцам,

кварталам или годам. Тем не менее, эта метрика может быть рассчитана и
для всех остальных типов проектов за произвольный период, но только в этом
случае в формуле будут не подписчики, а любые пользователи, покинувшие
сервис. Для них также должен быть, прежде всего, определен период
бездействия в приложении, который и будет признаком отвала.

В случае, если речь идет о потерянных подписчиках, то Churn Rate может быть
рассчитан в денежном эквиваленте (тогда его называют MRR Churn Rate):
Здесь MRR (Monthly Recurring Revenue) – это регулярный ежемесячный доход

(который идет чаще всего от подписок). Этот показатель говорит о том,
сколько потеряно денег за период расчета.
Давайте посмотрим на примере, в чем разница между оттоком пользователей

и оттоком денежных средств.
| Сравнение оттока пользователей и оттока денежных средств
Несмотря на то, что количество пользователей уменьшилось на 25%, потери в

деньгах оказались намного больше – 38%, поэтому очень важно отслеживать
оба показателя.

Стоит учесть, что в этом случае, когда речь идет о подписках, оттоком может
быть не только уход клиента, но и переход на более дешевый тарифный план,
в результате чего этот пользователь начинает меньше платить, оставаясь при
этом в сервисе.

Churn Rate часто сравнивают с дырявым ведром: вы наливаете в него воду
(новые пользователи), а она вытекает через дыры в этом ведре (отток), и чтобы
в нем находилась вода (аудитория проекта), нужно отток уменьшать, либо
наливать очень много воды, что может быть затратно.
| Вытекающая из дырявого ведра вода, как аналог оттока пользователей
Так как возможна такая ситуация, что в приложение приходит много

новых пользователей, но они не задерживаются надолго (отток намного
больше), платить получается некому и выходит, что усилия, потраченные на
привлечение, не окупаются, а это обязательно скажется на доходе.

Рассмотрим такой пример: в продукте уже есть какое-то количество платящих
пользователей, мы докупаем новых, но в то же время существует отток и вот
как он влияет на финансовые показатели:

| Влияние оттока на доход приложения
Чтобы в данном примере исправить снижающийся тренд и сделать так, чтобы

доход увеличивался от периода к периоду, можно:

● уменьшить стоимость привлечения пользователей, правда в данном
примере, даже если их стоимость будет равна нулю, тренд по-прежнему
будет нисходящим;
● увеличить конверсию в покупку новых пользователей (для выравнивания
тренда минимум на 150%, до значения 50%);
● снизить Churn Rate (на 60%, до значения 4%).
Как видно, в этом примере Churn Rate требует меньших изменений,

чем другие метрики. Помимо общего оттока, можно дополнительно
рассчитывать Churn Rate на определенном этапе работы пользователя с
приложением. Такой подход наиболее актуален для игр и образовательных
приложений, где есть какие-либо уровни или этапы, которые пользователь
должен пройти. Например, так можно посмотреть как «отваливаются»
пользователи на различных уровнях в игре.
| Отток пользователей на определенных уровнях. Скриншот из демо devtodev

Или даже на шагах туториала.
| Отвал пользователей на шагах туториала. Скриншот из демо devtodev
Зная, где пользователи уходят, можно экспериментировать в этих конкретных

точках, чтобы предотвратить там отток и сохранить пользователей в продукте.

ЧТО МОЖЕТ СТАТЬ ПРИЧИНОЙ
ОТТОКА ПОЛЬЗОВАТЕЛЕЙ
● Пожалуй, в первую очередь – это качество продукта, его удобство и
полезность для пользователя. Если продукт решает задачи клиента,
то это будет положительно влиять на отток.
Если же потребности остаются неудовлетворенными, то появляется

вероятность, что пользователь пойдет искать другой продукт для решения
своих вопросов.
● Влиять на отток может цена, особенно если она довольно высокая

по сравнению с конкурентами. Но в тоже время, если пользователь уже
оценил продукт и привык им регулярно пользоваться, то цена может и не
стать решающим фактором.
● Приток нецелевой аудитории может повысить Churn Rate, поскольку

в этом случае в приложение попадут пользователи, ожидания которых
вряд ли совпадут с тем, что они получат, скачав приложение.
● Запуск приложения на переполненном рынке, где и так уже много

подобных продуктов, завоевавших свою аудиторию, может вести к оттоку,
ведь у потенциальных пользователей уже сформировалось видение
подходящего для них продукта, а вокруг много альтернатив.
● Если это игра, то высокая или, наоборот, слишком низкая сложность

ее прохождения приведет к тому, что пользователи или не получат радость
от преодоления уровней или заскучают, пройдя несколько этапов.
● Появление на рынке нового поставщика таких же услуг может привести

к уменьшению аудитории, особенно если у него привлекательнее цена.
● Большое количество рекламы во время работы с продуктом или

периодически возникающие ошибки могут также стать причиной оттока.

КАК УМЕНЬШИТЬ ОТТОК
Методы борьбы с оттоком вытекают из описанных выше возможных его причин.

И не лишним будет понять, что именно приводит пользователей к оттоку, и в
какой момент это происходит; выполняет ли пользователь целевые действия
продукта, все ли проходит гладко для него?

Кроме того, можно сказать, что это метрика обратная Retention: чтобы
пользователи не покидали проект, нужно подумать, как их удерживать. Это
можно сделать несколькими путями.
● Создать правильное впечатление во время первой сессии в

приложении: зачастую именно от нее зависит, вернется пользователь
или нет, именно она определяет Retention (а соответственно, и Churn)
последующих дней. Поэтому первую сессию нужно использовать,
чтобы максимально хорошо показать пользователю возможности и
преимущества приложения, заинтересовать продуктом.
● Изучать отзывы пользователей о приложении, чтобы понять, чем они
недовольны и чего не хватает.
● Напоминать пользователям о продукте, сообщать о новых функциях,
бонусах, персональных предложениях при помощи пуш- и email-
уведомлений.
● Если это игра, варьировать сложность, чтобы поддерживать постоянный
интерес игроков.
● Быть лучше конкурентов, изучать потребности клиентов, их изменение,
развивать и совершенствовать продукт.
Churn Rate – очень важная метрика для любого продукта, ведь она определяет
размер аудитории, указывает на востребованность и понятность приложения
для пользователей и непосредственно влияет на доход. Поэтому усилия,
потраченные на работу с оттоком, обязательно дадут результат в виде роста
финансовых показателей.

23 ЗАКЛЮЧЕНИЕ
Итак, мы рассмотрели основные продуктовые метрики и инструменты
анализа, оперируя которыми можно развивать и улучшать продукт, изучать
пользователей и повышать их лояльность.
Давайте резюмируем несколько общих мыслей и советов по анализу

описанных метрик.
● Игровые метрики — важнейший инструмент анализа эффективности и

успешности проекта, позволяющий принимать взвешенные решения по
его изменению.
● Работая с одной метрикой, не забывайте следить за другими: улучшение

одного показателя может привести к ухудшению другого. А также, делая
изменение на одном шаге пользователя в продукте, проверяйте, не
повлияло ли это изменение на последующие действия пользователя.
● Старайтесь отслеживать каждое изменение в ваших метриках (даже

если оно произошло не по причине ваших экспериментов) и быстро
реагировать на любое из них.
● Контролируйте основные метрики продукта, следите за ними ежедневно

или хотя бы раз в неделю, так вы станете лучше «чувствовать» свой проект
и точнее предполагать, к чему приведут те или иные изменения
● Начинайте анализ сверху, с базовых метрик, а потом разбирайте их на

составляющие, уходите вглубь: сегментируйте, используйте воронки,
исследуйте действия пользователей с помощью кастомных событий или
других инструментов, делите путь пользователя на этапы и анализируйте
каждый из них отдельно.

● А если в вашем проекте еще не настроена аналитика, скорее интегрируйте
ее и погружайтесь в этот интересный мир метрик и цифр, узнавайте своих
пользователей и получайте инсайты.
Если хотя бы какая-то из метрик оказалась для вас новой, если вы получили
хотя бы одну новую идею того, как сделать ваш проект лучше - мы добились
своей цели.
СПАСИБО ЗА ВНИМАНИЕ!

ПЛАТФОРМА ПРОДУКТОВОЙ АНАЛИТИКИ
ДЛЯ РАЗРАБОТЧИКОВ ИГР И ПРИЛОЖЕНИЙ
С DEVTODEV ВЫ СМОЖЕТЕ:
Рассчитать и оценить все доступные метрики
Оценить качество источников трафика
Провести RFM-анализ и продуктивно работать с отдельными

сегментами аудитории
Проанализировать структуру аудитории и поведение

пользователей в проекте
Прогнозировать LTV с высокой точностью
Найти слабые места в первой сессии
Узнать всё о структуре покупок
Оцените эти и другие возможности платформы в демоверсии devtodev
Регистрируйтесь, чтобы получить бесплатный доступ к полному

функционалу devtodev на 30 дней

Язык

Devtodev Igrovyje Metriki Kniga

Загружено:

Сведения о документе

Описание:

Оригинальное название

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Описание:

Авторское право:

Devtodev Igrovyje Metriki Kniga

Оригинальное название:

Загружено:

Описание:

Авторское право:

ИГРОВЫЕ

An ultimate product analytics platform for data-driven teams

В ней мы объединили описание основных метрик игрового проекта, а также

К слову, быть разработчиком либо аналитиком именно игрового проекта,

После прочтения этой книги вы сможете ответить на вопросы:

За какими метриками стоит следить в первую

Эффективно ли было сделанное изменение?

Как оценить эффективность источников трафика,

Как найти «слабое» место в продукте?

Как проанализировать структуру аудитории и

Мы уверены, что эта книга поможет вам познакомиться со всеми

2. ПЕРВАЯ СЕССИЯ (First-Time User Experience) ...................... 10

3. УДЕРЖАНИЕ (Retention) .................................................... 16

3.2. Почему важно следить за удержанием и увеличивать его 25

3.3. Как можно улучшить удержание 27

4.2. Как использовать Lifetime 34

5. АУДИТОРИЯ ПРОЕКТА: DAU / WAU / MAU ..................... 35

6. СРЕДНЯЯ ПРОДОЛЖИТЕЛЬНОСТЬ СЕССИИ .............. 44

7. ИГРОВОЕ ВРЕМЯ (Total Daily Play Time) ............................... 49

8. ЛИПКОСТЬ (Sticky Factor) ................................................... 53

8.2. Как увеличить Sticky Factor 55

10. КОНВЕРСИЯ В ПЛАТЕЖ (Paying Conversion) ...................... 60

11. ПЛАТЯЩИЕ ПОЛЬЗОВАТЕЛИ (Paying Users) .................... 66

12. RFM-АНАЛИЗ ................................................................... 77

13. ПОТРЕБИТЕЛЬСКАЯ КОРЗИНА (Consumer Basket) ............ 87

14. СРЕДНИЙ ДОХОД С ПОЛЬЗОВАТЕЛЯ (ARPU) ................. 93

15. СРЕДНИЙ ДОХОД С ПЛАТЯЩЕГО ПОЛЬЗОВАТЕЛЯ .... 98

16. НАКОПИТЕЛЬНЫЙ ДОХОД С ПОЛЬЗОВАТЕЛЯ ............ 103

18. ВОЗВРАТ ИНВЕСТИЦИЙ (ROI) ......................................... 115

19. ВИРАЛЬНОСТЬ (k-factor) .................................................. 124

20. СОЦИАЛЬНЫЙ LTV (Social LTV) ......................................... 131

21. NET PROMOTER SCORE (NPS) .......................................... 133

22. ОТТОК (Churn Rate) ............................................................. 141

23. ЗАКЛЮЧЕНИЕ .................................................................. 150

Безусловно, приятно смотреть на их активно растущий график. Но значит ли

Очевидно, что чем больше пользователей скачивает приложение, тем лучше.

Но кроме этого, рост количества скачиваний приводит к новым скачиваниям,

В первую очередь, количество загрузок влияет на положение приложения в

Второй цикл – это цикл виральности, когда пользователи делятся

Чаще всего о виральности говорят в положительном ключе, поскольку,

5 An ultimate product analytics platform for data-driven teams www.devtodev.com

Все это можно измерить и проанализировать, например, используя показатели

КАК УВЕЛИЧИТЬ КОЛИЧЕСТВО

Циклы, которые мы рассмотрели в начале раздела, в большей степени влияют

Помимо них, на органические скачивания влияет комплекс мер, называемый

www.devtodev.com An ultimate product analytics platform for data-driven teams 6

Оптимизируя страницу приложения в App Store, не стоит забывать про

По-иному работает платное привлечение. Здесь уже разработчик должен

Поэтому при привлечении пользователей стоит проанализировать следующие

7 An ultimate product analytics platform for data-driven teams www.devtodev.com

Это нужно, чтобы однозначно определить эффективность канала привлечения

Важно отметить, что для сравнения различных каналов нужно использовать

Кстати, стоит также вычислить процентный состав поступающего трафика:

| Доля платных и органических установок

www.devtodev.com An ultimate product analytics platform for data-driven teams 8

| ARPU проекта с сегментацией по странам

Несмотря на кажущуюся простоту показателя загрузок, его можно

Такой подробный анализ позволит контролировать и повышать качество

9 An ultimate product analytics platform for data-driven teams www.devtodev.com

КАК УЛУЧШИТЬ ПЕРВУЮ СЕССИЮ?

В первую очередь стоит обратить внимание на удержание (Retention) 0-го и