Игра в цифры. Как аналитика позволяет видеоиграм жить лучше - Василий Сабиров
Все события, которые всплыли у вас в голове, также запишите на листочек. Они вам пригодятся.
Допустим, вам важно событие «Встроенная покупка» (что вполне логично, это важное событие, и мы рекомендуем его отслеживать). Какие шаги пользователь перед ним совершает?
– Входит в магазин.
– Выбирает нужный раздел в магазине.
– Выбирает товар и читает его описание.
– Нажимает кнопку «Купить».
– Делает подтверждение покупки.
А какие шаги пользователь совершает сразу после встроенной покупки? Если пользователь купил, допустим, меч, то логично предположить, что дальнейшим этапом будет один из следующих:
– бой бегемотика против крокодила;
– примерка, чтобы посмотреть, как он смотрится на бегемотике;
– сообщение в социальных сетях.
Все события из обоих списков также добавляем в наш листочек.
Шаг 3. Проработка первой сессии
Что-что, а первая сессия должна быть проработана максимально детально. Дело в том, что, как правило, исправления в первой сессии делаются достаточно быстро и дешево: иначе расставить подсказки, поменять порядок экранов, поработать над копирайтом. А эффект, который дадут эти изменения, может стать хорошим рычагом на исправление последующих метрик удержания, начиная от удержания первого дня и заканчивая долгосрочным удержанием.
Рекомендуем не экономить на передаваемых во время первой сессии (или просто обучающего этапа) событиях: здесь стоит отслеживать каждый шаг, чтобы впоследствии строить воронки по этим шагам.
ИСТОРИЯ
Известен кейс, когда на одном из шагов туториала у 20 % пользователей возникала критическая ошибка при подключении к Facebook, и они попросту срезались, вылетая из игры на самой ранней стадии. И лишь детальный анализ первой сессии помог это выяснить. Исправление заняло 5 минут, а в результате игра перестала терять ⅕ своих пользователей с самого начала.
Шаг 4. Задайте себе «Самый Важный Вопрос»
С опытом в аналитике приходит осознание довольно простой истины.
Аналитика делается не ради самой аналитики, а ради принятия решений.
Поэтому, выписав все события, которые вы хотите интегрировать, задайте себе «Самый Важный Вопрос»: а что вы будете делать, увидев это событие в отчете? Сможете ли вы принять на основании этой информации какое-то решение?
Приведем пример. Один из клиентов решил передавать в аналитическую систему событие «Удар в бою». Разумеется, за бой игрок наносит множество ударов. Таким образом, количество хранимых data points (строк в базе данных аналитической системы) увеличилось в несколько раз. Когда мы задали вопрос, каким образом клиент использует это событие, то клиент ответил, что планирует смотреть, сколько ударов за бой наносит каждый игрок.
Это неплохо, и в целом можно было бы предположить, что это довольно полезная информация, однако впоследствии выяснилось, что никаких решений по боевке клиент предпринимать не будет. Таким образом, вся информация о количестве ударов в бою стала не более чем справочной (а занимала она 80 % от всей информации этого клиента).
И, кстати, если количество ударов в бою бегемотика против крокодила вам так уж важно, то эту информацию можно передать в качестве параметра события (то есть занять не N строк, а лишь одну ячейку).
Поэтому, выписав события в листочек, задайте себе «Самый Важный Вопрос». Не исключено, что некоторые события вы вычеркнете оттуда с легким сердцем.
Шаг 5. Базовые и кастомные события
Все аналитические системы работают по-разному. Но, как правило, во всех системах есть базовые и кастомные методы и события. Базовые события – это уже заранее реализованные в системе методы, для которых написаны стандартные обработчики. Кастомные события – это, вообще говоря, любые события, которые передает клиент, и ограничений тут только два: фантазия клиента и технические возможности системы.
Не все игры, как вы понимаете, посвящены противостоянию бегемотика и крокодилов. Бывают разные. А потому системы аналитики дают возможность передавать любые действия в игре: просто придумывайте имена для событий, наполняйте их параметрами и отправляйте в базу данных.
Шаг 6. Проработка параметров событий
Вместе с информацией о событии вы можете передать аналитической системе еще и множество параметров этого события: как быстро пройден уровень, с каким счетом закончился поединок, сколько на это потребовалось попыток, шагов, ресурсов. Эти параметры можно использовать в любых отчетах, включая воронки.
Подумайте над тем, какие параметры сопутствуют выполнению события.
Важно различать при этом параметры пользователя и параметры события. Параметры пользователя – это информация о том, кто выполнил событие, а не информация о самом событии. К параметрам пользователя относятся, например:
– дата регистрации пользователя. Это очень важный параметр, на нем построен весь когортный анализ;
– источник трафика. Откуда пришел пользователь?
– уровень пользователя в игре;
– метка, платящий ли пользователь или не платящий (а если он платит, то как регулярно);
– информация о девайсе, стране, языке пользователя.
Дело в том, что аналитические системы собирают информацию о пользователе отдельно. Соответственно, нет смысла передавать параметры пользователя в событии. У вас в любом случае будет возможность отдельно строить отчеты по платящим и по не платящим пользователям, по разным источникам трафика, по разным устройствам и т. д. Экономьте параметры.
Кстати говоря, сам по себе параметр – это средство экономии данных. Допустим, вы передаете событие «Победа бегемотика в бою» и событие «Поражение бегемотика в бою». То есть вы задействуете два разных события и, вполне возможно, скоро достигнете лимитов по используемым в аналитической системе событиям. В данном случае можно было сделать просто событие «Окончание боя» и передать в параметре Result его итог: 0 или 1.
Это же относится и к примеру, о котором мы говорили на четвертом шаге: количество ударов в бою можно было бы просто передать в качестве значения другого параметра этого же события.
Шаг 7. Тестирование
Представьте, что вы интегрировали события неправильно и выпустили игру на soft launch. По сути, вы лишите себя аналитики на этот период если не полностью, то частично. Исправление интеграции само по себе потребует некоторого времени, а затем нужно будет еще ждать, пока магазин обновит ваше приложение, а потом – пока пользователи поставят новую версию.
Экономьте себе время и заранее заложите достаточное количество времени на тестирование правильности интеграции.
Обычно аналитические системы позволяют вам проверять правильность интеграции буквально с телефоном в руках: вы делаете событие в приложении, и оно появляется в системе в реальном времени или с задержкой максимум в несколько минут.
Вот пример того, как может выглядеть описание одного события при интеграции аналитики:
И еще несколько советов, которые помогут вам лучше
