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

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

И тут вопрос. Что лучше, высокая конверсия на маленьких/средних платежах. Или низкая конверсия, но с высоким средним чеком? Например, 10% конверсии в платящих и средний чек на $3. Или 0.6% и средний чек $50?

Правильного варианта, само собой, тут нет.

#exercises

Мои размышления по поводу недавней задачки. Рекомендую также почитать комментарии, там много хороших идей.

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

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

Низкая конверсия и высокие чеки значат, что большинство пользователей не готовы что-либо покупать в игре. А покупают только супер-киты — либо очень лояльные (хотя на прототипе это странно), либо для кого это незначительный платеж. Принцип “сможет ли шейх потратить в твоей игре $20к” все еще хорош для оценки емкости. Остальные игроки не видят достаточной ценности в покупке, не готовы вкладываться, так как чувствуют, что недостаточно вовлечены или же им и так хорошо играть. В f2p играх обычно китовая монетизация, но она хороша и нужна на длинном периоде, а не одномоментно. В данном случае это плохая ситуация — нам удалось зацепить только очень узкую аудиторию и даже возможно, что случайно. Масштабировать такую закупку может быть сложно, риски не поймать таких китов очень высокие.

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

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

#exercises

Пост дружеского пиара.

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

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

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

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

#links

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

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

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

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

#books

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

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

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

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

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

https://news.1rj.ru/str/analytics_kaanal/198

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

Некоторое время назад мы на одном прототипе решили посмотреть, а как же играют и платят лояльные пользователи. Оределили лояльных как тех, кто играл 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

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

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

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

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

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

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

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

Вторая книга — коллективная монография (каждая глава отдельного автора) на тему исследований пользовательского опыта в опросах, интервью и т. д. Выглядит достаточно подробно, надеюсь, что окажется чем-то типа 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. При этом есть сразу несколько докладов про разметку событий, логи и документацию. Я к этой теме тоже питаю слабость, так как сам много занимают дизайном событий для логирования.

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

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

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

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

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

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

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

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

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

Всем привет. Друзья из Lategame Studio (Krista) ищут аналитика. Чем опытнее, тем лучше. Но все знают, что сеньоров не существует, поэтому они готовы (святые люди!) рассмотреть и стажеров/джунов. Формальное описание позиции на миддла здесь.

Более приближенное к реальным задачам описание вот, цитирую:

Кто мы: Lategame Studio, у нас в разработке 2 проекта, один из них выходит в Soft Launch в конце этого года (мобильный тим баттлер в аниме стилистике, мобильный но с фокусом на кроссплатформу в дальнейшем). Второй проект ПК/мобайл/web, тоже кроссплатформа, но там пока аналитика не нужна, он на ранней стадии.

Ищем продуктового аналитика, который поможет нам с аналитикой нашего тим баттлера (сейчас, в основном, используем Firebase, Amplitude, AppMetrica). Нужно будет решать, какие ивенты собирать, проводить исследования, проектировать и обновлять дашборды с метриками для команды, делать отчеты, заниматься формированием и проверкой продуктовых гипотез, участвовать в разработке фичей, участвовать в развитии внутренней системы сбора, анализа, хранения данных, в дальнейшем - поиском точек роста проекта и лайвопсом. Нужно знать SQL (плюсом будет также R, Python), статистический анализ, теорвер, иметь понимание базовых метрик также иметь опыт работы с системами аналитики на уровне интеграции ивентов и работы с дашбордами.

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

Кто заинтересовался — откликайтесь на вакансию на HH или пишите напрямую прекрасной Юлии.

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

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

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

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

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

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

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

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

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

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

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

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