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

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

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

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

Метрики первого дня

• 1-Day Retention
• 0-Day Retention (референс 60−70%)
• Tutorial COR (референс 70−80%)
• Tutorial Skip Rate
• Скорость прохождения Tutorial
• Доля игроков дошедших до Уровня N

Метрики первой недели

• CARPU N day — накопительный ARPU за N дней (или RPI — Revenue Per Install). «Допустим, 1 февраля вы налили трафик. Зафиксируйте эту дату и замеряйте, сколько денег приносят игроки за первый день / за первые два дня / за первую неделю в игре в перерасчете на общее число игроков, зарегистрированных 1 февраля».
• CR в первый платеж (в окне 7 дней)
• 7-Days Retention

Формула «40−20−10»

Средне-хорошее значение удержания 1-го дня — 40%, 7-го дня — 20%, 28-го дня — 10%.

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

Карта метрик

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

North Star Metric (NSM)

NSM — это показатель, который лучше всего отражает основную ценность продукта для пользователей.

Свойства NSM:

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

Возврат инвестиций

2 способа расчета ROI:

\[ROI = {Revenue-Investments \over Investments} \] \[ROI = {Revenue \over Investments} \times 100 \% \]

В первом случае инвестиции скупились, если ROI > 0. Во втором — ROI > 100%.

Чтобы контролировать процесс и скорость возврата инвестиций, ROI принято считать в динамике за 7-й, 14-й, 30-й, 60-й, 90-й и остальные дни. Такой расчет ROI — в определенные дни — и позволяет сравнивать разные проекты, даже если вложения были сделаны не одновременно.

Aha!-момент

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

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

Установка => активация => возвращение => совершение платежа

Виды Retention

1. Classic Retention
2. Rolling Retention — Rolling Retention N-го дня показывает процент пользователей, которые вернулись в приложение в день N с момента установки или позже.
3. Full Retention — Full Retention N-го дня показывает процент пользователей, которые заходили в приложение каждый день до дня N.
4. Return Retention — Return Retention N-го дня показывает процент пользователей, которые вернулись хотя бы один раз за N дней.
5. Bracket-Dependent Return Retention — аналогично Return Retention, но за диапазон.

LifeTime

LifeTime показывает через какое время пользователь покинет проект.

LifeTime можно посчитать как интеграл от функции Retention (равен площади под кривой Retention). Посчитав LifeTime по каждой из 2 когорт можно принять решение о том, лучше ли продуктовое улучшение или нет. По кривой Retention это видно не всегда.

Очевидно, что LifeTime нужно растить, тогда растет LifeTimeValue, ну и как следствие — Revenue.

Метрики для оценки качества трафика

• ARPU (Average Revenue Per User);
• RPI (Revenue Per Install);
• CPI (Cost Per Install);
• доля платящих пользователей (Paying Share);
• процентное удержание (Retention);
• возврат инвестиций (ROI).

Active Users

• Users Online / Concurrent Users (CCU) — активные пользователи, которые в текущий момент находятся в приложении.
• Peak Concurrent Users — максимальное кол-во пользователей, одновременно находящихся в приложении, метрика важна при планировании нагрузки на серверы.
• New Users → Active Users → Paying Users

Sticky Factor

\[Sticky Factor = {DAU \over MAU} \times 100 \% \]

Платящие пользователи

\[Paying Share = {Paying Users \over Active Users} \] \[Revenue = ARPPU \times Paying Users \]

Paying Share зависит от типа приложения, но зачастую она довольно небольшая — около 1−2%. Считается, что медиана показателя платящих пользователей в мобильных f2p-играх составляет 1% — то есть подавляющая часть аудитории обычно предпочитает не платить.

Виды сегментации платящих пользователей

→ По общей сумме платежей (% — квантили)

• Grand Whales (гран-киты) — 1%
• Whales (киты) — 2—10%
• Grand Dolphins (гран-дельфины) — 11—25%
• Dolphins (дельфины) — 25—50%
• Minows (пескари) — 50—100%

→ По количеству платежей

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

→ По времени с момента установки

RFM-анализ

• Recency — разница между текущей датой и датой последнего платежа, совершенного пользователем.
• Frequency — количество транзакций, которые сделал пользователь за исследуемый временной промежуток.
• Monetary — сумма покупок пользователя за этот же период.

ARPU / ARPDAU / ARPMAU

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

\[ ARPU = { Revenue \over Active Users} \] \[ Revenue = ARPU \times Active Users \]

ARPPU

\[ ARPPU = {Revenue \over Paying Users} \] \[ Revenue = ARPPU \times Paying Users \]

CARPU

\[ CARPU (day N) = {Revenue (day N) \over Users In Cohort} \]

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

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

LTV

• Lifetime Value, посчитанная по всей базе пользователей, — это метрика мало полезная, этакий сферический конь в вакууме.
• Пользователь должен приносить больше денег, чем было потрачено на его привлечение. Должно выполняться условие: \[ LTV > CAC \]

• LTV лучше считать отдельно по каналам привлечения, по кам- паниям, по странам.