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

Первая платящая сессия игрока

Также я хотел бы предложить такой концепт, как FTPUE – First Time Paying User Experience.

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

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

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

Игрок ведь не просто так решает: «Дай-ка я сделаю покупку». Этому предшествует некая последовательность действий: игрок может проиграть несколько раз подряд, у него может закончиться энергия, или же наоборот – он может пройти сложный уровень и решить дать денег разработчику за полученные эмоции. А еще игрок может просто открыть push-уведомление или нажать на предложенный оффер – это наиболее стандартные сценарии.

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

А теперь рассмотрим не последовательность действий игрока, а более простые и объективные значения – это день и уровень конверсии. В некоторых играх могут быть актуальны и другие параметры: мир, в котором находился игрок, персонаж, за которого он играл, локация в match-3 игре и т. д.

«Когда» – это не только день.

Как это проанализировать

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

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

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

Во-вторых, не днями едиными. Попробуйте построить такой график, например, по уровням игры.

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

Игрок сделал первый платеж – и что дальше?

Ранее мы рассматривали последовательность действий, приводящую к платежу. Сейчас же зададимся вопросом: что делает игрок после платежа? Это также легко проанализировать с помощью воронок, или User Flow. И это знание даст вам инсайты о том, на что тратится первая покупка и как она меняет поведение пользователя.

Как это проанализировать

Структуру покупок анализировать легко и просто.

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

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

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

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

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

Расскажу кейс.

В одной из игр конверсия в платеж была очень низкой. Стали анализировать – технически все в порядке. Но мы зашли в магазин и посмотрели на него своими глазами. Перед игроком стоит вопрос выбора из 200 (двух сотен!) наименований товаров. Разумеется, наступает паралич выбора, и игрок предпочитает не выбирать ничего, нежели выбрать что-то. Стоило уменьшить выбор до 7 позиций – конверсия выросла, игрокам стало проще выбирать. Остальные позиции отныне открываются постепенно, при росте уровня игрока.

Как это проанализировать

Аналитика вообще с трудом отвечает на вопрос «Как?», особенно если речь про UI/UX. Тем не менее можно использовать следующие методы аналитики.

1. Последовательность действий пользователей (см. выше).

2. A/B-тесты для проверки гипотез.

3. Плейтесты для получения эмоционального фидбека.

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

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

LTV

LTV, она же Lifetime Value, она же Customer Lifetime Value (CLV), – это показатель ценности клиента, которую он приносит за все время в проекте. Он показывает, сколько денег в среднем принесет один пользователь за все время использования продукта.

Показатель LTV универсален: он рассчитывается и в веб-аналитике, и в мобильной. Метрику считают для большинства видов продуктов, будь то кофейни Starbucks, мобильные операторы, банки, SaaS-продукты или игры.

Нужно сразу оговориться, что Lifetime Value, посчитанная по всей базе пользователей, – это метрика мало полезная, этакий сферический конь в вакууме. Можно пользоваться LTV по проекту в целом, но более точный результат дает показатель, рассчитанный по отдельным разрезам.

LTV > CPI

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

Под CPI (Cost Per Install) в данном случае мы имеем в виду среднюю стоимость привлечения одного пользователя по всем каналам сразу. Если вам привычнее аббревиатура CPA (Cost Per Acquisition), традиционная для веб-продуктов, используйте ее в дальнейших формулах.

На самом деле, что средний CPI, что средний CPA – показатели достаточно условные. Ведь, как правило, мы платим одному партнеру сумму A, другому – сумму B, третьему – сумму C, а общий средний CPI – это, скорее всего, значение, которое не равно ни A, ни B, ни C. LTV лучше считать отдельно по каналам привлечения, по кампаниям, по странам.

При этом может получиться так, что общая средняя LTV будет больше общего среднего CPI, однако в разрезе каналов привлечения будут и неэффективные каналы, где это условие не выполняется. Что делать в такой ситуации? Можно, конечно, сразу отключить попавший в немилость источник трафика. Однако эффективнее будет детально изучить его, «разрезать» по кампаниям, странам и платформам, и отключить те из них, где LTV меньше, чем CPI. А еще лучше – ввести подобный анализ в регулярную практику и отключать неэффективные SubID, которые появляются у поставщика трафика.

LTV основывается на значении многих метрик. На нее влияют и удержание пользователей (Retention), и доля платящих (Paying Share), и доход с платящего пользователя (ARPPU). Вместо того чтобы отслеживать динамику нескольких метрик, вы можете отслеживать динамику LTV – это покажет, насколько эффективны изменения, которые вы вносите в свой проект.

Если LTV растет от месяца к месяцу – прекрасно, продолжайте в том же духе. Если же она падает (а у большинства проектов LTV имеет нисходящий тренд по временной оси) – пора принимать меры.

Метриками оперируют аналитики, а деньги дают собственники и инвесторы. И этим серьезным людям важно знать, окупятся ли их вложения. Для этого придумана метрика ROI (Return On Investment), которая учитывает в себе и LTV, и стоимость привлечения.

ROI можно считать по-разному, мы сейчас говорим о следующей формуле:

По результатам расчетов ROI должен быть больше 100 %.

Рекомендую также рассчитывать ROI за определенные фиксированные интервалы времени от момента регистрации (первого входа) пользователя:

Здесь мы вводим новую метрику N Day Cumulative ARPU, которая демонстрирует, сколько денег в среднем принес один пользователь за первые N дней использования продукта. Подбирая различные N, вы лучше поймете динамику ROI и сможете рассчитать еще один важный показатель. А именно…

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

Синяя линия – это показатель Cumulative ARPU, он показывает, сколько денег в среднем приносит один пользователь за первые N дней использования продукта. Показатель LTV – это предел Cumulative ARPU при N, стремящемся к бесконечности (хотя на практике берут фиксированные значения N вроде 120, 180, 360 дней).

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

Вернемся к основной формуле:

LTV > CPI

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

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

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

Чистая LTV > eCPI + издержки на 1 пользователя (переменные, постоянные)

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

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

Например, вы сможете ответить на такие вопросы:

– что будет с выручкой через три месяца, если мы сейчас сократим платный трафик на 50 % при сохранении всех прочих метрик;

– что станет с выручкой, если мы внесем в проект изменение, которое увеличит удержание пользователей на 3 %;

– когда окупится трафик, который мы закупили у партнера X, и т. д.

Как видим, LTV – важнейший показатель в аналитике проекта. Но есть одна трудность: чтобы посчитать эту метрику, нужно время, а времени, как правило, нет. Если вы считаете Lifetime Value за короткий срок, прогноз получится не самым точным. Если вы делаете расчет за длительный период, то вопрос прогнозирования перестает быть актуальным: будущее настигает нас.

Вопрос расчета Lifetime Value рано или поздно встает перед разработчиками мобильных приложений. Методов расчета придумано множество, и по поводу того, как считать LTV, сколько существует людей, столько и мнений. Вот, например, скриншот про расчет LTV из книги Database Marketing: analyzing and managing customers – кстати, хорошая и мощная книга по аналитике и маркетингу, если вы любите хардкор:

В рамках книги мы опишем наиболее распространенные методы, обозначим их плюсы и минусы. Данные методы подходят прежде всего для описания модели free-to-play.

Начнем с простого. Этот метод выделяется на фоне всех последующих, так как он не моделирует LTV и не прогнозирует ее, а считает фактическую LTV.

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

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

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

Пример

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

Мы делим суммарный доход за год на количество уникальных пользователей, которые были с нами в течение года (Yearly Active Users).

Таким образом, LTV примерно равна $492 600 / 14 550 = $33,86.

Грубая, но оценка.

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

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

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

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

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

Формула этого метода такова:

LTV = Lifetime * ARPU

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

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

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

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

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

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

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

4. Рассчитываем среднее значение по всем пользователям. Это и есть Lifetime.

Ну а ARPU (в данном случае ARPU = ARPDAU) рассчитывается как дневной Revenue, деленный на DAU. Умножаем Lifetime на ARPU и получаем LTV.

Пример

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

Таковых набралось трое, и средний период от даты установки до даты последней активности у них равен (12 + 29 + 3) / 3 = 14,7 дня.

Почему мы задали как период неактивности именно 7 дней?

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

Плюсы метода

1. Простота расчетов. Рассчитать Lifetime таким образом нетрудно, еще легче рассчитать ARPU. А перемножить одно на другое сможет любой школьник.

2. Можно рассчитывать LTV хоть каждый день.

3. LTV можно рассчитать по каждому пользовательскому сегменту в отдельности.

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

1. Значение сильно зависит от периода неактивности, задаваемого, как правило, экспертным путем (как и сделали мы в нашем примере).

2. Мы умножаем среднее значение Lifetime на среднее значение ARPU, получаем накопленную ошибку.

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

4. Сильное предположение о неизменности ARPU. Мы берем ARPU лишь за один день и на его основании прогнозируем LTV на множество дней вперед.

Формула метода точно такая же:

LTV = Lifetime * ARPU

Но Lifetime тут считается немного сложнее и получается намного точнее. Вспомним, как выглядит график Retentio n:

Дело в том, что Lifetime – это площадь фигуры под графиком Retention, иначе говоря – интеграл от Retention по времени.

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

О моделировании Retention вы можете подробно прочитать в главе 3. Вернитесь к ней и перечитайте тот сложный текст про выбор оптимальной функции.

И возвращайтесь сюда снова.

…Итак, Retention мы смоделировали. Это еще не конец задачи, но мы уже близко. Дальше по-прежнему можно выбрать сложный или простой метод.

Сложный метод заключается в нахождении интеграла от функции Retention.

Напомним, что:

Простой же метод заключается в том, чтобы, пусть и примерно, поделить кривую Retention на сегменты в зависимости от значения Lifetime. Например, на пользователей, ушедших через день, проживших в приложении от 2 до 7 дней, от 8 до 30 дней, от 1 до 3 месяцев, свыше 3 месяцев. Чем больше сегментов, тем лучше. Для каждого сегмента посчитать по таблице Retention процент пользователей (вес сегмента), относящихся к нему, а затем посчитать средневзвешенный Lifetime по всем сегментам.

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

Простой метод заключается в том, что правый край задается экспертно.

Обычно это происходит так:

– А давайте возьмем полгода!

– Почему?

– А почему бы и нет?

– Хорошо, давайте полгода.

Сложный метод заключается в использовании дисконтирования и нахождении ставки дисконтирования WACC.

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

Формула такова:

Здесь PV (Present Value) – текущая стоимость будущих денег, CFi – деньги, которые вы получите через i временных периодов, WACC (Weighted Average Cost of Capital) – та самая ставка дисконтирования.

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

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

Будем считать, что Lifetime мы посчитали. Теперь же считаем ARPU (Revenue/DAU), умножаем ARPU на Lifetime и получаем LTV.

Плюсы метода:

1. Точность. Lifetime рассчитан очень точно, погрешность в нем минимальна.

2. Побочный эффект от расчета такого метода – бонусом вы получаете еще и прогноз Retention на сколько угодно дней.

3. Возможность посчитать LTV для каждого сегмента в отдельности.

Минусы метода:

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

2. Вновь предположение о неизменности ARPU во времени. Можно немного перестраховаться и взять в расчет не ARPU за один день, а среднедневной ARPU за Lifetime, это увеличит точность.