Ранее я уже говорил, что склонен эпизодически мудрить с решением задачи и делать сложно там, где можно было бы сделать проще. Однако бывают и обратные ситуации, в которых эпизодически меня упрекает лид. Когда я чрезмерно упрощаю решение.
Самый простой пример. Смотрим, сколько боев в день делает пользователь, смотрим в динамике от даты инсталла (т. е. сколько делает в день инсталла, сколько на след.день, сколько на седьмой день и далее). Метрика когортная, считаю по лафтайму, а не по количеству активных дней, но это непринципиально.
Считаю обычные средние (сколько боев / сколько зашло), вижу снижение. Вроде бы ничего особенного, достаточно типовая структура, можно детально не останавливаться
Однако потом посмотрел структуру аудитории — какая доля зашедших делает 0 боев, какая 1 - Q1, и квартилями Q2-3Q, Q3-Q4, дробность бинов тут тоже не столь принципиальна. И оказалось, что у нас очень сильно, прям непривычно сильно растет доля тех, кто вообще не делает бои, хотя в игру заходит. А вот доля тех, кто делает какое-то среднее количество, типа 1-6 боев — вполне стабильна.
То есть снижение среднего, которое я увидел, объясняется специфичным поведением одного сегмента. И я вполне мог пропустить этот момент, до этого мне средние казались весьма информативными.
Так что сейчас пытаюсь переформатировать свою оптику так, чтобы все вопросы, которые касаются аудитории, смотреть именно сегментами, не опускаясь до агрегатных статистик. Тоже крайность, конечно, но для формирования навыка самое то.
Самый простой пример. Смотрим, сколько боев в день делает пользователь, смотрим в динамике от даты инсталла (т. е. сколько делает в день инсталла, сколько на след.день, сколько на седьмой день и далее). Метрика когортная, считаю по лафтайму, а не по количеству активных дней, но это непринципиально.
Считаю обычные средние (сколько боев / сколько зашло), вижу снижение. Вроде бы ничего особенного, достаточно типовая структура, можно детально не останавливаться
Однако потом посмотрел структуру аудитории — какая доля зашедших делает 0 боев, какая 1 - Q1, и квартилями Q2-3Q, Q3-Q4, дробность бинов тут тоже не столь принципиальна. И оказалось, что у нас очень сильно, прям непривычно сильно растет доля тех, кто вообще не делает бои, хотя в игру заходит. А вот доля тех, кто делает какое-то среднее количество, типа 1-6 боев — вполне стабильна.
То есть снижение среднего, которое я увидел, объясняется специфичным поведением одного сегмента. И я вполне мог пропустить этот момент, до этого мне средние казались весьма информативными.
Так что сейчас пытаюсь переформатировать свою оптику так, чтобы все вопросы, которые касаются аудитории, смотреть именно сегментами, не опускаясь до агрегатных статистик. Тоже крайность, конечно, но для формирования навыка самое то.
Наконец-то дочитал-долистал Games User Research by Anders Drachen, Pejman Mirza-Babaei, Lennart Nacke (Eds). Много страниц, отличная бумага и полиграфия, прям очень хорошая структура и оформление. Oxford University Press, как никак.
Книга — сборник статей большого количества авторов. Часть авторов имеют отношение к геймдеву — работали в Ubisoft, EA, Paradox Interactive, Sony Playstation. Другие — академические исследователи (в том числе HCI) или просто исследователи-практики из специализированных агентств.
Все статьи организованы в три части. Первая больше про организацию процесса — как могут быть устроены UX-исследователи в геймдев-командах и как выглядят процессы с их участием; уровни зрелости UX-исследований; как должна выглядеть лаборатория для проведения исследований.
Вторая часть посвящена методам. Это самая большая часть книги, почти половина от общего объема. И здесь полное разнообразие — короткие интро в опросы, пользовательские интервью, RITE подход, think-aloud метод, особенности исследования playability. Есть пара статей, которые посвящены сбору биометрических данных (вплоть до миографии и энцефалографии). Последняя статья части вообще про аналитику и данные, и их сочетание с user research методами.
Третья часть более разнородная по содержанию. Тут и кейс-стади (Dissecting Dragon: GUR for Dragon Age: Inquisition, например), и рекомендации по проведению исследований маленьким студиям, и некоторые обзоры методов и подходов (Social network analysis, Virtual reality) и так далее.
Из неочевидных, но порадовавших меня вещей — достаточно много внимания уделяется мелким деталям. Как может быть расставлена мебель и комнаты в лаборатории, что писать респондентам, какие могут быть нюансы в опросах и прочие практические мелочи, с которыми сталкивается каждый, кто начинает делать исследования.
В общем, книга отличная. И введение в методы, и в ResearchOps, и практические детали, и фокус на доменной области очень четко выдерживается. Цветные иллюстрации и хорошая бумага тоже оставляют приятное впечатление. Конечно, есть и некоторые недостатки — книга выпущена в 2018 году, писать ее начали в 2016 году. И как со всеми сборниками статей, во многих статьях есть перекликающиеся темы (например, про рекрут респондентов). Но это все вполне нивелируется содержанием.
#books
Книга — сборник статей большого количества авторов. Часть авторов имеют отношение к геймдеву — работали в Ubisoft, EA, Paradox Interactive, Sony Playstation. Другие — академические исследователи (в том числе HCI) или просто исследователи-практики из специализированных агентств.
Все статьи организованы в три части. Первая больше про организацию процесса — как могут быть устроены UX-исследователи в геймдев-командах и как выглядят процессы с их участием; уровни зрелости UX-исследований; как должна выглядеть лаборатория для проведения исследований.
Вторая часть посвящена методам. Это самая большая часть книги, почти половина от общего объема. И здесь полное разнообразие — короткие интро в опросы, пользовательские интервью, RITE подход, think-aloud метод, особенности исследования playability. Есть пара статей, которые посвящены сбору биометрических данных (вплоть до миографии и энцефалографии). Последняя статья части вообще про аналитику и данные, и их сочетание с user research методами.
Третья часть более разнородная по содержанию. Тут и кейс-стади (Dissecting Dragon: GUR for Dragon Age: Inquisition, например), и рекомендации по проведению исследований маленьким студиям, и некоторые обзоры методов и подходов (Social network analysis, Virtual reality) и так далее.
Из неочевидных, но порадовавших меня вещей — достаточно много внимания уделяется мелким деталям. Как может быть расставлена мебель и комнаты в лаборатории, что писать респондентам, какие могут быть нюансы в опросах и прочие практические мелочи, с которыми сталкивается каждый, кто начинает делать исследования.
В общем, книга отличная. И введение в методы, и в ResearchOps, и практические детали, и фокус на доменной области очень четко выдерживается. Цветные иллюстрации и хорошая бумага тоже оставляют приятное впечатление. Конечно, есть и некоторые недостатки — книга выпущена в 2018 году, писать ее начали в 2016 году. И как со всеми сборниками статей, во многих статьях есть перекликающиеся темы (например, про рекрут респондентов). Но это все вполне нивелируется содержанием.
#books
Что ж, прошел еще один год. Писал немного, но вроде бы регулярно. Сделал меньше, чем хотелось, зато есть что попробовать и показать в следующем году. Вперед и вверх, как завещали классики.
Спасибо, что читаете и комментируете.
С новым годом вас.
Спасибо, что читаете и комментируете.
С новым годом вас.
Праздники закончились, надо возвращаться к работе.
Вот вам небольшая задачка, прям из рабочих дашбордов меты. На графике — прокачка двух спеллов по игровым уровням/этапам (уровни как в Homescapes или Archero).
По оси OX — номер уровня. По оси OY — средний уровень прокачки заклинания в мете у тех пользователей, кто играл на этом уровне/этапе.
Собственно, вопрос. Что вы видите на этом графике?
Мо комментарий сегодня вечером или завтра днем.
#exercises
Вот вам небольшая задачка, прям из рабочих дашбордов меты. На графике — прокачка двух спеллов по игровым уровням/этапам (уровни как в Homescapes или Archero).
По оси OX — номер уровня. По оси OY — средний уровень прокачки заклинания в мете у тех пользователей, кто играл на этом уровне/этапе.
Собственно, вопрос. Что вы видите на этом графике?
Мо комментарий сегодня вечером или завтра днем.
#exercises
Комментарий по задаче про прокачку заклинаний.
В комментариях было много идей. Расскажу, на что я обратил внимание.
Есть всякая мелочь — ломаные линии на поздних уровнях, обычно это из-за небольшого количества пользователей. Синий спелл похож на имбу — сильно и быстро растет, надо смотреть, насколько он популярен у пользователей. Возможно, надо будет нерфить.
Но самое важное — то, что линия голубого спелла загибается и идет вниз на поздних уровнях. Выглядит странно, так как при нормальном ходе событий, когда пользователи прокачивают заклинания, линия должна быть монотонной / неубывающей.
Такое возможно, если у тех пользователей, кто играет на поздних уровнях, голубой спелл прокачан слабо / не прокачан. И тут вопрос, а что стало с теми, у кого этот спелл прокачан сильно? Вероятно, они отвалились или просто медленнее и тяжелее идут по уровням, потому что этот спелл оказался неэффективен, а ресурсы на его прокачку потрачены.
Дальше уже надо проверять эту гипотезу и разговаривать с геймдизайнерами и, может быть, делать это заклинание сильнее.
В комментариях было много идей. Расскажу, на что я обратил внимание.
Есть всякая мелочь — ломаные линии на поздних уровнях, обычно это из-за небольшого количества пользователей. Синий спелл похож на имбу — сильно и быстро растет, надо смотреть, насколько он популярен у пользователей. Возможно, надо будет нерфить.
Но самое важное — то, что линия голубого спелла загибается и идет вниз на поздних уровнях. Выглядит странно, так как при нормальном ходе событий, когда пользователи прокачивают заклинания, линия должна быть монотонной / неубывающей.
Такое возможно, если у тех пользователей, кто играет на поздних уровнях, голубой спелл прокачан слабо / не прокачан. И тут вопрос, а что стало с теми, у кого этот спелл прокачан сильно? Вероятно, они отвалились или просто медленнее и тяжелее идут по уровням, потому что этот спелл оказался неэффективен, а ресурсы на его прокачку потрачены.
Дальше уже надо проверять эту гипотезу и разговаривать с геймдизайнерами и, может быть, делать это заклинание сильнее.
Во вторник послушал стрим Ильи Красинского на канале Юры Борзило. Вот тут есть запись.
Говорили про конверсию и то, что обычно она не в фокусе продактов, про текучку продактов и деградацию со временем процессов и культуры в кампаниях, про аб-тесты конверсии. Когда пошел технический разговор про лендинги, iframes и прочие тонкости веб-аналитики, я отвалился. В последний раз я веб-аналитику трогал больше десяти лет назад, когда работал с сайтом Консультант+, и больше не хочу.
Не могу сказать, что для меня стрим был интересным. Разве что Красинского да байки из другого мира послушать. Но комментарии в чате были любопытные. Например, мне очень понравилась фраза: “АБ тесты не про проверку гипотез, а про защиту прода от ошибочных гипотез”. Хороший акцент, полезный.
Говорили про конверсию и то, что обычно она не в фокусе продактов, про текучку продактов и деградацию со временем процессов и культуры в кампаниях, про аб-тесты конверсии. Когда пошел технический разговор про лендинги, iframes и прочие тонкости веб-аналитики, я отвалился. В последний раз я веб-аналитику трогал больше десяти лет назад, когда работал с сайтом Консультант+, и больше не хочу.
Не могу сказать, что для меня стрим был интересным. Разве что Красинского да байки из другого мира послушать. Но комментарии в чате были любопытные. Например, мне очень понравилась фраза: “АБ тесты не про проверку гипотез, а про защиту прода от ошибочных гипотез”. Хороший акцент, полезный.
Смотрю на фичи недавнего релиза одного из новых проектов. Там, среди прочего, добавили квесты. Квесты традиционно считаются способом создания среднесрочных целей пользователя, поэтому ждали изменения в ретеншене 3-7 и далее дней.
Естественно, чтобы оценить влияние на рет, в идеальных условиях надо делать A/B-тест. В реальности же это потребует больших изменений в интерфейсе и экономике. В общем, новый билд. Конечно, можно выкладывать новый билд и открывать на половину аудитории, этакая “сплитовалка для бедных”, но мороки с этим тоже хватает. Не говоря уже о том, что прочие фичи релиза тоже делать надо.
В общем, я уже собрался искать похожих пользователей, кто завершал квесты и кто не завершал квесты, чтобы по ним сравнить удержание. Умные люди это вроде называют propensity score matching. А потом просто посмотрел ретеншен новой версии в сравнении с предыдущей. И не нашел каких-либо сильных отличий. Других фич на удержание не было, а мелкие колебания не так интересны.
Как итог — делать матчинг бессмысленно, квесты не работают, печаль и расстройство.
Естественно, чтобы оценить влияние на рет, в идеальных условиях надо делать A/B-тест. В реальности же это потребует больших изменений в интерфейсе и экономике. В общем, новый билд. Конечно, можно выкладывать новый билд и открывать на половину аудитории, этакая “сплитовалка для бедных”, но мороки с этим тоже хватает. Не говоря уже о том, что прочие фичи релиза тоже делать надо.
В общем, я уже собрался искать похожих пользователей, кто завершал квесты и кто не завершал квесты, чтобы по ним сравнить удержание. Умные люди это вроде называют propensity score matching. А потом просто посмотрел ретеншен новой версии в сравнении с предыдущей. И не нашел каких-либо сильных отличий. Других фич на удержание не было, а мелкие колебания не так интересны.
Как итог — делать матчинг бессмысленно, квесты не работают, печаль и расстройство.
Valve ищет психологов для проведения экспериментов/исследований.
В описании задач — создание новых геймплейных механик (я не знал, что у Valve есть свои игры), исследование пользователей Steam, изучение новых технологий железа, улучшение методов плейтестов и тому подобное. В требованиях — психологическое или рядом образование, знание экспериментальной психологии, статистики и языков программирования (such as C++, Python, SQL, and PHP). @coglebed го?
В общем, ничего не понятно, но очень интересно. Притом, кажется, это уже не первый раз, когда они ищут такого человека.
upd: я плохо знаю PC и консольные игры, простите %)
В описании задач — создание новых геймплейных механик (я не знал, что у Valve есть свои игры), исследование пользователей Steam, изучение новых технологий железа, улучшение методов плейтестов и тому подобное. В требованиях — психологическое или рядом образование, знание экспериментальной психологии, статистики и языков программирования (such as C++, Python, SQL, and PHP). @coglebed го?
В общем, ничего не понятно, но очень интересно. Притом, кажется, это уже не первый раз, когда они ищут такого человека.
upd: я плохо знаю PC и консольные игры, простите %)
Недавно мне предложили рассказать продактам одного стартапа что-нибудь интересное про поведение пользователей. И причем тут может быть продуктовая аналитика.
Вот, например, два схожих примера — в одном проекте продакты заметили, что пользователи с никнеймом платят больше. А в совершенно другом проекте — если пользователь прошел аутентификацию, то он больше платит. И им показалось логичным (sic!), что надо бы пользователей обязать создавать никнеймы / проходить аутентификацию.
Естественно, это не повысит платежи. Потому что тут есть латентный фактор, который мы не наблюдаем прямо, но можем предполагать — лояльность. Пользователь лоялен продукту и поэтому прошел аутентификацию / создал никнейм, это наблюдаемые маркеры лояльности. Пользователь лоялен и поэтому больше платит.
То есть мало увидеть связку никнейм ~ платежи, надо еще задуматься, что это не причинная связь, что может быть что-то еще. Что-то, что мы не наблюдаем, но что делает возможной эту взаимосвязь. И что это “что-то” лежит в области мотивации, эмоций и прочей личностной сферы пользователя.
И я не знаю, как этому научить.
Вот, например, два схожих примера — в одном проекте продакты заметили, что пользователи с никнеймом платят больше. А в совершенно другом проекте — если пользователь прошел аутентификацию, то он больше платит. И им показалось логичным (sic!), что надо бы пользователей обязать создавать никнеймы / проходить аутентификацию.
Естественно, это не повысит платежи. Потому что тут есть латентный фактор, который мы не наблюдаем прямо, но можем предполагать — лояльность. Пользователь лоялен продукту и поэтому прошел аутентификацию / создал никнейм, это наблюдаемые маркеры лояльности. Пользователь лоялен и поэтому больше платит.
То есть мало увидеть связку никнейм ~ платежи, надо еще задуматься, что это не причинная связь, что может быть что-то еще. Что-то, что мы не наблюдаем, но что делает возможной эту взаимосвязь. И что это “что-то” лежит в области мотивации, эмоций и прочей личностной сферы пользователя.
И я не знаю, как этому научить.
И еще один интересный отчет, теперь от GameAnalytics. Кажется, они решили возобновить свои ежегодные отчеты, чему я рад — последний подобный отчет от них я видел в 2018 году. Отчет посвящен бенчмаркам базовых метрик типа ретеншена, длины и количества сессий, плюс разбивка по регионам и жанрам. Жаль, что нет ничего про FTUE.
Мне интереснее всего ретеншен. И первое, что бросается в глаза — у топ25% Android-проектов D1 retention rate в 2023 году был на уровне 28-29%, к 2024 году сполз до 25%-27%. Медианные проекты вообще в районе 17-18% болтаются. К слову, жанр Action в этом смысле как раз вполне типовой, выше него согласно отчету казуальные игры, а ниже — адвентюры.
К отчету надо относиться с некоторой осторожностью — данные взяты по 11.5к+ игр в 16 жанрах, где интегрирован Game Analytics. То есть, выборка изначально несколько искажена. Например, я по знакомым проектам не слышал, чтобы кто-то их устанавливал, а пару раз вроде даже слышал отзывы, что аналитика в сервисе может привирать.
Тем не менее, бенчи тут ловить можно, пусть и с оговорками. Тренды — тем более. Ну и ответы на вечнозеленые вопросы вида “а как влияют Новый Год / Рождество / 1 сентября и школа” на метрики.
Мне интереснее всего ретеншен. И первое, что бросается в глаза — у топ25% Android-проектов D1 retention rate в 2023 году был на уровне 28-29%, к 2024 году сполз до 25%-27%. Медианные проекты вообще в районе 17-18% болтаются. К слову, жанр Action в этом смысле как раз вполне типовой, выше него согласно отчету казуальные игры, а ниже — адвентюры.
К отчету надо относиться с некоторой осторожностью — данные взяты по 11.5к+ игр в 16 жанрах, где интегрирован Game Analytics. То есть, выборка изначально несколько искажена. Например, я по знакомым проектам не слышал, чтобы кто-то их устанавливал, а пару раз вроде даже слышал отзывы, что аналитика в сервисе может привирать.
Тем не менее, бенчи тут ловить можно, пусть и с оговорками. Тренды — тем более. Ну и ответы на вечнозеленые вопросы вида “а как влияют Новый Год / Рождество / 1 сентября и школа” на метрики.
Прочитал недавно вышедшую “Как делать хорошие игры. От идеи до запуска” Петра Прохоренко, ветерана российского геймдева («Сталинград», «Блицкриг 3», «Танки Онлайн», «Days after» и т. д.)
Небольшая, очень практическая книжка, битком набитая как рекомендациями, так и просто примерами из опыта и байками. В девяти главах рассматривается путь от идеи игры, придумывания геймплея и препродакшена (Петр предлагает свою методологию) до сбора команды, управлениями проектом и пивотов. Есть даже история проекта Days After, как пример тезисов из прочих глав.
Мне понравилось. Несмотря на фразу “донатные помойки” на первых страницах и общую разговорную манеру текста. Отрезвляющие рекомендации типа “внимательно изучайте, во что хотят играть пользователи”, “не делайте игру на свои [последние] деньги”, “осторожнее с экспериментальным геймплеем” и тому подобное. Ну и в целом легализация пивотов, гемдизовских и менеджерских факапов и прочих случающихся вещей в нашей жизни. Вообще, книга местами правда похожа на разбор полетов, как автор и говорит в интервью App2Top.
По аналитике там практически ничего нет, но прочитать полезно для понимания специфики индустрии и развития эмпатии к продюсерам и их повседневному аду.
#books
Небольшая, очень практическая книжка, битком набитая как рекомендациями, так и просто примерами из опыта и байками. В девяти главах рассматривается путь от идеи игры, придумывания геймплея и препродакшена (Петр предлагает свою методологию) до сбора команды, управлениями проектом и пивотов. Есть даже история проекта Days After, как пример тезисов из прочих глав.
Мне понравилось. Несмотря на фразу “донатные помойки” на первых страницах и общую разговорную манеру текста. Отрезвляющие рекомендации типа “внимательно изучайте, во что хотят играть пользователи”, “не делайте игру на свои [последние] деньги”, “осторожнее с экспериментальным геймплеем” и тому подобное. Ну и в целом легализация пивотов, гемдизовских и менеджерских факапов и прочих случающихся вещей в нашей жизни. Вообще, книга местами правда похожа на разбор полетов, как автор и говорит в интервью App2Top.
По аналитике там практически ничего нет, но прочитать полезно для понимания специфики индустрии и развития эмпатии к продюсерам и их повседневному аду.
#books
Отпуск, конечно, затягивает, особенно если стараешься не открывать ноутбук. У моего папы был даже критерий хорошего отпуска — когда дату узнаешь по чекам в магазине. Но я не настолько преисполнился, к сожалению, поэтому иногда поглядываю в чаты да пытаюсь доделать долгострои.
Из интересных новостей. Друзья из ChillBase ищут миддла продуктового аналитика на проект One State (если нет доступа к чату — напишите мне в личку, пришлю копипаст).
А Сергей Матросов открывает набор на восьмой поток своего курса по А/Б-тестам. Мастхэв. Особенно если вы хотите хорошей глубокой статистики и современных подходов. Будет долго, насыщенно и сложно. Я вот в первый раз просто слушал, а теперь жалею, пересматриваю и иногда повторяю логику и вывод формул на бумаге.
Вернусь из отпуска, расскажу что-нибудь методологическое да техническое. А там, глядишь, и рубрика #onedaystory про один день из жизни аналитика дозреет.
Из интересных новостей. Друзья из ChillBase ищут миддла продуктового аналитика на проект One State (если нет доступа к чату — напишите мне в личку, пришлю копипаст).
А Сергей Матросов открывает набор на восьмой поток своего курса по А/Б-тестам. Мастхэв. Особенно если вы хотите хорошей глубокой статистики и современных подходов. Будет долго, насыщенно и сложно. Я вот в первый раз просто слушал, а теперь жалею, пересматриваю и иногда повторяю логику и вывод формул на бумаге.
Вернусь из отпуска, расскажу что-нибудь методологическое да техническое. А там, глядишь, и рубрика #onedaystory про один день из жизни аналитика дозреет.
Обещанные методологические размышления.
В одном из недавних релизов на одном из проектов мы выкатили новый контентый слой.
То есть добавили еще одну категорию контента / инструмент, который пользователь может использовать для победы. Например, раньше у него были заклинания и различные артефакты. Заклинания разных стихий наносят урон, артефакты модифицируют урон (коэффициенты на крит, на кулдаун, на урон и т.д.). А теперь мы добавили еще слой спутников героя, которые также могут наносить урон.
Анализировать это можно по-разному. Первый и самый простой уровень — есть ли изменение на графике платежей. По возможности — в тех категориях, которые связаны с этим контентным слоем (офферы, покупка харды и трата ее на сундуки и т. д.). В принципе, это должно быть видно на дашбордах.
Если усложнять, то дальше надо смотреть, используют ли этот контент — берут ли в бои, какая доля пользователей им пользуется и как быстро вся аудитория начинает пользоваться этим контентом. У нас, кстати, получилось так, что платящие не проявили особого интереса, а вот неплатящие как раз нагриндили валют и купили.
Можно смотреть еще ниже — как изменилось поведение пользователя в игре. Новый контентный слой предполагает, что где-то в игре будут источники, как можно получить и прокачать этот контент. Если мету делать емкой, то это будут отдельные ресурсы (условные шарды и/или валюты) и чтобы их получить, надо сходить в бои, открывать сундуки и т.д.
То есть, смотрим, увеличилось ли количество боев на пользователя, особенно того режима, который дает соответствующие валюты. Косвенно это еще и маркер, насколько контент оказался интересен пользователям.
Во-вторых, этот контентный слой должен помогать пользователю выигрывать. Поэтому смотрим, изменилась ли вероятность победы после покупки, какой вклад в общий урон дает этот контент, стало ли игроку легче играть.
И это еще хорошо, что в нашем варианте для прокачки нужна отдельная валюта, так как иначе надо смотреть, не произошло ли распределение трат валют от других категорий (каннибализации).
В общем, когда вводим новый слой контента, надо строить граф (или брать у гд картинку, если они ее нарисовали), каких игровых компонент этот слой касается и как меняет поведение пользователя. И исходя из этого строить стратегию анализа.
При оперировании, к слову, уже другой акцент — на использовании этого контента. У меня про это даже была где-то старая, еще времен GI, открытая лекция нашего лида. Надо будет поискать.
В одном из недавних релизов на одном из проектов мы выкатили новый контентый слой.
То есть добавили еще одну категорию контента / инструмент, который пользователь может использовать для победы. Например, раньше у него были заклинания и различные артефакты. Заклинания разных стихий наносят урон, артефакты модифицируют урон (коэффициенты на крит, на кулдаун, на урон и т.д.). А теперь мы добавили еще слой спутников героя, которые также могут наносить урон.
Анализировать это можно по-разному. Первый и самый простой уровень — есть ли изменение на графике платежей. По возможности — в тех категориях, которые связаны с этим контентным слоем (офферы, покупка харды и трата ее на сундуки и т. д.). В принципе, это должно быть видно на дашбордах.
Если усложнять, то дальше надо смотреть, используют ли этот контент — берут ли в бои, какая доля пользователей им пользуется и как быстро вся аудитория начинает пользоваться этим контентом. У нас, кстати, получилось так, что платящие не проявили особого интереса, а вот неплатящие как раз нагриндили валют и купили.
Можно смотреть еще ниже — как изменилось поведение пользователя в игре. Новый контентный слой предполагает, что где-то в игре будут источники, как можно получить и прокачать этот контент. Если мету делать емкой, то это будут отдельные ресурсы (условные шарды и/или валюты) и чтобы их получить, надо сходить в бои, открывать сундуки и т.д.
То есть, смотрим, увеличилось ли количество боев на пользователя, особенно того режима, который дает соответствующие валюты. Косвенно это еще и маркер, насколько контент оказался интересен пользователям.
Во-вторых, этот контентный слой должен помогать пользователю выигрывать. Поэтому смотрим, изменилась ли вероятность победы после покупки, какой вклад в общий урон дает этот контент, стало ли игроку легче играть.
И это еще хорошо, что в нашем варианте для прокачки нужна отдельная валюта, так как иначе надо смотреть, не произошло ли распределение трат валют от других категорий (каннибализации).
В общем, когда вводим новый слой контента, надо строить граф (или брать у гд картинку, если они ее нарисовали), каких игровых компонент этот слой касается и как меняет поведение пользователя. И исходя из этого строить стратегию анализа.
При оперировании, к слову, уже другой акцент — на использовании этого контента. У меня про это даже была где-то старая, еще времен GI, открытая лекция нашего лида. Надо будет поискать.
Весна в самом разгаре. Время тепла, время любви время конференции AHA!25. Это дружеского пиара пост, да.
Как обычно, два дня 29-30 мая, плюс онлайн-секция 22го мая. Программа еще в стадии формирования, однако основной набор докладов уже понятен.
Мне интереснее всего показались доклады по статистике — “Формула доверия: аналитические доверительные интервалы для ratio- и uplift-метрик” (Яндекс) и “SPRT + CUPAC. Максимально ускоряем эксперименты” (Kolesa group). К слову, в прошлом году от Kolesa group был интересный доклад про causal impact — видимо, там подобралась сильная стат. команда. Еще интересные для меня доклады — “Проксируй это: как использовать прокси-метрики умнее?” (X5 Tech) и “Как пересчитать в деньги эффект по любому изменению в продукте?” (Литрес).
Также есть пара любопытных секций, одна по нестандартным продуктовым задачам (например, геоданные в геозависимых бизнесах типа Я.Такси или поиск стильных атрибутов в Lamoda). Вторая — по поведенческой экономике. Правда, в ней ни одного анонса пока нет, только слоты. Даже интересно, что и кто там будет. Будет забавно, если Кючарев или кто-то из сберовской лабы.
В программе пока нет онлайн-секции, но это, думаю, временно. В программе также много LLM/AI (я б сказал, что это основной фокус конференции, судя по программе), а также организации экспериментов и в целом *Ops. Жаль, что практически ничего нет из behavioral studies про поведение пользователей, кроме пока пустой секции по поведенческой экономике.
Несмотря на то, что игровые аналитики на подобных конференциях обычно не бывают, на прошлой конференции удалось даже немного понетворкаться. С кем-то развиртуализировались (@smatrosov, @borzilo_y, @lena_astr, привет!), с кем-то просто встретились впервые за много лет.
В общем. Если есть возможность — сходите или посмотрите онлайн. Цена за оффлайн, конечно, кусается. Но организаторы любезно сделали промокод со скидкой в 10% для читателей моего канала: DICEANALYTICS10.
Как обычно, два дня 29-30 мая, плюс онлайн-секция 22го мая. Программа еще в стадии формирования, однако основной набор докладов уже понятен.
Мне интереснее всего показались доклады по статистике — “Формула доверия: аналитические доверительные интервалы для ratio- и uplift-метрик” (Яндекс) и “SPRT + CUPAC. Максимально ускоряем эксперименты” (Kolesa group). К слову, в прошлом году от Kolesa group был интересный доклад про causal impact — видимо, там подобралась сильная стат. команда. Еще интересные для меня доклады — “Проксируй это: как использовать прокси-метрики умнее?” (X5 Tech) и “Как пересчитать в деньги эффект по любому изменению в продукте?” (Литрес).
Также есть пара любопытных секций, одна по нестандартным продуктовым задачам (например, геоданные в геозависимых бизнесах типа Я.Такси или поиск стильных атрибутов в Lamoda). Вторая — по поведенческой экономике. Правда, в ней ни одного анонса пока нет, только слоты. Даже интересно, что и кто там будет. Будет забавно, если Кючарев или кто-то из сберовской лабы.
В программе пока нет онлайн-секции, но это, думаю, временно. В программе также много LLM/AI (я б сказал, что это основной фокус конференции, судя по программе), а также организации экспериментов и в целом *Ops. Жаль, что практически ничего нет из behavioral studies про поведение пользователей, кроме пока пустой секции по поведенческой экономике.
Несмотря на то, что игровые аналитики на подобных конференциях обычно не бывают, на прошлой конференции удалось даже немного понетворкаться. С кем-то развиртуализировались (@smatrosov, @borzilo_y, @lena_astr, привет!), с кем-то просто встретились впервые за много лет.
В общем. Если есть возможность — сходите или посмотрите онлайн. Цена за оффлайн, конечно, кусается. Но организаторы любезно сделали промокод со скидкой в 10% для читателей моего канала: DICEANALYTICS10.
Расскажу вам про одну рядовую задачу, которая возникла недавно.
Приходит ко мне наша прекрасная трафик-менеджер, которая работает с прототипами, и говорит: “мы вчера начали тестовую закупку, там десяток платящих, но у нас что-то данные в AppsFlyer не сходятся ни с внутренней, ни с внешней системами трекинга, ни с интерфейсами третьих сервисов, давай поисследуем”.
Решение простое — потранзакционное сличение и поиск потеряшек, благо идентификаторы транзакций везде есть. А вот результаты получились забавными.
Во-первых, читеры. Их оказалось достаточно просто вычислить — их идентификатор транзакции оказался совсем не похож на стандартный ios-овский идентификатор. Вопрос в том, как они вообще просочились — по идее, информация о платеже должна отправляться во все системы после того, как сервер погасит чек от стора и выдаст пользователю купленные ресурсы. Ребята срочно накатили хотфикс, который фильтрует и не отправляет информацию о платежах с такими индентификаторами. Но позже, видимо, придется системно решать валидацию платежей на стороне клиента, хотя это так себе решение.
Во-вторых, косяк в инфраструктуре. Платежи с тестовых девайсов попадали в общий поток платежей для AppsFlyer, но уходили на тестовый стенд в наших аналитических системах. Обычно на тестовые платежи можно не обращать внимания, пара десятков долларов погоды не делают, да и на других проектах не было таких проблем. Но на старте закупки они оказались заметными. Тоже, наверное, надо будет решать и встраивать механики маркировки тестовых платежей от AF.
Третий кейс вообще смешной. Пользователь сделал платеж. Сервер начислил ему ресурсы. А вот через шесть часов с клиента ушло еще одно сообщение в AF об этом же платеже. В результате два платежа с одним идентификатором. Наши системы отфильтровали дубль, AF — нет, да и не его это задача. Как это произошло — непонятно и скорее всего мы не будем ничего делать, если таких кейсов будет единицы.
Попутно было еще несколько нюансов, которые изрядно подпортили жизнь. Типа того что бд некоторых сервисов работает в локальной таймзоне (легаси, однако). А некоторые интерфейсы по умолчанию показывают не потоковые статистики за дату, а когортные.
В общем, как обычно, причина никогда не бывает одна. А дублирующие системы сбора данных — благо в большинстве случаев, но может вызвать головную боль, если их несколько.
Приходит ко мне наша прекрасная трафик-менеджер, которая работает с прототипами, и говорит: “мы вчера начали тестовую закупку, там десяток платящих, но у нас что-то данные в AppsFlyer не сходятся ни с внутренней, ни с внешней системами трекинга, ни с интерфейсами третьих сервисов, давай поисследуем”.
Решение простое — потранзакционное сличение и поиск потеряшек, благо идентификаторы транзакций везде есть. А вот результаты получились забавными.
Во-первых, читеры. Их оказалось достаточно просто вычислить — их идентификатор транзакции оказался совсем не похож на стандартный ios-овский идентификатор. Вопрос в том, как они вообще просочились — по идее, информация о платеже должна отправляться во все системы после того, как сервер погасит чек от стора и выдаст пользователю купленные ресурсы. Ребята срочно накатили хотфикс, который фильтрует и не отправляет информацию о платежах с такими индентификаторами. Но позже, видимо, придется системно решать валидацию платежей на стороне клиента, хотя это так себе решение.
Во-вторых, косяк в инфраструктуре. Платежи с тестовых девайсов попадали в общий поток платежей для AppsFlyer, но уходили на тестовый стенд в наших аналитических системах. Обычно на тестовые платежи можно не обращать внимания, пара десятков долларов погоды не делают, да и на других проектах не было таких проблем. Но на старте закупки они оказались заметными. Тоже, наверное, надо будет решать и встраивать механики маркировки тестовых платежей от AF.
Третий кейс вообще смешной. Пользователь сделал платеж. Сервер начислил ему ресурсы. А вот через шесть часов с клиента ушло еще одно сообщение в AF об этом же платеже. В результате два платежа с одним идентификатором. Наши системы отфильтровали дубль, AF — нет, да и не его это задача. Как это произошло — непонятно и скорее всего мы не будем ничего делать, если таких кейсов будет единицы.
Попутно было еще несколько нюансов, которые изрядно подпортили жизнь. Типа того что бд некоторых сервисов работает в локальной таймзоне (легаси, однако). А некоторые интерфейсы по умолчанию показывают не потоковые статистики за дату, а когортные.
В общем, как обычно, причина никогда не бывает одна. А дублирующие системы сбора данных — благо в большинстве случаев, но может вызвать головную боль, если их несколько.
Сложный кейс из недавнего исследования.
На графике — какая доля пользователей вернется на следующий день после регистрации, в зависимости от количества сделанных в день установки матчей.
Сравнение двух версий. Версии, помимо прочего, отличаются в дизайне первой сесии — в версии 0.3 туториальные матчи существенно короче, чем в предыдущей версии. Точнее, раньше туториальные матч были из трех-пяти раундов, теперь из одного-двух.
Собственно вопрос, что вы видите на графике и как вы это можете проинтерпретировать?
Мой комментарий через пару дней.
UPD: в комментарии положил распределение пользователей по группам
#exercises
На графике — какая доля пользователей вернется на следующий день после регистрации, в зависимости от количества сделанных в день установки матчей.
Сравнение двух версий. Версии, помимо прочего, отличаются в дизайне первой сесии — в версии 0.3 туториальные матчи существенно короче, чем в предыдущей версии. Точнее, раньше туториальные матч были из трех-пяти раундов, теперь из одного-двух.
Собственно вопрос, что вы видите на графике и как вы это можете проинтерпретировать?
Мой комментарий через пару дней.
UPD: в комментарии положил распределение пользователей по группам
#exercises
Комментрий по недавней задачке.
Кейс, к слову, получился не очень наглядный и интересный, но что уж. Постараюсь другие делать по-прозрачнее.
Во-первых, общие размышления. Я смотрю на рет1 в том числе и в разрезе по группам активности. Группы можно выделять как по абсолютным значениям (так гд обычно делают), так и по квартилям (наш лид недавно предложил такой вариант, пока тестируем). Это помогает понять, за счет какой аудитории изменилось удержание. Тут, к слову, нередко бывают забавы в духе парадокса Симпсона, когда ретеншен изменился за счет перераспределения аудитории по группам (когда какая-нибудь сильно выросла в численности, например). В этой ситуации тоже есть прирост в группе самых активных, но это только часть ответа.
Собственно, по картинке. Тут самое подозрительное, что ретеншен неактивных и малоактивных пользователей упал. А у самых активных — вырос. В норме, если изменения первой сессии оказались очень хороши, я бы ожидал системного роста удержания во всех группах.
Я склонен интерпретировать ситуацию следующим образом. Когда мы сделали туториал быстрее и короче (так как сделали меньше раундов в туториальных матчах), пользователи стали дальше проваливать по воронке боев, делать их больше. Но при этом все равно отваливаться. Таким образом мы просто сдвинули точку отвала и несколько обострили выбор. То есть, пользователи, которые раньше ждали конца первого матча туториала и потом отваливались, сейчас делают выбор намного раньше.
При этом у нас вырос рет у очень активных пользователей (и количество тоже). Для меня это выглядит так, будто нам удалось заинтересовать какую-то аудиторию, которая проскочила быстрый туториал и потом еще надолго задержалась в игре и вернулась на след.день.
В комментариях были предложения смотреть время сессии. Я, признаться, не люблю эту метрику, ее достаточно сложно корректно посчитать в мобилках. Но у нас есть что-то похожее — heartbeat, события, которые отправляются каждые X секунд (по аналогии с user_engagement из Firebase-трекинга). Правда, под рукой этого графика сейчас нет, а что там было в отчете, уже не помню, к сожалению.
#exercises
Кейс, к слову, получился не очень наглядный и интересный, но что уж. Постараюсь другие делать по-прозрачнее.
Во-первых, общие размышления. Я смотрю на рет1 в том числе и в разрезе по группам активности. Группы можно выделять как по абсолютным значениям (так гд обычно делают), так и по квартилям (наш лид недавно предложил такой вариант, пока тестируем). Это помогает понять, за счет какой аудитории изменилось удержание. Тут, к слову, нередко бывают забавы в духе парадокса Симпсона, когда ретеншен изменился за счет перераспределения аудитории по группам (когда какая-нибудь сильно выросла в численности, например). В этой ситуации тоже есть прирост в группе самых активных, но это только часть ответа.
Собственно, по картинке. Тут самое подозрительное, что ретеншен неактивных и малоактивных пользователей упал. А у самых активных — вырос. В норме, если изменения первой сессии оказались очень хороши, я бы ожидал системного роста удержания во всех группах.
Я склонен интерпретировать ситуацию следующим образом. Когда мы сделали туториал быстрее и короче (так как сделали меньше раундов в туториальных матчах), пользователи стали дальше проваливать по воронке боев, делать их больше. Но при этом все равно отваливаться. Таким образом мы просто сдвинули точку отвала и несколько обострили выбор. То есть, пользователи, которые раньше ждали конца первого матча туториала и потом отваливались, сейчас делают выбор намного раньше.
При этом у нас вырос рет у очень активных пользователей (и количество тоже). Для меня это выглядит так, будто нам удалось заинтересовать какую-то аудиторию, которая проскочила быстрый туториал и потом еще надолго задержалась в игре и вернулась на след.день.
В комментариях были предложения смотреть время сессии. Я, признаться, не люблю эту метрику, ее достаточно сложно корректно посчитать в мобилках. Но у нас есть что-то похожее — heartbeat, события, которые отправляются каждые X секунд (по аналогии с user_engagement из Firebase-трекинга). Правда, под рукой этого графика сейчас нет, а что там было в отчете, уже не помню, к сожалению.
#exercises
Команды прототипов -- это, конечно, особый мир, безжалостный и беспощадный. Вайпы прогресса, радикальные перешатывания меты (если продюсер будет нежен(а), то с миграцией), нерфы абилок и болезненные кривые сложности, зажимание в углах и лишение прототипной девственности, картинки и идеи, которые никогда не пойдут в прод, жестокосердность продюсеров..."Мы уже давно почту саппорта не читаем. Будет сильно ныть -- вообще забаним". Так и живем.
*по следам плейтеста пивота
*по следам плейтеста пивота