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

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

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

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

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

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

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

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

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

Рассмотрим пример: допустим, первого января 2019 года (01.01.2019) первый раз приложение запустили 1 020 человек.

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

Размер когорты – 1 020 пользователей.

Количество пользователей, вернувшихся в проект, и Retention в 1–28 дни с момента установки

Чаще всего график удержания выглядит следующим образом:

График метрики Retention по дням с момента установки

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

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

– удержание 1-го дня – 40 %;

– удержание 7-го дня – 20 %;

– удержание 28-го дня – 10 %.

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

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

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

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

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

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

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

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

Посмотрим, как изменение принципа расчета может повлиять на результат.

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

Сессии пользователя по календарным дням и 24-часовым интервалам

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

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

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

Помимо классического варианта расчета Retention, выделяют еще четыре подхода.

1. Повторяющееся удержание (Rolling Retention)

Повторяющееся удержание N-го дня показывает процент пользователей, которые вернулись в приложение в день N с момента установки или позже (N+M).

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

2. Полное удержание (Full Retention)

Полное удержание N-го дня показывает процент пользователей, которые заходили в приложение каждый день до дня N.

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

3. Возвратное удержание (Return Retention)

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

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

4. Диапазонное удержание (Bracket-Dependent Return Retention)

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

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

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

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

Из всех описанных выше вариантов наиболее часто используется повторяющееся удержание (Rolling Retention).

Его формула выглядит следующим образом:

Для начала рассмотрим на примере, как рассчитывается этот показатель.

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

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

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

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

Если сравнить эти два вида удержания, то получится такая картина:

Сравнение графиков классического и повторяющегося удержания

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

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

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

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

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

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

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

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

График повторяющегося удержания и оттока по дням с момента установки

– Удержание влияет на размер аудитории.

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

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

– Удержание влияет на доход.

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

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

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

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

LTV = ∑ Retention * ARPDAU

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

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

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

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

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

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

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

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

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

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

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

Как моделировать удержание

График показателя удержания пользователей (Retention) имеет схожий вид и для веб, и для мобильных приложений, а также для интернет-магазинов и многих офлайн-продуктов:

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

– затем те, кто все же остался, понемногу отпадают, но уже не с такой скоростью, как в самом начале;

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

Графически Retention выглядит примерно так:

Такую кривую еще называют «кривой забывания» (forgetting curve), потому что ею же описывается процесс забывания человеком полученной информации.

Иногда может возникнуть следующая ситуация: у вас есть значения удержания за какие-то фиксированные периоды (1 день, 7 дней, 30 дней), и вы хотите узнать значения показателя за промежуточные периоды (6 дней, 14 дней, 23 дня) или после них (35 дней).

Это может пригодиться, если вы хотите прогнозировать Lifetime, или LTV (Lifetime Value), а также просто планируете, сколько из ныне активных пользователей останутся таковыми в будущем.

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

– Open Office, а именно его электронные таблицы и «Решатель» (Solver) во вкладке «Сервис»;

– «Нелинейный решатель», который нужно поставить отдельным бесплатным плагином.

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

Итак, какой же из функций можно аппроксимировать Retention?

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

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

A, B, C, D – коэффициенты, которые нам предстоит найти.

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

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

В Excel это делается с помощью СУММКВРАЗН (SUMXMY2). В Open Office эта функция нами не обнаружена, но это не проблема: рассчитываем в отдельном столбце отклонения (просто как разность между модельными и фактическими значениями), возводим их в квадрат, а затем суммируем квадраты отклонений.

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

Здесь и далее мы пользовались поочередно DEPS Evolutionary Algorithm и SCO Evolutionary Algorithm, за стартовые данные новой итерации брали значения коэффициентов, полученные на предыдущей итерации. Процесс заканчивался тогда, когда сумма квадратов отклонений с новой итерацией уменьшалась не более чем на 0,01.

Возьмем за исходные данные показатели удержания неназываемого проекта за 28 дней. По горизонтали – дни в игре, по вертикали – проценты Retention.

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

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

Вот что получается:

Как видно, желтая и красная линии совпали, но от исходной кривой они очень далеки.

А вот зеленая и бордовая линии довольно точно повторили исходную кривую.

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

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

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

Если обратить внимание на кривую, то видно, что с каждым днем она меняется все меньше. Нам это напомнило логарифмическую кривую, и мы подумали: а что если вместо X в уравнение подставить LN(X), не улучшит ли это наши результаты?

Поэтому следующим шагом давайте сравним результаты лучшей функции с X и LN(X). Единственное, в одном из случаев добавим под логарифм коэффициент E:

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

Какие выводы можно сделать?

– Лучше всего аппроксимируют кривые с четырьмя и пятью переменными.

– Замена X на LN(X) пусть и немного, но улучшает аппроксимацию.

На этом этапе мы прощаемся с кривой . Она не выдержала конкуренции.

Остались три кривые, однако неизвестно, как они работают на длинных дистанциях. Мы тестировали их лишь на первых 28 днях. Вполне вероятен случай, что если вместо X подставить большое значение (скажем, 365), то они уйдут в минус, что невозможно по определению Retention.

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

Мы просто взяли несколько примеров долгосрочного Retention из интернета и протестировали наши кривые на каждом из них:

– за 90 дней;

– за 540 дней (18 месяцев);

– за 720 дней.

Пример про 720 дней рассмотрим графически.

Данные были взяты из статьи How to measure the success of your app, и в данном случае мы пытались повторить приведенную статистику по удержанию в социальной сети.

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

Теперь делимся результатами по всем трем примерам (напомним, чем меньше сумма квадратов отклонений, тем лучше):

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

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

Вывод:

для аппроксимации Retention хорошо подходят три вида кривых:

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

1. Если у вас мало исходных точек, то лучше использовать ту кривую, в которой меньше коэффициентов. И запомните: никогда не используйте кривую, у которой неизвестных коэффициентов больше, чем точек! Скажем, если у вас есть лишь три точки Retention (допустим, 1 дня, 7 дня, 28 дня), то максимальное количество коэффицентов, которые вы можете использовать, – это три, и в этом случае лучше всего подойдет функция .

2. Вы всегда вольны менять оптимизационную функцию как вздумается (мы воспользовались стандартным МНК и применили простую сумму квадратов отклонений). Допустим, вам не так важно поведение Retention в другие периоды, но вы хотите, чтобы модельное и фактические значения Retention точь-в-точь совпали на 180 днях. Поэтому для оптимизационной функции отклонение на 180 днях можно взять с большим коэффициентом или в большой степени.

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