Грустные вайбы "quality of life фич" и "фич N-ой линии приоритета (N > 10)". А уж сколько из них касается аналитических событий и хотелок...
Я вот как-то полгода ждал, чтобы в опросы SurveyMonkey начали из инбоксов прокидывать некоторую полезную информацию.

Недавно во время одного из рабочих созвонов сформулировал ряд сомнений про офферы и концепции их формирования.

Допустим, у вас вся экономика и лайвопс стоят на офферах (предложениях купить со скидкой контент / ресурсы и т. д.). А покупки в банке если кто и делает, то это незначительная доля в структуре платежей (в отличие от тех же *scapes от Playrix, где, насколько я помню, преимущественно покупки харды в банке).

Я знаю две системы, какие офферы и когда мы показываем пользователю. Первая — триггерная. То есть у пользователя разлочился новый контент, и мы даем ему оффер с ним. Или пользователь проиграл / потратил энергию и мы даем ему в этом месте оффер. Эти офферы предполагают немедленную яркую потребность пользователя в контенте или ресурсах.

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

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

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

Если у вас есть примеры других систем офферов или опыт их оптимизации — расскажите, пожалуйста.

Dev2dev выпустили еще одну методичку, теперь по монетизации проектов. Внутри весьма обыденно — классическое перечисление метрик и их взаимосвязей, ничего про оперирование и принятие продуктовых решений на основе этих метрик. Несколько бестолковый блок по ARPU и привычная маета с разделением cumARPU и LTV (кажется, это вообще тема отдельного разговора). Плюс выделение Social LTV и фактора виральности, при этом нет про ad monetization.

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

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

Мне кажется, что-то в таком подходе есть — каким бы ни был интересным концепт, игнорировать глобальные тренды или не очень четко очерчивать ЦА и ее потребности все же не стоит. Да и понимание рынка растет.

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

В общем, не знаю. Будем пробовать, видимо.

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

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

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

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

В чате по монетизации кто-то искал эксперта "по играм с успешными кейсами. Нужно помочь сформировать kpi для игр". Мой ответ местные умельцы сразу же засунули в генератор мемов. Впрочем, суть все равно та же — так или иначе, на мой взгляд, деньги и окупаемость и есть основной критерий успеха игры (особенно f2p). Собственно, это одна из причин, почему применение в геймдеве фреймворка north star метрик кажется мне сомнительной затеей.

Сегодня в 18 по Лондону Валера Бабушкин и Стас Носуленко (AliExpress) будут разговаривать про Marketing Mix Modeling. Что это, зачем, какие подводные камни (а точнее рифы) могут быть и так далее.

Тема будет интересна больше маркетинговым аналитикам. Мы некоторое время назад смотрели на MMM, но до реального выведения в прод не дошли.

https://www.tgoop.com/cryptovalerii/445


UPD: запись встречи https://youtu.be/rSZFKDqH5eA

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

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

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

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

Пока я болтался в отпуске, вышла книга собрата по потанинской песочнице Даниила Ханина “Юнит-экономика для стартапов и бизнеса”. У него было много статей, обучающих видео и прочего, и вот до книги дозрел.

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

Весьма симпатично и понятно через концепцию юнитов масштабирования и историю доткомов показана смена фокуса с товаров на пользователей. Что в свою очередь приводит к концепции когортных метрик и LTV. Мне самому не хватало такого теоретического контекста, будет хоть что студентам рассказать.

Даниил много работал со стартапами, поэтому книга не столько по юнит-экономике, сколько по построению фин.модели стартапа и поиску точек роста в ней. Притом стартапы в его примерах — не цифровые, поэтому некоторые нюансы будут непривычны тем, кто работает с цифровыми продуктами.

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

#books

Признаться, я не люблю UI-аналитику. Мороки с ней много, а влияние на выручку сомнительное. Крупные косяки на плейтестах видно, а мелкие… раз они мелкие, то ими можно пренебречь или положить в бэклог и брать в работу, когда появляется свободное время.

Тем не менее мы кое-что собираем. Во-первых, это тапы пользователей по кнопкам, с трекингом на каком экране тап / откуда и куда переход. Эти данные крутят UI-дизайнеры, я лично их старательно избегаю. Во-вторых мы иногда трекаем поведение пользователя во время боя. Чаще всего это просто координаты смерти/убийства, потом для левел-дизайнеров рисуем хитмапы по ним. Но вот буквально недавно левел-дизайнеры запросили еще и перемещения по карте, чтобы выловить холодные места, по которым пользователи не ходят. Посмотрим, что за картинки получатся.

Помимо спорной (с точки зрения продуктовой аналитики) ценности UI-данных, есть еще одна особенность, которую приходится учитывать — количество этих данных. Когда мы несколько лет назад стали собирать тапы со всего DAU, команда DWH весьма горячо высказала нам свое неодобрение. Поэтому если дизайнить сбор UI-данных, надо сразу закладывать ограничение, чтобы данные собирались только по части аудитории. Да хотя бы примитивный фильтр встроить, типа sample(1:20, 1) == 1, или другой рубильник, который позволит открыть фичу только на часть аудитории. Глобальная связность данных пользователя тут необязательна, главное, чтобы в рамках сессии/боя они были целостны. Ну и хранить их дольше месяца вряд ли нужно.

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

Вообще, предсказание оттока в геймдеве достаточно специфичная задача. Почему-то больше всего говорят о ней wannabe-аналитики и соискатели на собесах, когда рассказывают, какой бы ml они хотели делать. Лично в моей практике полезнее даже не исследования оттока, а более точечный анализ отвалов (на каком уровне/локации/лиге) на старте игры.

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

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

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

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

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

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

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

Если вы где-то видели хорошие определения, что такое игровая экономика/монетизация, или же просто знаете хорошие материалы про это — пришлите мне, пожалуйста.

Мои прекрасные друзья из Lategame/Krista ищут себе опытного продуктового аналитика. Формальное описание вакансии здесь. Фуллтайм, удаленка.

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

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

В общем, если вы такой человек или знаете, кому это может быть интересно -- напишите мне, пожалуйста.

Сижу, читаю ГДД по новой фиче — скоро релиз и разрабам нужен дизайн события логирования. В разделе “Аналитика” вижу запрос: “Как повлияла фича на дальнее удержание?”

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

С другой стороны — ответить на такой вопрос весьма непросто. A/B-тесты лучший и самый надежный вариант, конечно. Но тестировать вклад крупных фич в A/B-тестах бывает затруднительно — может не быть инструментов A/B-тестов, фичу может быть трудно выдать только части аудитории, банально может не хватать выборки и т. д.

В результате остаются только косвенные методы, близкие по духу casual inference идеям. В частности, взять (не)доживших до day X и сравнить их, насколько они различаются по использованию фичи. Попутно можно саму выборку кластеризовать на несколько близких по разным метриками групп (по метрикам активности, например) и сравнивать пользователей внутри кластеров. Одна проблема с таким методом: воспользовавшиеся фичой и не воспользовавшиеся — принципиально разные люди, с разным поведением и мотивами, и это стоит учитывать в выводах.

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

P.S. спасибо коллегам из чатов аналитиков за обсуждение темы и интересные идеи.

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

И ладно если метрики относительно прозрачные, типа эффективности юнита в бою. Можно пробовать и смотреть разное — kills / spawn, damage / health, damage / time_in_battle, что угодно. Измерить просто, сравнить по ценности — тоже.

А иногда интересны такие вещи, на которые сидишь, смотришь и думаешь, как тот волче — “а как тебя операционализировать-то?”. Через какое наблюдаемое поведение мы можем делать вывод о том, что происходит с пользователем?

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

Но как вот это “не нравится” измерять? Спрашивать бессмысленно, пользователи сами не знают, что происходит или будут конструировать объяснение. Тестировать A/B-тестами количество ботов можно, но это локальное и тактическое решение, да и не всегда возможное. Ко всему прочему, надо всегда учитывать, какие рычаги для изменения метрики у нас есть.

Поэтому приходится останавливаться на весьма бедных интерпретациях — “не нравится == не пошел в следующий бой”, “не нравится == вышел из боя в первые секунды” и тому подобных. Можно, конечно, начать с вопроса “почему не нравятся боты”, но это отдельное (в идеале качественное) исследование, на которое может не быть ресурсов или квалификации.

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

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

Несколько лет назад в одном из проектов обсуждали, нужны ли боты на старте игры. Надо, не надо, сколько первых боев с ботами делать и так далее. Аргументы “против” понятные — ботов надо делать (мозги придумывать и все такое), боты могут не нравиться пользователям, тюнить ботов по сложности и человекоподобности — отдельное сомнительное развлечение, да и при полноценной заливке может быть достаточно пользователей для наполнения матчмейкинга людьми и т. д.

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

Но есть еще один аргумент “за”, о котором я, признаться, даже и не подумал тогда. Если мы делаем бои на всю аудиторию, сугубо pvp и без ботов, то это надо поднимать достаточное количество гейм-серверов. Но при ретеншене порядка 35-45% мы в первые несколько боев безвозвратно теряем больше половины игроков. Соответственно, зачем тратить деньги на геймы, если можно сделать ботов и пользователи будут играть с ними на клиенте первые бои?

Таким образом, понимание метрик ретеншена и игровой активности в первый день помогло принять решение по ботам, озадачить разрабов реализацией боев на клиенте и, по словам СТО, сократить расходы.

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

А в аналитике хотят разного. Очень видно качественно иной подход — больше метрик вовлечения, больше акцент на отвалы, на боевые статистики, на ладдеры коммьюнити-ивентов и тому подобное. От некоторых запросов вообще накрывает флешбеками многолетней давности, когда сидишь, смотришь на сырую табличку по пользователям из d2d, и единственное, что можешь оттуда вытянуть — rolling retention. Эхо тех сумеречных эпох, когда хранили только последний стейт пользователя, а не все логины-логауты и промежуточные логи.

Несмотря на все мое ворчание, интересно посмотреть, как оно будет работать в оперировании (пока только закрытая бета). Мы много работаем с метриками монетизации и экономики, но вот тот же отток обычно смотрим с точки зрения “китам что-то не нравится”. Бездушные “донатные сосалки” (c) однако, а тут высокий и тонкий мир ПК-бояр со своей атмосферой.

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

Немного технических страданий (после пары недель плохого самочувствия все равно ничего более осмысленное сказать не получается). Некоторое время назад тихо-мирно тестировал скрипт для агрегации данных под дашборды. Краем глаза увидел вот такой варнинг: FutureWarning: The default value of regex will change from True to False in a future version.

То есть в следующей версии (а точнее уже в текущей, так как у меня локально стоит древняя) все выражения вида pd.Series.str.replace(’[0-9]’, ‘’) перестанут работать. Потому что раньше паттерн [0-9] по умолчанию интерпретировался как regex, а сейчас — как строка.

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

А мы как раз недавно обновили Airflow, который потребовал новых панд.

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

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

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

И вот мы видим, что один сегмент просел. То есть после одного из изменений пользователи с таким количеством боев стали хуже возвращаться. Но не настолько хуже, чтобы объяснить общее снижение ретеншена. Оказалось, что еще часть просадки была обусловлена изменением структуры аудитории — пользователей с небольшим количеством боев (и, соответственно, с не очень высоким удержанием) стало существенно больше.

Почему так произошло (просел один сегмент и изменилась структура сегментов) — вопрос отдельного размышления и исследований. Это следующий шаг в понимании, почему изменилась метрика.

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

В общем, доли, парадокс Симпсона и его вариации.

NB. Пример навеян недавними задачами, но все же во многом искусственный и упрощенный.