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

Итак, у вас есть прототип

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

Что значит «аналитика настроена»? Это значит, что в код игры уже встроена передача так называемых игровых событий в аналитику. Все, что делает игрок в игре, должно передаваться в некую базу данных: игрок запускает игру, выбирает персонажа, проходит (или не проходит) уровень, делает покупку за золото или за рубли, – все эти события стоит передавать в систему аналитики. Они агрегируются, по ним считаются метрики (о метриках мы еще будем говорить очень много), по ним делаются выводы. Это очень важно сделать, притом сделать заранее, чтобы вы начали получать выводы еще на том этапе, пока игра «обкатывается» на маленькой аудитории. Хорошая практика, если сам аналитик играет в игру с самого раннего этапа, прописывает структуру событий и поддерживает ее впоследствии: если у вас есть под рукой документ с описанными событиями, вам в процессе оперирования игры будет намного проще отвечать на вопрос о том, какие данные у вас уже есть, а какие придется добавить.

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

– Какие события интегрировать?

– Правильно ли я их передаю в аналитическую систему?

– Смогу ли я потом ответить на все вопросы?

– Как вообще принято это делать? Другие же как-то делают!

– Как получить максимум от выбранной системы?

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

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

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

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

Шаг 1. Сформулируйте ключевые события

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

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

– прошел обучающий этап;

– дошел до магазина/пэйволла (то есть впервые столкнулся с потребностью совершить внутриигровую покупку);

– совершил платеж;

– пригласил друзей.

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

Шаг 2. Найдите окрестность ключевых событий: что было до, что будет после?

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

– Что делает пользователь непосредственно до этого события?

– Что делает пользователь непосредственно после этого события?

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

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

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

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

– Входит в магазин.

– Выбирает нужный раздел в магазине.

– Выбирает товар и читает его описание.

– Нажимает кнопку «Купить».

– Делает подтверждение покупки.

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

– бой бегемотика против крокодила;

– примерка, чтобы посмотреть, как он смотрится на бегемотике;

– сообщение в социальных сетях.

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

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

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

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

ИСТОРИЯ

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

Шаг 4. Задайте себе «Самый Важный Вопрос»

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

Аналитика делается не ради самой аналитики, а ради принятия решений.

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

ИСТОРИЯ

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

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

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

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

Шаг 5. Базовые и кастомные события

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

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

Шаг 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 (определить число игроков, страны, нужные метрики), чтобы как можно плотнее приблизиться к будущим метрикам глобального запуска.

Метрики первого дня

Пожалуй, главная и наиболее популярная метрика на этом этапе – это 1-Day Retention (подробнее о метриках Retention – в главе, посвященной метрикам лояльности). Ее рассчитывают все аналитические системы, и она показывает долю пользователей, входивших в приложение на следующий день после первого запуска. Эта метрика представляет собой реализацию правила «встречают по одежке», и для ее увеличения надо работать над оптимизацией первой сессии и визуального стиля игры. Впрочем, про 1-Day Retention уже написано достаточно много, мы же сосредоточимся на менее изученных метриках.

Метрика 0-Day Retention. Не удивляйтесь, она совсем не обязана быть равной 100 %. Она показывает долю пользователей, которые в течение 24 часов после первого входа совершили второй вход. То есть это доля тех, кто вернулся в игру. Она считается быстрее, чем 1-Day Retention, и очень полезна на soft launch, когда нужно быстро понять ситуацию. Обычно она равна 60–70 % для успешных проектов.

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

Если мы говорим о Retention, то существует и метрика Tutorial Retention. Неважно, сколько минут/часов/дней вы потратили на прохождение обучения в игре, – важно, чтобы вы вернулись в нее снова. По сути, метрика показывает долю игроков, которые говорят игре: «Окей, я тебя понял, я прошел обучение и хочу узнать, тяжело ли мне будет в бою».

Конверсия туториала – то есть доля тех, кто прошел туториал от начала до конца. Важная метрика, которая говорит и о понятности вашего туториала, и вообще о его проходимости (с точки зрения сложности и временных затрат). Обычно, анализируя эту метрику, ориентируются на 70–80 %, но опять же – все сильно зависит от жанра и сложности игры.

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

Итак, игрок может:

1) отказаться от прохождения обучения;

2) пройти его;

3) начать, но не закончить.

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

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

ИСТОРИЯ

Лирическое отступление: вы знаете, что такое медиана и чем она отличается от среднего? Я не стал это подробно описывать в книге, потому что тогда вся она могла бы стать книгой о статистике. Для понимания основ математической статистики рекомендую книжку «Статистика и котики» – ссылка на нее будет в списке литературы.

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

После прохождения обучения игрок всецело поглощен игрой, и универсальные метрики дальнейшего поведения выделить будет сложно. Однако в большинстве игр существует понятие уровня (либо уровня игрока, либо уровня в игре), поэтому мы выделяем такую метрику, как доля игроков, дошедших до уровня N. Это полезная метрика, позволяющая отследить поведение игрока на начальных этапах игры, найти его. А дальше можно либо строить графики по уровням и находить узкие места (сложные уровни), либо стимулировать удержание игроков таргетированными предложениями, либо отсылать игрокам push-уведомления с подсказками, либо делать все вышеперечисленное сразу. Еще одна полезная метрика: сколько уровней в среднем (или опять же по медиане) проходит игрок в свой первый, второй, третий день в игре.

Метрики первой недели

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

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

Многие на этом этапе используют стандартную метрику https://apptractor.ru/measure/user-analytics/arpu-i-arppu-odna-bukva-i-printsipialnyie-otlichiya.html, однако мы считаем это ошибкой.

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

Мы рекомендуем использовать такую метрику, как накопительный ARPU за N дней (также встречается название RPI – Revenue Per Install).

Допустим, 1 февраля вы налили трафик. Зафиксируйте эту дату и замеряйте, сколько денег приносят игроки за первый день / за первые два дня / за первую неделю в игре в перерасчете на общее число игроков, зарегистрированных 1 февраля.

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

Кстати, именно эта метрика при устремлении числа N к бесконечности и превратится в LTV, но это уже долгая история.

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

Также по прошествии недели вы можете замерить и 7-Days Retention, то есть долю игроков, вернувшихся в игру через семь дней после своего первого визита. Это игроки, которые уже наверняка прошли туториал, ознакомились с игрой и начали свои игровые циклы. От того, насколько удачно эти циклы реализованы, и зависит значение этой метрики. В магической формуле «40–20–10» она находится посередине, то есть среднее значение семидневного удержания для хороших игр составляет 20 %.

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