Игры — это цифры

Привет! Меня зовут Сергей Панюшкин, я работаю в игровой компании Crazy Panda в должности product analytics team lead и веду блог New Analytics. В этой статье я хочу рассказать о том, как у нас устроена аналитика, а также поделиться кейсом по предсказанию churn, который мы решали.

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

«Что ты делаешь на работе?» — люди не из индустрии довольно-таки часто задают мне этот вопрос. В России gamedev-студий представлено мало, а с развитой аналитикой — и того меньше. Связано это, в первую очередь, с тем, что для аналитики нужны данные, а данные у вас появятся, когда у игры будет большое количество пользователей. Но этот вопрос можно услышать и от коллег по цеху: у каждого разработчика игр своя специфика управления и структура иерархии, и нередко аналитики в разных компаниях решают разные задачи. Так что сразу оговорюсь: я буду говорить о том, как мы с командой работаем в Crazy Panda.

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

В Crazy Panda очень развита культура работы с данными, и мы пропагандируем data-driven подход в лучшем его смысле: большинство управленческих решений принимается на основе данных. Так откуда брать гипотезы для развития проекта? С одной стороны — это, конечно, бенчмаркинг, с другой — исследование данных и поиск закономерностей. Очень важно искать на графиках выбросы и искажения: как подъемы, так и провалы метрик. Как только выброс обнаружен, необходимо понять, почему он произошел и как его повторить (или, наоборот, не повторять). Это входит в задачи аналитика. Скажем, на графике push-уведомлений ниже можно увидеть выброс. И рано или поздно проекту будет интересно, почему такое произошло:

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

Кстати, об оценке результата. Одновременно в одном проекте может быть запущено различное количество AB-тестов: 10, 50, 100... Аналитик должен обладать хорошей математической подготовкой, поэтому именно он курирует проведение AB-тестов в проектах: начиная от расчета размера выборки и длительности теста и заканчивая проведением статистических тестов по результатам внедрения и принятием решения, какой вариант остается.

Так как проекты постоянно развиваются (в том числе и World Poker Club, которому уже более восьми лет), то отдельную часть работы занимает мониторинг ключевых метрик: с изменением чего-либо в одном месте может поменяться логика в абсолютно другом. Однако аналитик не был бы аналитиком, если бы это не автоматизировал: так, мы разработали сервис, который автоматически следит за метриками. На текущий момент система мониторинга отлично ловит ошибки на основе заданных формальных правил: система по заранее сформированному SQL-запросу выгружает данные из КХД, далее последняя точка сопоставляется с необходимыми историческими данными. Соответственно, возникает вопрос, что считать за «нормальный» уровень. Так как многие метрики привязаны ко дню недели/времени в целом, то используется: в случае дневной проверки — распределение с временным промежутком «неделя» (то есть берутся точки за тот же день недели), в случае часовой проверки — распределение с временным промежутком «сутки» (берутся точки того же часа). Какие проверки осуществляются? Построив временной ряд, система высчитывает среднее и стандартное отклонение. В зависимости от волатильности метрики задаются трешхолды. Чаще всего это три сигмы, но есть как более «жесткие» условия, так и более «мягкие». Мы ловим все ошибки, которые возникают в проекте, но при этом получаем довольно-таки много спама (срабатывания false positive). Сейчас ведется работа над предиктивной системой мониторинга: мы прогнозируем «нормальное» значение метрики в проекте, и, в случае выхода за пределы доверительного интервала, сообщаем в Slack вместе с графиком. После этого QA-отдел уже самостоятельно будет разбираться в причинах срабатывания метрики.

Во время разработки новой игры аналитик совместно с командой проекта подготавливает систему сбора статистики, на основе use case подробно описывая ивенты, которые необходимо собирать. Прописываются все данные, которые должны лететь в КХД (мы используем ClickHouse, а в день со всех проектов летит порядка 4-5 млрд. событий). Основная парадигма в компании — у каждой фичи должна быть собственная система метрик, покрывающая все этапы жизни функции: активация, конверсия, успешность и т.д. — на основе которых будет принято решение о дальнейшей поддержке фичи.

Наиболее важный момент при проектировании системы — определиться, кто и за что отвечает. В нашей компании аналитик глубоко погружается в гейм-дизайн, еще на этапе создания игры тестируя ее и рассматривая ее сквозь «призму данных». Далее команда аналитики формирует список фич, которые необходимо отслеживать и статистика по которым имеет business value (на их основе можно улучшать продукт). После этого список обсуждается с проектом, где определяются ключевые моменты и делается приоритезация. Полностью описанное техническое задание на данные включает в себя момент, когда нужно отправлять ивент, а также все поля, которые он должен содержать.

Так как данных много, аналитику легко и необходимо развиваться в data science, причем начиная с оптимизации для обработки big data и заканчивая разработкой алгоритмов machine learning. Сейчас в компании крутится несколько моделей для маркетинговой аналитики: система предсказания плательщика, расчет LTV по рекламным каналам, система прокси-ивентов для оценки рекламных кампаний и несколько моделей для продуктовой аналитики (матч-мейкинг для покера, система предсказания чёрна, о которой мы и поговорим чуть дальше). Вообще, 2018 год можно назвать поворотным в геймдеве — крупнейшие компании таки поняли, что с помощью ML можно монетизировать данные, которые они собирали в последние годы.

Еще одной крупной сферой развития является монетизационная составляющая игр. В нашей компании есть система персональных предложений, настройкой которой занимается отдел аналитики. Кроме этого, от аналитиков ожидается планирование акций (на основе различных вариантов анализа данных), предложения по развитию банка, да и прочие дополнительные улучшения монетизации. Поэтому круто, если аналитик увлекается областями науки brain science и decision-making. Конечно, знание основ матстатистики и тервера, запросов SQL и Python для аналитика важны, но самое важное — умение структурно мыслить и находить закономерности там, где они есть.

И что дальше? Благодаря качественному подходу к аналитике, наши проекты растут, а монетизационная составляющая улучшается в разы: за год работы мы улучшили LTV старого проекта на 50%, конверсию в плательщика — на 30%, ретеншен 3-го дня — на 15%. Это позволяет проекту органически расти, как в аудитории, так и в денежном выражении.

Несколько месяцев назад мы надумали сделать модель предсказания оттока для нашего основного проекта — World Poker Club, ведь это позволит значительно улучшить его ретеншен. Задача звучит довольно-таки просто: у нас есть большое количество пользователей (как отвалившихся, так и нет) и большой объем данных по ним. Саму задачу мы сформулировали так: «определить, что пользователь не зайдет в течение следующих 14 дней». Для нас важнее был recall, чем precision: мы хотим найти всех пользователей, которые отвалятся.

Первым делом нужно, естественно, собрать данные. Изначально мы понимали, что сделать хорошую модель универсальной тяжело, поэтому мы собрали большой датасет, который включает в себя поведение именно в нашей игре: вид авторизации, девайс, агрессивность игры, качество игры, платежи, уровень, количество матчей, информацию по оппонентам (гипотеза: пользователям не нравится играть с all-in'щиками), использование различных фичей (например, hold’ em/omaha, силомер) и т.д. Итого в датасете было 68 колонок, описывающих сессию игрока всесторонне. Конечно, мы не забыли и про динамику; некоторые фичи отвечали за изменение поведения пользователя. Как таргет-переменную мы выбрали бинарную величину: придет ли пользователь в следующие 14 дней. Всего же в анализе была информация о 500 тысяч пользователей.

Естественно, датасет получился несбалансированным — большинство пользователей все-таки возвращается в течение 14 дней. Мы использовали undersampling, так как могли легко увеличить объем выборки, взяв больший промежуток времени. Здесь стоит оговориться, что сверху мы также ограничены: игра меняется, поэтому мы не можем брать слишком старую информацию. Так как в апреле игра претерпела очень большие изменения, этот месяц стал для нас наиболее старым.

Начали обучать классификатор. В рамках разработки были протестированы несколько различных моделей, начиная от логистической регрессии и заканчивая бустингом. Наиболее точную модель показал XGboost, точность которой на валидации составила 96%, на тесте — 90%. Что ж, модель есть; осталось понять — что делать дальше?

Во-первых, у нас появилось понимание, от чего зависит желание продолжать игру. Посмотрим F-score:

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

Во-вторых, мы знаем пользователей, которые планируют не открывать приложение. Что же мы можем с этим сделать? Мы предложили: давайте этим пользователям дарить фишки через push-уведомления, чтобы замотивировать их снова заглянуть в игру. Гипотеза есть — можно проверять. Быстро сделали MVP: обученную модель повесили на Cron, который каждую ночь обсчитывал последние сессии игроков и планировал рассылку push-уведомлений.

Что же в итоге? Ретеншн незначительно подрос, но количество матчей — нет. Оказывается, пользователи переходили по пушу, заходили в игру, шли all-in — и больше к нам не возвращались. Таким образом, мы ничего не могли сделать с этими людьми.

Глубокое изучение данных по пользователям World Poker Club и тестирование ряда предположений помогли нам выяснить следующее:

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

«И что, это всё?» — спросите вы. Нет, конечно! Так как в нашем покере абсолютно честные классические правила, то мы не можем их изменять, стремясь как-то угодить игрокам, «неохотно» вернувшимся после отсутствия (хотя у многих может появиться идея подкрутить карты). Однако мы можем протестировать гипотезу, в которой увеличивается социальное взаимодействие в игре с пользователем, склонным к отвалу, через другие механики. В общем, постараться сделать так, чтобы пользователю было приятно находиться в игре.

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

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