Какие события отправлять из игры, чтобы потом было что считать

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

Почему считать партии бесполезно

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

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

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

Базовый набор событий

Этот набор нужно заложить до запуска, а не после. Он небольшой, и его хватает почти любой игре.

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

События «бросил на шаге N»

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

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

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

Отдельно стоит отмечать повторные попытки на одном шаге: это признак непонятного экрана.

Метка источника и связь с продажей

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

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

Связь игрока с заявкой и покупкой. Это самый важный кусок и самый часто пропущенный. У игрока есть идентификатор внутри игры. Когда он оставляет контакт, этот идентификатор должен уехать вместе с заявкой в CRM и остаться там.

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

Как считать по этим данным окупаемость — в статье об окупаемости игры.

Где хранить события и что в них не класть

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

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

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

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

Как читать результат

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

Доля дошедших до конца. Универсальной нормы нет. Важна динамика: изменили экран — доля выросла или упала.

Доля оставивших контакт. Считается от дошедших, а не от всех открывших. Иначе цифра размазывается случайными заходами.

Повторные заходы. Показывают, есть ли у игры жизнь после первого дня. Если возвратов почти нет, игра разовая, и продвигать её придётся постоянно заново.

Деньги. Считаются по заявкам и покупкам из игры, а не по активности. Активность объясняет, почему денег много или мало, но сама деньгами не является.

Типичные ошибки

События добавили после запуска. Первая волна игроков прошла без данных, и сравнивать новые цифры не с чем. Это самая обидная ошибка, потому что она необратима.

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

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

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

Частые вопросы

Сколько событий достаточно для начала?

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

Что делать, если игра уже работает без событий?

Завести их сейчас и зафиксировать дату. Прошлый период честно посчитать не выйдет, но дальше данные будут, и через пару недель появится база для сравнения.

Можно ли обойтись одной внешней аналитикой?

Для быстрой картины — да. Но связать игрока с заявкой и покупкой в ней обычно неудобно, а именно эта связь отвечает на вопрос про деньги.

Как отличить живого игрока от повторных заходов одного человека?

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

Нужно ли хранить события вечно?

Нет. Достаточно срока, который покрывает сезонность и позволяет сравнивать периоды. Обезличенные события при этом хранить проще, чем персональные данные.

Коротко о главном

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

Метку источника надо тащить через все события, а идентификатор игрока — передавать вместе с заявкой в CRM. События при этом держать обезличенными, а персональные данные оставлять там, где им место. Читать результат по воронке и по долям, а деньги считать по заявкам из игры.

Если игра уже запущена, а понятных данных по ней нет — расскажите, что и куда она сейчас пишет. Помогу собрать минимальный набор событий и отчёт, по которому видно результат. Напишите в Telegram, MAX или VK.