аналитика на кубах टेलीग्राम पोस्ट

Что вы знаете о боли, что называется. У нас на одном проекте разработчик решил, что в параметр 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

В продолжение предыдущего поста, раз уж возник запрос.

Графики, которые у меня получились для сравнения объектов. Первый график, на котором я показываю метрики референсных проектов, получился полезнее всего, так как при хорошем подборе метрик вполне себе видно основные проблемы проекта. И проседания метрик, и “профиль проекта” в виде совокупности метрик. Когда-то меня учили, что нельзя интрепретировать шкалы MMPI отдельно, только профилем, синдромом. Тут аналогично.

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

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

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

Один из моих первых лидов как-то посмотрел на мои графики и возопил “зачем так сложно”. У меня очень противоречивые воспоминания о нем, но конкретно в этом месте он был прав.

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

В итоге у меня получился просто график в plotly, на котором фасетами десяток метрик и точками с пяток референсных проектов, на метрики которых нам интересно смотреть. Добавим метрики нашего прототипа и поймем, где мы относительно референсов. Это не основа для принятия решений, конечно же, но некоторая ориентация на местности.

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

Немного технического.

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

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

Самое полезное для меня — сочетание ipywidgets и plotly. Позволяет быстро и не растягивая ноутбук на километры посмотреть сразу много метрик в разных разрезах. Коллеги, правда, смеются, говорят: “сделал себе дашборд/zeppelin в джупитере”. Да, я люблю странное.

Остальное — всякие выдранные из недр SO трюки по акцентированию внимания и внесению доп.информации на графики (вертикальные линии и подписи дат релизов, ховеры-тултипы). Ну и всякие способы навести красоту на графике, особенно если используются фасеты.

Полноценный интерактив в nbviewer / github не завезли, поэтому сделал пример в Google Colab. Да и там c оговорками — в частности, в режиме общего доступа не работают селекторы. Так что если хочется потыкать палочкой — скопируйте себе, датасеты должны быть открыты для всех.

Данные, естественно, синтетические и ничего общего с моими реальными проектами не имеют.

https://colab.research.google.com/drive/1JoSYxbBvjIKf8xNTHscyCARTbjHOqfOf#scrollTo=fe24c2f2-fc83-4a9d-af0e-a57519230419

Расскажу вам про одну не очень удачную идею.

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

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

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

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

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

Даталорды интересно набросили, конечно.
Кто из нас без греха, кто не оценивал тренды на глазок?

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

https://t.me/analytics_kaanal/198

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

- а в Юнити есть инструменты из коробки простеньку физику воды посчитать? Не сталкивался?
Можно конечно погуглить и написать расчёт гидродинамики для, например, 10 вертексов, но может что-то готовое есть.
- Сталкивался. Навье-Стокса на GPU писал) Немного не то, да

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

Недавно попалась в руки небольшая книжка-брошюра Best Practices for In-Game Shop Design от Balancy про трюки и приемы для повышения эффективности внутриигрового магазина. Balancy — платформа для LiveOps (офферы, сегментация, ивенты), автор материалов — Михаил Хрипин, в прошлом проюдер Hero Wars в Nexters.

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

Взгляд аналитика, к сожалению, добавляет немного дегтя. Книжка называется “best practices”, но нет явного обоснования, почему эти рекомендации действительно работают. Аргументы уровня “так делают успешные проекты” вполне понятны, но для меня недостаточны.

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

#books