АБ-тесты - это не только ценный мех… Но еще и процессы.
Цикл постов про АБ-тестирование. Пост 1.

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

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

При этом для офлайн-бизнеса внедрение АБ-тестирования во многом организационная, а не математическая проблема.

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

С точки зрения бизнес-процессов компании АБ-тестирование - часть инвестиционного цикла проектов и продуктов, за который отвечает финансовое подразделение. Внутри инвестиционного цикла АБ-тестирование – это один из способов дизайна и оценки пилотных экспериментов компании для того, чтобы принять решение о дальнейших инвестициях в проект.

Обобщенно инвестиционный цикл можно разбить на этапы:

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

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

- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.

- Разработка MVP. Разрабатывается прототип решения.

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

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

Как тут помогает АБ тестирование: математически корректная методика дизайна и оценки результатов экспериментов дает возможность сделать правильные выводы о ценности разработанного MVP.

- Инвестиционный комитет по процедурам компании для решения о том, идет ли проект дальше по циклу.

- Ролл-аут. Осуществляется внедрение проекта на все целевые объекты в масштабе компании.

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

Прежде всего - контрфактические методы причинно-следственного анализа. Мы писали о них в начале года (тут, тут и тут).

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

Эту структуру полезно иметь в виду при интеграции АБ-тестирования в бизнес-процессы компании.

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

#business #ab_testing

#ltv #AB #statistics

Проведение A/B тестов над LTV.

Учитывая, что LTV - метрика с достаточно долгим сроком прогнозирования (от месяцев до лет), очевидным образом у нас может возникнуть вопрос - а как это тестировать то? Кажется, что при скорости A/B тестов 1 раз в полгода-год, конкуренты легкой лунной походкой обойдут нас на всех поворотах и вырвутся в лидеры. Потому надо что-то делать. 

В принципе, проблему A/B тестирования LTV можно свести к более общей проблеме оценки Long-term эффектов. Этой проблеме даже посвятили отдельный раздел в paper’е Рона Кохави и Лукаса Веермеера “Top Challenges from the first Practical Online Controlled Experiments Summit”. Давайте посмотрим на предлагаемые индустрией решения этой проблемы.

Итак, что же нам предлагают исследователи из разных компаний:

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

- Прокси-метрики.
Простой вариант - мы смотрим не на основную метрику, а на какой-то промежуточный показатель, который, как нам кажется, хорошо определяет поведение основного показателя. Например, для LTV это может быть retention, или user-engagement. То есть, вовлеченность пользователя может неплохо отражать его склонность тратить на нас деньги.
Но минус тут очевидный - “correlation may not imply causation”. Т.к. зависимость между метриками может и не быть реальной причинно-следственной связью. И тогда выводы на proxy не будут вести к улучшению главного показателя. 

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

- Суррогаты.
Можно сказать, что это своего рода расширение над прокси-метриками. В данном случае, мы ищем статистические суррогаты, которые находятся в графе причинно-следственных связей между treatment и outcome. И, что главное, имеют следующее свойство: treatment и outcome условно независимы при условии суррогата. При этом, нам не обязательно использовать только одну прокси-метрику для построения суррогата - мы можем построить вектор прокси-метрик, который будет иметь требуемое свойство.
Соответственно, из минусов у нас то, что нам надо строить какую-то причинно следственную модель, отбирать прокси-метрики в суррогат, пытаясь учесть все нужные прокси (что не так просто, как может показаться на первый взгляд).

Чтобы чуть углубитьcя в тему, давайте рассмотрим какой-нибудь из вариантов решения проблемы оценки Long-term эффектов. В следующей заметке я опишу использование статистических суррогатов на основе статьи от LinkedIn.

АБ-тесты. Интеграция в процесс пилотирования. Как выглядит типовой бизнес-процесс без АБ.
Цикл постов про АБ-тестирование. Пост 2.

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

В частности, мы определились, что наиболее важный этап инвестиционного цикла для АБ-тестирования - это этап пилотирования для понимания финансового эффекта от MVP какого-либо проекта.

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

Итак, бизнес-процесс пилота - еще до всяких АБ-тестирований - как правило, выглядит так:

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

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

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

- Согласование запуска пилота с операционной службой. Изменения в пилотной группе объектов должны быть согласованы с операционным подразделением. Коллегам непосредственно на местах необходимо будет обеспечить исполнение пилота.

- Проведение пилота. Реализация MVP на местах в пилотной группе при отсутствии изменений в контрольной группе. Если эти понятия, конечно, выделяются при отсутствии АБ-тестирования. Надо сказать, что чаще всего, выделяются.

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

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

В следующем посте рассмотрим риски, с которыми связан этот бизнес-процесс. И почему они формируются.

#business #ab_testing

АБ-тесты. Интеграция в процесс пилотирования. Риски типового бизнес-процесса без АБ
Цикл постов про АБ-тестирование. Пост 3

Бизнес-процесс, описанный в предшествующем посте цикла, связан со значительными рисками для компании:

- Риск некорректного финального решения о дальнейшем развитии проекта. Наиболее значимый риск среди всех. Как мы написали выше, компания идет по инвестиционному циклу вслепую. И очень важно понимать, что это связано не только с отсутствием АБ-тестирования в шаге оценки результатов пилотов. Даже если у вас стройная и правильная математика при оценке результата пилота, риски остаются и в других шагах:

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

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

- Нет единой методики/правил экстраполяции результатов пилота для расчета финансового эффекта на все объекты. Даже при суперкорректной статистической оценке результатов пилота на основе АБ, финальное решение об инвестициях в проект может оказаться некорректным, если нет правил его масштабирования на всю сеть. Получили +1% к выручке на 5 объектах. Можем ли сказать, что при ролл-ауте проекта, для всей сети будет +1% к выручке? Была ли выборка репрезентативна для всей сети? Можем ли назвать результаты пилота робастными? Например, 5 объектов пилота могли быть расположены в Сибири, а основные объекты компании расположены в Центральных регионах.

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

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

#business #ab_testing

Подытожим в одной картинке выводы последних двух постов цикла про АБ-тестирование: о бизнес-процессе пилотирования и его рисках.

P.S. Хочется выразить большую благодарность моим замечательным коллегам Анастасии Комович и Эдуарду Григоряну, которые вместе со мной в разное время долгие часы формировали концепцию внедрения АБ-тестирования в бизнес-процессы компаний. Без них понимания бизнес-процессов и того, что со всем этим делать, не состоялось бы.

#business #ab_testing

#ltv #AB #statistics

Использование суррогатных метрик в онлайн экспериментах.

https://telegra.ph/Online-Experimentation-with-Surrogate-Metrics-Guidelines-and-a-Case-Study-07-24

#ltv #libraries

Интересные библиотеки.

С библиотеками в плане расчета LTV не особо густо, но советую посмотреть пару библиотек.

Первая библиотека - lifetimes. Библиотека с реализацией алгоритмов и семейства Pareto/NBD моделей. Последние коммиты достаточно давно, но ее все же часто упоминают в разных материалах по предсказанию LTV. 

Вторая библиотека уже как-то встречалась в моих постах. Это - retentioneering. Не совсем про LTV, но там точно есть возможности построить из логов матрицу переходов и проделать над ней некоторые операции. Что сильно напоминает подходы с использованием Марковских цепей.

#libraries

Наткнулся на порт shiny for python. Знаю, что многие любители R его хвалят (сам не использовал, т.к. в R почти не залезал).

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

Вот страничка с примерами для shiny for python.

P.S. Серия про LTV закончилась, а новую я пока не стартовал (по некоторым понятным причинам). Так что пока будут разные мелкие заметки выходить.

АБ-тесты. Интеграция в процесс пилотирования. Что делать.
Цикл постов про АБ-тестирование. Пост 4.

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

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

Создание такого бизнес-процесса (далее - БП):

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

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

Необходимые атрибуты процесса взаимодействия бизнеса с командой АБ-тестирования: единое окно для подачи всех заявок на АБ, механизм приоритезации, чек-листы для подачи заявки на дизайн пилота и на оценку эффекта после пилота, SLA ответа на корректно поданную заявку.

Ключевой атрибут - это чек-листы. Рассмотрим их подробнее.

A. Чек-лист для подачи заявки на дизайн пилота в команду АБ, включающий как технику, так и бизнес-постановку.

Бизнес-часть:

- сведения о заказчике пилота (бизнес-подразделение, контакты);
- содержание пилота (что внедряем, почему это принесет эффект);
- категория приоритетности расчета. Пока у вас нет библиотеки или платформы АБ-тестирования и дизайны экспериментов требуют вовлечения DS-ов, необходимо выстроить процесс приоритезации заявок: какие проекты оцениваются в 1/2/3 очередь, какие - не оцениваются вообще. Основа критериев: бюджет проведения пилота (считается ли проект крупным с точки зрения инвестиционного цикла компании) и материальность ожидаемого эффекта для PnL компании (ждем ли реально большой пользы от проекта).

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

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

Б. Чек-лист для подачи заявки в команду АБ на оценку пилота. Здесь возможны 2 варианта:

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

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

#business #ab_testing

​​#competition

Немного похвастаюсь.

Поучаствовал в соревновании Цифровой Прорыв 2022. Задачкой была "Разработка концепции ранжирования районов города по уровню самодостаточности на основе больших данных". То есть, не классическое ML соревнование, а скорее соревнование презентаций, без явного лидерборда (хотя финальные оценки были для каждого). В принципе, подумал, что презентации я делаю лучше среднего DS'а, а анализирую лучше среднего консультанта, так что есть преимущество. Ну и плюсом было, что задачка интересная, а я когда-то занимался городским планированием в сфере наземного транспорта.

В итоге занял 1-е место.

Процесс примерно так проходил:
1. Выделил первые ключевые слова для поиска (self-sufficient city);
2. Наткнулся на концепцию 15(20)-минутного города, пошел уже по целевым словам этой идеи;
3. Отсюда получилась основная концепция - строим изохроны и рассчитываем количество жителей с доступностью к благу;
4. Реализовал первую версию в коде;
5. Стало понятно, что одной цифры мало, так что в итоге предложил еще и в матрицу BCG все уложить, взяв за оси среднюю доступность и разброс доступности;
6. Дошлифовал примеры, вытащил нужные данные, описал пути развития.

Итоговое решение здесь.

P.S. Несколько интересных ссылок по теме 20-минутного города и оценки городских пространств (раз, два, три, четыре)

#statistics

Сегодня поговорим об особенностях теста Манна-Уитни.

https://telegra.ph/O-Manne-Uitni-zamolvite-slovo-10-11

​​#statistics

А вы знали про связь теста Манна-Уитни и AUC?

Смутные сомнения такой связи меня посетили после того, как я узнал про то, что критерий Манна-Уитни проверяет стохастическое равенство (stochastic equality). То есть, следующую гипотезу H_0: P(X > Y) = P(X < Y).

Тут сразу возникла идея, что очень уж похоже на вероятность того, что значения из одного списка окажутся выше значений из другого. Потому полез смотреть о связи между понятиями. И, как оказалось, она достаточно прямая 🤯.

Формула связи между AUC и U статистикой такая:

AUC = U / (n_0 * n_1)

где U - U статистика, n_0 и n_1 - количество наблюдений в группах.

Собственно, это показывается в следующей статье.

Кстати, смысл тут весьма логичный - мы хотим проверить, как хорошо у нас отличаются два множества. То есть, оценить, одинаковы ли наши распределения (если одинаковы, то это соответствует тому, чтобы случайно назначать нашим элементам выборок их scores, следовательно, и вероятности будут равны 0.5 и для P(X > Y) и для P(X < Y)).

Еще я нашел красивую визуальную интерпретацию вывода (можно найти по ссылке). Эта визуализация в приложении к посту.

На ней все становится понятнее.

Сверху мы визуализируем ранги по двум выборкам (можем назначить одну за "позитивный" класс и вторую за "негативный").

Снизу переводим эти ранги в вид кривой на двух осях, где каждый шаг вверх - это позитивный класс на графике вверх, а шаг вправо - негативный. Это достаточно сильно напоминает то, как мы строим ROC-AUC кривую.

В итоге, получаем, что площадь зеленой фигуры в черном пунктирном прямоугольнике будет равна U-статистике. Масштабируя эту площадь на оси (то есть, поделив на (n_0 * n_1)), получаем нашу искомую площадь под фигурой, что и есть AUC (Area Under Curve).

Бонусом, нашел красивый пост-ноутбук "The ROC-AUC and the Mann-Whitney U-test" (там еще и доп. материалы есть, например, про доверительные интервалы для AUC).

​​#books

Какие времена - такие и книги ¯\_(ツ)_/¯

Сегодня напишу про книгу "Терапия беспокойства" доктора Дэвида Бернса. Автор практикующий терапевт в области КПТ (когнитивно-поведенческая терапия).

А КПТ, между прочим, показала доказанную эффективность во множестве исследований (результаты мета-анализа множества исследований). Так что метод рабочий.

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

Только сразу скажу, что эффективнее реально выполнять упражнения, а не просто читать книгу. Тут работает правило "как потопаешь - так и полопаешь".

P.S. В мета-анализе увидел про g Хеджеса, как показатель величины эффекта. Кому интересно - можно почитать здесь.

#libraries

Fitter - простая библиотечка для поиска подходящего типа распределения. Берет данные, после чего фиттит все распределения из scipy, и выдает лучшие в плане суммы квадратов ошибок.

Дешево и сердито, но может пригодиться, если хотите прикинуть тип распределения ваших данных.

АБ-тесты. Интеграция в процесс пилотирования. Что делать. База пилотов
Цикл постов про АБ-тестирование. Пост 5

Как мы разобрались раньше, при внедрении АБ-тестирования в процесс пилотирования полезно создать базу пилотов. Хорошая база позволяет не только снизить риск некорректного финального решения о дальнейшем развитии проекта (можем отслеживать пересечения пилотов: чтобы в пилотной группе тестировался только один проект, а в контрольной - ни одного), но и сильно систематизировать знания компании о пилотах. А последнее потом очень помогает подбить эффект от работы команды АБ-тестирования за год 😉, а также найти проблемы в работе с пилотами (как технические, так и бизнесовые).

Каковы компоненты идеальной базы пилотов?

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

К этим данным стоит добавить:

- Параметры пилота, полученные после осуществления дизайна: расчетные даты границ пилота и препилота, полученные ошибки 1-го и 2-го рода, минимально детектируемый эффект, на который рассчитан дизайн, ID объектов пилотной и контрольной группы.

- Результаты оценки эффекта пилота, рассчитанные после его окончания: итоговый эффект пилота (или его отсутствие😐), итоговые параметры пилота (даты пилота/препилота, ошибки, ID объектов). Для этих данных полезно проставить метку estimation (этап оценки эффекта пилота).

Так мы видим идеальную базу. Будем рады комментариям и дополнениям!

Предыдущие посты цикла тут.
Продолжение следует!

#tech #ab_testing

#statistics

Нашел клевую штуку - интерактивную книгу "Дружелюбная эконометрика". Полистал, выглядит весьма интересно.

В качестве выдержки приведу "чек-лист эконометриста" из источника:
1. Нет ли в модели пропущенных существенных переменных?
2. Верна ли выбранная функциональная форма?
3. Нет ли в модели эндогенности в результате двусторонней причинно-следственной связи?
4. Не искажены ли выводы из-за сильных ошибок измерения регрессора?
5. Не забыли ли вы использовать состоятельные в данных условиях стандартные ошибки?
6. Если переменная интереса оказалась незначимой, не вызвана ли эта незначимость сильной мультиколлинеарностью?
7. Верно ли определены границы генеральной совокупности, на которую вы обобщаете выводы своей модели?