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