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

Глава 8
Поведение игрока

Человек есть не что иное, как ряд его поступков.

Георг Вильгельм Фридрих Гегель

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

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

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

Воронки (Funnels)

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

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

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

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

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

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

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

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

Воронка пользовательских действий

Получив результат воронки, можно выявить слабые места: места с наименьшей конверсией. В данном примере это совершение первого платежа после загрузки приложения. Конверсия на этом шаге наиболее низкая – всего 4 %. Затем, выявив это место и поэкспериментировав с ним, можно снова построить воронку и посмотреть, как изменения повлияли на конверсию.

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

Сравнение конверсий двух воронок

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

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

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

Воронка из установки приложения в совершение платежа

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

Профили пользователей

Все мы с вами читали книжки про Шерлока Холмса и помним его индуктивный метод. На всякий случай напомню: индукция – переход от частного к общему. Противоположностью является дедукция – от общего к частному.

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

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

Если вы хотите глубже понимать свой проект, вы встраиваете в него аналитику и начинаете видеть метрики (DAU, ARPU, LTV и т. д.) и отчеты. Значит ли это, что вы понимаете проект, над которым работаете? Не совсем. Да, вы можете делать выводы о поведении большинства, однако взглянуть на проект глазами конкретного пользователя у вас не получится.

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

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

Профили пользователей в системе Amplitude

Те из вас, кто смотрел фильм «Игра на понижение», помнят, как персонаж Кристиана Бейла изучает огромную таблицу с ипотечными кредитами и находит в ней признаки грядущего финансового кризиса. Банки (привыкшие анализировать всех разом, а не пользователей по отдельности) ему не верят и оказываются в проигрыше. Чем не яркий пример такого рода анализа?

Из чего состоит профиль пользователя?

Во-первых, это информация, собираемая аналитической системой по умолчанию:

– дата установки;

– язык;

– страна;

– часовой пояс;

– девайс;

– версия ОС;

– источник трафика;

– версия приложения;

– и т. д.

Имея эту информацию, вы уже сможете фильтровать пользователей по тем или иным параметрам, создавать сегменты и в дальнейшем отслеживать их поведение. Допустим, выбрать всех пользователей с iPad, всех из Франции, всех пришедших с Facebook, всех использующих предыдущую версию приложения – и т. д. Фильтры можно комбинировать, чтобы ориентироваться на точечно выбранную аудиторию: англоговорящие пользователи из Западной Европы, пользующиеся новой версией приложения и зарегистрированные в сервисе не более двух месяцев назад.

Профиль пользователя в системе devtodev

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

Информация о платежах в профиле пользователя в devtodev

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

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

– Какое событие обычно следует после события A?

– Какое событие предшествует событию B?

– Все ли пользователи выполняют событие C после события D? Или же уходят на событие E?

– Какие события предшествуют уходу пользователя из проекта?

– И т. д.

История событий, совершенных пользователем, в системе devtodev

Профили пользователей в системе MixPanel

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

Наконец, профиль пользователя включает в себя User Properties, которые определяете вы сами. Это может быть что угодно: уровень в игре, код группы при проведении A/B-теста, классификация по платежной активности (Minnow/Dolphin/Whale) и т. д.

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

В чем практическая польза наличия профилей пользователей в системе аналитики?

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

– Помимо этого, некоторые системы позволяют отправлять выбранным пользователям push-уведомления. Вы видите, что пользователь застрял на уровне, и отправляете ему уведомление с подсказкой, как этот уровень пройти. Затем вы замечаете, что он не один такой, и много пользователей застревают на одном и том же уровне, а потом уходят, и их нет уже в среднем семь дней. Вы пишете постановку на упрощение уровня (вы ведь хотите, чтобы ваши пользователи не уходили?), а пока всем застрявшим вы можете отправить push-уведомление с подсказкой. А тем, кто не входил в игру семь дней и больше, вы можете послать небольшой бонус в виртуальной валюте – это тоже можно сделать с помощью push-уведомлений, воспользовавшись передаваемыми параметрами.

Отправка push-уведомлений пользователям системы devtodev

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

– Доверие. Допустим, аналитическая система что-то вам посчитала (допустим, ARPU = $0,2), и вы не знаете, как это значение было получено и можно ли ему доверять. Как представитель аналитической системы скажу, что доверять можно, однако я сам прекрасно понимаю людей, которые испытывают некое недоверие к системе, считая ее черным ящиком. Часто людям, работающим с данными, хочется самим выгрузить данные и перепроверить все руками. Наличие профилей пользователей увеличивает доверие к системе аналитики: вы видите не голые цифры, а данные по каждому пользователю отдельно. Ну а возможность выгрузки данных как раз дает возможность особенно недоверчивым выгрузить данные и посчитать все самим. Поэтому наличие профилей пользователей взаимовыгодно и для клиента, и для самой аналитической системы.

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

Глава 9
Игровая экономика

– А ты умеешь считать?

– Нет.

– Отлично… два сольдо плюс два сольдо – будет десять сольдо. Десять сольдо плюс десять сольдо – будет сто сольдо. Плати один золотой.

Алексей Толстой

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

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

Как анализировать покупки пользователей

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

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

Покупки товаров по уровням

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

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

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

Еще один вариант анализа структуры покупок – ABC/XYZ анализ. Его задача заключается в том, чтобы выявить товары, которые приносят наибольшую ценность для проекта, с целью увеличить их долю среди покупаемых продуктов.

ABC/XYZ анализ состоит из двух частей.

– ABC-анализ распределяет товары на группы в зависимости от их вклада в общий доход и количества среди всех купленных товаров:

– товары группы A приносят 80 % дохода и составляют 20 % в общем количестве;

– товары группы B составляют 15 % в доходе и 30 % в общем количестве;

– товары группы C составляют 5 % в доходе и 50 % в общем количестве.

Деление товаров по доле в общем доходе (ABC-анализ)

– XYZ-анализ характеризует стабильность спроса по коэффициенту вариации и точность прогнозирования:

– группа X – товары с наиболее стабильным спросом, имеющие коэффициент вариации меньше 10 % и высокую степень надежности прогноза;

– группа Y – товары со средне-стабильным спросом, имеющие коэффициент вариации от 10 до 25 % и среднюю степень надежности прогноза;

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

Деление товаров по стабильности спроса (XYZ-анализ)

После разделения всех товаров на ABC– и XYZ-группы они объединяются в одну таблицу следующим образом.

Группы ABC/XYZ анализа

Товары, попавшие в AX, AY, BX, – самые выгодные товары, так как имеют стабильный спрос и приносят большую долю в доходе. А вот от тех, которые попали в CZ, возможно, стоит отказаться, потому что они обладают худшими характеристиками. С товарами в группе CX и AZ стоит поработать, так как один из критериев у них довольно хороший и, исправив другой, можно перевести их в более выгодную категорию.

Потребительская корзина и структура покупок

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

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

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

Допустим, в приложение попали 1000 пользователей, и в первый месяц они купили следующие товары.

Количество и стоимость покупок пользователей

Пересчитав эти покупки на одного пользователя, получается, что стоимость его потребительской корзины в первый месяц – $20,25, а ее состав:

– кристаллы – 7,4 штуки;

– персонаж – 0,35 штуки;

– скин – 0,02 штуки.

Как использовать анализ потребительской корзины

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

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

Зная наиболее популярные комбинации, можно менять расположение товаров или порядок их отображения в магазине, делать скидки на сопутствующие товары, делать нужные товары более видимыми или даже отказываться от каких-то товаров в пользу новых.

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

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

Глава 10
Акции и анализ изменений

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

Анатоль Франс

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

Если проводить параллель с реальной жизнью, то LiveOps-менеджер – это аниматор в отеле, работающем по системе «все включено». Вроде бы ни за что более платить не нужно: знай себе ходи на море, а с моря – в ресторан на завтрак, обед и ужин. Но нет, помимо основного цикла «море – ресторан» в отеле есть еще и аниматоры, которые вечно придумают что-то интересное: то дискотеку, то турнир по настольному теннису, то какие-нибудь песни под гитару. И кстати говоря, может быть и такое, что за эти дополнительные активности придется платить.

Ровно так же и работает LiveOps-менеджер: его задача – работать на увеличение удержания и монетизации как бы «над» основным геймплеем. День щедрых скидок, удвоенные опыты, подарки каждому десятому игроку, случайным образом сыплющаяся сверху манна небесная – все это его рук дело. Кстати говоря, вполне часто LiveOps-менеджером становятся и аналитики, так как правильное планирование всех активностей – задача, которая может и должна решаться на данных.

В данной главе мы рассмотрим лишь один аспект работы LiveOps-менеджера, а именно планирование внутриигровых акций.