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

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

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

Допустим, вам важно событие «Встроенная покупка» (что вполне логично, это важное событие, и мы рекомендуем его отслеживать). Какие шаги пользователь перед ним совершает?

– Входит в магазин.

– Выбирает нужный раздел в магазине.

– Выбирает товар и читает его описание.

– Нажимает кнопку «Купить».

– Делает подтверждение покупки.

А какие шаги пользователь совершает сразу после встроенной покупки? Если пользователь купил, допустим, меч, то логично предположить, что дальнейшим этапом будет один из следующих:

– бой бегемотика против крокодила;

– примерка, чтобы посмотреть, как он смотрится на бегемотике;

– сообщение в социальных сетях.

Все события из обоих списков также добавляем в наш листочек.

Шаг 3. Проработка первой сессии

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

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

ИСТОРИЯ

Известен кейс, когда на одном из шагов туториала у 20 % пользователей возникала критическая ошибка при подключении к Facebook, и они попросту срезались, вылетая из игры на самой ранней стадии. И лишь детальный анализ первой сессии помог это выяснить. Исправление заняло 5 минут, а в результате игра перестала терять ⅕ своих пользователей с самого начала.

Шаг 4. Задайте себе «Самый Важный Вопрос»

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

Аналитика делается не ради самой аналитики, а ради принятия решений.

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

Приведем пример. Один из клиентов решил передавать в аналитическую систему событие «Удар в бою». Разумеется, за бой игрок наносит множество ударов. Таким образом, количество хранимых data points (строк в базе данных аналитической системы) увеличилось в несколько раз. Когда мы задали вопрос, каким образом клиент использует это событие, то клиент ответил, что планирует смотреть, сколько ударов за бой наносит каждый игрок.

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

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

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

Шаг 5. Базовые и кастомные события

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

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

Шаг 6. Проработка параметров событий

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

Подумайте над тем, какие параметры сопутствуют выполнению события.

Важно различать при этом параметры пользователя и параметры события. Параметры пользователя – это информация о том, кто выполнил событие, а не информация о самом событии. К параметрам пользователя относятся, например:

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

– источник трафика. Откуда пришел пользователь?

– уровень пользователя в игре;

– метка, платящий ли пользователь или не платящий (а если он платит, то как регулярно);

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

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

Кстати говоря, сам по себе параметр – это средство экономии данных. Допустим, вы передаете событие «Победа бегемотика в бою» и событие «Поражение бегемотика в бою». То есть вы задействуете два разных события и, вполне возможно, скоро достигнете лимитов по используемым в аналитической системе событиям. В данном случае можно было сделать просто событие «Окончание боя» и передать в параметре Result его итог: 0 или 1.

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

Шаг 7. Тестирование

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

Экономьте себе время и заранее заложите достаточное количество времени на тестирование правильности интеграции.

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

Вот пример того, как может выглядеть описание одного события при интеграции аналитики:

И еще несколько советов, которые помогут вам лучше