Кто такой игровой аналитик?

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

Аналитика — это данные

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

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

График открытия 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%. Это позволяет проекту органически расти, как в аудитории, так и в денежном выражении.

Статья была изначально опубликована на VC.ru.

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

Leave a Comment

Ваш e-mail не будет опубликован. Обязательные поля помечены *