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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот пример того, как могут выглядеть описания нескольких событий при интеграции аналитики (отрывок из внутренней документации devtodev):

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

Совет 1. Учитывайте ограничения системы

Ограничения бывают разные:

– на количество уникальных событий;

– на количество событий в день;

– на количество параметров у события;

– на область значений параметра события.

Совет 2. Изучите возможности выбранной системы

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

Убедитесь, что сможете решить все задачи, которые ставите. Например, что, встроив ивенты с параметрами, вы действительно сможете оперировать ими так, как планировали.

Вот несколько вещей, на которые стоит обратить внимание.

– Можно ли применить фильтр к воронке и построить ее, например, для определенной когорты или для пришедших из определенного канала пользователей?

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

– В каком виде будет отображаться статистика по параметрам ивента, доступна ли динамика по дням?

– Можно ли посмотреть распределение пользователей по комбинации нескольких параметров?

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

Совет 3. Не откладывайте интеграцию на потом

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

Совет 4. Дублируйте информацию в несколько систем

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

Soft launch

А дальше, когда вы имеете на руках прототип и готовы выходить на новые рынки, начинается довольно важный и интересный этап, называемый soft launch, реже называемый на русском языке «мягким запуском». Сразу скажу: несмотря на то что в названии этапа есть soft, работать вам придется более чем hard.

В чем сущность soft launch? Перед запуском игры на глобальный рынок есть смысл попробовать ее на прочность на более мелком локальном рынке (например, перед запуском в США игра часто проверяется на рынке Австралии и/или Новой Зеландии). Это необходимо для того, чтобы, во-первых, проверить техническую пригодность игры, нет ли там критических ошибок или мелких багов (как правило есть); во-вторых, замерить предварительные метрики и спрогнозировать, как игра будет работать на большом рынке (если будет); и, в-третьих, просто понять, как игроки воспринимают игру: нравится ли она им, что они пишут в комментариях, как долго они играют, как часто возвращаются и насколько регулярно платят.

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

«Нет времени объяснять, давай нальем еще трафика!» – часто слышим мы в devtodev от наших клиентов, сопровождая аналитику игры на soft launch.

Я проведу вам обзор «быстрых метрик», то есть показателей игры, которые можно использовать уже в день запуска или первые дни после него. Конечно же, нужно понимать, что, работая на этапе soft launch с метриками, особенно с «быстрыми», мы не гарантируем себе на 100 %, что такие же значения повторятся при глобальном запуске. Однако задачей аналитика является так спланировать soft launch (определить число игроков, страны, нужные метрики), чтобы как можно плотнее приблизиться к будущим метрикам глобального запуска.