Читаю Талера, "Новая поведенческая экономика". Сама по себе книга любопытная, но для меня это больше введение в историю поведенческой экономики от одного из ее лидеров. Слишком уж много в ней малоинтересных для меня экспериментов или наблюдений.

Однако одно наблюдение, описанное буквально в первых главах, вполне отозвалось. Талер пересказывает исследование Repositioning Dynamics and Pricing Strategy (Ellickson, Misra, and Nair 2012). Если коротко, то магазины, делающие эпизодические распродажи, оказываются в большем выигрыше, чем те магазины, которые придерживались стратегии низких цен. Это мне напомнило мое недоумение от регулярных х3-распродаж в одном из проектов, с которым я работал.

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

Обсуждали тут с @dkd_kdk проблемы трекинга стоимости того или иного слоя контента. Мое наивное "так есть же движение ресурсов, а курс харды мы знаем" быстро оказалось повержено. Когда у тебя экономика вся на харде (то есть, покупаешь за реал только харду, а ее тратишь на все остальные предметы и ресурсы), движение ресурсов действительно помогает. Но в проектах, где большая часть контента продается за прямые платежи (в частности в офферах), так, видимо, не работает. И если оптимальный для своих проектов формат трекинга движений ресурсов я выработал, то вот с группой событий платежей и их информативностью / полезностью, чую, у меня могут быть некоторые пробелы.

У Ариэли в "Предсказуемой иррациональности" в одной из первых глав описывается ситуация, когда компании заставили раскрывать зарплаты топ-менеджеров, и вместо планируемого снижения разрыва зарплат топов и рядовых сотрудников это привело к обратной ситуации --- росту зарплат топов. Потому что люди сравнивают себя с другими и хотят так же. И тут же мне вспомнились глобальные извещения в Magic Rush (старенький баттлер, я начал играть в него году в 2015 примерно и с тех пор раз в год ставлю и вспоминаю). Извещения вида "ХХХ получил легендарного героя YYY". Вроде как не очень заметная штука, но вполне может работать на общее количество круток гачи, так как использует тот же механизм сравнения и легализации --- "этот получил, значит и я могу, стоит попробовать".
Было бы интересно простестировать, но разработка глобальных оповещений, издержки от информ.шума в лобби проекта и подобное делает подобный тест весьма сложно реализуемым, к сожалению. С другой стороны, исключающий аб-тест тоже будет сложно провести (у нас в одном из продуктов есть такая фича, как оказалось), если только не затеят глобальную переработку ui или не продать фичу командам новых проектов.

Я все понимаю, но product_id / unified_product_id / company_id вида 20600013730899 (или еще длинее) в appannie — это где-то за гранью разумного. Даже таймстампы в миллисекундах не так раздражают.

В ODS#analytics пробежал хороший вопрос, перескажу его и коментарии. "Что делать, когда мы хотим в аб-тесте оценить влияние фичи на монетизацию, но знаем, что даже в тестовой группе ею воспользуются не все". Стандартный подход -- сравниваем тест и контроль, смотрим аплифт и разницу, и оцениваем значимость различий. Ребята в комментариях предлагают еще два решения. Первое -- триггеринг, то есть определить параметры и выбрать минимальную подгруппу, которая потенциально может воспользоваться фичей. Второй вариант -- матчинг. В тестовой группе по параметрам пользователя учимся определять, воспользуется ли он фичей, а потом в контрольной группе фильтруем тех, кто вероятнее всего воспользовался бы фичей, если бы попал в тестовую группу, и уже эти группы сравниваем.

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

Rush Royale сделали коллаб с Bubble и их комиксом Майор Гром. Надо будет узнать, как они выбирали коллаб и как будут оценивать его эффективность / что в целях. А то как-то в моем опыте это достаточно сомнительное дело, хорошо если затраты на арт и разработку ивентов отбить получалось.

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

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

@konhis и гдд, регулярный ивент