Интеграция системы аналитики в игру

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

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

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

Во время интеграции разработчик обычно задает себе следующие вопросы:

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

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

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

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

Давайте начнём со сценария, в котором вы уже выбрали себе систему и теперь собираетесь её интегрировать.

Для формирования структуры передаваемых событий мы в devtodev применяем довольно стандартный алгоритм и хотим вам о нём рассказать.

Чего вы вообще ждёте от пользователя? В зависимости от типа бизнеса, вы по-разному ответите на этот вопрос. Вам нужно, чтобы пользователь:

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

События, которые вас интересуют, вы уже выделили. Теперь ответьте для себя на вопросы:

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

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

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

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

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

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

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

Например, в devtodev существует отчёт Tutorial steps: это упрощённая воронка именно по первой сессии, и в нём можно задавать более ста шагов.

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

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

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

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

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

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

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

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

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

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

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

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

Сессия — это визит пользователя в приложение, информация о котором позволяют рассчитывать такие метрики как DAU, WAU, MAU, retention и характеристики сессий (продолжительность, количество сессий на пользователя и так далее).

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

Второе не менее важное событие — платеж, который совершается за реальную валюту. То есть покупка in-app, созданного в магазине приложений, внутри игры. Этот ивент позволит получить доступ ко всем финансовым метрикам и отчётам, таким как Gross, Revenue, Average Check, ARPU, ARPPU, paying share и так далее, а в сочетании с информацией о сессиях — и к более глубоким отчётам, таким как Cumulative ARPU, LTV.

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

Для контроля таких платежей (обмен виртуальной валюты на какой-либо товар/предмет) встраивается ещё одно событие — In-app purchase, которое позволяет отслеживать и сравнивать количество и сумму покупок различных товаров (как общие, так и в разрезе уровней) и анализировать структуру потребительской корзины.

Ещё один ивент, который позволяет анализировать и контролировать движение игровой валюты по уровням — это currencyAccrual. С его помощью можно отследить, сколько игровой валюты было заработано игроком в процессе игры, сколько было куплено и находится на аккаунте.

В процессе некоторых игр, игрок постоянно повышает свой уровень: улучшает скиллы, развивает способности персонажа, совершенствует оружие и т.д. Обычно это линейный процесс (когда за уровнем N следует уровень N+1) и для его контроля встраивается ивент LevelUp, который передаётся в момент перехода пользователя на следующий уровень и позволяет строить отчёты в разрезе этих уровней. Кроме того, с этим событием можно передавать текущее количество внутренней валюты у игрока, чтобы получить распределение игровой валюты у пользователей в зависимости от их уровня.

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

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

Если в игре есть обучающий этап, то встроив события tutorial step на каждый шаг, а также Start, Finish и Skip tutorial, можно получить ряд отчётов, которые позволят узнать, сколько времени требуется игрокам на прохождение туториала, сколько из них отваливаются в процессе и на каких шагах.

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

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

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

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

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

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

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

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

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

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

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

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

И самое главное ограничение конечно касается монетизации аналитической системы. Часть систем строит свои тарифы от data points, то есть чем больше событий вы шлёте, тем больше вы платите. Часть же систем отталкивается от вашей месячной аудитории: в этом случае вы можете слать больше событий, так как платите за пользователей.

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

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

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

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

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

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

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