Текст книги "Игра в цифры. Как аналитика позволяет видеоиграм жить лучше"

Цель RFM-анализа и формирования сегментов заключается в том, чтобы в зависимости от платежного поведения пользователей воздействовать на них определенным образом: отправлять push– или email-уведомления, предлагать бонусы, офферы и скидки, разблокировать контент и т. д. Причем важно все это делать таргетированно – с посылом, который будет релевантен каждой отдельной группе. Таким образом вы сможете перемещать пользователей по RFM-группам, сдвигая их в более выгодные для вас сегменты.

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

Вот несколько примеров сегментов, которые можно выделить в результате RFM-анализа.

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

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

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

– Тех, кто недавно совершил один платеж (R = 3, F = 1, M = X), стоит мотивировать на совершение повторных платежей.

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

Отчет RFM-анализ

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

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

Средний доход с пользователя (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 является одним из ключевых показателей монетизационной эффективности проекта и напрямую влияет на доход.

Revenue =ARPU * Active Users

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

ARPU = ARPPU * Paying Share,

где ARPPU – Average Revenue Per Paying User – средний доход от одного платящего пользователя. Подробнее эта метрика будет рассмотрена в следующем разделе.

А пока посмотрим на примере, как рассчитываются эти показатели. Допустим, за выбранный период в приложение пришли 1000 пользователей, 100 из них совершили платеж на общую сумму $500.

Получается, что средний пользователь приносит $0,5.

ARPU = $500 / 1000 = $0,5

Из всей аудитории 100 пользователей что-то купили:

Paying Share = 100 / 1000 = 10 %

А средний чек платящих – $5:

ARPPU = $500 / 100 = $5

Объединив Paying Share и ARPPU, получаем:

ARPU = 10 % * $5 = $0,5

– Для анализа ценовых экспериментов

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

Допустим, продукт стоил $15 и при аудитории в 1500 человек приносил $1500, но мы решили поэкспериментировать и повысили цену до $17, что привело к уменьшению аудитории до 1200 человек и выручки до $1400. На первый взгляд кажется, что эксперимент не удался, но давайте посчитаем ARPU:

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, – это Paying Share и ARPPU.

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

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

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

Средний доход с платящего пользователя (ARPPU)

Как можно было заметить, при рассмотрении ARPU часто фигурирует еще один похожий на него показатель: ARPPU (Average Revenue Per Paying User) – средний доход, который приносит пользователь, совершивший хотя бы один платеж за определенный период, и который характеризует реакцию платящих пользователей на ценность проекта.

Рассчитывается ARPPU как отношение дохода к количеству платящих пользователей:

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

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

Как и ARPU, ARPPU оказывает прямое влияние на доход:

Revenue = ARPPU * Paying Users

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

Предположим, что в нашем приложении 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 без ущерба для других показателей.

Рассмотрим это на нашем примере. Добавим следующее условие к начальным данным: пусть из наших 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

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

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

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

Рассмотрим различие между ARPPU и средним чеком на нашем примере.

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

Average Сheck = ($2*100 + $3*50)/(100+50) = $350/150 = $2,33

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

Накопительный доход с пользователя (Cumulative ARPU)

Рассмотрим еще одну производную метрику от обычного ARPU, которая будет очень полезна для оценки качества трафика и выбора оптимального показателя CPI. Это накопительный ARPU (Cumulative ARPU, или CARPU, или RPI, или Revenue Per Install).

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

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

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

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

Теперь мы уже можем посчитать накопительный ARPU, для второго дня он будет равен сумме ARPU 0-го (день установки) и 1-го дней, то есть $0,8 + $0,5 = $1,3.

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

Накопительный ARPU когорты за 14 дней

Имея представление о его вычислении, выведем формулу вычисления накопительного ARPU:

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

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

График накопительного ARPU

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

Этот уровень CARPU, когда метрика перестает увеличиваться, можно считать Lifetime Value (LTV или CLV) – средним доходом с одного пользователя за все время его жизни в проекте.

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

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

Сравнение накопительного ARPU 3-х когорт

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

Еще несколько метрик

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

Для начала давайте определимся с терминологией.

У вас есть общая аудитория: за дневную аудиторию проекта отвечает метрика DAU, за месячную – метрика MAU.

Есть платящая аудитория: Paying Share, допустим, за день обычно рассчитывается как число плательщиков данного дня (то есть тех, кто конкретно в этот день сделал платеж), деленное на DAU.

Стоит дополнительно выделить две категории пользователей:

– «спящие» плательщики – то есть те, кто в конкретный день не платил, но вообще-то платит;

– новые плательщики – то есть те, кто в конкретный день совершил свой первый платеж в проекте.

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

То есть вместо одной привычной метрики Paying Share можно рассчитать и дополнительные показатели.

Доля плательщиков от DAU

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

Доля плативших сегодня от плативших вообще

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

Эта метрика будет довольно изменчива в дни акций и специальных ивентов, однако стоит иметь ее в виду, когда вы анализируете свою монетизацию: почему не заплатили в этот день спящие пользователи? Какую акцию сделать так, чтобы их «разбудить»?

Доля новых платящих

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

Соотношение дневного и месячного ARPPU

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

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

Удержание платящих пользователей

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

Можно нарисовать два простых графика: Retention платящих и Retention не платящих.

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

Примечание по методике расчета:

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

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

Сегмент R-

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

Сегмент F-

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

Сегмент R+

Соответственно, сегмент R+ – это количество (либо доля) пользователей, улучшивших по итогам пересчета RFM свое платежное поведение по части давности платежей. Иначе говоря, это те, кто наконец заплатил снова. Будет нелишним изучить причины их возвращения в платежное поведение, чтобы использовать те же рычаги в будущем.

Сегмент F+

Сегмент F+ – количество (либо доля) тех, кто улучшил свое платежное поведение по части частоты платежей. Проще говоря, те, кто после пересчета RFM стал платить чаще. Чем вызвано увеличение частоты платежей? Такой анализ очень уместно сочетать с логированием всех апдейтов и изменений.

На что тратится первый платеж?

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

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