В последнее время на глаза попадалось несколько статьей про data design/modelling. Для меня интересная тема, так как я немалую часть времени занимаюсь проектированием системы логов на новых проектах — что логировать, как именно, как мы это будем использовать и т. д.

Тема сама по себе непростая, помнится, Никита Шустиков из Зепты меня как-то убеждал, что amplitude-like модель данных — лучшее, что может быть. А отдельные события, джойны и прочее — бессмысленный олдскул. Я же люблю воронки, обогащенные данные, рамочные события для ключевых компонент меты, много информации из конфигов, агрегаты на стороне проекта и прочее. В общем, есть о чем поговорить.

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

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

#datamodel

Последнее время иногда думаю про логирование событий (когда устаю думать “а почему XXX такое низкое”). Хочется как-то перейти от простого “вот это надо обложить аналитикой” к какому-то более абстрактному/концептуальному уровню. Чтобы можно было для любой игры относительно быстро и безболезненно сформировать модель данных, например.

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

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

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

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

Я же предпочитаю не плодить множество событий и все логировать в рамках только одного, но с разным значением в поле статуса (started / finished / etc). То есть длинный формат таблиц и потом группировка по соответствующим полям.

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

#datamodel

В середине прошлой недели ко мне внезапно подкрался аудит. Есть такая забава у публичных компаний или компаний, которые хотят стать публичными / привлечь инвесторов. И ключевое там — как рассчитывать отложенную выручку для отчетности в формате МСФО.

Казалось бы, причем тут аналитики. Однако мы в играх продаем харду и различные наборы ресурсов. Некоторые из них можно потратить мгновенно (бустеры). А некоторые — вечны, типа единиц контента или прокачки. Плюс пользователи отваливаются или не полностью используют купленную харду, которая остается у них на руках. Зная курс харды к доллару, можно вычислить, на какую сумму были проданы товары, а что остается в обязательствах и должно быть записано в отложенную выручку (насколько я понял эту бухгалтерскую магию).

Собственно, все это и интересует финансистов, которые готовят отчеты для аудиторов. А аналитики ближе всего к подобным данным.

Вообще, как сказал @dkd_kdk, “аудит — это ультимативное испытание для модели данных”. Если модель хорошая, то собрать траты платной харды и ее курс будет относительно просто. Наша модель оказалась относительно неплоха, я доволен. Есть пара выявившихся лакун, а кое-что уже давно в бэклоге лежит. Есть и пара мест, которые на других проектах придется менять, без этого тоже не обошлось, к сожалению.

#datamodel

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

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

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

Разработчики в такие моменты нередко говорят: “ну у вас же есть таймстамп получения уровня, вот все что после него — как раз и бои на этом уровне, считайте у себя сами”. Аналитики в этот момент страдают и дуреют. Другой вариант — когда гейм получает информацию о профиле пользователя от меты и потом прицепляет ее к отправляемым событиям. И тут нехорошо становится уже разработчикам, еще на этапе обсуждения идеи. Обогащение на стороне базы данных аналитиков в момент получения событий от проекта — хорошее решение, но не без нюансов и весьма замороченное. Как минимум потому что может быть рассинхрон между временем получения события (особенно ярко это видно, когда событие от меты приходит раньше события от клиента).

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

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

#datamodel

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

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

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

Очень хочется свою документацию довести до схожего вида, ведь примерно половина уже есть. Мечты-мечты.

#datamodel

Всем привет!

Я Филипп Управителев и это мой канал по продуктовой аналитике в геймдеве.

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

Посты для знакомства с каналом:

Фреймворки продуктовой аналитики
Продуктовое мышление игровых аналитиков (текст выступления с митапа)
Особенности монетизации на офферах
UX-исследования глазами аналитика
Ретеншен платящих
Метрики второго порядка

Основные тэги:
#courses — комментарии по курсам продуктовой аналитики
#books — про книги об аналитике и статистике
#exercises — задачки и кейсы
#links — что попалось хорошего в сети
#datamodel — про разметку данных, логирование и т. д.

Продуктовой аналитикой я занимаюсь больше десяти лет. У меня базовое психологическое образование, одновременно и экспериментально-академическое, и терапевтическое (гештальт). Какое-то время преподавал мат.методы в психологии, фрилансил, написал учебник по R. Был одним из админов в ODS, сейчас админю каналы по R и когнитивной психологии, веду курсы по анализу данных в ВШЭ. И вот я здесь.

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