Даталорды интересно набросили, конечно.
Кто из нас без греха, кто не оценивал тренды на глазок?
Вообще, не люблю временные ряды.
(а за график с серой подложкой отдельное фи)
https://www.tgoop.com/analytics_kaanal/198
Кто из нас без греха, кто не оценивал тренды на глазок?
Вообще, не люблю временные ряды.
(а за график с серой подложкой отдельное фи)
https://www.tgoop.com/analytics_kaanal/198
Расскажу вам про одну не очень удачную идею.
Некоторое время назад мы на одном прототипе решили посмотреть, а как же играют и платят лояльные пользователи. Оределили лояльных как тех, кто играл 14 дней подряд и смотрели изменения в их активности — сколько боев в первую и вторую неделю, сколько платежей, соотношение недель и т. д. Ребята-геймдизы даже смотрели таймлайны некоторых игроков, чтобы попробовать реконструировать их опыт (редкий пример почти феноменологического анализа случаев). А то что за дела, играть-то играют, а платить перестают.
Идея была в том, что лояльные пользователи — ядро аудитории, лучше всех понимают игру, сильнее всех реагируют на изменения. Этакая фокусирующая призма, с помощью которой можно было бы увидеть сильную реакцию на какие-то изменения в мете и балансах. Оказалось же наоборот, они суперлояльны и играют несмотря ни на какие шатания меты. И, видимо, более чувствительны к изменениям будут те, кто заходит не столь регулярно.
Недавно я попробовал второй подход к снаряду — сравнивал проекты группы и в том числе решил посмотреть, как работают такие метрики как “доля лояльных в ретеншене” (из вернувшихся на седьмой день какая доля играла все семь дней) и связанный с ней “ретеншен лояльных” (какая доля всей когорты на X день от инсталла играет ровно X дней).
Работают не очень хорошо. У первой низкая дифференцирующая способность (совершенно банально — межквартильный размах не кратный, как в случае других метрик), то есть проекты с разной монетизацией слабо различаются по этой метрике. А вторая метрика очень сильно (намного сильнее, чем я ожидал) коррелирует с обычным ретеншеном и смысла ее отдельно считать и интерпретировать нет.
В общем, на данный момент я склонен признать, что я, скорее всего, просто не докрутил идею и метрики. Либо сам концепт “лояльности” не очень информативен для понимания поведения пользователей прототипов.
Некоторое время назад мы на одном прототипе решили посмотреть, а как же играют и платят лояльные пользователи. Оределили лояльных как тех, кто играл 14 дней подряд и смотрели изменения в их активности — сколько боев в первую и вторую неделю, сколько платежей, соотношение недель и т. д. Ребята-геймдизы даже смотрели таймлайны некоторых игроков, чтобы попробовать реконструировать их опыт (редкий пример почти феноменологического анализа случаев). А то что за дела, играть-то играют, а платить перестают.
Идея была в том, что лояльные пользователи — ядро аудитории, лучше всех понимают игру, сильнее всех реагируют на изменения. Этакая фокусирующая призма, с помощью которой можно было бы увидеть сильную реакцию на какие-то изменения в мете и балансах. Оказалось же наоборот, они суперлояльны и играют несмотря ни на какие шатания меты. И, видимо, более чувствительны к изменениям будут те, кто заходит не столь регулярно.
Недавно я попробовал второй подход к снаряду — сравнивал проекты группы и в том числе решил посмотреть, как работают такие метрики как “доля лояльных в ретеншене” (из вернувшихся на седьмой день какая доля играла все семь дней) и связанный с ней “ретеншен лояльных” (какая доля всей когорты на X день от инсталла играет ровно X дней).
Работают не очень хорошо. У первой низкая дифференцирующая способность (совершенно банально — межквартильный размах не кратный, как в случае других метрик), то есть проекты с разной монетизацией слабо различаются по этой метрике. А вторая метрика очень сильно (намного сильнее, чем я ожидал) коррелирует с обычным ретеншеном и смысла ее отдельно считать и интерпретировать нет.
В общем, на данный момент я склонен признать, что я, скорее всего, просто не докрутил идею и метрики. Либо сам концепт “лояльности” не очень информативен для понимания поведения пользователей прототипов.
Немного технического.
С точки зрения кода у меня очень примитивные задачи. Выгрузить данные, всячески их покрутить, порезать на слайсы, нарисовать. Статистика есть, конечно же, это важная часть майндсета и инструментария продуктовых аналитиков, но такие задачи не ежедневны. Основная сложность в моей работе — придумать гипотезу и понять, как ее можно проверить и/или что нужно для этого измерить.
В общем, для визуализации я использую plotly и у меня накопилось какое-то количество шаблонов и трюков. Я решил из них сделать шпаргалку для своей команды, заодно основной частью и с вами поделюсь.
Самое полезное для меня — сочетание ipywidgets и plotly. Позволяет быстро и не растягивая ноутбук на километры посмотреть сразу много метрик в разных разрезах. Коллеги, правда, смеются, говорят: “сделал себе дашборд/zeppelin в джупитере”. Да, я люблю странное.
Остальное — всякие выдранные из недр SO трюки по акцентированию внимания и внесению доп.информации на графики (вертикальные линии и подписи дат релизов, ховеры-тултипы). Ну и всякие способы навести красоту на графике, особенно если используются фасеты.
Полноценный интерактив в nbviewer / github не завезли, поэтому сделал пример в Google Colab. Да и там c оговорками — в частности, в режиме общего доступа не работают селекторы. Так что если хочется потыкать палочкой — скопируйте себе, датасеты должны быть открыты для всех.
Данные, естественно, синтетические и ничего общего с моими реальными проектами не имеют.
https://colab.research.google.com/drive/1JoSYxbBvjIKf8xNTHscyCARTbjHOqfOf#scrollTo=fe24c2f2-fc83-4a9d-af0e-a57519230419
С точки зрения кода у меня очень примитивные задачи. Выгрузить данные, всячески их покрутить, порезать на слайсы, нарисовать. Статистика есть, конечно же, это важная часть майндсета и инструментария продуктовых аналитиков, но такие задачи не ежедневны. Основная сложность в моей работе — придумать гипотезу и понять, как ее можно проверить и/или что нужно для этого измерить.
В общем, для визуализации я использую plotly и у меня накопилось какое-то количество шаблонов и трюков. Я решил из них сделать шпаргалку для своей команды, заодно основной частью и с вами поделюсь.
Самое полезное для меня — сочетание ipywidgets и plotly. Позволяет быстро и не растягивая ноутбук на километры посмотреть сразу много метрик в разных разрезах. Коллеги, правда, смеются, говорят: “сделал себе дашборд/zeppelin в джупитере”. Да, я люблю странное.
Остальное — всякие выдранные из недр SO трюки по акцентированию внимания и внесению доп.информации на графики (вертикальные линии и подписи дат релизов, ховеры-тултипы). Ну и всякие способы навести красоту на графике, особенно если используются фасеты.
Полноценный интерактив в nbviewer / github не завезли, поэтому сделал пример в Google Colab. Да и там c оговорками — в частности, в режиме общего доступа не работают селекторы. Так что если хочется потыкать палочкой — скопируйте себе, датасеты должны быть открыты для всех.
Данные, естественно, синтетические и ничего общего с моими реальными проектами не имеют.
https://colab.research.google.com/drive/1JoSYxbBvjIKf8xNTHscyCARTbjHOqfOf#scrollTo=fe24c2f2-fc83-4a9d-af0e-a57519230419
Один из моих первых лидов как-то посмотрел на мои графики и возопил “зачем так сложно”. У меня очень противоречивые воспоминания о нем, но конкретно в этом месте он был прав.
Ковырялся недавно с проектами группы, смотрел, можно ли их использовать как референсы для наших прототипов. Собрал кучу метрик (и поведенческие, и бизнесовые), на автомате покрутил-посмотрел, нарисовал боксы. Потом подумал, что боксы как-то ну совсем примитив, надо попробовать что-то посерьезнее. Окунулся в иерархический кластерный, немножко зацепил линейную регрессию и просто оценку на мультиколлинеарность (хорошо хоть до PCA не докатился). Кое-что забавное получилось, но не очень удобное для решаемой задачи.
В итоге у меня получился просто график в plotly, на котором фасетами десяток метрик и точками с пяток референсных проектов, на метрики которых нам интересно смотреть. Добавим метрики нашего прототипа и поймем, где мы относительно референсов. Это не основа для принятия решений, конечно же, но некоторая ориентация на местности.
В общем, не надо делать сложно, когда можно сделать просто. Достаточно интуитивная идея, но я постоянно про нее забываю и недооцениваю.
Ковырялся недавно с проектами группы, смотрел, можно ли их использовать как референсы для наших прототипов. Собрал кучу метрик (и поведенческие, и бизнесовые), на автомате покрутил-посмотрел, нарисовал боксы. Потом подумал, что боксы как-то ну совсем примитив, надо попробовать что-то посерьезнее. Окунулся в иерархический кластерный, немножко зацепил линейную регрессию и просто оценку на мультиколлинеарность (хорошо хоть до PCA не докатился). Кое-что забавное получилось, но не очень удобное для решаемой задачи.
В итоге у меня получился просто график в plotly, на котором фасетами десяток метрик и точками с пяток референсных проектов, на метрики которых нам интересно смотреть. Добавим метрики нашего прототипа и поймем, где мы относительно референсов. Это не основа для принятия решений, конечно же, но некоторая ориентация на местности.
В общем, не надо делать сложно, когда можно сделать просто. Достаточно интуитивная идея, но я постоянно про нее забываю и недооцениваю.
В продолжение предыдущего поста, раз уж возник запрос.
Графики, которые у меня получились для сравнения объектов. Первый график, на котором я показываю метрики референсных проектов, получился полезнее всего, так как при хорошем подборе метрик вполне себе видно основные проблемы проекта. И проседания метрик, и “профиль проекта” в виде совокупности метрик. Когда-то меня учили, что нельзя интрепретировать шкалы MMPI отдельно, только профилем, синдромом. Тут аналогично.
Второй график немного посложнее — это визуализация места нашего проекта в каком-то выбранном диапазоне значений. На самом деле совсем не факт, что я буду его использовать, так как есть вопросы к тому, как выбирать референсный диапазон значений.
Я это использовал для проектов, но так можно сравнивать любые множества объектов. Например, группы пользователей по активности и их метрики (активности, платежей и т. д.), и все это в сочетании с гд-балансами.
Данные, разумеется, искусственные (поэтому осмысленных профилей проектов тут нет). Прикладываю код, так как там есть ряд нетривиальных решений, особенно на втором графике, когда надо комбинировать пофасетно слои.
Графики, которые у меня получились для сравнения объектов. Первый график, на котором я показываю метрики референсных проектов, получился полезнее всего, так как при хорошем подборе метрик вполне себе видно основные проблемы проекта. И проседания метрик, и “профиль проекта” в виде совокупности метрик. Когда-то меня учили, что нельзя интрепретировать шкалы MMPI отдельно, только профилем, синдромом. Тут аналогично.
Второй график немного посложнее — это визуализация места нашего проекта в каком-то выбранном диапазоне значений. На самом деле совсем не факт, что я буду его использовать, так как есть вопросы к тому, как выбирать референсный диапазон значений.
Я это использовал для проектов, но так можно сравнивать любые множества объектов. Например, группы пользователей по активности и их метрики (активности, платежей и т. д.), и все это в сочетании с гд-балансами.
Данные, разумеется, искусственные (поэтому осмысленных профилей проектов тут нет). Прикладываю код, так как там есть ряд нетривиальных решений, особенно на втором графике, когда надо комбинировать пофасетно слои.
Наконец-то дочитал 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
Акадмический бэкграунд автора (магистратуры LSE и Беркли по математике, политологии и демографии) просматривается с самого начала. От методологии до кода на R, с кучей отступлений и инфомационных справок. В конце концов, когда еще в книге по аналитике прочитаешь про утилитаризм Бентама.
Книга состоит из пяти частей. Первая — методологическая. Вторая посвящена базовым статистическим методам (распределения, создание метрик, введение в A/B-тесты). Третья часть о предиктивных моделях (регрессии, деревья решений, SVM). Четвертая — о Casual inference методах (difference-in-difference, разрывный регрессионный дизайн, матчинг, аплифт-моделирование). Пятая часть про реализацию большей части методов на R.
Первая часть самая интересная и самая важная. В ней всего три главы. В первой главе проговаривается идея, что поведение пользователей сложное, у них разные мотивы, и мы никогда не обладаем всей полнотой информации. И для того, чтобы как-то начать предсказывать и менять пользователей, надо создать теорию, почему они ведут себя тем образом, который мы наблюдаем. Вторая глава как раз посвящена тому, как создавать подобные теории — какие критерии хорошей теории, как создавать метрики и формулировать гипотезы для проверки теории. И третья глава — как на основе теории менять поведение пользователей. Как понять, что мы действительно что-то изменили, как измерить. Даже предлагается несколько подходов, как обеспечивать изменения, в частности описывается Fogg Behavior Model.
Прочие части в целом неплохи, но какого-то уникального знания там меньше. Конечно, чувствуется политолого-демографический бэкграунд в описании casual inference подхода, да и в целом вся книга так или иначе фокусируется на этой парадигме (условно, “когда реальность очень неоднородна, квазиэксперименты лучше аб-тестов”). А код на R… приятно, что на R, но как и у многих академиков, как будто из 00-х, сильно отстал от реальности.
Из любопытного — в отличие от многих других книг по продуктовой аналитике, тут нет стандартного перечисления бизнес-метрик типа DAU или ARPU. Акцент сделан на поведении, концептуализации и измерении.
В общем, мне понравилось, несмотря на тяжеловесность текста. Я сам когда-то из академии и поэтому идея, что надо понять поведение пользователей и это будет ключом к изменению, мне понятна и очень близка.
#books
Что ж, с днем рождения меня. В поисках интересного опять зашел на Amazon (не делайте так!).
Мой улов и чтиво на ближайшее время. Первая — весьма старенькая книга, но с вполне симпатичным оглавлением. Вряд ли найду что-то новое, но интересны подходы и акценты.
Вторая книга — коллективная монография (каждая глава отдельного автора) на тему исследований пользовательского опыта в опросах, интервью и т. д. Выглядит достаточно подробно, надеюсь, что окажется чем-то типа 101-учебника, в котором затронуты основные темы.
Третья — дань моей любви к истории и социологии науки. Ну и к статистике. Насколько я помню, Найман с Фишером чуть ли не на ножах были, интересно почитать, как это было. А Леманн — мало того, что сам сделал вклад в непараметрические методы, так еще и непосредственный свидетель событий.
Мой улов и чтиво на ближайшее время. Первая — весьма старенькая книга, но с вполне симпатичным оглавлением. Вряд ли найду что-то новое, но интересны подходы и акценты.
Вторая книга — коллективная монография (каждая глава отдельного автора) на тему исследований пользовательского опыта в опросах, интервью и т. д. Выглядит достаточно подробно, надеюсь, что окажется чем-то типа 101-учебника, в котором затронуты основные темы.
Третья — дань моей любви к истории и социологии науки. Ну и к статистике. Насколько я помню, Найман с Фишером чуть ли не на ножах были, интересно почитать, как это было. А Леманн — мало того, что сам сделал вклад в непараметрические методы, так еще и непосредственный свидетель событий.
Что вы знаете о боли, что называется. У нас на одном проекте разработчик решил, что в параметр fps_95 надо писать не 95 перцентиль (как по доке), а значение, выше которого 95% значений FPS за бой. То есть, по сути, 5 перцентиль. Ему показалось, что так будет полезнее.
В общем, если у вас какая-то метрика показывают лютую дичь, иногда будет полезным уточнить, а как же именно она собирается. Особенно если это новая для вас команда и вы еще в процессе притирки.
В общем, если у вас какая-то метрика показывают лютую дичь, иногда будет полезным уточнить, а как же именно она собирается. Особенно если это новая для вас команда и вы еще в процессе притирки.
Алексей Никушин анонсировал предварительную программу Матемаркетинга’42. Программа большая и разнообразная. Приятно встречать знакомые имена в списке докладчиков (@borzilo_y и @smatrosov, вижу вас, вы крутые). На саму конференцию я вряд ли попаду, но любопытно, про что сообщество хочет говорить в настоящий момент.
Из первого дня для меня интереснее всего блок, который называется “A/B-тестирование". Хотя там не только и не столько тесты — еще и приоритизация гипотез, и causal inference, и продуктовая аналитика в discovery-этапе разработки продукта. А еще есть доклад про нерелевантные рекомендации в HH.ru, в котором докладчик обещает рассказать про ситуацию, когда “контентные признаки пользователя не всегда отражают поведение пользователя и наоборот”. Мне всегда интересно про наблюдаемое поведение и его интерпретацию с точки зрения продукта.
В тот же же день будут еще пять докладов на стыке ML и продуктовой аналитики. Доклады пока не анонсированы, но очень хочется глубоких и интересных кейсов. Параллельно с практическим ML будет еще секция “Аналитика реального финансового эффекта”. У меня от этого названия сначала были флешбеки отчетов для аудиторов. А потом я зацепился за фразу в одном из анонсов: “почему мы заработали столько сколько мы заработали”.
И это очень интересная тема, на самом деле, над которой мы сами очень много думаем в последнее время. Когда проект большой, в нем много точек и методов монетизации, много контентных слоев и т. д., хорошо сбалансировать это может быть очень сложно. Не говоря уже о том, чтобы уверенно контролировать. Сколько-то мы зарабатываем, но почему именно столько — вопрос открытый.
Темы второго дня менее интересные. DWH, дашборды, перформанс-маркетинг и импортозамещение. Из любопытного — визионерская секция с докладом Себранта, Дубынина и прочих. Вопрос только, это про тренды или про future studies.
В онлайн-секции (она будет в отдельный день) солянка разных докладов. A/Б-тесты, кейсы, кулстори и прочие how-to. При этом есть сразу несколько докладов про разметку событий, логи и документацию. Я к этой теме тоже питаю слабость, так как сам много занимают дизайном событий для логирования.
В общем, выглядит весьма симпатично и интересно.
Из первого дня для меня интереснее всего блок, который называется “A/B-тестирование". Хотя там не только и не столько тесты — еще и приоритизация гипотез, и causal inference, и продуктовая аналитика в discovery-этапе разработки продукта. А еще есть доклад про нерелевантные рекомендации в HH.ru, в котором докладчик обещает рассказать про ситуацию, когда “контентные признаки пользователя не всегда отражают поведение пользователя и наоборот”. Мне всегда интересно про наблюдаемое поведение и его интерпретацию с точки зрения продукта.
В тот же же день будут еще пять докладов на стыке ML и продуктовой аналитики. Доклады пока не анонсированы, но очень хочется глубоких и интересных кейсов. Параллельно с практическим ML будет еще секция “Аналитика реального финансового эффекта”. У меня от этого названия сначала были флешбеки отчетов для аудиторов. А потом я зацепился за фразу в одном из анонсов: “почему мы заработали столько сколько мы заработали”.
И это очень интересная тема, на самом деле, над которой мы сами очень много думаем в последнее время. Когда проект большой, в нем много точек и методов монетизации, много контентных слоев и т. д., хорошо сбалансировать это может быть очень сложно. Не говоря уже о том, чтобы уверенно контролировать. Сколько-то мы зарабатываем, но почему именно столько — вопрос открытый.
Темы второго дня менее интересные. DWH, дашборды, перформанс-маркетинг и импортозамещение. Из любопытного — визионерская секция с докладом Себранта, Дубынина и прочих. Вопрос только, это про тренды или про future studies.
В онлайн-секции (она будет в отдельный день) солянка разных докладов. A/Б-тесты, кейсы, кулстори и прочие how-to. При этом есть сразу несколько докладов про разметку событий, логи и документацию. Я к этой теме тоже питаю слабость, так как сам много занимают дизайном событий для логирования.
В общем, выглядит весьма симпатично и интересно.
У нас одна из команд прототипов пошла в отрыв и пилит жанрово непривычные нам проекты. И я вот сейчас сижу и пытаюсь задизайнить события для логирования. Когда игра — по сути картинка над табличкой балансов (как в фермах/ситибилдерах), или смесь механизмов дистрибуции контента, геймплея и прогрессии (как в шутерах), очень много можно описать статой результата боя и логами движений ресурсов.
Но когда мета примитивная и все лежит в коре… Так и хочется сказать “сложна, у меня лапки”. Потому что с одной стороны, много деталей и хочется все учесть. При этом не испугав разработчиков объемами логов. А с другой стороны — некоторые процессы, типа синергии предметов / эффектов непонятно ни как хорошо трекать, ни как анализировать.
Кто хочет развлечься — попробуйте описать, что надо логировать в Rush Royale / Clash Royale. В первую очередь, чтобы была возможность проверить гипотезы “есть доминирующие стратегии” или “контр-стратегии не работают”.
Но когда мета примитивная и все лежит в коре… Так и хочется сказать “сложна, у меня лапки”. Потому что с одной стороны, много деталей и хочется все учесть. При этом не испугав разработчиков объемами логов. А с другой стороны — некоторые процессы, типа синергии предметов / эффектов непонятно ни как хорошо трекать, ни как анализировать.
Кто хочет развлечься — попробуйте описать, что надо логировать в Rush Royale / Clash Royale. В первую очередь, чтобы была возможность проверить гипотезы “есть доминирующие стратегии” или “контр-стратегии не работают”.
Обсуждали вчера одну фичу. Маленький ежедневный ивент, в котором надо побеждать босса. Всего доступно четыре попытки (раунда), первая бесплатная, остальные три — платно. При победе за каждый раунд дается награда, финальной награды за использование всех четырех попыток нет.
Минут десять обсуждали блок с четырьмя чекбоксами, которые бы маркировали результат раунда (галочка при победе, крестик при поражении, пустой — если попыткой не воспользовался). Вопрос был в том, как его заполнять и как бы на нем показать, что только первая попытка бесплатно. И не сделать ли просто счетчик попыток.
На мой вопрос, зачем нам вообще этот чекбокс, выяснилось, что ребята хотят таким образом эксплуатировать желание завершать действие, чтобы незаполненные чекбоксы подталкивали покупать попытки и проходить их. Всякие сборки коллекций в баттлерах и не только работают по похожему принципу, к слову.
Идея любопытная, на самом деле — какая мотивация сильнее, сохранить деньги и потерять вероятную награду. Или заплатить, завершить коллекцию и с какой-то вероятностью получить награду за успешные попытки.
Прям классическая задача для А/Б-теста интерфейса. Одну группу сделать с чекбоксами (подталкиванием), другую — без чекбоксов, просто со счетчиком попыток. И потом посмотреть, будет ли прирост в платежах/тратах харды. Но делать сейчас такой тест мы, конечно же, не будем. И потому что гипотеза слабая (талеровские примеры подталкиваний вроде сильнее были), и потому что проще скопировать счетчик, который уже реализован в другом месте. И потому что это тюнинг одной маленькой точки трат валюты, а при оценке прототипов хочется сначала более крупные рычаги освоить и протестировать.
Минут десять обсуждали блок с четырьмя чекбоксами, которые бы маркировали результат раунда (галочка при победе, крестик при поражении, пустой — если попыткой не воспользовался). Вопрос был в том, как его заполнять и как бы на нем показать, что только первая попытка бесплатно. И не сделать ли просто счетчик попыток.
На мой вопрос, зачем нам вообще этот чекбокс, выяснилось, что ребята хотят таким образом эксплуатировать желание завершать действие, чтобы незаполненные чекбоксы подталкивали покупать попытки и проходить их. Всякие сборки коллекций в баттлерах и не только работают по похожему принципу, к слову.
Идея любопытная, на самом деле — какая мотивация сильнее, сохранить деньги и потерять вероятную награду. Или заплатить, завершить коллекцию и с какой-то вероятностью получить награду за успешные попытки.
Прям классическая задача для А/Б-теста интерфейса. Одну группу сделать с чекбоксами (подталкиванием), другую — без чекбоксов, просто со счетчиком попыток. И потом посмотреть, будет ли прирост в платежах/тратах харды. Но делать сейчас такой тест мы, конечно же, не будем. И потому что гипотеза слабая (талеровские примеры подталкиваний вроде сильнее были), и потому что проще скопировать счетчик, который уже реализован в другом месте. И потому что это тюнинг одной маленькой точки трат валюты, а при оценке прототипов хочется сначала более крупные рычаги освоить и протестировать.
Продюсер на ежемесячной презентации проектов цитирует Фуко, в алерты мониторинга качества данных коллега воткнул случайные ссылки на базу SCP Foundation, в оупенспейсе аналитиков сидит скелет Андрей (а вот кушетку кто-то умыкнул при переезде), в джире другой коллеги стоит таска "попробовать балканский специалитет в любомом кафе Белграда" (продуктовая аналитика бывает и такой, да).
Бытовые зарисовки и немного ностальгии по офисным временам.
Бытовые зарисовки и немного ностальгии по офисным временам.
Разработчики одного проекта второй день подряд тиранят нас вопросами про то, что мы будем делать, если вдруг найдутся пользователи, которые взломают сдк и начнут слать нам в аналитику какие-то мусорные логи. И вообще, как можно будет тогда доверять аналитике.
Лично мне эта проблема напоминает неуловимого Джо, который никому не нужен. Мне встречались и ботофермы, и эмуляторы, и начисления ресурсов на клиенте, коллеги рассказывали еще про сговоры с саппортами для начисления ресурсов из админки… но вот целенаправленный взлом и отправку мусорных событий в аналитику я не видел. И не представляю, зачем это может быть нужно пользователям. Особенно если учесть, что схему события надо еще как-то узнать.
Меж тем вопрос “как вы будете вычислять такое” сам по себе хорош. Обычно мы видим странности либо на графиках, либо во время исследований. Все-таки поведенческие данные достаточно многомерные, так или иначе одно игровое действие редко когда описывается только одним событием в аналитику. И всякие несуразности вполне себе ловятся на графиках или в исследованиях. Но вот автоматическую систему сложнее чем просто отклонения по количеству событий надо отдельно придумывать.
Другое дело, что продуктовая аналитика в целом достаточно терпима к некоторой неточности данных. И какие-нибудь корнер-кейсы (типа следующий бой по таймстампу начался раньше, чем завершился предыдущий), которые встречаются у долей процента пользователей можно просто проигнорировать, на поведенческие паттерны они обычно влияют незначительно.
Лично мне эта проблема напоминает неуловимого Джо, который никому не нужен. Мне встречались и ботофермы, и эмуляторы, и начисления ресурсов на клиенте, коллеги рассказывали еще про сговоры с саппортами для начисления ресурсов из админки… но вот целенаправленный взлом и отправку мусорных событий в аналитику я не видел. И не представляю, зачем это может быть нужно пользователям. Особенно если учесть, что схему события надо еще как-то узнать.
Меж тем вопрос “как вы будете вычислять такое” сам по себе хорош. Обычно мы видим странности либо на графиках, либо во время исследований. Все-таки поведенческие данные достаточно многомерные, так или иначе одно игровое действие редко когда описывается только одним событием в аналитику. И всякие несуразности вполне себе ловятся на графиках или в исследованиях. Но вот автоматическую систему сложнее чем просто отклонения по количеству событий надо отдельно придумывать.
Другое дело, что продуктовая аналитика в целом достаточно терпима к некоторой неточности данных. И какие-нибудь корнер-кейсы (типа следующий бой по таймстампу начался раньше, чем завершился предыдущий), которые встречаются у долей процента пользователей можно просто проигнорировать, на поведенческие паттерны они обычно влияют незначительно.
Пока читаю купленное да ковыряюсь в результатах недавнего релиза, присоединюсь к флешмобу аналитических каналов. Поэтому вот вам пост дружеского пиара.
Ребята из NEWHR проводят очередную волну своего исследования рынка аналитики, первая была в 2018 году, последняя — в 2023-м. Я каждый год с интересом и участвую в исследовании, и читаю результаты.
Я считаю, что это очень полезное мероприятие — повышает прозрачность рынка, да и в целом служит неплохим ориентиром для специалистов, что происходит вокруг. В опросе затрагиваются следующие темы:
- Зарплаты и их динамика (где деньги, Билли?)
- Рейтинг работодателей для аналитиков (в топе ли Яндекс и другие не очень хрупкие гипотезы, да).
- Где работают аналитики, как работают (удалёнка/офис), какие планы на трудоустройтво.
- Как меняется зона ответственности аналитиков и чем хотят заниматься аналитики (на мой взгляд, самое интересное).
- Как аналитики ищут работу и выбирают работодателя.
Если вы дата/продуктовый/BI/маркетинговый/веб-аналитик — потратьте, пожалуйста, немного своего драгоценного времени и пройдите опросник.
Результаты планируются в начале 2025 года, но с участниками обещают поделиться промежуточными результатами.
Ребята из NEWHR проводят очередную волну своего исследования рынка аналитики, первая была в 2018 году, последняя — в 2023-м. Я каждый год с интересом и участвую в исследовании, и читаю результаты.
Я считаю, что это очень полезное мероприятие — повышает прозрачность рынка, да и в целом служит неплохим ориентиром для специалистов, что происходит вокруг. В опросе затрагиваются следующие темы:
- Зарплаты и их динамика (где деньги, Билли?)
- Рейтинг работодателей для аналитиков (в топе ли Яндекс и другие не очень хрупкие гипотезы, да).
- Где работают аналитики, как работают (удалёнка/офис), какие планы на трудоустройтво.
- Как меняется зона ответственности аналитиков и чем хотят заниматься аналитики (на мой взгляд, самое интересное).
- Как аналитики ищут работу и выбирают работодателя.
Если вы дата/продуктовый/BI/маркетинговый/веб-аналитик — потратьте, пожалуйста, немного своего драгоценного времени и пройдите опросник.
Результаты планируются в начале 2025 года, но с участниками обещают поделиться промежуточными результатами.
Дочитал 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
Книга состоит из трех частей по три главы, из трех параграфов каждая. Первая небольшая часть про 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
Небольшая рабочая задачка. В игре у пользователя есть три основные возможности повысить свою мощность в бою. Прокачка тех или иных абилок и повышение общего уровня урона. Оба требуют для прокачки одну и ту же валюту (софту), плюс свои типы шардов. Цены разные, дефицит создан именно по софте.
Когда у пользователя доступны прокачки и одного, и второго способов, то на обоих висят помидорки-нотификации. Но так как оба требуют одну валюту, то в ситуации ограниченных ресурсов пользователь, выбрав прокачать один способ, автоматически лишается возможности прокачать второй, если он до этого был доступен.
Тут хочется на регулярной основе мониторить ситуации, когда пользователи имеют воможность что-то прокачать, но по каким-то причинам это не делают. Что качают, когда имеют возможность. Какие приоритеты у пользователей и как с прогрессом в игре (и стоимостью прокачки) они меняются.
Качественные исследования тут, конечно, подойдут, но мне нужны именно мониторинг, регулярность и простота проверки гипотез — релизы каждый месяц. Поэтому сижу, думаю, какими логами это можно обложить.
Когда у пользователя доступны прокачки и одного, и второго способов, то на обоих висят помидорки-нотификации. Но так как оба требуют одну валюту, то в ситуации ограниченных ресурсов пользователь, выбрав прокачать один способ, автоматически лишается возможности прокачать второй, если он до этого был доступен.
Тут хочется на регулярной основе мониторить ситуации, когда пользователи имеют воможность что-то прокачать, но по каким-то причинам это не делают. Что качают, когда имеют возможность. Какие приоритеты у пользователей и как с прогрессом в игре (и стоимостью прокачки) они меняются.
Качественные исследования тут, конечно, подойдут, но мне нужны именно мониторинг, регулярность и простота проверки гипотез — релизы каждый месяц. Поэтому сижу, думаю, какими логами это можно обложить.
Мда. Поймал вирусную пневмонию — и двух недель просто нет в памяти. И еще две-три уйдут на восстановление хоть какой-то приемлемой работоспособности. Не болейте, дурное это дело.
В общем, вот вам небольшой пост из черновиков.
В общем, вот вам небольшой пост из черновиков.
Ранее я уже говорил, что склонен эпизодически мудрить с решением задачи и делать сложно там, где можно было бы сделать проще. Однако бывают и обратные ситуации, в которых эпизодически меня упрекает лид. Когда я чрезмерно упрощаю решение.
Самый простой пример. Смотрим, сколько боев в день делает пользователь, смотрим в динамике от даты инсталла (т. е. сколько делает в день инсталла, сколько на след.день, сколько на седьмой день и далее). Метрика когортная, считаю по лафтайму, а не по количеству активных дней, но это непринципиально.
Считаю обычные средние (сколько боев / сколько зашло), вижу снижение. Вроде бы ничего особенного, достаточно типовая структура, можно детально не останавливаться
Однако потом посмотрел структуру аудитории — какая доля зашедших делает 0 боев, какая 1 - Q1, и квартилями Q2-3Q, Q3-Q4, дробность бинов тут тоже не столь принципиальна. И оказалось, что у нас очень сильно, прям непривычно сильно растет доля тех, кто вообще не делает бои, хотя в игру заходит. А вот доля тех, кто делает какое-то среднее количество, типа 1-6 боев — вполне стабильна.
То есть снижение среднего, которое я увидел, объясняется специфичным поведением одного сегмента. И я вполне мог пропустить этот момент, до этого мне средние казались весьма информативными.
Так что сейчас пытаюсь переформатировать свою оптику так, чтобы все вопросы, которые касаются аудитории, смотреть именно сегментами, не опускаясь до агрегатных статистик. Тоже крайность, конечно, но для формирования навыка самое то.
Самый простой пример. Смотрим, сколько боев в день делает пользователь, смотрим в динамике от даты инсталла (т. е. сколько делает в день инсталла, сколько на след.день, сколько на седьмой день и далее). Метрика когортная, считаю по лафтайму, а не по количеству активных дней, но это непринципиально.
Считаю обычные средние (сколько боев / сколько зашло), вижу снижение. Вроде бы ничего особенного, достаточно типовая структура, можно детально не останавливаться
Однако потом посмотрел структуру аудитории — какая доля зашедших делает 0 боев, какая 1 - Q1, и квартилями Q2-3Q, Q3-Q4, дробность бинов тут тоже не столь принципиальна. И оказалось, что у нас очень сильно, прям непривычно сильно растет доля тех, кто вообще не делает бои, хотя в игру заходит. А вот доля тех, кто делает какое-то среднее количество, типа 1-6 боев — вполне стабильна.
То есть снижение среднего, которое я увидел, объясняется специфичным поведением одного сегмента. И я вполне мог пропустить этот момент, до этого мне средние казались весьма информативными.
Так что сейчас пытаюсь переформатировать свою оптику так, чтобы все вопросы, которые касаются аудитории, смотреть именно сегментами, не опускаясь до агрегатных статистик. Тоже крайность, конечно, но для формирования навыка самое то.