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

Смотрю на фичи недавнего релиза одного из новых проектов. Там, среди прочего, добавили квесты. Квесты традиционно считаются способом создания среднесрочных целей пользователя, поэтому ждали изменения в ретеншене 3-7 и далее дней.

Естественно, чтобы оценить влияние на рет, в идеальных условиях надо делать A/B-тест. В реальности же это потребует больших изменений в интерфейсе и экономике. В общем, новый билд. Конечно, можно выкладывать новый билд и открывать на половину аудитории, этакая “сплитовалка для бедных”, но мороки с этим тоже хватает. Не говоря уже о том, что прочие фичи релиза тоже делать надо.

В общем, я уже собрался искать похожих пользователей, кто завершал квесты и кто не завершал квесты, чтобы по ним сравнить удержание. Умные люди это вроде называют propensity score matching. А потом просто посмотрел ретеншен новой версии в сравнении с предыдущей. И не нашел каких-либо сильных отличий. Других фич на удержание не было, а мелкие колебания не так интересны.

Как итог — делать матчинг бессмысленно, квесты не работают, печаль и расстройство.

Во вторник послушал стрим Ильи Красинского на канале Юры Борзило. Вот тут есть запись.

Говорили про конверсию и то, что обычно она не в фокусе продактов, про текучку продактов и деградацию со временем процессов и культуры в кампаниях, про аб-тесты конверсии. Когда пошел технический разговор про лендинги, iframes и прочие тонкости веб-аналитики, я отвалился. В последний раз я веб-аналитику трогал больше десяти лет назад, когда работал с сайтом Консультант+, и больше не хочу.

Не могу сказать, что для меня стрим был интересным. Разве что Красинского да байки из другого мира послушать. Но комментарии в чате были любопытные. Например, мне очень понравилась фраза: “АБ тесты не про проверку гипотез, а про защиту прода от ошибочных гипотез”. Хороший акцент, полезный.

Комментарий по задаче про прокачку заклинаний.

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

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

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

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

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

Праздники закончились, надо возвращаться к работе.

Вот вам небольшая задачка, прям из рабочих дашбордов меты. На графике — прокачка двух спеллов по игровым уровням/этапам (уровни как в Homescapes или Archero).

По оси OX — номер уровня. По оси OY — средний уровень прокачки заклинания в мете у тех пользователей, кто играл на этом уровне/этапе.

Собственно, вопрос. Что вы видите на этом графике?

Мо комментарий сегодня вечером или завтра днем.

#exercises

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

Спасибо, что читаете и комментируете.

С новым годом вас.

Наконец-то дочитал-долистал 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

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

Самый простой пример. Смотрим, сколько боев в день делает пользователь, смотрим в динамике от даты инсталла (т. е. сколько делает в день инсталла, сколько на след.день, сколько на седьмой день и далее). Метрика когортная, считаю по лафтайму, а не по количеству активных дней, но это непринципиально.

Считаю обычные средние (сколько боев / сколько зашло), вижу снижение. Вроде бы ничего особенного, достаточно типовая структура, можно детально не останавливаться

Однако потом посмотрел структуру аудитории — какая доля зашедших делает 0 боев, какая 1 - Q1, и квартилями Q2-3Q, Q3-Q4, дробность бинов тут тоже не столь принципиальна. И оказалось, что у нас очень сильно, прям непривычно сильно растет доля тех, кто вообще не делает бои, хотя в игру заходит. А вот доля тех, кто делает какое-то среднее количество, типа 1-6 боев — вполне стабильна.

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

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

Мда. Поймал вирусную пневмонию — и двух недель просто нет в памяти. И еще две-три уйдут на восстановление хоть какой-то приемлемой работоспособности. Не болейте, дурное это дело.
В общем, вот вам небольшой пост из черновиков.

Небольшая рабочая задачка. В игре у пользователя есть три основные возможности повысить свою мощность в бою. Прокачка тех или иных абилок и повышение общего уровня урона. Оба требуют для прокачки одну и ту же валюту (софту), плюс свои типы шардов. Цены разные, дефицит создан именно по софте.

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

Тут хочется на регулярной основе мониторить ситуации, когда пользователи имеют воможность что-то прокачать, но по каким-то причинам это не делают. Что качают, когда имеют возможность. Какие приоритеты у пользователей и как с прогрессом в игре (и стоимостью прокачки) они меняются.

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

Дочитал Freemium Mobile Games: Design & Monetization by Dimitar Draganov. Судя по био на Амазоне, автор — спец по геймдизайну и монетизации, работал в Gameloft. Хотя в тексте очень часто ссылается на Clash of Clans, Candy Crash Saga и Game of War.

Книга состоит из трех частей по три главы, из трех параграфов каждая. Первая небольшая часть про f2p мобильные игры и что это вообще такое. Цифры и аргументы из 2013-14 годов, сейчас это читать уже просто скучно, достаточно посмотреть оценки объемов мобильного рынка в отчетах Newzoo или других сервисов.

Вторая часть больше геймдизайнерская и посвящена трем ключевым задачам и этапам жизни мобильной игры — "hook, habit, hobby” (HHH). То есть, этапы “зацепить пользователя”, “сформировать привычку” и “сделать игру частью повседневной жизни”. Весьма близкие мне идеи, на самом деле, всегда считал, что один из уровней оценки вовлечения — насколько игра рутинизирована, встроена в ежедневные рутины.

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

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

Однако несмотря на кажущуюся привычность идей и рецептов, попадались и неожиданные идеи. Одна из них — “metagame is never complex enough”. Под метагеймом тут понимается “the sum of optimal behaviors, including established strategies, exploits of game mechanics and even game bugs, that allow some players to dominate over other players in a game challenges”.

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

#books

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

Ребята из NEWHR проводят очередную волну своего исследования рынка аналитики, первая была в 2018 году, последняя — в 2023-м. Я каждый год с интересом и участвую в исследовании, и читаю результаты.

Я считаю, что это очень полезное мероприятие — повышает прозрачность рынка, да и в целом служит неплохим ориентиром для специалистов, что происходит вокруг. В опросе затрагиваются следующие темы:

- Зарплаты и их динамика (где деньги, Билли?)
- Рейтинг работодателей для аналитиков (в топе ли Яндекс и другие не очень хрупкие гипотезы, да).
- Где работают аналитики, как работают (удалёнка/офис), какие планы на трудоустройтво.
- Как меняется зона ответственности аналитиков и чем хотят заниматься аналитики (на мой взгляд, самое интересное).
- Как аналитики ищут работу и выбирают работодателя.

Если вы дата/продуктовый/BI/маркетинговый/веб-аналитик — потратьте, пожалуйста, немного своего драгоценного времени и пройдите опросник.

Результаты планируются в начале 2025 года, но с участниками обещают поделиться промежуточными результатами.

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

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

Меж тем вопрос “как вы будете вычислять такое” сам по себе хорош. Обычно мы видим странности либо на графиках, либо во время исследований. Все-таки поведенческие данные достаточно многомерные, так или иначе одно игровое действие редко когда описывается только одним событием в аналитику. И всякие несуразности вполне себе ловятся на графиках или в исследованиях. Но вот автоматическую систему сложнее чем просто отклонения по количеству событий надо отдельно придумывать.

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

Продюсер на ежемесячной презентации проектов цитирует Фуко, в алерты мониторинга качества данных коллега воткнул случайные ссылки на базу SCP Foundation, в оупенспейсе аналитиков сидит скелет Андрей (а вот кушетку кто-то умыкнул при переезде), в джире другой коллеги стоит таска "попробовать балканский специалитет в любомом кафе Белграда" (продуктовая аналитика бывает и такой, да).

Бытовые зарисовки и немного ностальгии по офисным временам.

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

Минут десять обсуждали блок с четырьмя чекбоксами, которые бы маркировали результат раунда (галочка при победе, крестик при поражении, пустой — если попыткой не воспользовался). Вопрос был в том, как его заполнять и как бы на нем показать, что только первая попытка бесплатно. И не сделать ли просто счетчик попыток.

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

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

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

У нас одна из команд прототипов пошла в отрыв и пилит жанрово непривычные нам проекты. И я вот сейчас сижу и пытаюсь задизайнить события для логирования. Когда игра — по сути картинка над табличкой балансов (как в фермах/ситибилдерах), или смесь механизмов дистрибуции контента, геймплея и прогрессии (как в шутерах), очень много можно описать статой результата боя и логами движений ресурсов.

Но когда мета примитивная и все лежит в коре… Так и хочется сказать “сложна, у меня лапки”. Потому что с одной стороны, много деталей и хочется все учесть. При этом не испугав разработчиков объемами логов. А с другой стороны — некоторые процессы, типа синергии предметов / эффектов непонятно ни как хорошо трекать, ни как анализировать.

Кто хочет развлечься — попробуйте описать, что надо логировать в Rush Royale / Clash Royale. В первую очередь, чтобы была возможность проверить гипотезы “есть доминирующие стратегии” или “контр-стратегии не работают”.

Алексей Никушин анонсировал предварительную программу Матемаркетинга’42. Программа большая и разнообразная. Приятно встречать знакомые имена в списке докладчиков (@borzilo_y и @smatrosov, вижу вас, вы крутые). На саму конференцию я вряд ли попаду, но любопытно, про что сообщество хочет говорить в настоящий момент.

Из первого дня для меня интереснее всего блок, который называется “A/B-тестирование". Хотя там не только и не столько тесты — еще и приоритизация гипотез, и causal inference, и продуктовая аналитика в discovery-этапе разработки продукта. А еще есть доклад про нерелевантные рекомендации в HH.ru, в котором докладчик обещает рассказать про ситуацию, когда “контентные признаки пользователя не всегда отражают поведение пользователя и наоборот”. Мне всегда интересно про наблюдаемое поведение и его интерпретацию с точки зрения продукта.

В тот же же день будут еще пять докладов на стыке ML и продуктовой аналитики. Доклады пока не анонсированы, но очень хочется глубоких и интересных кейсов. Параллельно с практическим ML будет еще секция “Аналитика реального финансового эффекта”. У меня от этого названия сначала были флешбеки отчетов для аудиторов. А потом я зацепился за фразу в одном из анонсов: “почему мы заработали столько сколько мы заработали”.

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

Темы второго дня менее интересные. DWH, дашборды, перформанс-маркетинг и импортозамещение. Из любопытного — визионерская секция с докладом Себранта, Дубынина и прочих. Вопрос только, это про тренды или про future studies.

В онлайн-секции (она будет в отдельный день) солянка разных докладов. A/Б-тесты, кейсы, кулстори и прочие how-to. При этом есть сразу несколько докладов про разметку событий, логи и документацию. Я к этой теме тоже питаю слабость, так как сам много занимают дизайном событий для логирования.

В общем, выглядит весьма симпатично и интересно.

Что вы знаете о боли, что называется. У нас на одном проекте разработчик решил, что в параметр fps_95 надо писать не 95 перцентиль (как по доке), а значение, выше которого 95% значений FPS за бой. То есть, по сути, 5 перцентиль. Ему показалось, что так будет полезнее.

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

Что ж, с днем рождения меня. В поисках интересного опять зашел на Amazon (не делайте так!).

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

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

Третья — дань моей любви к истории и социологии науки. Ну и к статистике. Насколько я помню, Найман с Фишером чуть ли не на ножах были, интересно почитать, как это было. А Леманн — мало того, что сам сделал вклад в непараметрические методы, так еще и непосредственный свидетель событий.

Наконец-то дочитал Product Analytics: Applied Data Science Techniques for Actionable Consumer Insights by Joanne Rodrigues. Много страниц, мелкий шрифт, очень плотный по содержанию текст.

Акадмический бэкграунд автора (магистратуры LSE и Беркли по математике, политологии и демографии) просматривается с самого начала. От методологии до кода на R, с кучей отступлений и инфомационных справок. В конце концов, когда еще в книге по аналитике прочитаешь про утилитаризм Бентама.

Книга состоит из пяти частей. Первая — методологическая. Вторая посвящена базовым статистическим методам (распределения, создание метрик, введение в A/B-тесты). Третья часть о предиктивных моделях (регрессии, деревья решений, SVM). Четвертая — о Casual inference методах (difference-in-difference, разрывный регрессионный дизайн, матчинг, аплифт-моделирование). Пятая часть про реализацию большей части методов на R.

Первая часть самая интересная и самая важная. В ней всего три главы. В первой главе проговаривается идея, что поведение пользователей сложное, у них разные мотивы, и мы никогда не обладаем всей полнотой информации. И для того, чтобы как-то начать предсказывать и менять пользователей, надо создать теорию, почему они ведут себя тем образом, который мы наблюдаем. Вторая глава как раз посвящена тому, как создавать подобные теории — какие критерии хорошей теории, как создавать метрики и формулировать гипотезы для проверки теории. И третья глава — как на основе теории менять поведение пользователей. Как понять, что мы действительно что-то изменили, как измерить. Даже предлагается несколько подходов, как обеспечивать изменения, в частности описывается Fogg Behavior Model.

Прочие части в целом неплохи, но какого-то уникального знания там меньше. Конечно, чувствуется политолого-демографический бэкграунд в описании casual inference подхода, да и в целом вся книга так или иначе фокусируется на этой парадигме (условно, “когда реальность очень неоднородна, квазиэксперименты лучше аб-тестов”). А код на R… приятно, что на R, но как и у многих академиков, как будто из 00-х, сильно отстал от реальности.

Из любопытного — в отличие от многих других книг по продуктовой аналитике, тут нет стандартного перечисления бизнес-метрик типа DAU или ARPU. Акцент сделан на поведении, концептуализации и измерении.

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

#books