Всем привет!
Я Филипп Управителев и это мой канал по продуктовой аналитике в геймдеве.
Здесь я пишу о задачах и ситуациях, которые встречаются в моей работе, делюсь методологическими размышлениями. Эпизодически делаю обзоры учебных курсов и книг по аналитике, комментирую интересные посты. Также иногда даю практические задачки.
Посты для знакомства с каналом:
Фреймворки продуктовой аналитики
Продуктовое мышление игровых аналитиков (текст выступления с митапа)
Особенности монетизации на офферах
UX-исследования глазами аналитика
Ретеншен платящих
Метрики второго порядка
Основные тэги:
#courses — комментарии по курсам продуктовой аналитики
#books — про книги об аналитике и статистике
#exercises — задачки и кейсы
#links — что попалось хорошего в сети
#datamodel — про разметку данных, логирование и т. д.
Продуктовой аналитикой я занимаюсь больше десяти лет. У меня базовое психологическое образование, одновременно и экспериментально-академическое, и терапевтическое (гештальт). Какое-то время преподавал мат.методы в психологии, фрилансил, написал учебник по R. Был одним из админов в ODS, сейчас админю каналы по R и когнитивной психологии, веду курсы по анализу данных в ВШЭ. И вот я здесь.
Подписывайтесь на канал, комментируйте, рассказывайте коллегам. Приходите в личку просто пообщаться или с запросами на консультацию/менторство.
Рекламу на канале не делаю, но могу порекомендовать, если мы лично знакомы.
Я Филипп Управителев и это мой канал по продуктовой аналитике в геймдеве.
Здесь я пишу о задачах и ситуациях, которые встречаются в моей работе, делюсь методологическими размышлениями. Эпизодически делаю обзоры учебных курсов и книг по аналитике, комментирую интересные посты. Также иногда даю практические задачки.
Посты для знакомства с каналом:
Фреймворки продуктовой аналитики
Продуктовое мышление игровых аналитиков (текст выступления с митапа)
Особенности монетизации на офферах
UX-исследования глазами аналитика
Ретеншен платящих
Метрики второго порядка
Основные тэги:
#courses — комментарии по курсам продуктовой аналитики
#books — про книги об аналитике и статистике
#exercises — задачки и кейсы
#links — что попалось хорошего в сети
#datamodel — про разметку данных, логирование и т. д.
Продуктовой аналитикой я занимаюсь больше десяти лет. У меня базовое психологическое образование, одновременно и экспериментально-академическое, и терапевтическое (гештальт). Какое-то время преподавал мат.методы в психологии, фрилансил, написал учебник по R. Был одним из админов в ODS, сейчас админю каналы по R и когнитивной психологии, веду курсы по анализу данных в ВШЭ. И вот я здесь.
Подписывайтесь на канал, комментируйте, рассказывайте коллегам. Приходите в личку просто пообщаться или с запросами на консультацию/менторство.
Рекламу на канале не делаю, но могу порекомендовать, если мы лично знакомы.
аналитика на кубах pinned «Всем привет! Я Филипп Управителев и это мой канал по продуктовой аналитике в геймдеве. Здесь я пишу о задачах и ситуациях, которые встречаются в моей работе, делюсь методологическими размышлениями. Эпизодически делаю обзоры учебных курсов и книг по аналитике…»
Сергей Матросов (X5 Tech, автор канала Не AБы какие тесты) опубликовал лонгрид про тест Манна-Уитни.
Статья действительно большая, я читал ее в несколько подходов и еще буду перечитывать. На мой взгляд, ее стоило бы разделить на две или три части, да и некоторые определения показались мне шероховатыми. Но это все вкусовщина, у Сергея была такая куча редакторов и итераций правок, что если я буду развивать эту тему, он меня проклянет и будет прав.
Первые две части посвящены эволюции критерия — от исходного поэлементного сравнения и вывода о равенстве распределений до сумм рангов и статистики W-Вилкоксона. Попутно есть ряд лирических отступлений про нулевую гипотезу и оценку значимости в симуляционном эксперименте.
Последняя треть статьи оказалась для меня одновременно самой сложной и самой интересной. Она посвящена практическому использованию критерия и особенности его реализации в Varioqub. Сергей делает разбор на кейсе Авито, одновременно вступая в полемику. Собственно, для лучшего понимания дискуссии стоить прочитать и статью Дмитрия Лунина.
Этот кейс очень близок к тому, с чем регулярно сталкиваемся мы в наших экспериментах — когда мы делаем изменения в стоимости/наполнении оффера, у нас есть и изменения конверсии, и большое количество неплатящих в обеих группах. Мы подобные эксперименты проверяем дедовским способом, простым как топор и вычислительно сложным — перестановочными тестами. Что ж, теперь есть что добавить в бэклог идей для R&D.
Помимо обсуждения критерия Вилкоксона-Манна-Уитни, в статье еще есть описание пары трюков про бакетизацию и преобразование данных (как они реализованы в Varioqub, но это непринципиально). И бонусом, уже в посте про статью, есть описание непараметрической меры центральной тенденции, оценки Hodges-Lehman’a. Новая для меня штука, любопытно.
#stats
Статья действительно большая, я читал ее в несколько подходов и еще буду перечитывать. На мой взгляд, ее стоило бы разделить на две или три части, да и некоторые определения показались мне шероховатыми. Но это все вкусовщина, у Сергея была такая куча редакторов и итераций правок, что если я буду развивать эту тему, он меня проклянет и будет прав.
Первые две части посвящены эволюции критерия — от исходного поэлементного сравнения и вывода о равенстве распределений до сумм рангов и статистики W-Вилкоксона. Попутно есть ряд лирических отступлений про нулевую гипотезу и оценку значимости в симуляционном эксперименте.
Последняя треть статьи оказалась для меня одновременно самой сложной и самой интересной. Она посвящена практическому использованию критерия и особенности его реализации в Varioqub. Сергей делает разбор на кейсе Авито, одновременно вступая в полемику. Собственно, для лучшего понимания дискуссии стоить прочитать и статью Дмитрия Лунина.
Этот кейс очень близок к тому, с чем регулярно сталкиваемся мы в наших экспериментах — когда мы делаем изменения в стоимости/наполнении оффера, у нас есть и изменения конверсии, и большое количество неплатящих в обеих группах. Мы подобные эксперименты проверяем дедовским способом, простым как топор и вычислительно сложным — перестановочными тестами. Что ж, теперь есть что добавить в бэклог идей для R&D.
Помимо обсуждения критерия Вилкоксона-Манна-Уитни, в статье еще есть описание пары трюков про бакетизацию и преобразование данных (как они реализованы в Varioqub, но это непринципиально). И бонусом, уже в посте про статью, есть описание непараметрической меры центральной тенденции, оценки Hodges-Lehman’a. Новая для меня штука, любопытно.
#stats
Я не люблю задачки вида “ползут три черепашки”, но они все же встречаются, даже в отлаженных системах трекинга. И заставляют извращаться с всяким манипулированием данными.
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы трекинга платежей. В ней потерялись некоторые платежи. Надо найти и изучить потеряшек.
Из условий: есть только общий идентификатор пользователя и таймстампы транзакций в каждой выгрузке. Будем считать, что идентификаторов транзакций, SKU и прочих полезных данных нет. Данные выгружены в csv из разных баз, никакого SQL.
Для упрощения ситуации будем считать, что таймстампы одной транзакции в двух системах различаются незначительно (допустим, меньше 30 секунд). И что разница времени двух разных транзакций больше, чем разница во времени одной транзакции в двух системах. В реальности, конечно же, такие предположения еще нужно сделать и, по возможности, проверить.
Как будете решать такую задачку?
Я вижу два решения. Одно прям дубовое и прожорливое по ресурсам. Второе поизящнее и поэкономнее. И оба грязные. Впрочем, я вообще не уверен, что такие задачи можно чисто решать, честно говоря.
#exercises
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы трекинга платежей. В ней потерялись некоторые платежи. Надо найти и изучить потеряшек.
Из условий: есть только общий идентификатор пользователя и таймстампы транзакций в каждой выгрузке. Будем считать, что идентификаторов транзакций, SKU и прочих полезных данных нет. Данные выгружены в csv из разных баз, никакого SQL.
Для упрощения ситуации будем считать, что таймстампы одной транзакции в двух системах различаются незначительно (допустим, меньше 30 секунд). И что разница времени двух разных транзакций больше, чем разница во времени одной транзакции в двух системах. В реальности, конечно же, такие предположения еще нужно сделать и, по возможности, проверить.
Как будете решать такую задачку?
Я вижу два решения. Одно прям дубовое и прожорливое по ресурсам. Второе поизящнее и поэкономнее. И оба грязные. Впрочем, я вообще не уверен, что такие задачи можно чисто решать, честно говоря.
#exercises
Решение предыдущей задачки.
Первое решение, как я и говорил, дубовое и прожорливое. Основная идея — так как в pandas нет нечеткого джойна, делаем cross join, так, чтобы для каждой транзакции из консоли были все транзакции в нашей системе трекинга. Потом ищем дельту во времени между транзакциями и берем для каждой транзакции в сторе одну минимально близкую по времени в системе трекинга. Если такой нет (все транзакции в системе за пределами интервала [1, 30] секунд), то это транзакция и была потеряна.
Основная идея второго решения — выстроить все транзакции в один временной ряд, так как ожидаем, что пользователи делают платежи с большим интервалом, чем наша разница между двумя системами. И если после транзакции в консоли не было транзакции в нашей системе — то вот она, наша потерянная транзация.
Оба решения грязные. Первое опирается на предположения о порогах и размножает платежи, c этим нужно быть аккуратными. Второе просто полагается на допущения о соотношений систем трекинга. На моем рабочем датасете первое решение еще и меньше потеряшек нашло. Но на безрыбье и панды — фреймворк для работы с данными, что уж, для общего понимания ситуации и анализа паттернов, кто потерялся, вполне подойдет.
Код можно посмотреть здесь.
UPD: в пандах таки есть merge_asof. Видимо, статья на SO была совсем древней, а я не посмотрел на ее дату :(
#exercises
Первое решение, как я и говорил, дубовое и прожорливое. Основная идея — так как в pandas нет нечеткого джойна, делаем cross join, так, чтобы для каждой транзакции из консоли были все транзакции в нашей системе трекинга. Потом ищем дельту во времени между транзакциями и берем для каждой транзакции в сторе одну минимально близкую по времени в системе трекинга. Если такой нет (все транзакции в системе за пределами интервала [1, 30] секунд), то это транзакция и была потеряна.
Основная идея второго решения — выстроить все транзакции в один временной ряд, так как ожидаем, что пользователи делают платежи с большим интервалом, чем наша разница между двумя системами. И если после транзакции в консоли не было транзакции в нашей системе — то вот она, наша потерянная транзация.
Оба решения грязные. Первое опирается на предположения о порогах и размножает платежи, c этим нужно быть аккуратными. Второе просто полагается на допущения о соотношений систем трекинга. На моем рабочем датасете первое решение еще и меньше потеряшек нашло. Но на безрыбье и панды — фреймворк для работы с данными, что уж, для общего понимания ситуации и анализа паттернов, кто потерялся, вполне подойдет.
Код можно посмотреть здесь.
UPD: в пандах таки есть merge_asof. Видимо, статья на SO была совсем древней, а я не посмотрел на ее дату :(
#exercises
Telegram
аналитика на кубах
Я не люблю задачки вида “ползут три черепашки”, но они все же встречаются, даже в отлаженных системах трекинга. И заставляют извращаться с всяким манипулированием данными.
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы…
Ситуация: есть выгрузка о платежах из консоли стора. Есть выгрузка из своей системы…
Дочитал Game Analytics: Retention and Monetization in Free-to-Play Mobile Games by Russell Ovans. Книга вполне свежая, 2023 года издания. Автор — лид аналитики Eastside Games (Appmagic). Когда-то в 2007 году он основал игровую студию с играми в Fb, в 2010 он ее продал и ушел варить пиво. А в 2018 году вернулся в геймдев, чтобы поддержать свою пивоварню.
В книге 12 глав, каждая в среднем 20-25 страниц. Первые две главы погружают в аналитический быт — что такое монетизация, пайплайн работы, дизайн событий, основные метрики. Основные инструменты в книге и, как я понимаю, в работе — SQL, Tableau и иногда R. Притом примеры что на SQL, что на R — просто ужасные на мой вкус, синтаксис каменного века.
Третья глава посвящена дашбордам и, по большей части, как их делать в Tableau. Для сбора требований к дашбордам я бы рекомендовал посмотреть на фреймворк Романа Бунина, например.
Следующие четыре главы — смысловое ядро книги, так как касаются ретеншена, отвалов и монетизации. Ретеншен дается в его классическом виде retention rate, что хорошо (возвраты на строго конкретный день от инсталла, календарно). Фитить и предсказывать ретеншен предлагается степенной функцией вида r(day_n) = a * day_n ^ b, для когорты, а не поюзерно. Один из инструментов фитинга — внутренние инструменты Tableau.
С монетизацией похожая история (главы 5 и 6) — предлагается предсказывать ревеню на N день от инсталла аналогичной степенной функцией, плюс фитить регресию на исторических данных. Для чистоты данные следует нормировать (т. е. revenue_90 как 100%). Либо использовать для оценки LTV сочетание ретеншена и ARPDAU когорты на конкретный день от инсталла. Вообще, предлагаемый подход к аналитике монетизации странноватый и по идеям, и по определениям. Так, я нигде не нашел определение ARPU и сломался на фразе “if ARPDAU is defined as the running sum of cohort revenue divided by the running sum of cohort DAU”.
Глава про отвалы опирается на “марковскую цепь” и количество последовательных дней активности — то есть, предлагается оценивать, какова вероятность, что пользователь (не)вернется на какой-то следующий день. Для lifetime = 3 это граф с ребрами 0 - 1, 0 - 2, 0-3, 1 - 2, 1 - 3, 2 - 3 и отвалами 0 - churn, 1 - churn, 2 - churn. Впрочем, что делать с полученными цифрами не уточняется.
Следующие две главы посвящены A/B-тестам. Немного статистики (ЦПТ и сравнение средних, перестановочные тесты), немного примеров. После главы про дашборды это самые бесполезные главы, на мой взгляд.
Десятая и одиннадцатая главы посвящены способам улучшения ретеншена. Наряду с тривиальными решениями ("оцените отвалы по шагам туториала") есть неплохие идеи — например, о корреляции поминутного ретеншена в день инсталла с ret_1 (мы тоже видели ту статью от гугла, да). Или оценка среднего возраста аудитории, чтобы понимать, какой контент делать. Хотя стратификация DAU по возрасту аудитории тут была бы лучше.
Способы улучшения монетизации тоже не ноу-хау (я их так или иначе делал уже, например), но любопытные — посмотреть, какой монетизационный профиль пользователей в зависимости от размера и типа первого платежа. И региональные цены. Жаль только, что нет примеров и результатов применения этих методов, предлагается только использовать A/B-тесты для тестирования подходов.
Последняя глава посвящена идее ROAS и окупаемости кампаний, этакий заход в маркетинговую аналитику. Даже про AEO-кампании говорится и про k-фактор и его определение по бейслайну органики. Оценивать окупаемость предлагается по экстраполяции кривой LTV (которое опирается на ARPDAU и ретеншен). Про коэффициентные модели и метрики, про какое-то машинное обучение — ни слова.
В общем, книга получилась любопытная, но очень кустарная по ощущениям. Если вы только начинаете погружаться в продуктовую/игровую аналитику, она вас запутает и научит плохому, поэтому не рекомендую. Она интересна только с точки зрения “а как это делают в другой команде”, не более. Я лично остался разочарован.
#books
В книге 12 глав, каждая в среднем 20-25 страниц. Первые две главы погружают в аналитический быт — что такое монетизация, пайплайн работы, дизайн событий, основные метрики. Основные инструменты в книге и, как я понимаю, в работе — SQL, Tableau и иногда R. Притом примеры что на SQL, что на R — просто ужасные на мой вкус, синтаксис каменного века.
Третья глава посвящена дашбордам и, по большей части, как их делать в Tableau. Для сбора требований к дашбордам я бы рекомендовал посмотреть на фреймворк Романа Бунина, например.
Следующие четыре главы — смысловое ядро книги, так как касаются ретеншена, отвалов и монетизации. Ретеншен дается в его классическом виде retention rate, что хорошо (возвраты на строго конкретный день от инсталла, календарно). Фитить и предсказывать ретеншен предлагается степенной функцией вида r(day_n) = a * day_n ^ b, для когорты, а не поюзерно. Один из инструментов фитинга — внутренние инструменты Tableau.
С монетизацией похожая история (главы 5 и 6) — предлагается предсказывать ревеню на N день от инсталла аналогичной степенной функцией, плюс фитить регресию на исторических данных. Для чистоты данные следует нормировать (т. е. revenue_90 как 100%). Либо использовать для оценки LTV сочетание ретеншена и ARPDAU когорты на конкретный день от инсталла. Вообще, предлагаемый подход к аналитике монетизации странноватый и по идеям, и по определениям. Так, я нигде не нашел определение ARPU и сломался на фразе “if ARPDAU is defined as the running sum of cohort revenue divided by the running sum of cohort DAU”.
Глава про отвалы опирается на “марковскую цепь” и количество последовательных дней активности — то есть, предлагается оценивать, какова вероятность, что пользователь (не)вернется на какой-то следующий день. Для lifetime = 3 это граф с ребрами 0 - 1, 0 - 2, 0-3, 1 - 2, 1 - 3, 2 - 3 и отвалами 0 - churn, 1 - churn, 2 - churn. Впрочем, что делать с полученными цифрами не уточняется.
Следующие две главы посвящены A/B-тестам. Немного статистики (ЦПТ и сравнение средних, перестановочные тесты), немного примеров. После главы про дашборды это самые бесполезные главы, на мой взгляд.
Десятая и одиннадцатая главы посвящены способам улучшения ретеншена. Наряду с тривиальными решениями ("оцените отвалы по шагам туториала") есть неплохие идеи — например, о корреляции поминутного ретеншена в день инсталла с ret_1 (мы тоже видели ту статью от гугла, да). Или оценка среднего возраста аудитории, чтобы понимать, какой контент делать. Хотя стратификация DAU по возрасту аудитории тут была бы лучше.
Способы улучшения монетизации тоже не ноу-хау (я их так или иначе делал уже, например), но любопытные — посмотреть, какой монетизационный профиль пользователей в зависимости от размера и типа первого платежа. И региональные цены. Жаль только, что нет примеров и результатов применения этих методов, предлагается только использовать A/B-тесты для тестирования подходов.
Последняя глава посвящена идее ROAS и окупаемости кампаний, этакий заход в маркетинговую аналитику. Даже про AEO-кампании говорится и про k-фактор и его определение по бейслайну органики. Оценивать окупаемость предлагается по экстраполяции кривой LTV (которое опирается на ARPDAU и ретеншен). Про коэффициентные модели и метрики, про какое-то машинное обучение — ни слова.
В общем, книга получилась любопытная, но очень кустарная по ощущениям. Если вы только начинаете погружаться в продуктовую/игровую аналитику, она вас запутает и научит плохому, поэтому не рекомендую. Она интересна только с точки зрения “а как это делают в другой команде”, не более. Я лично остался разочарован.
#books
Простенькая задачка. Вполне подходит для собесов, но абсолютно реальная.
Допустим, у вас есть MVP и вы хотите протестировать, как работает игровая экономика. В частности, протестировать монетизацию. Самый простой (но не идеальный) способ провести такой тест — посмотреть конверсию в платящих (сколько и как быстро).
И тут вопрос. Что лучше, высокая конверсия на маленьких/средних платежах. Или низкая конверсия, но с высоким средним чеком? Например, 10% конверсии в платящих и средний чек на $3. Или 0.6% и средний чек $50?
Правильного варианта, само собой, тут нет.
#exercises
Допустим, у вас есть MVP и вы хотите протестировать, как работает игровая экономика. В частности, протестировать монетизацию. Самый простой (но не идеальный) способ провести такой тест — посмотреть конверсию в платящих (сколько и как быстро).
И тут вопрос. Что лучше, высокая конверсия на маленьких/средних платежах. Или низкая конверсия, но с высоким средним чеком? Например, 10% конверсии в платящих и средний чек на $3. Или 0.6% и средний чек $50?
Правильного варианта, само собой, тут нет.
#exercises
Мои размышления по поводу недавней задачки. Рекомендую также почитать комментарии, там много хороших идей.
Была бы у нас возможность оценивать монетизацию в прототипе на интервале 90-180+ дней, было бы проще — что дает денег больше/быстрее окупается, то и лучше. Но в прототипах у нас нет такой возможности, нам надо достаточно быстро принять решение, продолжаем проект или срочно его во что-то пивотим. И в таком случае приходится спускаться на уровень пользователя и думать, о чем нам говорит сложившийся набор метрик.
В таком ключе конверсия для меня маркер, насколько пользователям интересно то, что мы им предлагаем. Насколько хорошо мы выстроили соотношение привлекательности геймлея и игровых дефицитов. Хотят ли они вкладываться в игру и/или делают патежи на вау-эффекте.
Низкая конверсия и высокие чеки значат, что большинство пользователей не готовы что-либо покупать в игре. А покупают только супер-киты — либо очень лояльные (хотя на прототипе это странно), либо для кого это незначительный платеж. Принцип “сможет ли шейх потратить в твоей игре $20к” все еще хорош для оценки емкости. Остальные игроки не видят достаточной ценности в покупке, не готовы вкладываться, так как чувствуют, что недостаточно вовлечены или же им и так хорошо играть. В f2p играх обычно китовая монетизация, но она хороша и нужна на длинном периоде, а не одномоментно. В данном случае это плохая ситуация — нам удалось зацепить только очень узкую аудиторию и даже возможно, что случайно. Масштабировать такую закупку может быть сложно, риски не поймать таких китов очень высокие.
Небольшие чеки и высокая конверсия в данном случае выглядят для меня предпочтительнее. Пользователи готовы что-то купить, попробовать эффект от платежа и так далее. Однако тут надо очень внимательно смотреть, на чем конвертятся пользователи. В первую очередь, нет ли демпинга — легко сделать высокую конверсию, раздав всем на старте паки с очень высокой скидкой. В этом, конечно, хорошо бы ориентироваться на какие-то бенчмарки по рынку, в крайнем случае на здравый смысл.
Для уточнения контекста хорошо бы смотреть еще, как долго пользователи играют после покупки, как меняются их статистики, какой у них ретеншен, есть ли повторные платежи и т. д. Но это уже полноценный анализ получившейся модели монетизации и за пределами этой задачи.
#exercises
Была бы у нас возможность оценивать монетизацию в прототипе на интервале 90-180+ дней, было бы проще — что дает денег больше/быстрее окупается, то и лучше. Но в прототипах у нас нет такой возможности, нам надо достаточно быстро принять решение, продолжаем проект или срочно его во что-то пивотим. И в таком случае приходится спускаться на уровень пользователя и думать, о чем нам говорит сложившийся набор метрик.
В таком ключе конверсия для меня маркер, насколько пользователям интересно то, что мы им предлагаем. Насколько хорошо мы выстроили соотношение привлекательности геймлея и игровых дефицитов. Хотят ли они вкладываться в игру и/или делают патежи на вау-эффекте.
Низкая конверсия и высокие чеки значат, что большинство пользователей не готовы что-либо покупать в игре. А покупают только супер-киты — либо очень лояльные (хотя на прототипе это странно), либо для кого это незначительный платеж. Принцип “сможет ли шейх потратить в твоей игре $20к” все еще хорош для оценки емкости. Остальные игроки не видят достаточной ценности в покупке, не готовы вкладываться, так как чувствуют, что недостаточно вовлечены или же им и так хорошо играть. В f2p играх обычно китовая монетизация, но она хороша и нужна на длинном периоде, а не одномоментно. В данном случае это плохая ситуация — нам удалось зацепить только очень узкую аудиторию и даже возможно, что случайно. Масштабировать такую закупку может быть сложно, риски не поймать таких китов очень высокие.
Небольшие чеки и высокая конверсия в данном случае выглядят для меня предпочтительнее. Пользователи готовы что-то купить, попробовать эффект от платежа и так далее. Однако тут надо очень внимательно смотреть, на чем конвертятся пользователи. В первую очередь, нет ли демпинга — легко сделать высокую конверсию, раздав всем на старте паки с очень высокой скидкой. В этом, конечно, хорошо бы ориентироваться на какие-то бенчмарки по рынку, в крайнем случае на здравый смысл.
Для уточнения контекста хорошо бы смотреть еще, как долго пользователи играют после покупки, как меняются их статистики, какой у них ретеншен, есть ли повторные платежи и т. д. Но это уже полноценный анализ получившейся модели монетизации и за пределами этой задачи.
#exercises
Пост дружеского пиара.
Я в этом канале достаточно регулярно задаюсь вопросами про то, как бы так измерить удовольствие пользователей, понять их мотивацию и тому подобное. И мне столь же регулярно намекают, что это все надо делать другими инструментами — качественными исследованиями (интервью, фокус-группы и т. д.).
Я этому сопротивляюсь, так как считаю, что ограничения качественных исследований делают их неприменимыми к немалой части моих вопросов. Сопротивляюсь вяло, потому что я не специалист, у меня другая ветка развития. Но на то, что происходит в лагере качественников и как они работают — стараюсь все же посматривать.
Есть немало чатов сообществ и каналов про качественные исследования. И PostPostResearch — один из лучших, на мой взгляд. В первую очередь за счет опыта ребят, системности и в целом акцента на методологию и методологическую рефлексию. К чему я и сам склонен. Вот, например, сейчас обдумываю их статью про то, ситуация влияет на потребительское поведение сильнее, чем личностные черты.
В общем, рекомендую подписаться и читать, полезно для расширения картины мира и инструментария.
#links
Я в этом канале достаточно регулярно задаюсь вопросами про то, как бы так измерить удовольствие пользователей, понять их мотивацию и тому подобное. И мне столь же регулярно намекают, что это все надо делать другими инструментами — качественными исследованиями (интервью, фокус-группы и т. д.).
Я этому сопротивляюсь, так как считаю, что ограничения качественных исследований делают их неприменимыми к немалой части моих вопросов. Сопротивляюсь вяло, потому что я не специалист, у меня другая ветка развития. Но на то, что происходит в лагере качественников и как они работают — стараюсь все же посматривать.
Есть немало чатов сообществ и каналов про качественные исследования. И PostPostResearch — один из лучших, на мой взгляд. В первую очередь за счет опыта ребят, системности и в целом акцента на методологию и методологическую рефлексию. К чему я и сам склонен. Вот, например, сейчас обдумываю их статью про то, ситуация влияет на потребительское поведение сильнее, чем личностные черты.
В общем, рекомендую подписаться и читать, полезно для расширения картины мира и инструментария.
#links
Недавно попалась в руки небольшая книжка-брошюра Best Practices for In-Game Shop Design от Balancy про трюки и приемы для повышения эффективности внутриигрового магазина. Balancy — платформа для LiveOps (офферы, сегментация, ивенты), автор материалов — Михаил Хрипин, в прошлом проюдер Hero Wars в Nexters.
Книжка, конечно, сделана с промо-целью. Тем не менее, это неплохой набор советов по организации магазина — начиная от чисто UI-рекомедаций до более сложных вещей типа порядка лотов, динамической замены лотов, логики формирования бандлов и тому подобного. Есть даже любопытный набор параметров для сегментации пользователей для персональных офферов. В общем, очень полезная вещь для тех, кто задумывается, как делать магазин в игре и какие могут быть варианты его организации.
Взгляд аналитика, к сожалению, добавляет немного дегтя. Книжка называется “best practices”, но нет явного обоснования, почему эти рекомендации действительно работают. Аргументы уровня “так делают успешные проекты” вполне понятны, но для меня недостаточны.
Поэтому лично я воспринимаю этот кукбук как смесь common sense рекомендаций и списка идей для аб-тестов. И то с некоторыми ограничениями — если в проекте вся монетизация идет через магазин, то да, это логичное и сильное место для оптимизации. А если в проекте монетизация на офферах, то шатания магазина дадут слабый эффект.
#books
Книжка, конечно, сделана с промо-целью. Тем не менее, это неплохой набор советов по организации магазина — начиная от чисто UI-рекомедаций до более сложных вещей типа порядка лотов, динамической замены лотов, логики формирования бандлов и тому подобного. Есть даже любопытный набор параметров для сегментации пользователей для персональных офферов. В общем, очень полезная вещь для тех, кто задумывается, как делать магазин в игре и какие могут быть варианты его организации.
Взгляд аналитика, к сожалению, добавляет немного дегтя. Книжка называется “best practices”, но нет явного обоснования, почему эти рекомендации действительно работают. Аргументы уровня “так делают успешные проекты” вполне понятны, но для меня недостаточны.
Поэтому лично я воспринимаю этот кукбук как смесь common sense рекомендаций и списка идей для аб-тестов. И то с некоторыми ограничениями — если в проекте вся монетизация идет через магазин, то да, это логичное и сильное место для оптимизации. А если в проекте монетизация на офферах, то шатания магазина дадут слабый эффект.
#books
Треды в рабочем мессенджере эпизодически поражают.
И развенчивают фантазии о наукоемкости работы аналитиков. Чувствую себя обезьяной с перестановочными тестами в кармане и Скиннером наперевес.
- а в Юнити есть инструменты из коробки простеньку физику воды посчитать? Не сталкивался?
Можно конечно погуглить и написать расчёт гидродинамики для, например, 10 вертексов, но может что-то готовое есть.
- Сталкивался. Навье-Стокса на GPU писал) Немного не то, да
Ничего особого, художники обсуждают, как замоделить бутылочку с плещущейся при движении водой.
И развенчивают фантазии о наукоемкости работы аналитиков. Чувствую себя обезьяной с перестановочными тестами в кармане и Скиннером наперевес.
- а в Юнити есть инструменты из коробки простеньку физику воды посчитать? Не сталкивался?
Можно конечно погуглить и написать расчёт гидродинамики для, например, 10 вертексов, но может что-то готовое есть.
- Сталкивался. Навье-Стокса на GPU писал) Немного не то, да
Ничего особого, художники обсуждают, как замоделить бутылочку с плещущейся при движении водой.
Даталорды интересно набросили, конечно.
Кто из нас без греха, кто не оценивал тренды на глазок?
Вообще, не люблю временные ряды.
(а за график с серой подложкой отдельное фи)
https://www.group-telegram.com/analytics_kaanal/198
Кто из нас без греха, кто не оценивал тренды на глазок?
Вообще, не люблю временные ряды.
(а за график с серой подложкой отдельное фи)
https://www.group-telegram.com/analytics_kaanal/198
Расскажу вам про одну не очень удачную идею.
Некоторое время назад мы на одном прототипе решили посмотреть, а как же играют и платят лояльные пользователи. Оределили лояльных как тех, кто играл 14 дней подряд и смотрели изменения в их активности — сколько боев в первую и вторую неделю, сколько платежей, соотношение недель и т. д. Ребята-геймдизы даже смотрели таймлайны некоторых игроков, чтобы попробовать реконструировать их опыт (редкий пример почти феноменологического анализа случаев). А то что за дела, играть-то играют, а платить перестают.
Идея была в том, что лояльные пользователи — ядро аудитории, лучше всех понимают игру, сильнее всех реагируют на изменения. Этакая фокусирующая призма, с помощью которой можно было бы увидеть сильную реакцию на какие-то изменения в мете и балансах. Оказалось же наоборот, они суперлояльны и играют несмотря ни на какие шатания меты. И, видимо, более чувствительны к изменениям будут те, кто заходит не столь регулярно.
Недавно я попробовал второй подход к снаряду — сравнивал проекты группы и в том числе решил посмотреть, как работают такие метрики как “доля лояльных в ретеншене” (из вернувшихся на седьмой день какая доля играла все семь дней) и связанный с ней “ретеншен лояльных” (какая доля всей когорты на X день от инсталла играет ровно X дней).
Работают не очень хорошо. У первой низкая дифференцирующая способность (совершенно банально — межквартильный размах не кратный, как в случае других метрик), то есть проекты с разной монетизацией слабо различаются по этой метрике. А вторая метрика очень сильно (намного сильнее, чем я ожидал) коррелирует с обычным ретеншеном и смысла ее отдельно считать и интерпретировать нет.
В общем, на данный момент я склонен признать, что я, скорее всего, просто не докрутил идею и метрики. Либо сам концепт “лояльности” не очень информативен для понимания поведения пользователей прототипов.
Некоторое время назад мы на одном прототипе решили посмотреть, а как же играют и платят лояльные пользователи. Оределили лояльных как тех, кто играл 14 дней подряд и смотрели изменения в их активности — сколько боев в первую и вторую неделю, сколько платежей, соотношение недель и т. д. Ребята-геймдизы даже смотрели таймлайны некоторых игроков, чтобы попробовать реконструировать их опыт (редкий пример почти феноменологического анализа случаев). А то что за дела, играть-то играют, а платить перестают.
Идея была в том, что лояльные пользователи — ядро аудитории, лучше всех понимают игру, сильнее всех реагируют на изменения. Этакая фокусирующая призма, с помощью которой можно было бы увидеть сильную реакцию на какие-то изменения в мете и балансах. Оказалось же наоборот, они суперлояльны и играют несмотря ни на какие шатания меты. И, видимо, более чувствительны к изменениям будут те, кто заходит не столь регулярно.
Недавно я попробовал второй подход к снаряду — сравнивал проекты группы и в том числе решил посмотреть, как работают такие метрики как “доля лояльных в ретеншене” (из вернувшихся на седьмой день какая доля играла все семь дней) и связанный с ней “ретеншен лояльных” (какая доля всей когорты на X день от инсталла играет ровно X дней).
Работают не очень хорошо. У первой низкая дифференцирующая способность (совершенно банально — межквартильный размах не кратный, как в случае других метрик), то есть проекты с разной монетизацией слабо различаются по этой метрике. А вторая метрика очень сильно (намного сильнее, чем я ожидал) коррелирует с обычным ретеншеном и смысла ее отдельно считать и интерпретировать нет.
В общем, на данный момент я склонен признать, что я, скорее всего, просто не докрутил идею и метрики. Либо сам концепт “лояльности” не очень информативен для понимания поведения пользователей прототипов.
Немного технического.
С точки зрения кода у меня очень примитивные задачи. Выгрузить данные, всячески их покрутить, порезать на слайсы, нарисовать. Статистика есть, конечно же, это важная часть майндсета и инструментария продуктовых аналитиков, но такие задачи не ежедневны. Основная сложность в моей работе — придумать гипотезу и понять, как ее можно проверить и/или что нужно для этого измерить.
В общем, для визуализации я использую plotly и у меня накопилось какое-то количество шаблонов и трюков. Я решил из них сделать шпаргалку для своей команды, заодно основной частью и с вами поделюсь.
Самое полезное для меня — сочетание ipywidgets и plotly. Позволяет быстро и не растягивая ноутбук на километры посмотреть сразу много метрик в разных разрезах. Коллеги, правда, смеются, говорят: “сделал себе дашборд/zeppelin в джупитере”. Да, я люблю странное.
Остальное — всякие выдранные из недр SO трюки по акцентированию внимания и внесению доп.информации на графики (вертикальные линии и подписи дат релизов, ховеры-тултипы). Ну и всякие способы навести красоту на графике, особенно если используются фасеты.
Полноценный интерактив в nbviewer / github не завезли, поэтому сделал пример в Google Colab. Да и там c оговорками — в частности, в режиме общего доступа не работают селекторы. Так что если хочется потыкать палочкой — скопируйте себе, датасеты должны быть открыты для всех.
Данные, естественно, синтетические и ничего общего с моими реальными проектами не имеют.
https://colab.research.google.com/drive/1JoSYxbBvjIKf8xNTHscyCARTbjHOqfOf#scrollTo=fe24c2f2-fc83-4a9d-af0e-a57519230419
С точки зрения кода у меня очень примитивные задачи. Выгрузить данные, всячески их покрутить, порезать на слайсы, нарисовать. Статистика есть, конечно же, это важная часть майндсета и инструментария продуктовых аналитиков, но такие задачи не ежедневны. Основная сложность в моей работе — придумать гипотезу и понять, как ее можно проверить и/или что нужно для этого измерить.
В общем, для визуализации я использую plotly и у меня накопилось какое-то количество шаблонов и трюков. Я решил из них сделать шпаргалку для своей команды, заодно основной частью и с вами поделюсь.
Самое полезное для меня — сочетание ipywidgets и plotly. Позволяет быстро и не растягивая ноутбук на километры посмотреть сразу много метрик в разных разрезах. Коллеги, правда, смеются, говорят: “сделал себе дашборд/zeppelin в джупитере”. Да, я люблю странное.
Остальное — всякие выдранные из недр SO трюки по акцентированию внимания и внесению доп.информации на графики (вертикальные линии и подписи дат релизов, ховеры-тултипы). Ну и всякие способы навести красоту на графике, особенно если используются фасеты.
Полноценный интерактив в nbviewer / github не завезли, поэтому сделал пример в Google Colab. Да и там c оговорками — в частности, в режиме общего доступа не работают селекторы. Так что если хочется потыкать палочкой — скопируйте себе, датасеты должны быть открыты для всех.
Данные, естественно, синтетические и ничего общего с моими реальными проектами не имеют.
https://colab.research.google.com/drive/1JoSYxbBvjIKf8xNTHscyCARTbjHOqfOf#scrollTo=fe24c2f2-fc83-4a9d-af0e-a57519230419
Один из моих первых лидов как-то посмотрел на мои графики и возопил “зачем так сложно”. У меня очень противоречивые воспоминания о нем, но конкретно в этом месте он был прав.
Ковырялся недавно с проектами группы, смотрел, можно ли их использовать как референсы для наших прототипов. Собрал кучу метрик (и поведенческие, и бизнесовые), на автомате покрутил-посмотрел, нарисовал боксы. Потом подумал, что боксы как-то ну совсем примитив, надо попробовать что-то посерьезнее. Окунулся в иерархический кластерный, немножко зацепил линейную регрессию и просто оценку на мультиколлинеарность (хорошо хоть до PCA не докатился). Кое-что забавное получилось, но не очень удобное для решаемой задачи.
В итоге у меня получился просто график в plotly, на котором фасетами десяток метрик и точками с пяток референсных проектов, на метрики которых нам интересно смотреть. Добавим метрики нашего прототипа и поймем, где мы относительно референсов. Это не основа для принятия решений, конечно же, но некоторая ориентация на местности.
В общем, не надо делать сложно, когда можно сделать просто. Достаточно интуитивная идея, но я постоянно про нее забываю и недооцениваю.
Ковырялся недавно с проектами группы, смотрел, можно ли их использовать как референсы для наших прототипов. Собрал кучу метрик (и поведенческие, и бизнесовые), на автомате покрутил-посмотрел, нарисовал боксы. Потом подумал, что боксы как-то ну совсем примитив, надо попробовать что-то посерьезнее. Окунулся в иерархический кластерный, немножко зацепил линейную регрессию и просто оценку на мультиколлинеарность (хорошо хоть до PCA не докатился). Кое-что забавное получилось, но не очень удобное для решаемой задачи.
В итоге у меня получился просто график в plotly, на котором фасетами десяток метрик и точками с пяток референсных проектов, на метрики которых нам интересно смотреть. Добавим метрики нашего прототипа и поймем, где мы относительно референсов. Это не основа для принятия решений, конечно же, но некоторая ориентация на местности.
В общем, не надо делать сложно, когда можно сделать просто. Достаточно интуитивная идея, но я постоянно про нее забываю и недооцениваю.