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

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

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

Босс слишком сложен.

Что было дальше?

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

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

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

Что именно было сделано?

Сложность стала нарастать очень плавно.

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

В «скучные» места добавлены диалоги и задания.

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

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

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

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

Как рассчитывать Lifetime

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

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

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

И это является показателем востребованности и заинтересованности пользователей, а также гарантией их финансовой активности.

Существует метрика, которая характеризует этот процесс и показывает, сколько в среднем времени пользователь активен в проекте, – Lifetime, или LT.

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

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

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

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

Как рассчитывать Lifetime

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

Например, в когорте 100 пользователей. Нам известно, сколько дней они провели в проекте перед тем, как уйти:

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

В этом случае их Lifetime составит 15,6 дня.

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

Поэтому Lifetime обычно принято не считать, а именно оценивать, взяв в расчет какую-либо стороннюю информацию, в частности Retention.Один из способов это сделать – считать «отвалившимися» тех пользователей, которые не заходили в приложение 7, 14, 30 и более дней. Иными словами, определить критерий «невозврата» пользователей.

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

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

Например, у нас есть значения Retention за первые 28 дней. Сложив их, мы получим значение Lifetime, которое равно 4,9.

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

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

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

Сравнение Retention до и после изменений

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

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

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

Вероятно, поведение таких сегментов