аналитика на кубах

По пятницам мы собираемся малым курултаем — рабочей группой из продюсера, геймдизов, аналитиков, спецов по монетизации и оперированию. Обсуждаем гипотезы, что и как можно сделать, чтобы достичь нужных метрик, какие результаты экспериментов и т. д. Я рассказывал результаты последнего радикального изменения метагейма. Жаль, но ожидаемых изменений в метриках не случилось (без названий и значений, простите). Постмортемы написаны, внутренняя рефлексия аналитиков почти завершена. Команда уже работает над новыми идеями. Я тоже в скором времени перейду на другие прототипы. Это были интересные несколько лет. Много экспериментов, качели от энтузиазма до разчарования в том, что и как делаешь, и обратно. Именно при работе над этим проектом я стал нащупывать, что мне важно в игровой продуктовой аналитике, как-то выстраивать собственную методологию. В принципе, в этом канале много отголосков идей и осознаний про это. Что ж, завтра будет. Лучше. Устал от ощущения, что из года в год рисую звездочки на фюзеляже. И хочу, в конце концов, научиться отвечать на вопрос “почему пользователи играют в нашу игру”.

Уже совсем скоро будет конференция Aha (6 июня оффлайн, 30 мая онлайн-трек). Ее организуют Алексей Никушин и его команда МатеМаркетинга. А это, кажется, единственные, кто делает именно продуктово-аналитические, а не датасаентистиские конференции (кому нужна техничка — велкам на ODS-датафест, а за продакт-менеджментом надо идти на ProductSence или Epic Growth). Если получится, попробую заглянуть. В прошлые года то просто не получалось, то программа не вызывала энтузиазма. В этом же году очень симпатичный трек по экспериментам и A/B-тестам в частности. Посмотрите программу — и global control, и работа с метриками в экспериментах, и графы, и воршопы. Даже про GrowthBook расскажут, про который я давно слышал, но еще ни разу не смотрел. Притом, как я понимаю, часть выступлений в оба дня будет доступна бесплатно в режиме live-трансляции. Так что как минимум стоит ее посмотреть.

Немного около-геймдизайнерских размышлений. Недавно с главным ГД на одном из наших прототипов возник небольшой спор — стоит ли вводить механики ограничения активности игроков типа энергии. Его агрументы простые — у нас в прототипе нет большого количества контента и если пользователей не ограничивать, они “пройдут игру” и не вернутся. Тем самым занизят нам тесты ретеншена. Мы видели и такие примеры, хотя ограничение пользователей всегда выглядит небезопасно — зачем нам выгонять пользователя из игры? А я как раз в последние пару дней активно залипаю в Backpack brawl (чудовищно аддиктивная штука). Там геймплей понятен на втором-третьем раунде, дальше уже просто комбинаторика и решение меты, как и в ККИ. Да и в некоторых наших прототипах-шутерах контента было, насколько я помню, два-три юнита и одна карта, а ретеншен был весьма и весьма приятный. То есть, пользователи сразу видели, что контента нет, и все равно возвращались. Собственно, можно насобирать референсы и подобрать множество аргументов "за” и “против”— в этой битве аналитики обычно проигрывают геймдизайнерам. Поэтому подобные тезисы должны ставиться под сомнение и разрешаться A/B-тестами. All others must bring data. Проблема только в том, что это прототипы, и там не всегда можно позволить себе тесты. А иногда и уверенность продюсера столь высока, что он не видит смысла в тестах. Или прототип копирует другой проект, и задача вообще не в тонких тестах, а в быстром повторе.

Комментарий по недавней задачке. Обычно мы считаем в DAU количество пользователей, которые заходили в игру в определенный календарный день, день считается по UTC. Конечно, среди пользователей могут быть те, кто зашел и ничего не делал (не заходил в бой / не делал базовый корлуп), но это уже вторично. На PC-проектах, в отличие от мобильных игр, сессия пользователя явно ограничена, так как есть событие логаута. Поэтому иногда на PC-проектах считают DAU по тем, кто залогинился в определенные сутки, и тем, кто сделал логаут (их логин был в предыдущие сутки). Или кто отыграл больше 50% сессии в новые сутки, а не просто логаут сделал. Собственно, именно это и было неожиданным для нас. Помимо просто подсчета абсолютного количества логинов мы обычно испольузем еще какую-то дополнительную сегментацию пользователей — по уровню, по лиге, по количеству заплаченного, и т.д. Это полезно и для понимания стабильности аудитории, и для некоторых других расчетов, например среднего прихода/расхода игровых валют на пользователя в сегменте. В отличие от лайтайма, тира стран или платформы это динамические параметры, которые могут меняться в течение дня. Поэтому мы берем то значение, которое было на момент логина пользователя. Брать первые значения параметров достаточно очевидная идея, однако у нее есть свой минус — низкая чувствительность к тем, кто только-только начал играть. Так как пользователь за первый день может пройти N уровней, заплатить M денег и т.д. Но тут без компромиссов, видимо, не обойтись — нам важно видеть честное значение DAU (а не умножать количество пользователей на сегменты, в которых они побывали), и начало игры для нас менее важно, в отличие от более поздних периодов. Для молодых проектов, возможно, сегменты надо делать тоньше и/или старт анализировать отдельно. В общем, учите, маги, санктуарий если дашборды на разных источниках не сходятся — возможно, дело не в данных. #exercises

Задачка по следам одного из неожиданных рабочих обсуждений. У вас PC-проект, нужно построить график DAU с разбивкой по пользовательским группам, например по уровню (или лиге). Какие события будете использовать, как построите процесс подготовки данных для дашборда? Какие могут быть подводные камни? Мое решение дам завтра или через день. #exercises

В канале GameDev Reports - by devtodev недавно было разбор исследования особенностей платящих пользователей, которое провела компания Mistplay. Исходный отчет и ссылка на русскоязычный разбор здесь. В отчете много разного, от отношения к рекламе до платежных паттернов и построения персон. Есть достаточно любопытные цифры. Например, согласно отчету и пересказу, “81% мидкорных пользователей совершает первую покупку в течение первого месяца. 7% для этого нужен только 1 день”. Или что “мотиваторы для совершения покупок - это прогрессия (54%) и получение удовольствия (44%)”. Есть даже целая иерархия, зачем пользователи играют в мобильные игры, по убыванию от “провести время и развлечься” до “стать лучшим в чем-то”. Тем не менее, в исследовании есть большая ложка методологического дегтя. Потому что исследование основано на изучении поведения 2к платящих пользователей из США и Канады, которые активно используют платформу Mistplay. Mistplay — платформа play-to-earn: пользователь через Mistplay устанавливает и запускает игру, играет и получает внутренние очки, которые потом может обналичить через Amazon gift card или другими путями (вот тут есть подробнее). Если я правильно понял схему, то пользователь получает немного виртуальных денег, разработчики — инсталлы, Mistplay — деньги за привлечение пользователей. Мы же получаем искаженную выборку, так как далеко не все разработчики используют Mistplay (т. е. мы не знаем, по пользователям каких игр сделаны выводы). И платящие пользователи, пришедшие через Mistplay, не факт что репрезентативны относительно всей совокупности платящих. Это приводит к грустно-забавным казусам, когда к хорошо платящим относят пользователей с $100 суммарно заплаченного в Q4 2023. Или что пользователям платформы повышения лояльности неожиданно очень нравятся программы лояльности и разные формы кэшбэка. В результате исследование получилось любопытным, но с некоторыми не очень очевидными искажениями, которые надо учитывать. С другой стороны, я теперь могу сравнить свои цифры с совсем внешним источником. Да и еще одна реализации механики кэшбека мне понравилась, не одними VIP-уровнями едиными, в конце концов.

Пока болтался в отпусуке, попалась на глаза статья от X5 Tech про разметку событий. Какой трекер они выбрали, как называть события, какая логика организации параметров. То, что я называю “дизайном событий” и что вполне может занимать до трети рабочего времени аналитика на ранних этапах проекта (потом, конечно, существенно меньше). Статья в целом симпатичная, сам буквально неделю назад думал над правилами названия событий и в целом над структурированием своей документации. В геймдеве набор сущностей, действий и процессов ощутимо сложнее, кажется, чем приведенные. Тем не менее подходы и идеи все равно весьма схожи. Но самое полезное в статье, на самом деле — не очень заметная ссылка на полную документацию по разметке событий. Она намного полнее и понятнее, чем статья, содержит в себе определения основных понятий, правила создания и ведения разметки, а также описание процессов разметки. Очень хочется свою документацию довести до схожего вида, ведь примерно половина уже есть. Мечты-мечты.

NEWHR выпустили очередной отчет по исследованию рынка продуктовых и дата-аналитиков. Из очевидно полезного — список задач и их регулярность (хорошо помогает от иллюзий “мы тут ML пилим 25/8”), зарплаты YoY по грейдам, длительность поиска работы в зависимости от локации. Из любопытного — доля респондентов с опытом 6 и более лет всего 16%. Вполне себе маркер, на мой взгляд, насколько же молодая дисциплина у нас. Ну или насколько сеньоры тихушники, а то есть за ними такой грех. Еще многие работают на двух работах. Тут для меня два момента — инди-командам редко когда нужен аналитик на фуллтайм, поэтому вполне можно вести несколько таких проектов. А во-вторых, это может быть еще одним подтверждением тренда, когда эксперты/сеньоры стараются разнообразить свою жизнь новыми продуктами и задачами, консультируя сторонние проекты. В целом отчет проходной, на мой вкус — глубоких инсайтов нет, слишком широкое поле. Но мониторить настроения помогает.

Всем привет. Пара вакансий из моего малого чата аналитиков (т.е. это не холодные ссылки). Junior+ / Middle позиция на Merge3-проект. Совсем без опыта не берут, нужен хотя бы небольшой опыт в аналитике / геймдизайне и общее понимание продуктовых особенностей f2p-игр. Детали вакансии здесь, вопросы можно задавать @Jerl_S. Чего нет по ссылке: проект на этапе софтлонча, но активно наполняется контентом, задач много. Полная удаленка, оформление на ИП, зарплата в евро. Или релокация в Молдову. Middle+ / Senior позиция на хардкорную MMO RPG. Когда я в последний раз общался с ребятами, они рассказывали смешные байки про кланы и их аналитику, а так же про драйв общения с кланлидами. Чем изрядно пошатнули мой скепсис относительно быстрой и наглядной эффективности социальных механик для метрик удержания. Детали вакансии здесь, вопросы можно задавать @Nordskolian.

Второй фреймворк продуктовой аналитики больше посвящен процессу разработки продукта и принятию решений. Он не столь строго сформулирован, как первый, но общую идею все же можно вычленить: “a framework that helps to gain clarity and confidence to develop a product while also providing an effective tool to communicate priorities to the team”. Фреймворк четко связывается с этапами разработки продукта в периоде от концепции до начала оперирования и ключевыми задачами, которые стоят перед аналитиками на этих этапах. Грубо говоря, на какие вопросы должна отвечать аналитика в каждом периоде разработки проекта. Так, при работе с MVP (Minimum Viable Product) в сферу задач аналитиков входят следующие пункты: - segment analytics (to better target their audience) - customer journey mapping (touchpoints and interactions customers have with the product throughout their journey) - core event logging (to identify critical success metrics that align with the product’s objectives) - experimentation (to test hypotheses and refine the product) Здесь меньше ориентации на какие-то конкретные методы и инструменты и больше бизнес-вопросов, ответы на которые нужны продакт-менеджерам / продюсерам. И в этом смысле этот фреймворк полезнее, чем просто перечисление методов — он позволяет соотнести работу аналитика с бизнес-задачами. Что, на самом деле, встречается реже, чем хотелось бы. Тем не менее, у подобного подхода есть, на мой взгляд, свои недостатки. Во-первых, он практически не затрагивает весьма большой этап оперирования — как будто там все понятно и просто нужно поддерживать то, что уже есть. А во-вторых, он оставляет аналитикам несколько реактивную роль — перечисленные вопросы-задачи помогают принять решение относительно альтернатив, но вряд ли показывают путь к радикальным изменениям / пивотам. И в этом фреймворке, и в предыдущем лично мне не хватает важного измерения, вопроса “а почему пользователи ведут себя именно так?”. Один фреймворк останавливается на каких-то измерениях, второй — на ключевых бенчмарках. Но и тот, и другой весьма косвенно, через верхнеуровневые метрики обращаются к мотивации / потребностям пользователя и тому, как продукт их удовлетворяет. Впрочем, думаю, это нормально для функциональных продуктов, но может быть недостаточно для гедонистических продуктов типа игр.