Посмотрел курс по продюсированию мобильных игр от Дмитрия Филатова (OwlCat, ex-MyGames/MGVC), автора канала DogDog. Курс выложен в открытый доступ, за что большое спасибо Дмитрию и Scream School.
Мне курс понравился. Кажется, он как раз закрывает недостающий кусочек — есть курсы по геймдизайну, по разработке или арту, да даже по аналитике кое-что есть. Но мало где говорится, как считать деньги команды, как оценивать перспективность игры, как мы вообще подходим к окупаемости, как декомпозировать задачи и выстраивать роадмап и т. д. “Вы пройдете полный цикл работы над идеей: от выбора и оценки до проработки и продажи ее бизнесу”.
Отдельно, конечно, было приятно услышать какие-то знакомые имена, близкие идеи и оценки — я с особым интересом слушал лекции по выбору жанра и по целям-этапам проекта до выхода в стадию оперирования.
При всем этом, я лично привык немного к другой роли продюсера. У Дмитрия сильный акцент сделан на организационно-финансовой части. Я же больше привык видеть другую сторону продюсеров — креативно-визионерскую. То есть я взаимодействую с продюсерами по поводу метагейма, экономики и в целом задачам вида “как повысить XXXX”. У Филатова в курсе эти компоненты оцениваются как менее значимые для работы продюсера. Даже на этапе прототипов, когда есть цели типа “нам нужен такой-то d1 retention”, роль продюсера в итеративном повышении метрики не особо раскрывается.
Возможно, это особенность студий, в которых я работал, и/или другой поход к развитию продукта. Или просто специфика именно этого курса.
#courses
Мне курс понравился. Кажется, он как раз закрывает недостающий кусочек — есть курсы по геймдизайну, по разработке или арту, да даже по аналитике кое-что есть. Но мало где говорится, как считать деньги команды, как оценивать перспективность игры, как мы вообще подходим к окупаемости, как декомпозировать задачи и выстраивать роадмап и т. д. “Вы пройдете полный цикл работы над идеей: от выбора и оценки до проработки и продажи ее бизнесу”.
Отдельно, конечно, было приятно услышать какие-то знакомые имена, близкие идеи и оценки — я с особым интересом слушал лекции по выбору жанра и по целям-этапам проекта до выхода в стадию оперирования.
При всем этом, я лично привык немного к другой роли продюсера. У Дмитрия сильный акцент сделан на организационно-финансовой части. Я же больше привык видеть другую сторону продюсеров — креативно-визионерскую. То есть я взаимодействую с продюсерами по поводу метагейма, экономики и в целом задачам вида “как повысить XXXX”. У Филатова в курсе эти компоненты оцениваются как менее значимые для работы продюсера. Даже на этапе прототипов, когда есть цели типа “нам нужен такой-то d1 retention”, роль продюсера в итеративном повышении метрики не особо раскрывается.
Возможно, это особенность студий, в которых я работал, и/или другой поход к развитию продукта. Или просто специфика именно этого курса.
#courses
Последнее время иногда думаю про логирование событий (когда устаю думать “а почему XXX такое низкое”). Хочется как-то перейти от простого “вот это надо обложить аналитикой” к какому-то более абстрактному/концептуальному уровню. Чтобы можно было для любой игры относительно быстро и безболезненно сформировать модель данных, например.
Дело идет со скрипом, если честно. Постоянно кажется, что это какой-то велосипед и более умные люди (системные аналитики, архитекторы бд и прочие разработчики) все это уже давным давно сделали. Но каких-то внятных материалов на эту тему я так и не нашел. Может, плохо искал.
Пока дошел до выделения сущностей, их параметров и состояний, переходов в другие состояния, краешком затронул ресурсы и их виды. И это только самое начало — есть же еще всякие замороченные компоненты типа транзакций в движениях ресурсов или тапы/переходы в UI, платежи и их структура, в конце концов.
Но одно уже понятно сразу — очень много вкусовщины. Самый простой пример — квесты. Обычно для анализа квестов требуется как минимум два события — событие получение квеста и событие выполнения. Иногда могут быть дополнительные этапы, типа “квест выдан сервером”, “награда за этап квеста начислена сервером” и тому подобное.
Так вот, очень часто делают два события, на получение и на выполнение. Потом эти две таблички в бд можно спокойно джойнить и смотреть, какие квесты реже всего завершались. По моим наблюдениям, разработчики очень любят такой формат.
Я же предпочитаю не плодить множество событий и все логировать в рамках только одного, но с разным значением в поле статуса (started / finished / etc). То есть длинный формат таблиц и потом группировка по соответствующим полям.
И это тоже только маленькая часть айсберга дизайна логов. Нейминг, можно ли json-ы или лучше строкой с разделителями позиций, новая колонка или еще одно значение в json, длинный или широкий формат таблиц — в каждом из этих пунктов можно долго и упоенно ругаться. Мы так и делали на этапе создания нашей модели, кстати. Движение ресурсов, помнится, неделю обсуждали — от нас даже маркетинг шарахаться начал, а они ребята вроде стойкие да привычные.
#datamodel
Дело идет со скрипом, если честно. Постоянно кажется, что это какой-то велосипед и более умные люди (системные аналитики, архитекторы бд и прочие разработчики) все это уже давным давно сделали. Но каких-то внятных материалов на эту тему я так и не нашел. Может, плохо искал.
Пока дошел до выделения сущностей, их параметров и состояний, переходов в другие состояния, краешком затронул ресурсы и их виды. И это только самое начало — есть же еще всякие замороченные компоненты типа транзакций в движениях ресурсов или тапы/переходы в UI, платежи и их структура, в конце концов.
Но одно уже понятно сразу — очень много вкусовщины. Самый простой пример — квесты. Обычно для анализа квестов требуется как минимум два события — событие получение квеста и событие выполнения. Иногда могут быть дополнительные этапы, типа “квест выдан сервером”, “награда за этап квеста начислена сервером” и тому подобное.
Так вот, очень часто делают два события, на получение и на выполнение. Потом эти две таблички в бд можно спокойно джойнить и смотреть, какие квесты реже всего завершались. По моим наблюдениям, разработчики очень любят такой формат.
Я же предпочитаю не плодить множество событий и все логировать в рамках только одного, но с разным значением в поле статуса (started / finished / etc). То есть длинный формат таблиц и потом группировка по соответствующим полям.
И это тоже только маленькая часть айсберга дизайна логов. Нейминг, можно ли json-ы или лучше строкой с разделителями позиций, новая колонка или еще одно значение в json, длинный или широкий формат таблиц — в каждом из этих пунктов можно долго и упоенно ругаться. Мы так и делали на этапе создания нашей модели, кстати. Движение ресурсов, помнится, неделю обсуждали — от нас даже маркетинг шарахаться начал, а они ребята вроде стойкие да привычные.
#datamodel
Недавно смотрел отчеты нашей кросс-проектной команды — они регулярно делают обзоры продуктовых метрик по всем проектам группы. Метрики у ребят интересные, сложные и непривычные, эпизодически приходится долго думать.
Теперь вот думаю, насколько все же методы формируют нашу картину мира. А если ближе к теме — как структура базы данных влияет на используемые метрики. Классический пример — какое-то время назад никто не собирал точную статистику по заходам пользователей в приложение. Максимум — писали дату последнего логина в таблицу состояния пользователя (условный “профиль”). В результате мы имеем rolling retention как единственную внятную метрику удержания пользователя (stickiness не беру как совсем бессмысленную) — и считать легко, и цифры для инвесторов красивые. Потом стали чаще спускаться на уровень поведения пользователя и логировать каждый заход. В результате retention rate стал стандартом, пусть и с некоторыми нюансами типа метода расчета интервала.
Вот и сейчас — смотрю на метрику, понимаю, что для меня она как минимум спорная. Но она достаточно легко считается при определенной модели данных. Зачем, почему так, есть ли в этом какой-то еще смысл, который я не вижу — буду спрашивать.
Я это постоянно говорю студентам, скажу и тут — утиный тест при чтении чужих отчетов сбоит. Если что-то называется retention/ARPU/conversion/etc, то всегда полезно уточнить, как именно это считается. Оно может быть совсем не тем, чем кажется. Хотя как тренировка гибкости мышления — наверное, неплохая практика. Но для таких целей лучше прочитать Джойса, на мой взгляд.
Теперь вот думаю, насколько все же методы формируют нашу картину мира. А если ближе к теме — как структура базы данных влияет на используемые метрики. Классический пример — какое-то время назад никто не собирал точную статистику по заходам пользователей в приложение. Максимум — писали дату последнего логина в таблицу состояния пользователя (условный “профиль”). В результате мы имеем rolling retention как единственную внятную метрику удержания пользователя (stickiness не беру как совсем бессмысленную) — и считать легко, и цифры для инвесторов красивые. Потом стали чаще спускаться на уровень поведения пользователя и логировать каждый заход. В результате retention rate стал стандартом, пусть и с некоторыми нюансами типа метода расчета интервала.
Вот и сейчас — смотрю на метрику, понимаю, что для меня она как минимум спорная. Но она достаточно легко считается при определенной модели данных. Зачем, почему так, есть ли в этом какой-то еще смысл, который я не вижу — буду спрашивать.
Я это постоянно говорю студентам, скажу и тут — утиный тест при чтении чужих отчетов сбоит. Если что-то называется retention/ARPU/conversion/etc, то всегда полезно уточнить, как именно это считается. Оно может быть совсем не тем, чем кажется. Хотя как тренировка гибкости мышления — наверное, неплохая практика. Но для таких целей лучше прочитать Джойса, на мой взгляд.
Недавно просматривал коллекцию тестовых заданий, которую выложил Павел Бухтик.
Коллекция любопытная — раньше мне попадались только сборники для датасаентистов, да иногда у своих студентов просил тестовые, которые они проходили. А тут именно продуктовая аналитика, на junior-middle уровни преимущественно, с разметкой тем, грейда и наличия датасетов.
Ко всему прочему, нашел там задания от геймдев-студий. Lesta/WG, Playrix, Crazy Panda, Vizor, EasyBrain, MyGames и Saber. Везде есть описание заданий, почти во всех есть данные. Самое интересное, на мой взгляд, задание у WG. “Проанализируйте показатели эффективности кораблей, выбрав наиболее верную на Ваш взгляд методологию” — прелесть же.
Самое скучное задание у Saber Interactive — задание касается аналитики тасок, а не игрового поведения пользователей. Впрочем, неудивительно. В заданиях остальных студий — анализ фич, A/B-тесты, немного теор.вера и маркетинга. Везде — SQL + Python.
Теперь вот думаю, что стоит порешать тестовые неигровых компаний. Хотя бы почитать их, потрогать данные. Глядишь, и студентам обновление для домашек так насобираю, а то они на сгенерированных датасетах сидят, бедняги. Да и самому интересно, как уши методологии будут торчать из формулировок заданий.
Коллекция любопытная — раньше мне попадались только сборники для датасаентистов, да иногда у своих студентов просил тестовые, которые они проходили. А тут именно продуктовая аналитика, на junior-middle уровни преимущественно, с разметкой тем, грейда и наличия датасетов.
Ко всему прочему, нашел там задания от геймдев-студий. Lesta/WG, Playrix, Crazy Panda, Vizor, EasyBrain, MyGames и Saber. Везде есть описание заданий, почти во всех есть данные. Самое интересное, на мой взгляд, задание у WG. “Проанализируйте показатели эффективности кораблей, выбрав наиболее верную на Ваш взгляд методологию” — прелесть же.
Самое скучное задание у Saber Interactive — задание касается аналитики тасок, а не игрового поведения пользователей. Впрочем, неудивительно. В заданиях остальных студий — анализ фич, A/B-тесты, немного теор.вера и маркетинга. Везде — SQL + Python.
Теперь вот думаю, что стоит порешать тестовые неигровых компаний. Хотя бы почитать их, потрогать данные. Глядишь, и студентам обновление для домашек так насобираю, а то они на сгенерированных датасетах сидят, бедняги. Да и самому интересно, как уши методологии будут торчать из формулировок заданий.
В середине прошлой недели ко мне внезапно подкрался аудит. Есть такая забава у публичных компаний или компаний, которые хотят стать публичными / привлечь инвесторов. И ключевое там — как рассчитывать отложенную выручку для отчетности в формате МСФО.
Казалось бы, причем тут аналитики. Однако мы в играх продаем харду и различные наборы ресурсов. Некоторые из них можно потратить мгновенно (бустеры). А некоторые — вечны, типа единиц контента или прокачки. Плюс пользователи отваливаются или не полностью используют купленную харду, которая остается у них на руках. Зная курс харды к доллару, можно вычислить, на какую сумму были проданы товары, а что остается в обязательствах и должно быть записано в отложенную выручку (насколько я понял эту бухгалтерскую магию).
Собственно, все это и интересует финансистов, которые готовят отчеты для аудиторов. А аналитики ближе всего к подобным данным.
Вообще, как сказал @dkd_kdk, “аудит — это ультимативное испытание для модели данных”. Если модель хорошая, то собрать траты платной харды и ее курс будет относительно просто. Наша модель оказалась относительно неплоха, я доволен. Есть пара выявившихся лакун, а кое-что уже давно в бэклоге лежит. Есть и пара мест, которые на других проектах придется менять, без этого тоже не обошлось, к сожалению.
#datamodel
Казалось бы, причем тут аналитики. Однако мы в играх продаем харду и различные наборы ресурсов. Некоторые из них можно потратить мгновенно (бустеры). А некоторые — вечны, типа единиц контента или прокачки. Плюс пользователи отваливаются или не полностью используют купленную харду, которая остается у них на руках. Зная курс харды к доллару, можно вычислить, на какую сумму были проданы товары, а что остается в обязательствах и должно быть записано в отложенную выручку (насколько я понял эту бухгалтерскую магию).
Собственно, все это и интересует финансистов, которые готовят отчеты для аудиторов. А аналитики ближе всего к подобным данным.
Вообще, как сказал @dkd_kdk, “аудит — это ультимативное испытание для модели данных”. Если модель хорошая, то собрать траты платной харды и ее курс будет относительно просто. Наша модель оказалась относительно неплоха, я доволен. Есть пара выявившихся лакун, а кое-что уже давно в бэклоге лежит. Есть и пара мест, которые на других проектах придется менять, без этого тоже не обошлось, к сожалению.
#datamodel
Вчера NEWHR опубликовали список, за какими экспертами, подкастами, каналами в Telegram и YouTube следят аналитики. Список был составлен по результатам ежегодного опроса.
Было неожиданно, но очень приятно увидеть мой канал там. Спасибо всем, кто упоминал и рекомендовал!
Если у вас есть какие-то комментарии или предложения по каналу — напишите, пожалуйста, в тред или мне в личку (@konhis). Немного фидбека всегда полезно.
Было неожиданно, но очень приятно увидеть мой канал там. Спасибо всем, кто упоминал и рекомендовал!
Если у вас есть какие-то комментарии или предложения по каналу — напишите, пожалуйста, в тред или мне в личку (@konhis). Немного фидбека всегда полезно.
newhr.org
За кем следят продуктовые и дата-аналитики
500 экспертов, каналов, подкастов и ютубов
Один мой знакомый продуктовый аналитик при каждой нашей встрече ворчит: “геймдев — это какая-то своя реальность”. В чем-то он прав, пожалуй. Своя атмосфера и в данных, и в фокусах анализа, и в подходе к интерпретации.
Вот небольшой пример. Изучаю факторы отвала на третий день — сравниваю, как играют те, кто отвалился раньше и те, кто все-таки вернулся. Интересно, чем различается игровой опыт этих групп пользователей, так как это как раз может быть причиной отвала.
Вижу, что у отвалившихся пользователей выше винрейт и KDA. Вопрос, можно ли утверждать (при прочих равных), что пользователям слишком легко играть, нет челленджа и они отваливаются?
Самый правильный ответ тут — недостаточно данных. Но в большинстве случаев вывод про отсутствие челленджа будет все же неверен. В данном случае от нас скрыта еще одна переменная — сколько боев сыграли те, кто отвалился и кто вернулся, и что это за бои. Обычно отвалившиеся пользователи играют в два-три раза менее активно, чем вернувшиеся. В этом и кроется ключевая ловушка — бои пользователей, особенно в самом начале, неодинаковы (для других жанров единицы будут другими, но смысл тот же). Самые первые бои обычно стараются делать легкими (беззубые и/или понерфленные боты и т. д.) и потом постепенно повышать сложность. Плюс пользователи растут по рейтингу и попадают в котлы к игрокам с более высоким рейтингом и, соответственно, опытом и прокачкой.
В результате пользователи, которые вернулись на третий день, скорее всего отыграли больше боев. И в этих боях они сталкивались уже с более сложными ботами и опытными игроками. Отвалившиеся пользователи ушли на легких боях, и поэтому у них winrate/KDA вполне может выше. Но это никак не говорит о том, что пользователи отвалились из-за того, что им легко и нет челленджа. Для проверки этой гипотезы надо брать тех, кто сыграл, например, ровно 10 боев, и смотреть метрики вернувшихся и отвалившихся по ним.
Собственно, вот эта неоднородность опыта пользователей, которая зависит от внутриигровой прогрессии — одна из ключевых особенностей игровых данных, влияющих на метрики и на подходы к анализу и выводу.
PS. сижу теперь и думаю — кажется, вполне неплохой кейс получился для задачника по продуктовой аналитике или для собесов
#exercises
Вот небольшой пример. Изучаю факторы отвала на третий день — сравниваю, как играют те, кто отвалился раньше и те, кто все-таки вернулся. Интересно, чем различается игровой опыт этих групп пользователей, так как это как раз может быть причиной отвала.
Вижу, что у отвалившихся пользователей выше винрейт и KDA. Вопрос, можно ли утверждать (при прочих равных), что пользователям слишком легко играть, нет челленджа и они отваливаются?
Самый правильный ответ тут — недостаточно данных. Но в большинстве случаев вывод про отсутствие челленджа будет все же неверен. В данном случае от нас скрыта еще одна переменная — сколько боев сыграли те, кто отвалился и кто вернулся, и что это за бои. Обычно отвалившиеся пользователи играют в два-три раза менее активно, чем вернувшиеся. В этом и кроется ключевая ловушка — бои пользователей, особенно в самом начале, неодинаковы (для других жанров единицы будут другими, но смысл тот же). Самые первые бои обычно стараются делать легкими (беззубые и/или понерфленные боты и т. д.) и потом постепенно повышать сложность. Плюс пользователи растут по рейтингу и попадают в котлы к игрокам с более высоким рейтингом и, соответственно, опытом и прокачкой.
В результате пользователи, которые вернулись на третий день, скорее всего отыграли больше боев. И в этих боях они сталкивались уже с более сложными ботами и опытными игроками. Отвалившиеся пользователи ушли на легких боях, и поэтому у них winrate/KDA вполне может выше. Но это никак не говорит о том, что пользователи отвалились из-за того, что им легко и нет челленджа. Для проверки этой гипотезы надо брать тех, кто сыграл, например, ровно 10 боев, и смотреть метрики вернувшихся и отвалившихся по ним.
Собственно, вот эта неоднородность опыта пользователей, которая зависит от внутриигровой прогрессии — одна из ключевых особенностей игровых данных, влияющих на метрики и на подходы к анализу и выводу.
PS. сижу теперь и думаю — кажется, вполне неплохой кейс получился для задачника по продуктовой аналитике или для собесов
#exercises
Недавно прочитал “50 бизнес-моделей новой экономики. Уроки компаний-единорогов”. Это не совсем про продуктовую аналитику, но, на мой взгляд, понимание бизнес-моделей полезно для развития продуктового мышления. Один из авторов — Александр Горный, его курс по юнит-экономике я проходил некоторое время назад.
Впечатления скорее негативные. Каждая статья — описание той или иной компании по фиксированной структуре: идея, история, ценность для пользователя и буквально пара слов про капитализацию. Группировка компаний скорее по авторству и по некоторым темам, которые, видимо, интересны авторам (например, у одного много про компании в области спорта, у другого — про компании, предоставляющие образовательные услуги).
Авторы прямо говорят (в комментариях на странице на литресе), что “в основу книги легли статьи из блогов авторов. При этом, каждый кейс был доработан. Мы постарались выявить закономерности и тенденции во введении и заключении”. И это ключевая проблема книги — нет никакого серьезного обобщения ни трендов, ни собственно бизнес-моделей. Максимум, на что хватило авторов — добавить в приложение табличку-сопоставления вида “Онлайн-обучение в виде развлечения: Duolingo, Masterclass, Outsсhool, VIPKid”. Книга была бы кратно интереснее, если бы было наоборот — сначала разбирались бы тренды в бизнес-моделях, а к ним давались бы иллюстрации в виде уже существующих компаний.
Некоторые компании и бизнес-модели показались устаревшими или несколько “притянутыми за уши”. Например, в чем новизна и специфика бизнес-модели в DOLLAR SHAVE CLUB, которые продавали подписку на бритвы? С учетом того, что компанию в 2016 году купил ее конкурент Unilever. Или Eng Authority, которые создали “большой красивый обзорный курс современного айтишника и продает его заинтересованным в обучении компаниям”. Да и утверждение про компании-единороги спорное, у многих компаний из списка оборот десятки миллионов долларов.
При этом любопытно было почитать про какие-то компании и решения, попримерять на себя — стал бы я пользоваться их продуктом и почему. Я бы сказал, сейчас ценность книги для меня заключается в материале, которые поможет чуть лучше различать тренды. Но всю исследовательско-аналитическую работу придется делать самому.
#books
Впечатления скорее негативные. Каждая статья — описание той или иной компании по фиксированной структуре: идея, история, ценность для пользователя и буквально пара слов про капитализацию. Группировка компаний скорее по авторству и по некоторым темам, которые, видимо, интересны авторам (например, у одного много про компании в области спорта, у другого — про компании, предоставляющие образовательные услуги).
Авторы прямо говорят (в комментариях на странице на литресе), что “в основу книги легли статьи из блогов авторов. При этом, каждый кейс был доработан. Мы постарались выявить закономерности и тенденции во введении и заключении”. И это ключевая проблема книги — нет никакого серьезного обобщения ни трендов, ни собственно бизнес-моделей. Максимум, на что хватило авторов — добавить в приложение табличку-сопоставления вида “Онлайн-обучение в виде развлечения: Duolingo, Masterclass, Outsсhool, VIPKid”. Книга была бы кратно интереснее, если бы было наоборот — сначала разбирались бы тренды в бизнес-моделях, а к ним давались бы иллюстрации в виде уже существующих компаний.
Некоторые компании и бизнес-модели показались устаревшими или несколько “притянутыми за уши”. Например, в чем новизна и специфика бизнес-модели в DOLLAR SHAVE CLUB, которые продавали подписку на бритвы? С учетом того, что компанию в 2016 году купил ее конкурент Unilever. Или Eng Authority, которые создали “большой красивый обзорный курс современного айтишника и продает его заинтересованным в обучении компаниям”. Да и утверждение про компании-единороги спорное, у многих компаний из списка оборот десятки миллионов долларов.
При этом любопытно было почитать про какие-то компании и решения, попримерять на себя — стал бы я пользоваться их продуктом и почему. Я бы сказал, сейчас ценность книги для меня заключается в материале, которые поможет чуть лучше различать тренды. Но всю исследовательско-аналитическую работу придется делать самому.
#books
Как я уже неоднократно говорил, я не очень люблю ui-аналитику. Тем нагляднее кейс, который некоторое время назад случился на одном из проектов, с которыми я работаю (пример основан на реальных событиях, но не полностью).
В одном из релизов отломали всплывающее окно с предложением докупить софты. Оно появлялось, когда у пользователя не хватает софты, а он хочет что-то купить/проапгрейдить и т. д. Мест, где такое окошко всплывает, было несколько, сломалось одно из них.
Про баг qa знали, приоритет был низкий, но в какой-то момент все же поправили. А пользователи стали тратить на 20% больше софты.
Казалось бы, все отлично. Но на самом деле это весьма проблемная история. Потому что в этот момент мы планировали тест новых балансов в экономике и такое изменение ошибочно можно было приписать нашему эксперименту. Во-вторых, багофиксы обычно проходят мимо аналитиков, разработчики вообще могли в рабочем режиме молча поправить баг, а мы бы потом долго разбирались, что же произошло. И в-третьих, такие вещи очень маятно отслеживать и контролировать на лету — к релизообразующим фичам всплывающее окошко не отнесешь, да и в ченджлоге такие изменения редко расписываются подробно. Логами и дашбордами события показа ui-окон обкладывать долго и дорого, всегда есть более важные задачи.
А самое противное — не особо понятно, что можно/нужно изменить, чтобы в следующий раз верно и с минимальными затратами исключать роль ui в изменениях метрик.
В одном из релизов отломали всплывающее окно с предложением докупить софты. Оно появлялось, когда у пользователя не хватает софты, а он хочет что-то купить/проапгрейдить и т. д. Мест, где такое окошко всплывает, было несколько, сломалось одно из них.
Про баг qa знали, приоритет был низкий, но в какой-то момент все же поправили. А пользователи стали тратить на 20% больше софты.
Казалось бы, все отлично. Но на самом деле это весьма проблемная история. Потому что в этот момент мы планировали тест новых балансов в экономике и такое изменение ошибочно можно было приписать нашему эксперименту. Во-вторых, багофиксы обычно проходят мимо аналитиков, разработчики вообще могли в рабочем режиме молча поправить баг, а мы бы потом долго разбирались, что же произошло. И в-третьих, такие вещи очень маятно отслеживать и контролировать на лету — к релизообразующим фичам всплывающее окошко не отнесешь, да и в ченджлоге такие изменения редко расписываются подробно. Логами и дашбордами события показа ui-окон обкладывать долго и дорого, всегда есть более важные задачи.
А самое противное — не особо понятно, что можно/нужно изменить, чтобы в следующий раз верно и с минимальными затратами исключать роль ui в изменениях метрик.
Коллеги попросили порекомендовать какие-нибудь каналы про аналитику и прочее. Решил и тут поделиться.
NB! Это то, что я более-менее активно и регулярно читаю по аналитике и геймдеву. Eсть другие хорошие каналы, но как-то с ними не сложилось (revealdata) или они совсем уж специфичны (типа по hr-аналитике).
продуктовая аналитика / продуктовое мышление
Product Science by Anton Martsen. Антон — продакт с большим опытом в аналитике. В канале много про исследования, фреймворки и в целом про персонализацию продукта под пользователя (интерфейс, контент и офферы).
Продакт аналитикс. Задорно, больше ориентировано на джунов и вкотиков, но полезные материалы встречаются.
Product analysis | Dmitry Varsanovich и Я твой продукт анализировал — два канала продуктовых аналитиков о жизни и работе. Немного похоже на мой канал, но задорнее, больше практики и меньше методологической рефлексии.
Продуктовое мышление / от ProductSense. Ребята из ProductSense выбирают и пересказывают полезные для продактов статьи.
Стартап дня. Александр Горный. Далеко от аналитики, но на мой взгляд, полезно для расширения насмотренности разных продуктов, потребностей пользователей и монетизации.
Products’ memes. Мемы, куда ж без них. Канал Ани Подображных и ее коллег, так что в первую очередь про продакт-менеджмент. Но попадаются и мемы про аналитику.
геймдев
App2Top. Новости, что вообще происходит в индустрии.
GameDev Reports - by devtodev. Сводные отчеты об исследованиях агентств и аналитических сервисов (Newzoo, SensorTower и т. д.)
DogDog. Канал Дмитрия Филатова (в прошлом продюсер, ныне кофаундер инвест-фонда для инди-разработчиков). Полезно для понимания индустрии, трендов и практик создания игр.
Product in Gamedev. Малоактивный канал с пересказами разных полезных статей (DoF и прочие).
Чатик игровых аналитиков (по инвайтам, для уже работающих аналитиков). Весьма малоактивный, по совокупности причин. Но иногда полезно что-то спросить или посмотреть на обсуждение чужих кейсов.
Чат гейм-дизайнеров | Манжеты ГД. Чат геймдизайнеров. Атмосфера как и во всех живых чатах — вперемешку интересное, флейм и срачи. В целом полезно для того, чтобы понимать, как думают геймдизайнеры.
stats
EXPF. Канал про эксперименты, статистику и анализ данных. Я плохо знаю проекты Вита и Искандера, но в канале они постят и комментируют ссылки на современные статьи.
Reliable ML. Хороший канал Иры Голощаповой и ее коллег про то, “как управлять внедрением и развитием аналитики и data science/machine learning/AI”. Ребята делают митапы и пишут статьи про интерпретируемость ML-моделей, casual inference и прочие edge-темы.
Время Валеры [Бабушкина]. Валера это конечно Валера, но временами попадаются пересказы интересных статей (например, разбор robyn) или ссылки на хорошие обсуждения аб-тестов.
BioStat <- R | Чат по статистике и R. Небольшой чат биоинформатиков и статистиков в фарме, нередко встречаются обсуждения сложных стат.методов. (на самом деле про R мало, больше по статистике)
dataviz
отвратительные графики. Канал плохих визуализаций. Беру оттуда примеры студентам, да и в целом учит, как не надо делать.
Чартомойка. Канал Александра Богачева “о графиках: плохих, хороших и других”. Хорошее про то, как надо делать [инфографику].
настенька и графики. “Датавиз, аналитика и всякое полезное и интересное”. Я только изредка /просматриваю, хотя канал хороший.
#links
NB! Это то, что я более-менее активно и регулярно читаю по аналитике и геймдеву. Eсть другие хорошие каналы, но как-то с ними не сложилось (revealdata) или они совсем уж специфичны (типа по hr-аналитике).
продуктовая аналитика / продуктовое мышление
Product Science by Anton Martsen. Антон — продакт с большим опытом в аналитике. В канале много про исследования, фреймворки и в целом про персонализацию продукта под пользователя (интерфейс, контент и офферы).
Продакт аналитикс. Задорно, больше ориентировано на джунов и вкотиков, но полезные материалы встречаются.
Product analysis | Dmitry Varsanovich и Я твой продукт анализировал — два канала продуктовых аналитиков о жизни и работе. Немного похоже на мой канал, но задорнее, больше практики и меньше методологической рефлексии.
Продуктовое мышление / от ProductSense. Ребята из ProductSense выбирают и пересказывают полезные для продактов статьи.
Стартап дня. Александр Горный. Далеко от аналитики, но на мой взгляд, полезно для расширения насмотренности разных продуктов, потребностей пользователей и монетизации.
Products’ memes. Мемы, куда ж без них. Канал Ани Подображных и ее коллег, так что в первую очередь про продакт-менеджмент. Но попадаются и мемы про аналитику.
геймдев
App2Top. Новости, что вообще происходит в индустрии.
GameDev Reports - by devtodev. Сводные отчеты об исследованиях агентств и аналитических сервисов (Newzoo, SensorTower и т. д.)
DogDog. Канал Дмитрия Филатова (в прошлом продюсер, ныне кофаундер инвест-фонда для инди-разработчиков). Полезно для понимания индустрии, трендов и практик создания игр.
Product in Gamedev. Малоактивный канал с пересказами разных полезных статей (DoF и прочие).
Чатик игровых аналитиков (по инвайтам, для уже работающих аналитиков). Весьма малоактивный, по совокупности причин. Но иногда полезно что-то спросить или посмотреть на обсуждение чужих кейсов.
Чат гейм-дизайнеров | Манжеты ГД. Чат геймдизайнеров. Атмосфера как и во всех живых чатах — вперемешку интересное, флейм и срачи. В целом полезно для того, чтобы понимать, как думают геймдизайнеры.
stats
EXPF. Канал про эксперименты, статистику и анализ данных. Я плохо знаю проекты Вита и Искандера, но в канале они постят и комментируют ссылки на современные статьи.
Reliable ML. Хороший канал Иры Голощаповой и ее коллег про то, “как управлять внедрением и развитием аналитики и data science/machine learning/AI”. Ребята делают митапы и пишут статьи про интерпретируемость ML-моделей, casual inference и прочие edge-темы.
Время Валеры [Бабушкина]. Валера это конечно Валера, но временами попадаются пересказы интересных статей (например, разбор robyn) или ссылки на хорошие обсуждения аб-тестов.
BioStat <- R | Чат по статистике и R. Небольшой чат биоинформатиков и статистиков в фарме, нередко встречаются обсуждения сложных стат.методов. (на самом деле про R мало, больше по статистике)
dataviz
отвратительные графики. Канал плохих визуализаций. Беру оттуда примеры студентам, да и в целом учит, как не надо делать.
Чартомойка. Канал Александра Богачева “о графиках: плохих, хороших и других”. Хорошее про то, как надо делать [инфографику].
настенька и графики. “Датавиз, аналитика и всякое полезное и интересное”. Я только изредка /просматриваю, хотя канал хороший.
#links
По мотивам одного из недавних рабочих обсуждений дизайна событий. В очередной раз вспомнил, что архитектура проекта сильно влияет на то, что из действий пользователя и как мы можем залогировать.
Вот очень простая ситуация. Допустим, мы хотим посмотреть, сколько боев делают пользователи на каждом уровне. Казалось бы — есть событие завершения боя, группируйся по уровню, и все хорошо. Но нет. Потому что в шутерах обычно есть такая сущность, как гейм-сервер, который собирает пользователей в бой и, собственно, ведет бой, считает киллы и прочее. С него же и отправляется событие со статой по бою (в нашем кейсе по старту/завершению боя).
Однако есть нюанс — гейм-сервер ничего не знает про уровни пользователя, это не его задача. Эта информация хранится на мета-сервере, где профиль игрока, все вычисления и начисления. Еще есть клиентская стата, с всяким логами ui и FPS, но в этом кейсе она не столь важна.
Разработчики в такие моменты нередко говорят: “ну у вас же есть таймстамп получения уровня, вот все что после него — как раз и бои на этом уровне, считайте у себя сами”. Аналитики в этот момент страдают и дуреют. Другой вариант — когда гейм получает информацию о профиле пользователя от меты и потом прицепляет ее к отправляемым событиям. И тут нехорошо становится уже разработчикам, еще на этапе обсуждения идеи. Обогащение на стороне базы данных аналитиков в момент получения событий от проекта — хорошее решение, но не без нюансов и весьма замороченное. Как минимум потому что может быть рассинхрон между временем получения события (особенно ярко это видно, когда событие от меты приходит раньше события от клиента).
В общем, при дизайне событий для логирования надо подробно погружаться в организацию проекта и много общаться с разработчиками. В идеале, наверное, вообще стоит какие-то навыки системного аналитика получить, но не уверен, статистика и продуктовое мышление все же важнее.
К слову, про мету и гейм-серверы недавно вышла неплохая статья. Она больше для разработчиков, но и аналитикам может быть полезна.
#datamodel
Вот очень простая ситуация. Допустим, мы хотим посмотреть, сколько боев делают пользователи на каждом уровне. Казалось бы — есть событие завершения боя, группируйся по уровню, и все хорошо. Но нет. Потому что в шутерах обычно есть такая сущность, как гейм-сервер, который собирает пользователей в бой и, собственно, ведет бой, считает киллы и прочее. С него же и отправляется событие со статой по бою (в нашем кейсе по старту/завершению боя).
Однако есть нюанс — гейм-сервер ничего не знает про уровни пользователя, это не его задача. Эта информация хранится на мета-сервере, где профиль игрока, все вычисления и начисления. Еще есть клиентская стата, с всяким логами ui и FPS, но в этом кейсе она не столь важна.
Разработчики в такие моменты нередко говорят: “ну у вас же есть таймстамп получения уровня, вот все что после него — как раз и бои на этом уровне, считайте у себя сами”. Аналитики в этот момент страдают и дуреют. Другой вариант — когда гейм получает информацию о профиле пользователя от меты и потом прицепляет ее к отправляемым событиям. И тут нехорошо становится уже разработчикам, еще на этапе обсуждения идеи. Обогащение на стороне базы данных аналитиков в момент получения событий от проекта — хорошее решение, но не без нюансов и весьма замороченное. Как минимум потому что может быть рассинхрон между временем получения события (особенно ярко это видно, когда событие от меты приходит раньше события от клиента).
В общем, при дизайне событий для логирования надо подробно погружаться в организацию проекта и много общаться с разработчиками. В идеале, наверное, вообще стоит какие-то навыки системного аналитика получить, но не уверен, статистика и продуктовое мышление все же важнее.
К слову, про мету и гейм-серверы недавно вышла неплохая статья. Она больше для разработчиков, но и аналитикам может быть полезна.
#datamodel
Интересно, конечно. И не очень радостно, конкуренция все-таки двигатель прогресса. Мне больше нравились AppAnnie, ST как-то совсем не зашел. Да и API мне чем-то не понравилось, было достаточно бедным. У AppAnnie API хоть и замороченное, но зато с кучей данных. Главное теперь, чтобы Appmagic не съели.
Forwarded from App2Top - про геймдев раньше всех
Sensor Tower покупает data.ai (бывшую App Annie)
Консолидация на рынке мобильной аналитики. Cервис Sensor Tower объявил о приобретении своего ключевого конкурента — data.ai
Сумма сделки не оглашается.
#Sensow_Tower #data_ai
Консолидация на рынке мобильной аналитики. Cервис Sensor Tower объявил о приобретении своего ключевого конкурента — data.ai
Сумма сделки не оглашается.
#Sensow_Tower #data_ai
Недавно наткнулся на пару статей по product analytics framework. Так как я в последнее время тяготею к подобным методологическим размышлениям, читал с большим интересом. Фреймворки в этих статьях очень разные и от этого только интереснее. Этот и следующий посты посвящу им.
Первая статья сразу дает определение: “A product analytics framework is a system for analyzing user interactions with a product to understand their needs and preferences, inform decision-making, and improve user experience”. Это очень инструментальный фреймворк, который в качестве ключевых компонентов рассматривает разные методы анализа:
- Segment analysis
- Cohort analysis
- Customer journey analysis
- Funnel analysis
- Trend analysis
- Conversion analysis
- Attribution analysis
- Churn analysis
- Retention analysis
В статье достаточно подробно расписывается каждый пункт (вообще, в этом блоге куча весьма интересных ссылок, я по ним как по википедии ползал достаточно долго).
Такая сильная ориентированность на различные методы понятна — этот фреймворк предложен аналитическим сервисом, который делает инструменты для продуктовых команд. По сути они рассказывают о конструкции своего сервиса. Поэтому сами методы описаны сильно беднее, чем могли бы быть на самом деле — в своей практике их надо дорабатывать и наполнять глубиной и гибкостью.
Собственно, в этом и слабость этого фреймворка, на мой взгляд — он не дает стратегии исследования, не помогает приоритизировать задачи. А самое главное, не особо помогает понять, как соотнести метод и его результаты с “inform decision-making, and improve user experience” — для этого уже желателен опыт в аналитике.
Тем не менее, список методов хорош, я даже над некоторыми хочу поглубже подумать (типа Customer journey analysis). Джунам и для вопросов кандидатам на собесах так вообще полезно. Да и сама попытка построить фреймворк аналитики не на основе иерархии метрик мне тоже любопытна.
Первая статья сразу дает определение: “A product analytics framework is a system for analyzing user interactions with a product to understand their needs and preferences, inform decision-making, and improve user experience”. Это очень инструментальный фреймворк, который в качестве ключевых компонентов рассматривает разные методы анализа:
- Segment analysis
- Cohort analysis
- Customer journey analysis
- Funnel analysis
- Trend analysis
- Conversion analysis
- Attribution analysis
- Churn analysis
- Retention analysis
В статье достаточно подробно расписывается каждый пункт (вообще, в этом блоге куча весьма интересных ссылок, я по ним как по википедии ползал достаточно долго).
Такая сильная ориентированность на различные методы понятна — этот фреймворк предложен аналитическим сервисом, который делает инструменты для продуктовых команд. По сути они рассказывают о конструкции своего сервиса. Поэтому сами методы описаны сильно беднее, чем могли бы быть на самом деле — в своей практике их надо дорабатывать и наполнять глубиной и гибкостью.
Собственно, в этом и слабость этого фреймворка, на мой взгляд — он не дает стратегии исследования, не помогает приоритизировать задачи. А самое главное, не особо помогает понять, как соотнести метод и его результаты с “inform decision-making, and improve user experience” — для этого уже желателен опыт в аналитике.
Тем не менее, список методов хорош, я даже над некоторыми хочу поглубже подумать (типа Customer journey analysis). Джунам и для вопросов кандидатам на собесах так вообще полезно. Да и сама попытка построить фреймворк аналитики не на основе иерархии метрик мне тоже любопытна.
Второй фреймворк продуктовой аналитики больше посвящен процессу разработки продукта и принятию решений. Он не столь строго сформулирован, как первый, но общую идею все же можно вычленить: “a framework that helps to gain clarity and confidence to develop a product while also providing an effective tool to communicate priorities to the team”.
Фреймворк четко связывается с этапами разработки продукта в периоде от концепции до начала оперирования и ключевыми задачами, которые стоят перед аналитиками на этих этапах. Грубо говоря, на какие вопросы должна отвечать аналитика в каждом периоде разработки проекта. Так, при работе с MVP (Minimum Viable Product) в сферу задач аналитиков входят следующие пункты:
- segment analytics (to better target their audience)
- customer journey mapping (touchpoints and interactions customers have with the product throughout their journey)
- core event logging (to identify critical success metrics that align with the product’s objectives)
- experimentation (to test hypotheses and refine the product)
Здесь меньше ориентации на какие-то конкретные методы и инструменты и больше бизнес-вопросов, ответы на которые нужны продакт-менеджерам / продюсерам. И в этом смысле этот фреймворк полезнее, чем просто перечисление методов — он позволяет соотнести работу аналитика с бизнес-задачами. Что, на самом деле, встречается реже, чем хотелось бы.
Тем не менее, у подобного подхода есть, на мой взгляд, свои недостатки. Во-первых, он практически не затрагивает весьма большой этап оперирования — как будто там все понятно и просто нужно поддерживать то, что уже есть. А во-вторых, он оставляет аналитикам несколько реактивную роль — перечисленные вопросы-задачи помогают принять решение относительно альтернатив, но вряд ли показывают путь к радикальным изменениям / пивотам.
И в этом фреймворке, и в предыдущем лично мне не хватает важного измерения, вопроса “а почему пользователи ведут себя именно так?”. Один фреймворк останавливается на каких-то измерениях, второй — на ключевых бенчмарках. Но и тот, и другой весьма косвенно, через верхнеуровневые метрики обращаются к мотивации / потребностям пользователя и тому, как продукт их удовлетворяет. Впрочем, думаю, это нормально для функциональных продуктов, но может быть недостаточно для гедонистических продуктов типа игр.
Фреймворк четко связывается с этапами разработки продукта в периоде от концепции до начала оперирования и ключевыми задачами, которые стоят перед аналитиками на этих этапах. Грубо говоря, на какие вопросы должна отвечать аналитика в каждом периоде разработки проекта. Так, при работе с MVP (Minimum Viable Product) в сферу задач аналитиков входят следующие пункты:
- segment analytics (to better target their audience)
- customer journey mapping (touchpoints and interactions customers have with the product throughout their journey)
- core event logging (to identify critical success metrics that align with the product’s objectives)
- experimentation (to test hypotheses and refine the product)
Здесь меньше ориентации на какие-то конкретные методы и инструменты и больше бизнес-вопросов, ответы на которые нужны продакт-менеджерам / продюсерам. И в этом смысле этот фреймворк полезнее, чем просто перечисление методов — он позволяет соотнести работу аналитика с бизнес-задачами. Что, на самом деле, встречается реже, чем хотелось бы.
Тем не менее, у подобного подхода есть, на мой взгляд, свои недостатки. Во-первых, он практически не затрагивает весьма большой этап оперирования — как будто там все понятно и просто нужно поддерживать то, что уже есть. А во-вторых, он оставляет аналитикам несколько реактивную роль — перечисленные вопросы-задачи помогают принять решение относительно альтернатив, но вряд ли показывают путь к радикальным изменениям / пивотам.
И в этом фреймворке, и в предыдущем лично мне не хватает важного измерения, вопроса “а почему пользователи ведут себя именно так?”. Один фреймворк останавливается на каких-то измерениях, второй — на ключевых бенчмарках. Но и тот, и другой весьма косвенно, через верхнеуровневые метрики обращаются к мотивации / потребностям пользователя и тому, как продукт их удовлетворяет. Впрочем, думаю, это нормально для функциональных продуктов, но может быть недостаточно для гедонистических продуктов типа игр.
Всем привет. Пара вакансий из моего малого чата аналитиков (т.е. это не холодные ссылки и не реклама).
Junior+ / Middle позиция на Merge3-проект. Совсем без опыта не берут, нужен хотя бы небольшой опыт в аналитике / геймдизайне и общее понимание продуктовых особенностей f2p-игр. Детали вакансии здесь, вопросы можно задавать @Jerl_S. Чего нет по ссылке: проект на этапе софтлонча, но активно наполняется контентом, задач много. Полная удаленка, оформление на ИП, зарплата в евро. Или релокация в Молдову.
Middle+ / Senior позиция на хардкорную MMO RPG. Когда я в последний раз общался с ребятами, они рассказывали смешные байки про кланы и их аналитику, а так же про драйв общения с кланлидами. Чем изрядно пошатнули мой скепсис относительно быстрой и наглядной эффективности социальных механик для метрик удержания. Детали вакансии здесь, вопросы можно задавать @Nordskolian.
Junior+ / Middle позиция на Merge3-проект. Совсем без опыта не берут, нужен хотя бы небольшой опыт в аналитике / геймдизайне и общее понимание продуктовых особенностей f2p-игр. Детали вакансии здесь, вопросы можно задавать @Jerl_S. Чего нет по ссылке: проект на этапе софтлонча, но активно наполняется контентом, задач много. Полная удаленка, оформление на ИП, зарплата в евро. Или релокация в Молдову.
Middle+ / Senior позиция на хардкорную MMO RPG. Когда я в последний раз общался с ребятами, они рассказывали смешные байки про кланы и их аналитику, а так же про драйв общения с кланлидами. Чем изрядно пошатнули мой скепсис относительно быстрой и наглядной эффективности социальных механик для метрик удержания. Детали вакансии здесь, вопросы можно задавать @Nordskolian.
NEWHR выпустили очередной отчет по исследованию рынка продуктовых и дата-аналитиков.
Из очевидно полезного — список задач и их регулярность (хорошо помогает от иллюзий “мы тут ML пилим 25/8”), зарплаты YoY по грейдам, длительность поиска работы в зависимости от локации.
Из любопытного — доля респондентов с опытом 6 и более лет всего 16%. Вполне себе маркер, на мой взгляд, насколько же молодая дисциплина у нас. Ну или насколько сеньоры тихушники, а то есть за ними такой грех.
Еще многие работают на двух работах. Тут для меня два момента — инди-командам редко когда нужен аналитик на фуллтайм, поэтому вполне можно вести несколько таких проектов. А во-вторых, это может быть еще одним подтверждением тренда, когда эксперты/сеньоры стараются разнообразить свою жизнь новыми продуктами и задачами, консультируя сторонние проекты.
В целом отчет проходной, на мой вкус — глубоких инсайтов нет, слишком широкое поле. Но мониторить настроения помогает.
Из очевидно полезного — список задач и их регулярность (хорошо помогает от иллюзий “мы тут ML пилим 25/8”), зарплаты YoY по грейдам, длительность поиска работы в зависимости от локации.
Из любопытного — доля респондентов с опытом 6 и более лет всего 16%. Вполне себе маркер, на мой взгляд, насколько же молодая дисциплина у нас. Ну или насколько сеньоры тихушники, а то есть за ними такой грех.
Еще многие работают на двух работах. Тут для меня два момента — инди-командам редко когда нужен аналитик на фуллтайм, поэтому вполне можно вести несколько таких проектов. А во-вторых, это может быть еще одним подтверждением тренда, когда эксперты/сеньоры стараются разнообразить свою жизнь новыми продуктами и задачами, консультируя сторонние проекты.
В целом отчет проходной, на мой вкус — глубоких инсайтов нет, слишком широкое поле. Но мониторить настроения помогает.
Пока болтался в отпуске, попалась на глаза статья от X5 Tech про разметку событий. Какой трекер они выбрали, как называть события, какая логика организации параметров. То, что я называю “дизайном событий” и что вполне может занимать до трети рабочего времени аналитика на ранних этапах проекта (потом, конечно, существенно меньше).
Статья в целом симпатичная, сам буквально неделю назад думал над правилами названия событий и в целом над структурированием своей документации. В геймдеве набор сущностей, действий и процессов ощутимо сложнее, кажется, чем приведенные. Тем не менее подходы и идеи все равно весьма схожи.
Но самое полезное в статье, на самом деле — не очень заметная ссылка на полную документацию по разметке событий. Она намного полнее и понятнее, чем статья, содержит в себе определения основных понятий, правила создания и ведения разметки, а также описание процессов разметки.
Очень хочется свою документацию довести до схожего вида, ведь примерно половина уже есть. Мечты-мечты.
#datamodel
Статья в целом симпатичная, сам буквально неделю назад думал над правилами названия событий и в целом над структурированием своей документации. В геймдеве набор сущностей, действий и процессов ощутимо сложнее, кажется, чем приведенные. Тем не менее подходы и идеи все равно весьма схожи.
Но самое полезное в статье, на самом деле — не очень заметная ссылка на полную документацию по разметке событий. Она намного полнее и понятнее, чем статья, содержит в себе определения основных понятий, правила создания и ведения разметки, а также описание процессов разметки.
Очень хочется свою документацию довести до схожего вида, ведь примерно половина уже есть. Мечты-мечты.
#datamodel
В канале GameDev Reports - by devtodev недавно было разбор исследования особенностей платящих пользователей, которое провела компания Mistplay. Исходный отчет и ссылка на русскоязычный разбор здесь.
В отчете много разного, от отношения к рекламе до платежных паттернов и построения персон. Есть достаточно любопытные цифры. Например, согласно отчету и пересказу, “81% мидкорных пользователей совершает первую покупку в течение первого месяца. 7% для этого нужен только 1 день”. Или что “мотиваторы для совершения покупок - это прогрессия (54%) и получение удовольствия (44%)”. Есть даже целая иерархия, зачем пользователи играют в мобильные игры, по убыванию от “провести время и развлечься” до “стать лучшим в чем-то”.
Тем не менее, в исследовании есть большая ложка методологического дегтя. Потому что исследование основано на изучении поведения 2к платящих пользователей из США и Канады, которые активно используют платформу Mistplay. Mistplay — платформа play-to-earn: пользователь через Mistplay устанавливает и запускает игру, играет и получает внутренние очки, которые потом может обналичить через Amazon gift card или другими путями (вот тут есть подробнее). Если я правильно понял схему, то пользователь получает немного виртуальных денег, разработчики — инсталлы, Mistplay — деньги за привлечение пользователей.
Мы же получаем искаженную выборку, так как далеко не все разработчики используют Mistplay (т. е. мы не знаем, по пользователям каких игр сделаны выводы). И платящие пользователи, пришедшие через Mistplay, не факт что репрезентативны относительно всей совокупности платящих. Это приводит к грустно-забавным казусам, когда к хорошо платящим относят пользователей с $100 суммарно заплаченного в Q4 2023. Или что пользователям платформы повышения лояльности неожиданно очень нравятся программы лояльности и разные формы кэшбэка.
В результате исследование получилось любопытным, но с некоторыми не очень очевидными искажениями, которые надо учитывать. С другой стороны, я теперь могу сравнить свои цифры с совсем внешним источником. Да и еще одна реализации механики кэшбека мне понравилась, не одними VIP-уровнями едиными, в конце концов.
В отчете много разного, от отношения к рекламе до платежных паттернов и построения персон. Есть достаточно любопытные цифры. Например, согласно отчету и пересказу, “81% мидкорных пользователей совершает первую покупку в течение первого месяца. 7% для этого нужен только 1 день”. Или что “мотиваторы для совершения покупок - это прогрессия (54%) и получение удовольствия (44%)”. Есть даже целая иерархия, зачем пользователи играют в мобильные игры, по убыванию от “провести время и развлечься” до “стать лучшим в чем-то”.
Тем не менее, в исследовании есть большая ложка методологического дегтя. Потому что исследование основано на изучении поведения 2к платящих пользователей из США и Канады, которые активно используют платформу Mistplay. Mistplay — платформа play-to-earn: пользователь через Mistplay устанавливает и запускает игру, играет и получает внутренние очки, которые потом может обналичить через Amazon gift card или другими путями (вот тут есть подробнее). Если я правильно понял схему, то пользователь получает немного виртуальных денег, разработчики — инсталлы, Mistplay — деньги за привлечение пользователей.
Мы же получаем искаженную выборку, так как далеко не все разработчики используют Mistplay (т. е. мы не знаем, по пользователям каких игр сделаны выводы). И платящие пользователи, пришедшие через Mistplay, не факт что репрезентативны относительно всей совокупности платящих. Это приводит к грустно-забавным казусам, когда к хорошо платящим относят пользователей с $100 суммарно заплаченного в Q4 2023. Или что пользователям платформы повышения лояльности неожиданно очень нравятся программы лояльности и разные формы кэшбэка.
В результате исследование получилось любопытным, но с некоторыми не очень очевидными искажениями, которые надо учитывать. С другой стороны, я теперь могу сравнить свои цифры с совсем внешним источником. Да и еще одна реализации механики кэшбека мне понравилась, не одними VIP-уровнями едиными, в конце концов.
Задачка по следам одного из неожиданных рабочих обсуждений.
У вас PC-проект, нужно построить график DAU с разбивкой по пользовательским группам, например по уровню (или лиге). Какие события будете использовать, как построите процесс подготовки данных для дашборда? Какие могут быть подводные камни?
Мое решение дам завтра или через день.
#exercises
У вас PC-проект, нужно построить график DAU с разбивкой по пользовательским группам, например по уровню (или лиге). Какие события будете использовать, как построите процесс подготовки данных для дашборда? Какие могут быть подводные камни?
Мое решение дам завтра или через день.
#exercises