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

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

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

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

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

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

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

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

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

#tech #ab_testing

#statistics

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

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

#statistics #AB

Сделал пересказ "Caveats and Limitations of A/B Testing at Growth Tech Companies".

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

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

P.S. Пересказ вышел весьма длинным (ближе к переводу), так что прикреплю ссылку на telegraph

https://telegra.ph/Caveats-and-Limitations-of-AB-Testing-at-Growth-Tech-Companies-11-17

АБ-тесты. Интеграция в процесс пилотирования. Что делать. Математическая методика дизайна и оценки результатов пилотов.
Цикл постов про АБ-тестирование. Пост 6

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

Почти в любой методике АБ-тестирования для офлайна можно выделить следующие этапы:

- Этап 1. Дизайн пилота. Подбор пилотной и контрольной групп объектов (число и id), оптимальной длительности пилота, минимально-детектируемого эффекта с учетом вводных от бизнеса (чек-лист тут). Часть этих параметров обязательно будет ограничена - но только за счет свободы по остальным: либо эффект хочется поймать минимальный, но готовы взять в пилот много объектов, либо готовы взять в пилот мало объектов и провести его надо быстро, но эффект от проекта ждем бомбический.

Что важно учитывать в этом этапе:

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

- (б) ошибки 1-го и 2-го рода на препилотном периоде, равном планируемому периоду пилота. Ошибка 1-го рода - вероятность поймать эффект, когда его нет. Ошибка 2-го рода - вероятность не поймать эффект, когда он есть. И то, и другое не есть хорошо. Период препилота - возможность протестировать корректность алгоритма оценки эффекта заранее - в ситуации, когда мы знаем, что различий между группами нет. Важно определить границы допустимых ошибок 1-2го рода в вашей компании. Для офлайн экспериментов на нашей практике бенчмарком являются границы в ~15%.

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

Выстроить корректную оценку для офлайн-экспериментов сложнее, чем для онлайна, по ряду причин. Основные из них: мало объектов можем позволить себе в пилот (причем это “мало” может варьироваться от 100-150 объектов для одного пилота (если это, например, банкоматы), до 2-10 объектов (если это, например, сеть продуктового ритейла с небольшим числом магазинов🤓), объекты очень сильно отличаются друг от друга, на них сильно воздействуют внешние факторы (это влияет и на рост волатильности целевых метрик).

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

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

Решение о значимости результатов пилота и возможности его экстраполяции должно осуществляться на основе доверительного интервала эффекта пилота.

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

Будьте бдительны и хороших вам АБ-тестов!

#tech #ab_testing

Продолжая говорить на тему прошлого материала, давайте обсудим плюсы и минусы data-driven подхода.

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

Основные недостатки заключаются в том, что сбор и анализ данных может быть дорогостоящим и отнимать много времени, а также в том, что не все данные являются точными и надежными.

Если более подробно говорить о преимуществах, то такой подход позволяет:
1) Избежать предвзятости: принимая решения на основе данных, предприятия могут избежать личных предубеждений, которые могут привести к неточному принятию решений;
2) Принимать более точные решения: данные могут дать понимание, которое предприятия не смогли бы получить только с помощью интуиции или опыта;
3) Экономить время и ресурсы: принятие решений на основе данных может сэкономить время и деньги, поскольку снижает необходимость проб и ошибок.

Соответственно, недостатки data-driven подхода заключаются в том, что он может быть:
1) Дорогостоящим и трудоемким для сбора и анализа данных: сбор достоверных данных может быть дорогостоящим и трудоемким. Анализ этих данных также может потребовать значительных ресурсов.
2) Не все данные будут точными или надежными: данные хороши лишь настолько, насколько они точны и надежны. Некачественные данные могут привести к неправильным выводам.
3) Чрезмерная зависимость от технологий: подход, основанный на данных, в значительной степени зависит от технологий, что означает, что в случае технических проблем процесс принятия решений может быть нарушен.

В целом, важность конкретных плюсов и минусов data-driven подхода, зависит от каждого конкретного бизнес-кейса. Тут, как со всем новым - лучше постепенно внедрять методы работы с данными и принятия решений на их основе. Это позволит "акклиматизироваться" и самим прочувствовать все плюсы и минусы.

Не удержался и тоже сгенерировал нечто забавное в новой нейронке для чатов от OpenAI.

Попросил написать стихи про любовь к пельменям. Потом озвучил ботом от Silero уже другой нейронкой.

What a wonderful time we live in 🧙‍♂️

#libraries

Yellowbrick - библиотека для визуального анализа и диагностики качества получаемых моделей. По сути - множество оберток с готовыми графиками, чтобы самим не писать их каждый раз. Например, есть график с validation curve с доверительными интервалами для train и cross validation скоров, в зависимости от значения какого-либо гиперпараметра.

P.S. В посте в прошлую субботу, я сделал небольшую шалость. Заметка про data-driven подход была сгенерирована сервисом для автоматического копирайтинга по заголовку "плюсы и минусы data-driven подхода" и немного отредактирована мной. Кажется, что шалость удалась ;)

Приходите послушать! Я буду выступать 17го с докладом про методы балансировки в causal inference

Митап ODS Reliable ML по АБ-тестированию и Causal Inference - 17 декабря
Анонсы докладов

Всем привет!

Не всё же читать про АБ-тесты, давайте про них говорить!

17 декабря мы с Димой приглашаем вас на митап по АБ-тестам от канала @Reliable ML и Open Data Science.
В программе 9 докладов от мэтров в этой области. Начнем в 11 утра по Мск, закончим - примерно в 18 (или как пойдет).

Регистрация на митап туть!

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

Программа:

11:00 - Ваагн Минасян, Lead DS @ X5 Tech - Оценка эффектов в АБ тестах при неслучайном разделении на тестовую и контрольную группы
11:45 - Дмитрий Васькин, Data Scientist @ Lenta - Synthetic Control для AB тестов на малых размерах выборок
12:30 - Аслан Байрамкулов, Head of Experimental Group @ МТС BigData - Ambrosia - open-source библиотека для быстрой и удобной работы с A/B тестами
13:15 - Артем Ерохин, Lead DS @ X5 Tech - Balancing Methods in Causal Inference
14:30 - Александр Сахнов - Парный, пуассоновский и дикий бутстреп
15:15 - Валерий Бабушкин, VP, Data Science @ Blockchain.com - Метрики: от офлайна до иерархии
16:00 - Максим Кочуров, PyMC Labs - Планирование Байесовских АБ тестов
16:45 - Дмитрий Торшин, Data Scientist @ Lenta - Causal Impact и как его готовить
17:30 - Григорий Чернов, PhD in Economics, University of Tuebingen, ВШЭ - Causal Discovery Methods for Experimental Design

Далее постараемся рассказать подробнее об отдельных докладах!

#анонс #tech #ab_testing

​​#statistics

Поговорим о causal trees.

Ранее мы говорили об uplift trees. Causal trees - некоторое обобщение для построения деревьев в causal inference.

Что же там происходит?

Как я ранее говорил, в обычных uplift trees используются некоторые эвристики, которые позволяют посчитать приближение при разбиении и учесть его при построении дерева.

Но что, если мы сделаем иную (и более честную) функцию для того, чтобы разделять дерево на ветви? Про это как раз и следующая работа (Athey, Susan, and Guido Imbens. "Recursive partitioning for heterogeneous causal effects." Proceedings of the National Academy of Sciences 113.27 (2016): 7353-7360).

Почему нам важно иметь иную функцию для разбиения? Все потому, что у нас стоит принципиально иная задача. Это не обычная классификация или регрессия, а оценка причинности влияния и размера эффекта. Соответственно, обычные методы будут привносить смещение (bias). И оценки наши, увы, будут несостоятельны.

Соответственно, наш критерий для сплита должен учитывать (см. пример хорошего и плохого разбиения в изображении к посту):
- Баланс между попавшими в ветвь дерева объектами из target и control;
- Ожидаемую точность оценки CATE (conditional average treatment effect). Если разбиение разбивает на группы неточно, то мы получаем искажение в нашей оценке

Потому, давайте введем новую функцию для получения оптимального разбиения - EMSE (expected mean squared error for treatment effects). Если коротко, то это просто MSE с поправкой и учетом разделения на тест и обучение. Выглядит формула примерно так 1 / N_test * sum_N_test( (Y_i - tau_est)**2 - Y_i**2)

То есть, мы обучаем наше разделение на одном множестве, а потом подставляем в другое. На коем и вычисляем MSE с поправкой на константу. Ну а expected здесь - это мат. ожидание от нашего MSE. При этом, test и estimation у нас независимы.

Доказано, что такая функция позволяет нам иметь нужные статистические свойства.

Итог:
Кажется весьма интересным такой способ оценки. Да и весьма в стиле ML решений с разделением на train/test части. Подробнее можно почитать в статьях + в этом блог-посте. А реализацию на python можно найти в пакете econml.

Сегодня поста не будет, т.к. я выступаю на митапе. Подключайтесь посмотреть ;)

Артем Ерохин - Методы балансировки в causal inference
17 декабря - митап ODS Reliable ML по AB-тестированию и Causal Inference

В 13:15 17 декабря на нашем митапе выступит Артем Ерохин, Lead DS X5 Tech, автор канала @Artificial Stupid.

В докладе Артем расскажет о том, что такое балансировка в causal inference, какие методы балансировки существуют и как они работают.

Регистрация на мероприятие тут.
Полное расписание мероприятия тут.

Ваш @Reliable ML

#анонс #tech #ab_testing

​​#statistics

Weighted Z-test для мета-анализа результатов экспериментов.

Мне попался на глаза пост от ebay про z-test для мета-анализа (спасибо коллегам). Так что сегодня поговорим про этот метод.

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

У нас есть N тестов (например, N t-тестов для средних), для каждого из которых есть свое p-value, свое значение статистики и свой доверительный интервал. Мы думаем, что объединение разрозненных источников информации даст нам преимущество и позволить уточнить наши выводы, увеличив мощность полученного комбинированного теста.

Для one-sided теста у нас может использоваться Fishers method. Но в случае two-sided теста нам нужен другой способ. И тут на сцену выходит Z-test.

Мы можем скомбинировать наши p-values в комбинированный p-value, используя Z-статистики из каждого эксперимента и веса, которые получаются из выражения w_i = 1 / SE_i, где SE_i - это standart error для i-го эксперимента (формула построения доверительного интервала комбинированного эксперимента есть в исходном посте по ссылке в начале).

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

Какие тут плюсы и минусы?

Плюсы:
- Тест может комбинировать отдельные результаты тестов с разными размерами выборки;
- Полученная комбинация имеет большую мощность, чем каждый отдельный тест

Минусы:
- Тест предполагает нормальность распределения (не забываем о Z-статистике при его расчете);
- Тест чувствителен к весам. Соответственно, есть возможность того, что какой-то тест попросту перевесит все остальные;
- Комбинированный тест может быть сложнее к пониманию и реализации, чем единичный обычный проведенный тест

Вот и заканчивается еще один год!

Что же произошло за этот год:
1. Я стал отцом! В начале года у меня родилась дочка - самое замечательное событие в моей жизни. Огромное спасибо моей жене, которая отвечает за большую часть ухода за нашей дочкой. Ну а я стараюсь помогать всеми силами :)
2. В этом году я руководил небольшой командой (6-8 человек) в X5. Мы справились с несколькими успешными проектами, продолжаем работать и развиваться.
3. Несколько раз я выступал с докладами, например, на X5 Data Driven Meetup #2 и на reliable ML секции во время Data Елки.
4. Я также помогал организовывать конференцию, хотя она и была отложена на некоторое время.
5. Я успешно обучился на Product Owner и повысил свою квалификацию по управлению проектной командой.
6. Весь год я ответственно вел канал, выпуская ~ по 1 посту в неделю. За год канал вырос с ~180 до ~760 подписчиков (тут огромное спасибо всем тем, кто меня читает).
7. В этом году я также получил награду ODS Award "ментор года" - это огромная честь для меня.
8. И, наконец, я выиграл одно из соревнований цифрового прорыва.

Я надеюсь, что следующий год будет не таким турбулентным. Желаю всем удачи и успехов в наступающем 2023 году!

May the Force be with you!

#libraries

Pysynthdid - синтетический diff-in-diff для Python. Подробнее про метод - в репозитории (там есть ссылка на medium пост и на оригинальную статью) и здесь. Метод работает для постепенной раскатки (staged adoption) и для множественных target объектов.

АБ-тесты. Экстраполяция результатов пилота
Цикл постов про АБ-тестирование. Пост 8

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

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

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

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

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

- характеристики объектов в пилот и контроль. Стоит учитывать планируемую экстраполяцию результата:

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

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

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

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

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

#tech #ab_testing

Reliable ML AB Testing & Causal Inference Meetup
Видео и презентации докладов

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

Все доклады, их описания и презентации можно найти на сайте ODS.ai, а также в плейлисте на YouTube.

Ссылки отдельно по докладам:

- Ваагн Минасян - Оценки с двойной надёжностью для выявления причинно-следственных связей в бизнесе (видео, презентация)

- Дмитрий Васькин - Synthetic Control для AB тестов на малых размерах выборок (видео, презентация)

- Аслан Байрамкулов - Ambrosia - open-source библиотека для быстрой и удобной работы с A/B тестами (видео, презентация)

- Артем Ерохин - Balancing Methods in Causal Inference (видео, презентация)

- Александр Сахнов - Парный, пуассоновский и дикий бутстреп (видео, презентация)

- Валерий Бабушкин - Метрики: от офлайна до иерархии (видео, презентация)

- Григорий Чернов - Causal Discovery Methods for Experimental Design (видео, презентация)

- Дмитрий Торшин - Causal Impact и как его готовить (видео, презентация)

- Максим Кочуров - Планирование Байесовских АБ тестов (видео, презентация)

Ваш @Reliable ML

#tech #ab_testing #causal_inference