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

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

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

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

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

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

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

#datamodel

www.group-telegram.com/jp/diceanalytics.com/101

1.3K viewsedited  Mar 11, 2024 at 09:03

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

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

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

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

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

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

#datamodel

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