В последнее время постоянно убеждаюсь в необходимости разделять в исследованиях и при принятии решений экономику и монетизацию.
Экономика — это, условно, как организована игра, как мы побуждаем пользователя к платежу. Пользователи платят там, где мы ожидаем платеж и тратят валюту туда, куда мы планируем. Например, динамическая сложность уровней в match3, где мы ожидаем пики платежей в наиболее сложных уровнях. Или прокачка предметов. Приход-расход и накопления валют на руках, стоимость игровых сущностей, модели дистрибуции контента — все сюда.
Монетизация — как мы оптимизируем платежи пользователей (в идеале, на уже работающей экономике). Персональные офферы, скидки, акции и тому подобное. Чудеса лайвопса во всей своей красе. Когда-нибудь, надеюсь, сюда и трюки из поведенческой экономики воткнуть смогу.
Сложности начинаются тогда, когда одно подменяется другим. Дать скидку проще, чем спроектировать кривую сложности, да и эффект быстрее. Но хуже всего, когда приходиться шатать экономику и одновременно тестируется система офферов — оркестрировать это маятно, а в выводах, без дополнительного контроля, появляется пространство для спекуляций. У меня даже появляются крамольные мысли, что на прототипах/MVP выстраивать монетизацию как можно раньше — не так чтобы хорошая идея. Хотя я понимаю команды, которые так делают — в конце концов, это живые деньги и возможность тестировать маркетинговые каналы.
Если вы где-то видели хорошие определения, что такое игровая экономика/монетизация, или же просто знаете хорошие материалы про это — пришлите мне, пожалуйста.
Экономика — это, условно, как организована игра, как мы побуждаем пользователя к платежу. Пользователи платят там, где мы ожидаем платеж и тратят валюту туда, куда мы планируем. Например, динамическая сложность уровней в match3, где мы ожидаем пики платежей в наиболее сложных уровнях. Или прокачка предметов. Приход-расход и накопления валют на руках, стоимость игровых сущностей, модели дистрибуции контента — все сюда.
Монетизация — как мы оптимизируем платежи пользователей (в идеале, на уже работающей экономике). Персональные офферы, скидки, акции и тому подобное. Чудеса лайвопса во всей своей красе. Когда-нибудь, надеюсь, сюда и трюки из поведенческой экономики воткнуть смогу.
Сложности начинаются тогда, когда одно подменяется другим. Дать скидку проще, чем спроектировать кривую сложности, да и эффект быстрее. Но хуже всего, когда приходиться шатать экономику и одновременно тестируется система офферов — оркестрировать это маятно, а в выводах, без дополнительного контроля, появляется пространство для спекуляций. У меня даже появляются крамольные мысли, что на прототипах/MVP выстраивать монетизацию как можно раньше — не так чтобы хорошая идея. Хотя я понимаю команды, которые так делают — в конце концов, это живые деньги и возможность тестировать маркетинговые каналы.
Если вы где-то видели хорошие определения, что такое игровая экономика/монетизация, или же просто знаете хорошие материалы про это — пришлите мне, пожалуйста.
👍10
Мои прекрасные друзья из Lategame/Krista ищут себе опытного продуктового аналитика. Формальное описание вакансии здесь. Фуллтайм, удаленка.
Из нюансов. Студия молодая, но ребята достаточно давно в индустрии. Делают мидкор, сейчас он на стадии MVP и пришла пора его оценки (собственно, почему открыли вакансию). Аналитики нет никакой, совсем. И ребята не очень готовы к самописным решениям.
Поэтому аналитику надо будет не только циферки крутить, но и сделать так, чтобы они были -- выбрать стек, обосновать его, задизайнить события для логирования и т.д. Ну и весь набор задач и экспериментов на ранних этапах проекта.
В общем, если вы такой человек или знаете, кому это может быть интересно -- напишите мне, пожалуйста.
Из нюансов. Студия молодая, но ребята достаточно давно в индустрии. Делают мидкор, сейчас он на стадии MVP и пришла пора его оценки (собственно, почему открыли вакансию). Аналитики нет никакой, совсем. И ребята не очень готовы к самописным решениям.
Поэтому аналитику надо будет не только циферки крутить, но и сделать так, чтобы они были -- выбрать стек, обосновать его, задизайнить события для логирования и т.д. Ну и весь набор задач и экспериментов на ранних этапах проекта.
В общем, если вы такой человек или знаете, кому это может быть интересно -- напишите мне, пожалуйста.
❤4
Сижу, читаю ГДД по новой фиче — скоро релиз и разрабам нужен дизайн события логирования. В разделе “Аналитика” вижу запрос: “Как повлияла фича на дальнее удержание?”
В чем-то запрос понятный. Особенно часто он встречается на новых продуктах, когда прототип только-только обрастает привычным набором фич. К тому же относительно многих фич есть ожидания, которые могут быть на самом деле далеки от реальности (например, насколько нужны бои с друзьями в шутерах) и которые хорошо бы проверять.
С другой стороны — ответить на такой вопрос весьма непросто. A/B-тесты лучший и самый надежный вариант, конечно. Но тестировать вклад крупных фич в A/B-тестах бывает затруднительно — может не быть инструментов A/B-тестов, фичу может быть трудно выдать только части аудитории, банально может не хватать выборки и т. д.
В результате остаются только косвенные методы, близкие по духу casual inference идеям. В частности, взять (не)доживших до day X и сравнить их, насколько они различаются по использованию фичи. Попутно можно саму выборку кластеризовать на несколько близких по разным метриками групп (по метрикам активности, например) и сравнивать пользователей внутри кластеров. Одна проблема с таким методом: воспользовавшиеся фичой и не воспользовавшиеся — принципиально разные люди, с разным поведением и мотивами, и это стоит учитывать в выводах.
Еще один способ (и он сейчас мне кажется наиболее интересным, надо тестировать) — сравнить ретеншен фичи и общий ретеншен проекта, и скорость изменения обеих метрик. Условно, если пользователи каждый день пользуются фичой, но в целом проект показывает слабое удержание и скорость отвала от фичи меньше скорости отвала от проекта — вклад фичи не столь уж и большой. И наоборот.
P.S. спасибо коллегам из чатов аналитиков за обсуждение темы и интересные идеи.
В чем-то запрос понятный. Особенно часто он встречается на новых продуктах, когда прототип только-только обрастает привычным набором фич. К тому же относительно многих фич есть ожидания, которые могут быть на самом деле далеки от реальности (например, насколько нужны бои с друзьями в шутерах) и которые хорошо бы проверять.
С другой стороны — ответить на такой вопрос весьма непросто. A/B-тесты лучший и самый надежный вариант, конечно. Но тестировать вклад крупных фич в A/B-тестах бывает затруднительно — может не быть инструментов A/B-тестов, фичу может быть трудно выдать только части аудитории, банально может не хватать выборки и т. д.
В результате остаются только косвенные методы, близкие по духу casual inference идеям. В частности, взять (не)доживших до day X и сравнить их, насколько они различаются по использованию фичи. Попутно можно саму выборку кластеризовать на несколько близких по разным метриками групп (по метрикам активности, например) и сравнивать пользователей внутри кластеров. Одна проблема с таким методом: воспользовавшиеся фичой и не воспользовавшиеся — принципиально разные люди, с разным поведением и мотивами, и это стоит учитывать в выводах.
Еще один способ (и он сейчас мне кажется наиболее интересным, надо тестировать) — сравнить ретеншен фичи и общий ретеншен проекта, и скорость изменения обеих метрик. Условно, если пользователи каждый день пользуются фичой, но в целом проект показывает слабое удержание и скорость отвала от фичи меньше скорости отвала от проекта — вклад фичи не столь уж и большой. И наоборот.
P.S. спасибо коллегам из чатов аналитиков за обсуждение темы и интересные идеи.
👍4
Одна из моих любимых задач в работе аналитика — придумывать метрики, которые нам помогут понять, что происходит. В эти моменты психодиагност во мне просыпается и с любопытством осматривается.
И ладно если метрики относительно прозрачные, типа эффективности юнита в бою. Можно пробовать и смотреть разное — kills / spawn, damage / health, damage / time_in_battle, что угодно. Измерить просто, сравнить по ценности — тоже.
А иногда интересны такие вещи, на которые сидишь, смотришь и думаешь, как тот волче — “а как тебя операционализировать-то?”. Через какое наблюдаемое поведение мы можем делать вывод о том, что происходит с пользователем?
Например, есть представление, что “пользователям не нравится играть с ботами”. Это достаточно важный вопрос, так как от него зависит требования к матчмейкингу и наполнению боев людьми, к количеству стартовых боев с ботами и так далее.
Но как вот это “не нравится” измерять? Спрашивать бессмысленно, пользователи сами не знают, что происходит или будут конструировать объяснение. Тестировать A/B-тестами количество ботов можно, но это локальное и тактическое решение, да и не всегда возможное. Ко всему прочему, надо всегда учитывать, какие рычаги для изменения метрики у нас есть.
Поэтому приходится останавливаться на весьма бедных интерпретациях — “не нравится == не пошел в следующий бой”, “не нравится == вышел из боя в первые секунды” и тому подобных. Можно, конечно, начать с вопроса “почему не нравятся боты”, но это отдельное (в идеале качественное) исследование, на которое может не быть ресурсов или квалификации.
В результате разница между тем, что интересно продюсеру и тем, что может в моменте оценить аналитик на данных — очень существенная, а приращение знания от таких паллиативов — не так чтобы впечатляющее. Как я в последнее время думаю, такие метрики требуют длительных исследований и накопления знания о процессе, чтобы потом было проще его оценивать.
И ладно если метрики относительно прозрачные, типа эффективности юнита в бою. Можно пробовать и смотреть разное — kills / spawn, damage / health, damage / time_in_battle, что угодно. Измерить просто, сравнить по ценности — тоже.
А иногда интересны такие вещи, на которые сидишь, смотришь и думаешь, как тот волче — “а как тебя операционализировать-то?”. Через какое наблюдаемое поведение мы можем делать вывод о том, что происходит с пользователем?
Например, есть представление, что “пользователям не нравится играть с ботами”. Это достаточно важный вопрос, так как от него зависит требования к матчмейкингу и наполнению боев людьми, к количеству стартовых боев с ботами и так далее.
Но как вот это “не нравится” измерять? Спрашивать бессмысленно, пользователи сами не знают, что происходит или будут конструировать объяснение. Тестировать A/B-тестами количество ботов можно, но это локальное и тактическое решение, да и не всегда возможное. Ко всему прочему, надо всегда учитывать, какие рычаги для изменения метрики у нас есть.
Поэтому приходится останавливаться на весьма бедных интерпретациях — “не нравится == не пошел в следующий бой”, “не нравится == вышел из боя в первые секунды” и тому подобных. Можно, конечно, начать с вопроса “почему не нравятся боты”, но это отдельное (в идеале качественное) исследование, на которое может не быть ресурсов или квалификации.
В результате разница между тем, что интересно продюсеру и тем, что может в моменте оценить аналитик на данных — очень существенная, а приращение знания от таких паллиативов — не так чтобы впечатляющее. Как я в последнее время думаю, такие метрики требуют длительных исследований и накопления знания о процессе, чтобы потом было проще его оценивать.
🔥14👍5❤2
На волне осмысления матчмейкинга вспомнил один весьма симпатичный пример связи метрик, денег и некоторых технических решений.
Несколько лет назад в одном из проектов обсуждали, нужны ли боты на старте игры. Надо, не надо, сколько первых боев с ботами делать и так далее. Аргументы “против” понятные — ботов надо делать (мозги придумывать и все такое), боты могут не нравиться пользователям, тюнить ботов по сложности и человекоподобности — отдельное сомнительное развлечение, да и при полноценной заливке может быть достаточно пользователей для наполнения матчмейкинга людьми и т. д.
Аргументы “за” тоже понятные — ботами проще контролировать опыт в первых боях (чтобы пользователи выигрывали), к тому же в тестах прототипов мы не сможем добиться полного матчмейкинга, слишком мало пользователей. Да и какие-то наброски по ботам уже есть, скорее всего.
Но есть еще один аргумент “за”, о котором я, признаться, даже и не подумал тогда. Если мы делаем бои на всю аудиторию, сугубо pvp и без ботов, то это надо поднимать достаточное количество гейм-серверов. Но при ретеншене порядка 35-45% мы в первые несколько боев безвозвратно теряем больше половины игроков. Соответственно, зачем тратить деньги на геймы, если можно сделать ботов и пользователи будут играть с ними на клиенте первые бои?
Таким образом, понимание метрик ретеншена и игровой активности в первый день помогло принять решение по ботам, озадачить разрабов реализацией боев на клиенте и, по словам СТО, сократить расходы.
Несколько лет назад в одном из проектов обсуждали, нужны ли боты на старте игры. Надо, не надо, сколько первых боев с ботами делать и так далее. Аргументы “против” понятные — ботов надо делать (мозги придумывать и все такое), боты могут не нравиться пользователям, тюнить ботов по сложности и человекоподобности — отдельное сомнительное развлечение, да и при полноценной заливке может быть достаточно пользователей для наполнения матчмейкинга людьми и т. д.
Аргументы “за” тоже понятные — ботами проще контролировать опыт в первых боях (чтобы пользователи выигрывали), к тому же в тестах прототипов мы не сможем добиться полного матчмейкинга, слишком мало пользователей. Да и какие-то наброски по ботам уже есть, скорее всего.
Но есть еще один аргумент “за”, о котором я, признаться, даже и не подумал тогда. Если мы делаем бои на всю аудиторию, сугубо pvp и без ботов, то это надо поднимать достаточное количество гейм-серверов. Но при ретеншене порядка 35-45% мы в первые несколько боев безвозвратно теряем больше половины игроков. Соответственно, зачем тратить деньги на геймы, если можно сделать ботов и пользователи будут играть с ними на клиенте первые бои?
Таким образом, понимание метрик ретеншена и игровой активности в первый день помогло принять решение по ботам, озадачить разрабов реализацией боев на клиенте и, по словам СТО, сократить расходы.
🔥18👍7❤1
На одном из совместных проектов продюсер и топы второй студии активизировались и хотят еще аналитики и дашбордов.
А в аналитике хотят разного. Очень видно качественно иной подход — больше метрик вовлечения, больше акцент на отвалы, на боевые статистики, на ладдеры коммьюнити-ивентов и тому подобное. От некоторых запросов вообще накрывает флешбеками многолетней давности, когда сидишь, смотришь на сырую табличку по пользователям из d2d, и единственное, что можешь оттуда вытянуть — rolling retention. Эхо тех сумеречных эпох, когда хранили только последний стейт пользователя, а не все логины-логауты и промежуточные логи.
Несмотря на все мое ворчание, интересно посмотреть, как оно будет работать в оперировании (пока только закрытая бета). Мы много работаем с метриками монетизации и экономики, но вот тот же отток обычно смотрим с точки зрения “китам что-то не нравится”. Бездушные “донатные сосалки” (c) однако, а тут высокий и тонкий мир ПК-бояр со своей атмосферой.
В общем, столкновение с Другим всегда обогащает, если суметь пережить и переварить этот опыт. Но мозги скрипят, мир за пределами своей модели и привычных инструментов уже кажется странным.
А в аналитике хотят разного. Очень видно качественно иной подход — больше метрик вовлечения, больше акцент на отвалы, на боевые статистики, на ладдеры коммьюнити-ивентов и тому подобное. От некоторых запросов вообще накрывает флешбеками многолетней давности, когда сидишь, смотришь на сырую табличку по пользователям из d2d, и единственное, что можешь оттуда вытянуть — rolling retention. Эхо тех сумеречных эпох, когда хранили только последний стейт пользователя, а не все логины-логауты и промежуточные логи.
Несмотря на все мое ворчание, интересно посмотреть, как оно будет работать в оперировании (пока только закрытая бета). Мы много работаем с метриками монетизации и экономики, но вот тот же отток обычно смотрим с точки зрения “китам что-то не нравится”. Бездушные “донатные сосалки” (c) однако, а тут высокий и тонкий мир ПК-бояр со своей атмосферой.
В общем, столкновение с Другим всегда обогащает, если суметь пережить и переварить этот опыт. Но мозги скрипят, мир за пределами своей модели и привычных инструментов уже кажется странным.
❤8
Немного технических страданий (после пары недель плохого самочувствия все равно ничего более осмысленное сказать не получается). Некоторое время назад тихо-мирно тестировал скрипт для агрегации данных под дашборды. Краем глаза увидел вот такой варнинг:
То есть в следующей версии (а точнее уже в текущей, так как у меня локально стоит древняя) все выражения вида
Решение удивительное. Да, поиск строки менее затратен, чем поиск по паттерну. Но ищут чаще всего ведь именно регулярки и тонны кода уже написаны, не сомневаюсь. Самое противное во всем этом, что никакие алерты кричать не будут, сообщений об ошибках и упавших скриптов тоже не будет. Но и полезного действия происходить не будет. Потому что всего лишь поменяли значение по умолчанию уже существующего аргумента. Отлавливать такое — очень сложно. Даже когда append отменили, скрипты падали и все было прозрачно и понятно, хоть и неприятно.
А мы как раз недавно обновили Airflow, который потребовал новых панд.
Вообще, конечно, dependency hell — совсем не то, что хочется держать в голове, хоть и приходится. Мне бы на выручку посмотреть да группы посравнивать, а не думать, что и у кого отвалится, когда обновимся. Ну и панды сами по себе мерзкие, а тут еще такой подарочек, зачем.
FutureWarning: The default value of regex will change from True to False in a future version.То есть в следующей версии (а точнее уже в текущей, так как у меня локально стоит древняя) все выражения вида
pd.Series.str.replace(’[0-9]’, ‘’) перестанут работать. Потому что раньше паттерн [0-9] по умолчанию интерпретировался как regex, а сейчас — как строка.Решение удивительное. Да, поиск строки менее затратен, чем поиск по паттерну. Но ищут чаще всего ведь именно регулярки и тонны кода уже написаны, не сомневаюсь. Самое противное во всем этом, что никакие алерты кричать не будут, сообщений об ошибках и упавших скриптов тоже не будет. Но и полезного действия происходить не будет. Потому что всего лишь поменяли значение по умолчанию уже существующего аргумента. Отлавливать такое — очень сложно. Даже когда append отменили, скрипты падали и все было прозрачно и понятно, хоть и неприятно.
А мы как раз недавно обновили Airflow, который потребовал новых панд.
Вообще, конечно, dependency hell — совсем не то, что хочется держать в голове, хоть и приходится. Мне бы на выручку посмотреть да группы посравнивать, а не думать, что и у кого отвалится, когда обновимся. Ну и панды сами по себе мерзкие, а тут еще такой подарочек, зачем.
😢10❤4
Классическая эвристика в ситуациях, когда просела какая-то метрика — поиск сегмента, за счет которого произошла просадка. Например, перестали платить новые пользователи. Или почему-то перестали возвращаться старые киты.
С относительными когортными метриками (ретеншен, конверсия) ситуация немного сложнее. Изменение может лежать как в самом сегменте, так и в структуре сегментов. Например, мы знаем, что чем больше боев пользователь сделал в день инсталла, тем выше вероятность, что он вернется на следующий день (рет1). У нас есть определенная разметка пользователей на несколько сегментов в зависимости от того, сколько боев они делают.
И вот мы видим, что один сегмент просел. То есть после одного из изменений пользователи с таким количеством боев стали хуже возвращаться. Но не настолько хуже, чтобы объяснить общее снижение ретеншена. Оказалось, что еще часть просадки была обусловлена изменением структуры аудитории — пользователей с небольшим количеством боев (и, соответственно, с не очень высоким удержанием) стало существенно больше.
Почему так произошло (просел один сегмент и изменилась структура сегментов) — вопрос отдельного размышления и исследований. Это следующий шаг в понимании, почему изменилась метрика.
Намного более простой пример — когда закупили много пользователей из Китая (они традиционно хуже удерживаются) или начался фичер. То есть пришло большое количество некачественных и/или нерелевантных пользователей, которые и уронили ретеншен. Тут изменение просто в структуре.
В общем, доли, парадокс Симпсона и его вариации.
NB. Пример навеян недавними задачами, но все же во многом искусственный и упрощенный.
С относительными когортными метриками (ретеншен, конверсия) ситуация немного сложнее. Изменение может лежать как в самом сегменте, так и в структуре сегментов. Например, мы знаем, что чем больше боев пользователь сделал в день инсталла, тем выше вероятность, что он вернется на следующий день (рет1). У нас есть определенная разметка пользователей на несколько сегментов в зависимости от того, сколько боев они делают.
И вот мы видим, что один сегмент просел. То есть после одного из изменений пользователи с таким количеством боев стали хуже возвращаться. Но не настолько хуже, чтобы объяснить общее снижение ретеншена. Оказалось, что еще часть просадки была обусловлена изменением структуры аудитории — пользователей с небольшим количеством боев (и, соответственно, с не очень высоким удержанием) стало существенно больше.
Почему так произошло (просел один сегмент и изменилась структура сегментов) — вопрос отдельного размышления и исследований. Это следующий шаг в понимании, почему изменилась метрика.
Намного более простой пример — когда закупили много пользователей из Китая (они традиционно хуже удерживаются) или начался фичер. То есть пришло большое количество некачественных и/или нерелевантных пользователей, которые и уронили ретеншен. Тут изменение просто в структуре.
В общем, доли, парадокс Симпсона и его вариации.
NB. Пример навеян недавними задачами, но все же во многом искусственный и упрощенный.
👍5🔥1
Разбираюсь сейчас с ретеншеном платящих. И понял, что в один пост не уложусь, сначала надо сделать подводку. Так что сейчас про активность пользователей, а завтра — уже про платящих.
Одна из ключевых особенностей игр как продукта — нам важны не только платежи пользователей, что и как они покупают, но и их внутриигровая активность.
Так как игры это развлечение, то активность служит маркером, насколько игра интересна сама по себе, будут ли пользователи оставаться, сможем ли мы их монетизировать, в конце концов. Мы не знаем мотивацию пользователей играть, но через их активность и вовлечение можем оценить, насколько наша игра ее удовлетворяет.
В результате это выливается в большое количество специфичных метрик активности — воронка боев, количество боев в день, длина сессии, DAU сегментов по платежеспособности и т. д. Да и классические метрики типа ретеншена мы смотрим по всей когорте, а не только по когорте платящих (как это нередко бывает в e-коме и прочих функциональных продуктах).
В добавление к метрикам у нас появляется еще одно измерение в интерпретациях. Ретеншен первого дня обычно интерпретируем как интересность геймплея, ретеншен дальних дней — как интересность метагейма. Отвалы лояльной аудитории суперкитов могут служить маркерами, как им зашли последние изменения.И так далее.
Когда дело доходит до платежей, становится еще интереснее.
Одна из ключевых особенностей игр как продукта — нам важны не только платежи пользователей, что и как они покупают, но и их внутриигровая активность.
Так как игры это развлечение, то активность служит маркером, насколько игра интересна сама по себе, будут ли пользователи оставаться, сможем ли мы их монетизировать, в конце концов. Мы не знаем мотивацию пользователей играть, но через их активность и вовлечение можем оценить, насколько наша игра ее удовлетворяет.
В результате это выливается в большое количество специфичных метрик активности — воронка боев, количество боев в день, длина сессии, DAU сегментов по платежеспособности и т. д. Да и классические метрики типа ретеншена мы смотрим по всей когорте, а не только по когорте платящих (как это нередко бывает в e-коме и прочих функциональных продуктах).
В добавление к метрикам у нас появляется еще одно измерение в интерпретациях. Ретеншен первого дня обычно интерпретируем как интересность геймплея, ретеншен дальних дней — как интересность метагейма. Отвалы лояльной аудитории суперкитов могут служить маркерами, как им зашли последние изменения.И так далее.
Когда дело доходит до платежей, становится еще интереснее.
❤14👍6
Львиная доля задач на новых проектах касается вопроса “как бы нам повысить ARPU”. Мы тут смотрим на форму кумулятивной кривой, ищем точки перегиба и выхода на плато, и пытаемся понять, что происходит. Два ключевых инструмента для меня здесь — воронка платежей и ретеншен платящих. Конверсия в платящих тоже важна, но это отдельная тема.
Ретеншен платящих — тот же возврат пользователей в игру по дням от инсталла, только за 100% мы берем общее количество платящих, сделавших платеж в определенный период. Например, в день инсталла, или в за первые X дней, или за все наблюдаемое время когорты. Иногда можно просто посмотреть количество дней в игре после последнего платежа, с учетом окна лайфтайма сравниваемых когорт. Общая задача — проверить, а интересна ли игра этим пользователям. Если пользователи быстро отваливаются — одна история. Если платят мало (например, сделали платеж в первый день), но продолжают играть — совсем другая.
По воронке платежей (какая доля от сделавших первый платеж, делает второй, третий и т. д.) мы смотрим как раз, а готовы ли пользователи покупать что-то дальше. Тут я предпочитаю контролировать лояльность — брать только тех пользователей, кто активно играл какое-то время, и смотреть их воронку в этом периоде. Это нужно для того, чтобы как раз исключить ситуации, когда воронка обрывается из-за того, что пользователь ушел.
В конечном счете это сводится к проверке гипотез, пользователи не платят, потому что отвалились (даже платящим игра неинтересна). Тут изменение лежит в области геймплея, проработанности меты и так далее. Или пользователи не платят, потому что им нравится игра, но нет потребности или желания что-то еще покупать. И это уже про удовольствие и ожидания от платежа, про субъективную оценку “дорого/дешево” офферов и так далее.
Впрочем, одна явно локализованная причина плохих кривых cARPU — это редкость. Чаще всего мы имеем комбо, и надо выбрать то, что пробуем исправить в первую очередь, а потом оценить, как поменялось платежное поведение. Все переплетено, как это обычно у людей и бывает.
Ретеншен платящих — тот же возврат пользователей в игру по дням от инсталла, только за 100% мы берем общее количество платящих, сделавших платеж в определенный период. Например, в день инсталла, или в за первые X дней, или за все наблюдаемое время когорты. Иногда можно просто посмотреть количество дней в игре после последнего платежа, с учетом окна лайфтайма сравниваемых когорт. Общая задача — проверить, а интересна ли игра этим пользователям. Если пользователи быстро отваливаются — одна история. Если платят мало (например, сделали платеж в первый день), но продолжают играть — совсем другая.
По воронке платежей (какая доля от сделавших первый платеж, делает второй, третий и т. д.) мы смотрим как раз, а готовы ли пользователи покупать что-то дальше. Тут я предпочитаю контролировать лояльность — брать только тех пользователей, кто активно играл какое-то время, и смотреть их воронку в этом периоде. Это нужно для того, чтобы как раз исключить ситуации, когда воронка обрывается из-за того, что пользователь ушел.
В конечном счете это сводится к проверке гипотез, пользователи не платят, потому что отвалились (даже платящим игра неинтересна). Тут изменение лежит в области геймплея, проработанности меты и так далее. Или пользователи не платят, потому что им нравится игра, но нет потребности или желания что-то еще покупать. И это уже про удовольствие и ожидания от платежа, про субъективную оценку “дорого/дешево” офферов и так далее.
Впрочем, одна явно локализованная причина плохих кривых cARPU — это редкость. Чаще всего мы имеем комбо, и надо выбрать то, что пробуем исправить в первую очередь, а потом оценить, как поменялось платежное поведение. Все переплетено, как это обычно у людей и бывает.
👍8🔥1
Так как я работаю с новыми проектами, у меня много задач, которые касаются разных версий игры. Притом версии существенно разные, особенно с точки зрения экономики. Где-то одна модель дистрибуции контента, где-то другая. Где-то изменили скорость прогрессии пользователя. Где-то просто перешатали дефициты.
Для подобных сравнений я в последнее время повадился считать метрики второго порядка. То есть, не просто кривую кумулятивного ARPU рисовать (или воронку боев), но и кривую коэффициентов. Где коэффициент — это значение cARPU day X / cARPU day 0. Берем и все значения cARPU делим на значение в какой-то выбранный день (день инсталла, третий день, седьмой, что угодно).
Такая метрика позволяет нам понять, а изменили ли мы вообще что-то в экономике и платежах, поменяв пол-игры. У проектов в оперировании, когда модель экономики уже сформирована, подобные кривые от версии к версии очень похожи. А вот у новых проектов из вариативность как раз и служит одним из маркеров, получилось ли нам что-то изменить или нет.
Второе применение подобных коэффициентов — понять, в каком именно месте расходятся версии. Потому что нередко бывает так, что, например, основной отвал происходит на второй день, а потом он просто длится. Такое можно поймать либо воронке с долями от предыдущего шага, либо как раз коэффициентом изменения для каждого шага относительно первого.
Для подобных сравнений я в последнее время повадился считать метрики второго порядка. То есть, не просто кривую кумулятивного ARPU рисовать (или воронку боев), но и кривую коэффициентов. Где коэффициент — это значение cARPU day X / cARPU day 0. Берем и все значения cARPU делим на значение в какой-то выбранный день (день инсталла, третий день, седьмой, что угодно).
Такая метрика позволяет нам понять, а изменили ли мы вообще что-то в экономике и платежах, поменяв пол-игры. У проектов в оперировании, когда модель экономики уже сформирована, подобные кривые от версии к версии очень похожи. А вот у новых проектов из вариативность как раз и служит одним из маркеров, получилось ли нам что-то изменить или нет.
Второе применение подобных коэффициентов — понять, в каком именно месте расходятся версии. Потому что нередко бывает так, что, например, основной отвал происходит на второй день, а потом он просто длится. Такое можно поймать либо воронке с долями от предыдущего шага, либо как раз коэффициентом изменения для каждого шага относительно первого.
👍13❤1
Знали бы вы, как я не люблю ботов. Именно как продуктовую фичу. Вечно с ними какие-то проблемы. То они слишком слабые. То слишком сложные. То они не очень похожи на поведение людей. То у них меняется логика или сложность, или все вместе. То их слишком много и постоянно кажется, что пользователям они не нравятся. То приходится использовать всякие трюки типа “пользователь не может отставать больше чем в полтора раза от ботов”, как мы в гоночках делали.
Переход от экономики, построенной на контролируемых ботах к экономике игры, где пользователи играют преимущественно друг с другом — отдельная головная боль сродни кластерной. Геймдизов и продюсера в первую очередь, но и аналитикам тоже с лихвой хватает.
Но без ботов тоже нельзя — банально нет столько DAU и регистраций, чтобы на прототипах наполнить бои людьми. Да и с учетом больших отвалов пользователей в первый день, дешевле пользователя онбордить и первые бои делать с ботами, а уж потом только в полноценный pvp отправлять.
Так и живем.
Переход от экономики, построенной на контролируемых ботах к экономике игры, где пользователи играют преимущественно друг с другом — отдельная головная боль сродни кластерной. Геймдизов и продюсера в первую очередь, но и аналитикам тоже с лихвой хватает.
Но без ботов тоже нельзя — банально нет столько DAU и регистраций, чтобы на прототипах наполнить бои людьми. Да и с учетом больших отвалов пользователей в первый день, дешевле пользователя онбордить и первые бои делать с ботами, а уж потом только в полноценный pvp отправлять.
Так и живем.
👍12😁3
В малом чате аналитиков недавно обсуждали, как можно измерить, что “пользователю было интересно в бою”. Конечно, самый простой вариант — спросить пользователя явно, но это читерство. Впрочем, думаю, мы и до этого скоро дойдем.
Самый простой и надежный ответ на этот вопрос — “в данных нет ответа”, так как не все можно измерить и отследить в логах. Кажется, валидное утверждение. Как минимум оно позволяет быстро перейти к другим инструментам или гипотезам.
Тем не менее, я, как правоверный гештальтист, склонен считать, что неявные личные особенности или процессы видны в любом действии человека. Проекции и изоморфизм, все дела. Просто нам может быть сложно увидеть эти действия или же их корректно проинтерпретировать. Или дешевле будет как-то по-другому ответить на свой вопрос.
В общем, немного методологической ереси вам в ленту.
Самый простой и надежный ответ на этот вопрос — “в данных нет ответа”, так как не все можно измерить и отследить в логах. Кажется, валидное утверждение. Как минимум оно позволяет быстро перейти к другим инструментам или гипотезам.
Тем не менее, я, как правоверный гештальтист, склонен считать, что неявные личные особенности или процессы видны в любом действии человека. Проекции и изоморфизм, все дела. Просто нам может быть сложно увидеть эти действия или же их корректно проинтерпретировать. Или дешевле будет как-то по-другому ответить на свой вопрос.
В общем, немного методологической ереси вам в ленту.
👍2
Прекрасный Антон Марцен, автор канала Product Science ищет аналитиков себе в команду Яндекс.Музыки. Вакансия зело симпатичная, хоть сам откликайся.
По требованиям стек понятный — SQL, Python, хорошая статистика и хорошая продуктовая часть. Ну и вся обвязка Яндекса в комплекте, само собой — от черномагических внутренних инструментов до процессов и плюшек.
Мне вакансия показалась интересной тем, что это развлекательный продукт, но еще не геймдев. Как я понимаю, сейчас такое называют “фантех”. Соответственно, разнообразное поведение и мотивация пользователей, которое надо огрокать и конвертировать в повышение бизнес-метрик.
По требованиям стек понятный — SQL, Python, хорошая статистика и хорошая продуктовая часть. Ну и вся обвязка Яндекса в комплекте, само собой — от черномагических внутренних инструментов до процессов и плюшек.
Мне вакансия показалась интересной тем, что это развлекательный продукт, но еще не геймдев. Как я понимаю, сейчас такое называют “фантех”. Соответственно, разнообразное поведение и мотивация пользователей, которое надо огрокать и конвертировать в повышение бизнес-метрик.
🤩1
В последнее время на глаза попадалось несколько статьей про data design/modelling. Для меня интересная тема, так как я немалую часть времени занимаюсь проектированием системы логов на новых проектах — что логировать, как именно, как мы это будем использовать и т. д.
Тема сама по себе непростая, помнится, Никита Шустиков из Зепты меня как-то убеждал, что amplitude-like модель данных — лучшее, что может быть. А отдельные события, джойны и прочее — бессмысленный олдскул. Я же люблю воронки, обогащенные данные, рамочные события для ключевых компонент меты, много информации из конфигов, агрегаты на стороне проекта и прочее. В общем, есть о чем поговорить.
Но есть один момент, который критически важен в самом начале, на уровне роадмапа проекта. Я нередко сталкиваюсь с представлением разработчиков, что их задача — делать игру. А аналитика — это что-то дополнительное, что можно выбросить из роадмапа, что отвлекает от реальной работы, можно обойтись минимальными логами и так далее. В моем же мире, детальная аналитика — это не дополнительная, а обязательная часть любой фичи, и требует достаточно много времени разработчиков.
В конце концов, мы работаем с f2p, нам критически важно понимать, что пользователь делает, и относительно гибко менять его опыт. Точнее, можно сделать f2p-игру без глубокой аналитики и при редкой удаче она даже сможет что-то зарабатывать, но оптимизировать и растить выручку будет сложно.
#datamodel
Тема сама по себе непростая, помнится, Никита Шустиков из Зепты меня как-то убеждал, что amplitude-like модель данных — лучшее, что может быть. А отдельные события, джойны и прочее — бессмысленный олдскул. Я же люблю воронки, обогащенные данные, рамочные события для ключевых компонент меты, много информации из конфигов, агрегаты на стороне проекта и прочее. В общем, есть о чем поговорить.
Но есть один момент, который критически важен в самом начале, на уровне роадмапа проекта. Я нередко сталкиваюсь с представлением разработчиков, что их задача — делать игру. А аналитика — это что-то дополнительное, что можно выбросить из роадмапа, что отвлекает от реальной работы, можно обойтись минимальными логами и так далее. В моем же мире, детальная аналитика — это не дополнительная, а обязательная часть любой фичи, и требует достаточно много времени разработчиков.
В конце концов, мы работаем с f2p, нам критически важно понимать, что пользователь делает, и относительно гибко менять его опыт. Точнее, можно сделать f2p-игру без глубокой аналитики и при редкой удаче она даже сможет что-то зарабатывать, но оптимизировать и растить выручку будет сложно.
#datamodel
❤12
Любопытные новости, конечно. Особенно на фоне того, что несколько лет назад один из журналов по социальной психологии отказался принимать статьи с p-value и стал требовать только bayes factor.
Интересно, что привело гугл к такому решению. NHST, как ни крути, ведь тоже не идеал, да и на выборку весьма прожорлива.
Интересно, что привело гугл к такому решению. NHST, как ни крути, ведь тоже не идеал, да и на выборку весьма прожорлива.
Telegram
EXPF – математическая статистика и эксперименты
Свершилось невозможное. Google отказался от байесианства в пользу частотки
Это не совсем общая стратегическая позиция, но в Firebase это уже на продакшене. Не прошло и 100 лет (но 10 прошло), мы увидели у них p-value
https://firebase.google.com/docs/ab…
Это не совсем общая стратегическая позиция, но в Firebase это уже на продакшене. Не прошло и 100 лет (но 10 прошло), мы увидели у них p-value
https://firebase.google.com/docs/ab…
❤1👍1🔥1😱1
Несколько лет назад делал что-то вроде аудита для одной студии с проектом жанра choices / love story. Так как жанр для меня совершенно незнакомый, спросил “а что мы продаем пользователю”. Получил несколько обескураживающий своей буквальностью ответ “харду и новые главы”. Пришлось уточнять, что меня больше интересовало, какой опыт получает пользователь, что его, по представлениям команды, привлекает и удерживает.
Вообще, чем дальше, тем я больше думаю, насколько же важно при разработке новых проектов регулярно задавать себе этот вопрос. С одной стороны, кажется, что это гигиена уровня “а не делаю ли я фигню”. С другой — он помогает держать фокус на опыте пользователя, на его мотивации и том, как это реализовано.
Для аналитики это еще и важнейший источник гипотез и идей для исследования. Например, в шутерах можно продавать блестяшки (скины и прочую кастомизацию), мощность в виде нового контента и геймплей в виде, опять-таки, нового контента. Блестяшки особый вариант — в первую очередь это характерно для проектов с многомиллионным DAU или для весьма специфичных ниш. А вот мощность (power) или геймплей — это да. Если мы предполагаем, что продаем геймплей, то наши юниты, кем мы играем, должны ярко различаться по боевым статистикам, тактике и т. д. Если мы продаем мощность, то тут возникают вопросы волн актуальности контента, активности и эффективности его использования и т. д.
В результате, если возникает вопрос “как бы увеличить ARPU”, мы можем оценить, правда ли мы продаем то, что планировали. А то вдруг юниты не различаются по геймплею или мощность у всех одинаковая. И действительно ли покупают то, что мы планировали — можно ведь продавать геймплей, а пользователи хотят покупать мощность. Или мы предлагаем скины, а пользователям они неинтересны в чистом слабо социальном мобильном pvp.
Вообще, чем дальше, тем я больше думаю, насколько же важно при разработке новых проектов регулярно задавать себе этот вопрос. С одной стороны, кажется, что это гигиена уровня “а не делаю ли я фигню”. С другой — он помогает держать фокус на опыте пользователя, на его мотивации и том, как это реализовано.
Для аналитики это еще и важнейший источник гипотез и идей для исследования. Например, в шутерах можно продавать блестяшки (скины и прочую кастомизацию), мощность в виде нового контента и геймплей в виде, опять-таки, нового контента. Блестяшки особый вариант — в первую очередь это характерно для проектов с многомиллионным DAU или для весьма специфичных ниш. А вот мощность (power) или геймплей — это да. Если мы предполагаем, что продаем геймплей, то наши юниты, кем мы играем, должны ярко различаться по боевым статистикам, тактике и т. д. Если мы продаем мощность, то тут возникают вопросы волн актуальности контента, активности и эффективности его использования и т. д.
В результате, если возникает вопрос “как бы увеличить ARPU”, мы можем оценить, правда ли мы продаем то, что планировали. А то вдруг юниты не различаются по геймплею или мощность у всех одинаковая. И действительно ли покупают то, что мы планировали — можно ведь продавать геймплей, а пользователи хотят покупать мощность. Или мы предлагаем скины, а пользователям они неинтересны в чистом слабо социальном мобильном pvp.
❤12
Всем привет.
Мы ищем продуктовых аналитиков. Описание вакансии здесь.
Подробности в личке, на что смогу — отвечу.
Из нюансов:
- в приоритете middle+ / senior, так как есть куча задач, которые решать надо прямо сейчас
- мы не используем внешние системы аналитики, сугубо DIY глубокая аналитика. Поэтому хорошие SQL+Python прямо обязательно
- если вы не из геймдева -- напишите, попробуем
- рассматриваем только зарубежные локации
- работать не со мной и моими проектами, но мы будем в одной команде
Мы ищем продуктовых аналитиков. Описание вакансии здесь.
Подробности в личке, на что смогу — отвечу.
Из нюансов:
- в приоритете middle+ / senior, так как есть куча задач, которые решать надо прямо сейчас
- мы не используем внешние системы аналитики, сугубо DIY глубокая аналитика. Поэтому хорошие SQL+Python прямо обязательно
- если вы не из геймдева -- напишите, попробуем
- рассматриваем только зарубежные локации
- работать не со мной и моими проектами, но мы будем в одной команде
❤14
Посмотрел курс по продюсированию мобильных игр от Дмитрия Филатова (OwlCat, ex-MyGames/MGVC), автора канала DogDog. Курс выложен в открытый доступ, за что большое спасибо Дмитрию и Scream School.
Мне курс понравился. Кажется, он как раз закрывает недостающий кусочек — есть курсы по геймдизайну, по разработке или арту, да даже по аналитике кое-что есть. Но мало где говорится, как считать деньги команды, как оценивать перспективность игры, как мы вообще подходим к окупаемости, как декомпозировать задачи и выстраивать роадмап и т. д. “Вы пройдете полный цикл работы над идеей: от выбора и оценки до проработки и продажи ее бизнесу”.
Отдельно, конечно, было приятно услышать какие-то знакомые имена, близкие идеи и оценки — я с особым интересом слушал лекции по выбору жанра и по целям-этапам проекта до выхода в стадию оперирования.
При всем этом, я лично привык немного к другой роли продюсера. У Дмитрия сильный акцент сделан на организационно-финансовой части. Я же больше привык видеть другую сторону продюсеров — креативно-визионерскую. То есть я взаимодействую с продюсерами по поводу метагейма, экономики и в целом задачам вида “как повысить XXXX”. У Филатова в курсе эти компоненты оцениваются как менее значимые для работы продюсера. Даже на этапе прототипов, когда есть цели типа “нам нужен такой-то d1 retention”, роль продюсера в итеративном повышении метрики не особо раскрывается.
Возможно, это особенность студий, в которых я работал, и/или другой поход к развитию продукта. Или просто специфика именно этого курса.
#courses
Мне курс понравился. Кажется, он как раз закрывает недостающий кусочек — есть курсы по геймдизайну, по разработке или арту, да даже по аналитике кое-что есть. Но мало где говорится, как считать деньги команды, как оценивать перспективность игры, как мы вообще подходим к окупаемости, как декомпозировать задачи и выстраивать роадмап и т. д. “Вы пройдете полный цикл работы над идеей: от выбора и оценки до проработки и продажи ее бизнесу”.
Отдельно, конечно, было приятно услышать какие-то знакомые имена, близкие идеи и оценки — я с особым интересом слушал лекции по выбору жанра и по целям-этапам проекта до выхода в стадию оперирования.
При всем этом, я лично привык немного к другой роли продюсера. У Дмитрия сильный акцент сделан на организационно-финансовой части. Я же больше привык видеть другую сторону продюсеров — креативно-визионерскую. То есть я взаимодействую с продюсерами по поводу метагейма, экономики и в целом задачам вида “как повысить XXXX”. У Филатова в курсе эти компоненты оцениваются как менее значимые для работы продюсера. Даже на этапе прототипов, когда есть цели типа “нам нужен такой-то d1 retention”, роль продюсера в итеративном повышении метрики не особо раскрывается.
Возможно, это особенность студий, в которых я работал, и/или другой поход к развитию продукта. Или просто специфика именно этого курса.
#courses
❤10👍1
Последнее время иногда думаю про логирование событий (когда устаю думать “а почему XXX такое низкое”). Хочется как-то перейти от простого “вот это надо обложить аналитикой” к какому-то более абстрактному/концептуальному уровню. Чтобы можно было для любой игры относительно быстро и безболезненно сформировать модель данных, например.
Дело идет со скрипом, если честно. Постоянно кажется, что это какой-то велосипед и более умные люди (системные аналитики, архитекторы бд и прочие разработчики) все это уже давным давно сделали. Но каких-то внятных материалов на эту тему я так и не нашел. Может, плохо искал.
Пока дошел до выделения сущностей, их параметров и состояний, переходов в другие состояния, краешком затронул ресурсы и их виды. И это только самое начало — есть же еще всякие замороченные компоненты типа транзакций в движениях ресурсов или тапы/переходы в UI, платежи и их структура, в конце концов.
Но одно уже понятно сразу — очень много вкусовщины. Самый простой пример — квесты. Обычно для анализа квестов требуется как минимум два события — событие получение квеста и событие выполнения. Иногда могут быть дополнительные этапы, типа “квест выдан сервером”, “награда за этап квеста начислена сервером” и тому подобное.
Так вот, очень часто делают два события, на получение и на выполнение. Потом эти две таблички в бд можно спокойно джойнить и смотреть, какие квесты реже всего завершались. По моим наблюдениям, разработчики очень любят такой формат.
Я же предпочитаю не плодить множество событий и все логировать в рамках только одного, но с разным значением в поле статуса (started / finished / etc). То есть длинный формат таблиц и потом группировка по соответствующим полям.
И это тоже только маленькая часть айсберга дизайна логов. Нейминг, можно ли json-ы или лучше строкой с разделителями позиций, новая колонка или еще одно значение в json, длинный или широкий формат таблиц — в каждом из этих пунктов можно долго и упоенно ругаться. Мы так и делали на этапе создания нашей модели, кстати. Движение ресурсов, помнится, неделю обсуждали — от нас даже маркетинг шарахаться начал, а они ребята вроде стойкие да привычные.
#datamodel
Дело идет со скрипом, если честно. Постоянно кажется, что это какой-то велосипед и более умные люди (системные аналитики, архитекторы бд и прочие разработчики) все это уже давным давно сделали. Но каких-то внятных материалов на эту тему я так и не нашел. Может, плохо искал.
Пока дошел до выделения сущностей, их параметров и состояний, переходов в другие состояния, краешком затронул ресурсы и их виды. И это только самое начало — есть же еще всякие замороченные компоненты типа транзакций в движениях ресурсов или тапы/переходы в UI, платежи и их структура, в конце концов.
Но одно уже понятно сразу — очень много вкусовщины. Самый простой пример — квесты. Обычно для анализа квестов требуется как минимум два события — событие получение квеста и событие выполнения. Иногда могут быть дополнительные этапы, типа “квест выдан сервером”, “награда за этап квеста начислена сервером” и тому подобное.
Так вот, очень часто делают два события, на получение и на выполнение. Потом эти две таблички в бд можно спокойно джойнить и смотреть, какие квесты реже всего завершались. По моим наблюдениям, разработчики очень любят такой формат.
Я же предпочитаю не плодить множество событий и все логировать в рамках только одного, но с разным значением в поле статуса (started / finished / etc). То есть длинный формат таблиц и потом группировка по соответствующим полям.
И это тоже только маленькая часть айсберга дизайна логов. Нейминг, можно ли json-ы или лучше строкой с разделителями позиций, новая колонка или еще одно значение в json, длинный или широкий формат таблиц — в каждом из этих пунктов можно долго и упоенно ругаться. Мы так и делали на этапе создания нашей модели, кстати. Движение ресурсов, помнится, неделю обсуждали — от нас даже маркетинг шарахаться начал, а они ребята вроде стойкие да привычные.
#datamodel
❤9