Один мой знакомый продуктовый аналитик при каждой нашей встрече ворчит: “геймдев — это какая-то своя реальность”. В чем-то он прав, пожалуй. Своя атмосфера и в данных, и в фокусах анализа, и в подходе к интерпретации.
Вот небольшой пример. Изучаю факторы отвала на третий день — сравниваю, как играют те, кто отвалился раньше и те, кто все-таки вернулся. Интересно, чем различается игровой опыт этих групп пользователей, так как это как раз может быть причиной отвала.
Вижу, что у отвалившихся пользователей выше винрейт и KDA. Вопрос, можно ли утверждать (при прочих равных), что пользователям слишком легко играть, нет челленджа и они отваливаются?
Самый правильный ответ тут — недостаточно данных. Но в большинстве случаев вывод про отсутствие челленджа будет все же неверен. В данном случае от нас скрыта еще одна переменная — сколько боев сыграли те, кто отвалился и кто вернулся, и что это за бои. Обычно отвалившиеся пользователи играют в два-три раза менее активно, чем вернувшиеся. В этом и кроется ключевая ловушка — бои пользователей, особенно в самом начале, неодинаковы (для других жанров единицы будут другими, но смысл тот же). Самые первые бои обычно стараются делать легкими (беззубые и/или понерфленные боты и т. д.) и потом постепенно повышать сложность. Плюс пользователи растут по рейтингу и попадают в котлы к игрокам с более высоким рейтингом и, соответственно, опытом и прокачкой.
В результате пользователи, которые вернулись на третий день, скорее всего отыграли больше боев. И в этих боях они сталкивались уже с более сложными ботами и опытными игроками. Отвалившиеся пользователи ушли на легких боях, и поэтому у них winrate/KDA вполне может выше. Но это никак не говорит о том, что пользователи отвалились из-за того, что им легко и нет челленджа. Для проверки этой гипотезы надо брать тех, кто сыграл, например, ровно 10 боев, и смотреть метрики вернувшихся и отвалившихся по ним.
Собственно, вот эта неоднородность опыта пользователей, которая зависит от внутриигровой прогрессии — одна из ключевых особенностей игровых данных, влияющих на метрики и на подходы к анализу и выводу.
PS. сижу теперь и думаю — кажется, вполне неплохой кейс получился для задачника по продуктовой аналитике или для собесов
#exercises
Вот небольшой пример. Изучаю факторы отвала на третий день — сравниваю, как играют те, кто отвалился раньше и те, кто все-таки вернулся. Интересно, чем различается игровой опыт этих групп пользователей, так как это как раз может быть причиной отвала.
Вижу, что у отвалившихся пользователей выше винрейт и KDA. Вопрос, можно ли утверждать (при прочих равных), что пользователям слишком легко играть, нет челленджа и они отваливаются?
Самый правильный ответ тут — недостаточно данных. Но в большинстве случаев вывод про отсутствие челленджа будет все же неверен. В данном случае от нас скрыта еще одна переменная — сколько боев сыграли те, кто отвалился и кто вернулся, и что это за бои. Обычно отвалившиеся пользователи играют в два-три раза менее активно, чем вернувшиеся. В этом и кроется ключевая ловушка — бои пользователей, особенно в самом начале, неодинаковы (для других жанров единицы будут другими, но смысл тот же). Самые первые бои обычно стараются делать легкими (беззубые и/или понерфленные боты и т. д.) и потом постепенно повышать сложность. Плюс пользователи растут по рейтингу и попадают в котлы к игрокам с более высоким рейтингом и, соответственно, опытом и прокачкой.
В результате пользователи, которые вернулись на третий день, скорее всего отыграли больше боев. И в этих боях они сталкивались уже с более сложными ботами и опытными игроками. Отвалившиеся пользователи ушли на легких боях, и поэтому у них winrate/KDA вполне может выше. Но это никак не говорит о том, что пользователи отвалились из-за того, что им легко и нет челленджа. Для проверки этой гипотезы надо брать тех, кто сыграл, например, ровно 10 боев, и смотреть метрики вернувшихся и отвалившихся по ним.
Собственно, вот эта неоднородность опыта пользователей, которая зависит от внутриигровой прогрессии — одна из ключевых особенностей игровых данных, влияющих на метрики и на подходы к анализу и выводу.
PS. сижу теперь и думаю — кажется, вполне неплохой кейс получился для задачника по продуктовой аналитике или для собесов
#exercises
👍20👎1🔥1
Задачка по следам одного из неожиданных рабочих обсуждений.
У вас PC-проект, нужно построить график DAU с разбивкой по пользовательским группам, например по уровню (или лиге). Какие события будете использовать, как построите процесс подготовки данных для дашборда? Какие могут быть подводные камни?
Мое решение дам завтра или через день.
#exercises
У вас PC-проект, нужно построить график DAU с разбивкой по пользовательским группам, например по уровню (или лиге). Какие события будете использовать, как построите процесс подготовки данных для дашборда? Какие могут быть подводные камни?
Мое решение дам завтра или через день.
#exercises
😁3🔥2❤1
Комментарий по недавней задачке.
Обычно мы считаем в DAU количество пользователей, которые заходили в игру в определенный календарный день, день считается по UTC. Конечно, среди пользователей могут быть те, кто зашел и ничего не делал (не заходил в бой / не сделал корлуп), но это уже вторично.
На PC-проектах, в отличие от мобильных игр, сессия пользователя явно ограничена, так как есть событие логаута. Поэтому иногда на PC-проектах считают DAU по тем, кто залогинился в определенные сутки, и тем, кто сделал логаут (их логин был в предыдущие сутки). Или кто отыграл больше 50% сессии в новые сутки, а не просто логаут сделал. Собственно, именно это и было неожиданным для нас.
Помимо просто подсчета абсолютного количества логинов мы обычно испольузем еще какую-то дополнительную сегментацию пользователей — по уровню, по лиге, по количеству заплаченного, и т.д. Это полезно и для понимания стабильности аудитории, и для некоторых других расчетов, например среднего прихода/расхода игровых валют на пользователя в сегменте. В отличие от лайфтайма, тира стран или платформы это динамические параметры, которые могут меняться в течение дня. Поэтому мы берем то значение, которое было на момент логина пользователя.
Брать первые значения параметров достаточно очевидная идея, однако у нее есть свой минус — низкая чувствительность к тем, кто только-только начал играть. Так как пользователь за первый день может пройти N уровней, заплатить M денег и т.д. Но тут без компромиссов, видимо, не обойтись — нам важно видеть честное значение DAU (а не умножать количество пользователей на сегменты, в которых они побывали), и начало игры для нас менее важно, в отличие от более поздних периодов. Для молодых проектов, возможно, сегменты надо делать тоньше и/или старт анализировать отдельно.
В общем,учите, маги, санктуарий если дашборды на разных источниках не сходятся — возможно, дело не в данных.
#exercises
Обычно мы считаем в DAU количество пользователей, которые заходили в игру в определенный календарный день, день считается по UTC. Конечно, среди пользователей могут быть те, кто зашел и ничего не делал (не заходил в бой / не сделал корлуп), но это уже вторично.
На PC-проектах, в отличие от мобильных игр, сессия пользователя явно ограничена, так как есть событие логаута. Поэтому иногда на PC-проектах считают DAU по тем, кто залогинился в определенные сутки, и тем, кто сделал логаут (их логин был в предыдущие сутки). Или кто отыграл больше 50% сессии в новые сутки, а не просто логаут сделал. Собственно, именно это и было неожиданным для нас.
Помимо просто подсчета абсолютного количества логинов мы обычно испольузем еще какую-то дополнительную сегментацию пользователей — по уровню, по лиге, по количеству заплаченного, и т.д. Это полезно и для понимания стабильности аудитории, и для некоторых других расчетов, например среднего прихода/расхода игровых валют на пользователя в сегменте. В отличие от лайфтайма, тира стран или платформы это динамические параметры, которые могут меняться в течение дня. Поэтому мы берем то значение, которое было на момент логина пользователя.
Брать первые значения параметров достаточно очевидная идея, однако у нее есть свой минус — низкая чувствительность к тем, кто только-только начал играть. Так как пользователь за первый день может пройти N уровней, заплатить M денег и т.д. Но тут без компромиссов, видимо, не обойтись — нам важно видеть честное значение DAU (а не умножать количество пользователей на сегменты, в которых они побывали), и начало игры для нас менее важно, в отличие от более поздних периодов. Для молодых проектов, возможно, сегменты надо делать тоньше и/или старт анализировать отдельно.
В общем,
#exercises
👍9😢1
Всем привет!
Я Филипп Управителев и это мой канал по продуктовой аналитике в геймдеве.
Здесь я пишу о задачах и ситуациях, которые встречаются в моей работе, делюсь методологическими размышлениями. Эпизодически делаю обзоры учебных курсов и книг по аналитике, комментирую интересные посты. Также иногда даю практические задачки.
Посты для знакомства с каналом:
Фреймворки продуктовой аналитики
Продуктовое мышление игровых аналитиков (текст выступления с митапа)
Особенности монетизации на офферах
UX-исследования глазами аналитика
Ретеншен платящих
Метрики второго порядка
Основные тэги:
#courses — комментарии по курсам продуктовой аналитики
#books — про книги об аналитике и статистике
#exercises — задачки и кейсы
#links — что попалось хорошего в сети
#datamodel — про разметку данных, логирование и т. д.
Продуктовой аналитикой я занимаюсь больше десяти лет. У меня базовое психологическое образование, одновременно и экспериментально-академическое, и терапевтическое (гештальт). Какое-то время преподавал мат.методы в психологии, фрилансил, написал учебник по R. Был одним из админов в ODS, сейчас админю каналы по R и когнитивной психологии, веду курсы по анализу данных в ВШЭ. И вот я здесь.
Подписывайтесь на канал, комментируйте, рассказывайте коллегам. Приходите в личку просто пообщаться или с запросами на консультацию/менторство.
Рекламу на канале не делаю, но могу порекомендовать, если мы лично знакомы.
Я Филипп Управителев и это мой канал по продуктовой аналитике в геймдеве.
Здесь я пишу о задачах и ситуациях, которые встречаются в моей работе, делюсь методологическими размышлениями. Эпизодически делаю обзоры учебных курсов и книг по аналитике, комментирую интересные посты. Также иногда даю практические задачки.
Посты для знакомства с каналом:
Фреймворки продуктовой аналитики
Продуктовое мышление игровых аналитиков (текст выступления с митапа)
Особенности монетизации на офферах
UX-исследования глазами аналитика
Ретеншен платящих
Метрики второго порядка
Основные тэги:
#courses — комментарии по курсам продуктовой аналитики
#books — про книги об аналитике и статистике
#exercises — задачки и кейсы
#links — что попалось хорошего в сети
#datamodel — про разметку данных, логирование и т. д.
Продуктовой аналитикой я занимаюсь больше десяти лет. У меня базовое психологическое образование, одновременно и экспериментально-академическое, и терапевтическое (гештальт). Какое-то время преподавал мат.методы в психологии, фрилансил, написал учебник по R. Был одним из админов в ODS, сейчас админю каналы по R и когнитивной психологии, веду курсы по анализу данных в ВШЭ. И вот я здесь.
Подписывайтесь на канал, комментируйте, рассказывайте коллегам. Приходите в личку просто пообщаться или с запросами на консультацию/менторство.
Рекламу на канале не делаю, но могу порекомендовать, если мы лично знакомы.
🔥37👍8
Я не люблю задачки вида “ползут три черепашки”, но они все же встречаются, даже в отлаженных системах трекинга. И заставляют извращаться с всяким манипулированием данными.
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы трекинга платежей. В ней потерялись некоторые платежи. Надо найти и изучить потеряшек.
Из условий: есть только общий идентификатор пользователя и таймстампы транзакций в каждой выгрузке. Будем считать, что идентификаторов транзакций, SKU и прочих полезных данных нет. Данные выгружены в csv из разных баз, никакого SQL.
Для упрощения ситуации будем считать, что таймстампы одной транзакции в двух системах различаются незначительно (допустим, меньше 30 секунд). И что разница времени двух разных транзакций больше, чем разница во времени одной транзакции в двух системах. В реальности, конечно же, такие предположения еще нужно сделать и, по возможности, проверить.
Как будете решать такую задачку?
Я вижу два решения. Одно прям дубовое и прожорливое по ресурсам. Второе поизящнее и поэкономнее. И оба грязные. Впрочем, я вообще не уверен, что такие задачи можно чисто решать, честно говоря.
#exercises
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы трекинга платежей. В ней потерялись некоторые платежи. Надо найти и изучить потеряшек.
Из условий: есть только общий идентификатор пользователя и таймстампы транзакций в каждой выгрузке. Будем считать, что идентификаторов транзакций, SKU и прочих полезных данных нет. Данные выгружены в csv из разных баз, никакого SQL.
Для упрощения ситуации будем считать, что таймстампы одной транзакции в двух системах различаются незначительно (допустим, меньше 30 секунд). И что разница времени двух разных транзакций больше, чем разница во времени одной транзакции в двух системах. В реальности, конечно же, такие предположения еще нужно сделать и, по возможности, проверить.
Как будете решать такую задачку?
Я вижу два решения. Одно прям дубовое и прожорливое по ресурсам. Второе поизящнее и поэкономнее. И оба грязные. Впрочем, я вообще не уверен, что такие задачи можно чисто решать, честно говоря.
#exercises
❤1
Решение предыдущей задачки.
Первое решение, как я и говорил, дубовое и прожорливое. Основная идея — так как в pandas нет нечеткого джойна, делаем cross join, так, чтобы для каждой транзакции из консоли были все транзакции в нашей системе трекинга. Потом ищем дельту во времени между транзакциями и берем для каждой транзакции в сторе одну минимально близкую по времени в системе трекинга. Если такой нет (все транзакции в системе за пределами интервала [1, 30] секунд), то это транзакция и была потеряна.
Основная идея второго решения — выстроить все транзакции в один временной ряд, так как ожидаем, что пользователи делают платежи с большим интервалом, чем наша разница между двумя системами. И если после транзакции в консоли не было транзакции в нашей системе — то вот она, наша потерянная транзация.
Оба решения грязные. Первое опирается на предположения о порогах и размножает платежи, c этим нужно быть аккуратными. Второе просто полагается на допущения о соотношений систем трекинга. На моем рабочем датасете первое решение еще и меньше потеряшек нашло. Но на безрыбье и панды — фреймворк для работы с данными, что уж, для общего понимания ситуации и анализа паттернов, кто потерялся, вполне подойдет.
Код можно посмотреть здесь.
UPD: в пандах таки есть merge_asof. Видимо, статья на SO была совсем древней, а я не посмотрел на ее дату :(
#exercises
Первое решение, как я и говорил, дубовое и прожорливое. Основная идея — так как в pandas нет нечеткого джойна, делаем cross join, так, чтобы для каждой транзакции из консоли были все транзакции в нашей системе трекинга. Потом ищем дельту во времени между транзакциями и берем для каждой транзакции в сторе одну минимально близкую по времени в системе трекинга. Если такой нет (все транзакции в системе за пределами интервала [1, 30] секунд), то это транзакция и была потеряна.
Основная идея второго решения — выстроить все транзакции в один временной ряд, так как ожидаем, что пользователи делают платежи с большим интервалом, чем наша разница между двумя системами. И если после транзакции в консоли не было транзакции в нашей системе — то вот она, наша потерянная транзация.
Оба решения грязные. Первое опирается на предположения о порогах и размножает платежи, c этим нужно быть аккуратными. Второе просто полагается на допущения о соотношений систем трекинга. На моем рабочем датасете первое решение еще и меньше потеряшек нашло. Но на безрыбье и панды — фреймворк для работы с данными, что уж, для общего понимания ситуации и анализа паттернов, кто потерялся, вполне подойдет.
Код можно посмотреть здесь.
UPD: в пандах таки есть merge_asof. Видимо, статья на SO была совсем древней, а я не посмотрел на ее дату :(
#exercises
Telegram
аналитика на кубах
Я не люблю задачки вида “ползут три черепашки”, но они все же встречаются, даже в отлаженных системах трекинга. И заставляют извращаться с всяким манипулированием данными.
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы…
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы…
Простенькая задачка. Вполне подходит для собесов, но абсолютно реальная.
Допустим, у вас есть MVP и вы хотите протестировать, как работает игровая экономика. В частности, протестировать монетизацию. Самый простой (но не идеальный) способ провести такой тест — посмотреть конверсию в платящих (сколько и как быстро).
И тут вопрос. Что лучше, высокая конверсия на маленьких/средних платежах. Или низкая конверсия, но с высоким средним чеком? Например, 10% конверсии в платящих и средний чек на $3. Или 0.6% и средний чек $50?
Правильного варианта, само собой, тут нет.
#exercises
Допустим, у вас есть MVP и вы хотите протестировать, как работает игровая экономика. В частности, протестировать монетизацию. Самый простой (но не идеальный) способ провести такой тест — посмотреть конверсию в платящих (сколько и как быстро).
И тут вопрос. Что лучше, высокая конверсия на маленьких/средних платежах. Или низкая конверсия, но с высоким средним чеком? Например, 10% конверсии в платящих и средний чек на $3. Или 0.6% и средний чек $50?
Правильного варианта, само собой, тут нет.
#exercises
❤1🔥1
Мои размышления по поводу недавней задачки. Рекомендую также почитать комментарии, там много хороших идей.
Была бы у нас возможность оценивать монетизацию в прототипе на интервале 90-180+ дней, было бы проще — что дает денег больше/быстрее окупается, то и лучше. Но в прототипах у нас нет такой возможности, нам надо достаточно быстро принять решение, продолжаем проект или срочно его во что-то пивотим. И в таком случае приходится спускаться на уровень пользователя и думать, о чем нам говорит сложившийся набор метрик.
В таком ключе конверсия для меня маркер, насколько пользователям интересно то, что мы им предлагаем. Насколько хорошо мы выстроили соотношение привлекательности геймлея и игровых дефицитов. Хотят ли они вкладываться в игру и/или делают патежи на вау-эффекте.
Низкая конверсия и высокие чеки значат, что большинство пользователей не готовы что-либо покупать в игре. А покупают только супер-киты — либо очень лояльные (хотя на прототипе это странно), либо для кого это незначительный платеж. Принцип “сможет ли шейх потратить в твоей игре $20к” все еще хорош для оценки емкости. Остальные игроки не видят достаточной ценности в покупке, не готовы вкладываться, так как чувствуют, что недостаточно вовлечены или же им и так хорошо играть. В f2p играх обычно китовая монетизация, но она хороша и нужна на длинном периоде, а не одномоментно. В данном случае это плохая ситуация — нам удалось зацепить только очень узкую аудиторию и даже возможно, что случайно. Масштабировать такую закупку может быть сложно, риски не поймать таких китов очень высокие.
Небольшие чеки и высокая конверсия в данном случае выглядят для меня предпочтительнее. Пользователи готовы что-то купить, попробовать эффект от платежа и так далее. Однако тут надо очень внимательно смотреть, на чем конвертятся пользователи. В первую очередь, нет ли демпинга — легко сделать высокую конверсию, раздав всем на старте паки с очень высокой скидкой. В этом, конечно, хорошо бы ориентироваться на какие-то бенчмарки по рынку, в крайнем случае на здравый смысл.
Для уточнения контекста хорошо бы смотреть еще, как долго пользователи играют после покупки, как меняются их статистики, какой у них ретеншен, есть ли повторные платежи и т. д. Но это уже полноценный анализ получившейся модели монетизации и за пределами этой задачи.
#exercises
Была бы у нас возможность оценивать монетизацию в прототипе на интервале 90-180+ дней, было бы проще — что дает денег больше/быстрее окупается, то и лучше. Но в прототипах у нас нет такой возможности, нам надо достаточно быстро принять решение, продолжаем проект или срочно его во что-то пивотим. И в таком случае приходится спускаться на уровень пользователя и думать, о чем нам говорит сложившийся набор метрик.
В таком ключе конверсия для меня маркер, насколько пользователям интересно то, что мы им предлагаем. Насколько хорошо мы выстроили соотношение привлекательности геймлея и игровых дефицитов. Хотят ли они вкладываться в игру и/или делают патежи на вау-эффекте.
Низкая конверсия и высокие чеки значат, что большинство пользователей не готовы что-либо покупать в игре. А покупают только супер-киты — либо очень лояльные (хотя на прототипе это странно), либо для кого это незначительный платеж. Принцип “сможет ли шейх потратить в твоей игре $20к” все еще хорош для оценки емкости. Остальные игроки не видят достаточной ценности в покупке, не готовы вкладываться, так как чувствуют, что недостаточно вовлечены или же им и так хорошо играть. В f2p играх обычно китовая монетизация, но она хороша и нужна на длинном периоде, а не одномоментно. В данном случае это плохая ситуация — нам удалось зацепить только очень узкую аудиторию и даже возможно, что случайно. Масштабировать такую закупку может быть сложно, риски не поймать таких китов очень высокие.
Небольшие чеки и высокая конверсия в данном случае выглядят для меня предпочтительнее. Пользователи готовы что-то купить, попробовать эффект от платежа и так далее. Однако тут надо очень внимательно смотреть, на чем конвертятся пользователи. В первую очередь, нет ли демпинга — легко сделать высокую конверсию, раздав всем на старте паки с очень высокой скидкой. В этом, конечно, хорошо бы ориентироваться на какие-то бенчмарки по рынку, в крайнем случае на здравый смысл.
Для уточнения контекста хорошо бы смотреть еще, как долго пользователи играют после покупки, как меняются их статистики, какой у них ретеншен, есть ли повторные платежи и т. д. Но это уже полноценный анализ получившейся модели монетизации и за пределами этой задачи.
#exercises
👍14❤8
Праздники закончились, надо возвращаться к работе.
Вот вам небольшая задачка, прям из рабочих дашбордов меты. На графике — прокачка двух спеллов по игровым уровням/этапам (уровни как в Homescapes или Archero).
По оси OX — номер уровня. По оси OY — средний уровень прокачки заклинания в мете у тех пользователей, кто играл на этом уровне/этапе.
Собственно, вопрос. Что вы видите на этом графике?
Мо комментарий сегодня вечером или завтра днем.
#exercises
Вот вам небольшая задачка, прям из рабочих дашбордов меты. На графике — прокачка двух спеллов по игровым уровням/этапам (уровни как в Homescapes или Archero).
По оси OX — номер уровня. По оси OY — средний уровень прокачки заклинания в мете у тех пользователей, кто играл на этом уровне/этапе.
Собственно, вопрос. Что вы видите на этом графике?
Мо комментарий сегодня вечером или завтра днем.
#exercises
Сложный кейс из недавнего исследования.
На графике — какая доля пользователей вернется на следующий день после регистрации, в зависимости от количества сделанных в день установки матчей.
Сравнение двух версий. Версии, помимо прочего, отличаются в дизайне первой сесии — в версии 0.3 туториальные матчи существенно короче, чем в предыдущей версии. Точнее, раньше туториальные матч были из трех-пяти раундов, теперь из одного-двух.
Собственно вопрос, что вы видите на графике и как вы это можете проинтерпретировать?
Мой комментарий через пару дней.
UPD: в комментарии положил распределение пользователей по группам
#exercises
На графике — какая доля пользователей вернется на следующий день после регистрации, в зависимости от количества сделанных в день установки матчей.
Сравнение двух версий. Версии, помимо прочего, отличаются в дизайне первой сесии — в версии 0.3 туториальные матчи существенно короче, чем в предыдущей версии. Точнее, раньше туториальные матч были из трех-пяти раундов, теперь из одного-двух.
Собственно вопрос, что вы видите на графике и как вы это можете проинтерпретировать?
Мой комментарий через пару дней.
UPD: в комментарии положил распределение пользователей по группам
#exercises
👍9
Комментрий по недавней задачке.
Кейс, к слову, получился не очень наглядный и интересный, но что уж. Постараюсь другие делать по-прозрачнее.
Во-первых, общие размышления. Я смотрю на рет1 в том числе и в разрезе по группам активности. Группы можно выделять как по абсолютным значениям (так гд обычно делают), так и по квартилям (наш лид недавно предложил такой вариант, пока тестируем). Это помогает понять, за счет какой аудитории изменилось удержание. Тут, к слову, нередко бывают забавы в духе парадокса Симпсона, когда ретеншен изменился за счет перераспределения аудитории по группам (когда какая-нибудь сильно выросла в численности, например). В этой ситуации тоже есть прирост в группе самых активных, но это только часть ответа.
Собственно, по картинке. Тут самое подозрительное, что ретеншен неактивных и малоактивных пользователей упал. А у самых активных — вырос. В норме, если изменения первой сессии оказались очень хороши, я бы ожидал системного роста удержания во всех группах.
Я склонен интерпретировать ситуацию следующим образом. Когда мы сделали туториал быстрее и короче (так как сделали меньше раундов в туториальных матчах), пользователи стали дальше проваливать по воронке боев, делать их больше. Но при этом все равно отваливаться. Таким образом мы просто сдвинули точку отвала и несколько обострили выбор. То есть, пользователи, которые раньше ждали конца первого матча туториала и потом отваливались, сейчас делают выбор намного раньше.
При этом у нас вырос рет у очень активных пользователей (и количество тоже). Для меня это выглядит так, будто нам удалось заинтересовать какую-то аудиторию, которая проскочила быстрый туториал и потом еще надолго задержалась в игре и вернулась на след.день.
В комментариях были предложения смотреть время сессии. Я, признаться, не люблю эту метрику, ее достаточно сложно корректно посчитать в мобилках. Но у нас есть что-то похожее — heartbeat, события, которые отправляются каждые X секунд (по аналогии с user_engagement из Firebase-трекинга). Правда, под рукой этого графика сейчас нет, а что там было в отчете, уже не помню, к сожалению.
#exercises
Кейс, к слову, получился не очень наглядный и интересный, но что уж. Постараюсь другие делать по-прозрачнее.
Во-первых, общие размышления. Я смотрю на рет1 в том числе и в разрезе по группам активности. Группы можно выделять как по абсолютным значениям (так гд обычно делают), так и по квартилям (наш лид недавно предложил такой вариант, пока тестируем). Это помогает понять, за счет какой аудитории изменилось удержание. Тут, к слову, нередко бывают забавы в духе парадокса Симпсона, когда ретеншен изменился за счет перераспределения аудитории по группам (когда какая-нибудь сильно выросла в численности, например). В этой ситуации тоже есть прирост в группе самых активных, но это только часть ответа.
Собственно, по картинке. Тут самое подозрительное, что ретеншен неактивных и малоактивных пользователей упал. А у самых активных — вырос. В норме, если изменения первой сессии оказались очень хороши, я бы ожидал системного роста удержания во всех группах.
Я склонен интерпретировать ситуацию следующим образом. Когда мы сделали туториал быстрее и короче (так как сделали меньше раундов в туториальных матчах), пользователи стали дальше проваливать по воронке боев, делать их больше. Но при этом все равно отваливаться. Таким образом мы просто сдвинули точку отвала и несколько обострили выбор. То есть, пользователи, которые раньше ждали конца первого матча туториала и потом отваливались, сейчас делают выбор намного раньше.
При этом у нас вырос рет у очень активных пользователей (и количество тоже). Для меня это выглядит так, будто нам удалось заинтересовать какую-то аудиторию, которая проскочила быстрый туториал и потом еще надолго задержалась в игре и вернулась на след.день.
В комментариях были предложения смотреть время сессии. Я, признаться, не люблю эту метрику, ее достаточно сложно корректно посчитать в мобилках. Но у нас есть что-то похожее — heartbeat, события, которые отправляются каждые X секунд (по аналогии с user_engagement из Firebase-трекинга). Правда, под рукой этого графика сейчас нет, а что там было в отчете, уже не помню, к сожалению.
#exercises
🔥3❤1👍1