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

Глава 3
С чего начинается аналитика?

Если у вас есть фломастер – вы сможете закрасить все, кроме самого фломастера.

Если у вас есть два фломастера – вы сможете закрасить весь мир.

Народное творчество

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

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

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

Если же вы все-таки хотите сделать именно то, что гарантированно будет востребовано на рынке, то, во‐первых, перечитайте предыдущий абзац, а во‐вторых, просто знайте, что особенность игровой индустрии и вообще игры как продукта в том, что гарантий тут никто не дает. За то я и люблю игры: это что-то на пересечении искусства, бизнеса и науки, с бóльшим уклоном в искусство. А раз так, то нет никаких гарантий, что, изучив рынок и выбрав свою нишу, вы точно получите окупаемый и хорошо продаваемый продукт. И даже большие игровые студии, уже известные громкими играми, очень часто так и не доводят проекты до глобального релиза. Конечно, со стороны может показаться, что есть студии, у них есть большие и известные игры, и все, что они делают, как по мановению руки царя Мидаса превращается в золото. Но есть такая штука, как ошибка выжившего. Дело в том, что мы знаем о крупных их играх, потому что они популярны, а есть много проектов у тех же студий, о которых мы не знаем, потому что они оказались настолько непопулярны, что их закрыли еще в самом начале. Некоторые же компании становятся «феноменом одного продукта»: все их знают лишь по флагманскому проекту, а с остальными получается куда хуже. Что-то вроде «групп одного хита» в музыке.

ИСТОРИЯ

Еще одно лирическое отступление. Принято считать, что Античность и Возрождение – важнейшие этапы в истории искусства, а, например, лучшее кино делалось в СССР. И это тоже ошибка выжившего. Моя гипотеза в том, что и в Античности, и в эпоху Возрождения, и в СССР были те, кто создавал далеко не шедевральные образцы искусства, просто они до нас либо не дошли, либо мы про них забыли, потому что они не были никому нужны. А дошли лишь те фильмы, скульптуры и картины, которые действительно являются шедеврами. Часто мы, вспоминая прошлое, утверждаем, что раньше было лучше. Просто мы взяли с собой из прошлого преимущественно положительные воспоминания, а отрицательные – оставили позади.

Извините, я отвлекся. Я к тому, что игровая индустрия тем и хороша, что здесь вы не можете претендовать на 100 %-ный успех. И это делает ее как минимум интересной.

Отрицать необходимость анализа рынка я все же не буду. Рынок анализировать можно и нужно. Как минимум стоит открыть игровые магазины (Google Play, AppStore, Steam, Epic Games Store) и посмотреть, какие игры сейчас популярны: какие жанры, какие сеттинги (на какую тему и в каком визуальном стиле сделана игра), какие проекты получают фичеринг (рекламируются игровыми магазинами). Это даст вам ориентиры и понимание того, что сейчас происходит на рынке.

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

Но все же вернусь к исходному тезису: ориентируйтесь в первую очередь на себя и свои желания. Если вы любите пиратов и пошаговые бои, сделайте пошаговую стратегию в море! Если вам нравятся шахматы и шашки, сделайте свои, немного изменив правила так, как этого хотите лично вы! Основатель компании Wargaming, известной своей игрой World of Tanks, Виктор Кислый с детства любил играть в солдатиков. Вместе с братом они придумывали военные игры для себя, а сейчас в их военную игру играет весь мир. Проектируйте игру таким образом, чтобы вам самим было интересно в нее играть. А аналитику вы подключите позднее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИСТОРИЯ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот пример того, как может выглядеть описание одного события при интеграции аналитики:

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

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