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

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

В этой статье я поделюсь своим опытом и советами о том, как это сделать. Статья собрана из серии постов в тг‑канале Reliable ML.

Место АБ-тестирования в бизнес-процессах компании

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

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

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

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

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

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

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

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

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

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

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

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

  Какие статистические инструменты доступны?

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

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

Доказательная лестница методов причинно-следственного анализа

evЛучшая, на мой взгляд, систематизация методов причинно-следственного анализа – Evidence Ladder от A.Rebecq (2020).

Методы Causal Inference можно упорядочить с помощью так называемой доказательной лестницы (Evidence Ladder). От нижней ступени к верхней будет расти, во‑первых, доказательная сила метода, во‑вторых, простота применения, или, другими словами, снижаться число необходимых проверок на устойчивость результата применения метода (robustness checks).

На вершине этой лестницы находятся естественные эксперименты (Natural Experiments). Это, например, классические лабораторные эксперименты в физике и химии, когда мы можем создать полностью одинаковые условия для двух вариантов Y, отличающихся только наличием Х.

Следующая ступень — статистические эксперименты (Statistical Experiments) aka рандомизированные контролируемые эксперименты (Randomized Controlled Trials) aka АБ‑тестирование (AB Testing). Здесь мы не можем обеспечить идеально одинаковые Y, но можем случайным образом собрать выборки объектов Y в пилотную (вводим событие Х) и контрольную (не вводим событие Х) группы таким образом, что размер этих выборок компенсирует различия Y между собой.

Если случайный отбор не работает, мы вынуждены спускаться еще на ступень ниже — к квази‑экспериментам (Quasi‑Experiments). На практике категории статистических экспериментов и квази‑экспериментов чаще всего смешиваются, и называются просто АБ‑тестами. В квази‑экспериментах объекты Y могут существенно отличаться и их общего количества недостаточно, чтобы обеспечить однородные выборки и корректный статистический эксперимент. Поэтому в таких АБ‑тестах мы вынуждены прибегать к дополнительным мерам снижения дисперсии типа CUPED и линеаризации, и другим танцам с бубном.

Иногда бизнес‑ограничения не позволяют добиться и корректной оценки даже с помощью квази‑экспериментов. В таком случае, мы вынуждены спуститься в самый низ нашей доказательной лестницы — к контрфактическим методам (Counterfactuals). Тут мы отказываемся от идеи пилотной и контрольной групп (на самом деле, не совсем), и, по сути, моделируем временной ряд Y по историческим данным без участия Х в будущее, где Х уже вступает в игру. Таким образом, в период проведения эксперимента мы сможем сравнить фактические данные Y (где Х участвовал) с модельными (прогноз Y без участия Х) и предположить размер эффекта, скорректировав его на точность модели для Y. Однако, чтобы это предположение оказалось близким к правде, нам нужно сделать наибольшее количество тестов на устойчивость метода. Результирующий эффект будет критически зависеть не только от качества модели, но и в целом от корректности применения выбранного метода CI категории Counterfactuals: от выбора самого метода до подбора гиперпараметров и учета при моделировании всех необходимых ковариатов (факторов, помимо Х).

Более детальное описание каждой ступени можно найти в моем докладе тут и в этой статье.

Структуру инвестиционного цикла, которую мы обсудили выше, полезно иметь в виду при интеграции АБ‑тестирования в бизнес‑процессы компании.

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

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

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

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

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

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

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

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

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

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

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

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

Риски типового бизнес-процесса без АБ

Описанный выше бизнес‑процесс связан со значительными рисками для компании. Рассмотрим детальнее, что это за риски и почему они формируются:

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

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

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

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

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

Что делать

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

Взаимодействие АБ-команды, финансовой службы и бизнеса

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

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

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

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

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

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

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

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

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

• сведения о заказчике пилота (бизнес‑подразделение, контакты);

• содержание пилота (что внедряем, почему это принесет эффект);

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

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

• что является объектом тестирования;

• целевые метрики пилота и ожидаемый количественный эффект пилота на них;

• есть ли период привыкания с точки зрения бизнес‑постановки. Например, распространено мнение, что изменение ассортимента в магазине может не сразу повлиять на спрос, покупателю требуется время привыкнуть к изменениям возможные границы периода пилота, ожидаемая дата начала;

• максимальное количество объектов, которое бизнес готов выделить в пилот;

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

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

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

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

База пилотов

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

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

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

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

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

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

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

Математическая методика дизайна и оценки результатов пилотов

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

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

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

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

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

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

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

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

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

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

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

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

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

Подборка материалов по АБ

Как создать корректную методику АБ‑тестирования для вашей компании в одну статью допразделом, конечно, не уместить. Выше мы обозначили ключевые, на наш взгляд, составляющие любой методики.

А детали, нюансы и примеры использования мы, например, обсуждали 17 декабря 2022 г. на большом митапе Open Data Science и Reliable ML по АБ‑тестированию ????. Если вам интересна тема, то все материалы митапа доступны публично.

А в этой статье мы дадим обещанную подборку материалов по АБ‑тестированию (большая часть — на русском языке):

• Книга Доверительное АБ‑тестирование простым и понятным языком рассказывает об основах АБ для онлайна и примерах применения его в крупных компаниях. На русском языке это одна из лучших книг по онлайн‑экспериментам.

• Книга Статистический анализ и визуализация данных с помощью R от Сергея Мастицкого. Это уже прям классика‑классика, но статистический фундамент, релевантный АБ, дает отличный. Я, например, пришла в DS именно по блогу и книгам Сергея.

• Статьи Паши Нестерова на Хабре по офлайн‑экспериментам (раз, два). Написаны давно, но настолько хорошо и понятно, что я до сих пор для объяснения каких‑то частей методологии даю ссылки на них. Например, ссылку на байку про мертвого лосося для раскрытия темы вреда множественного тестирования давала, наверное, уже миллион раз. Лучше эту тему на русском не раскрыл никто.

• Practical Defaults for A/B Testing от Ronny Kohavi. Советы по выбору дефолтных значений от автора книги Доверительное АБ‑тестирование.

• Caveats and Limitations of A/B Testing at Growth Tech Companies. Хорошая заметка, в тему этой статьи, про сложности проведения АБ в компаниях и отличный ее пересказ от Артема Ерохина.

• Продвинутые темы в АБ можно посмотреть: в треке Валеры Бабушкина на ODS Data Fest 2020 г. (от нюансов АБ на малых данных до оптимизации метрик для контроля качества проведения экспериментов), докладах Ваагна Минасяна и Ивана Максимова про ускорение АБ‑тестов, статьях Саши Сахнова о стратификации и бутстрепе (об основах АБ в оффлайне Саша, кстати, тоже классно пишет), а также о лайфхаках АБ от Авито (раз, два). Это из любимого. Из этих статей можно выйти на бесчисленное множество качественных материалов по интересующим вас нюансам в методике АБ‑тестирования.

Экстраполяция результатов пилота

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

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

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

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

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

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

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

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

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

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

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

В дополнение рассмотрим пару важных краевых сценариев:

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

  Это вопрос уже не экстраполяции результата, а методики оценки для подобных случаев. Тут вспоминаем доказательную лестницу методов причинно-следственного анализа и понимаем, что наш путь лежит от классических АБ-тестов к ступеньке ниже - методам контрфактического анализа. Самым популярным из которых является causal impact. Про него 17 декабря на митапе Reliable ML Дмитрий Торшин рассказал отличный доклад - Causal Impact и как его готовить (видео, презентация).

• Не хотим мучиться с методикой экстраполяции и продумывать параметры пилота. Внедряем как получилось, а потом бахаем causal impact и вуаля, у нас есть оценка и пилота, и ролл-аута.

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

• А что если моя модель хорошо отработала на пилоте, а потом - при работе на всех объектах - начнет деградировать? Результат же изменится и финансовый эффект тоже!

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

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

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

Поздравляем вас с завершением статьи про АБ-тестирование! Спасибо, что дочитали до конца :)

P.S. Статья основана на постах тг-канала Reliable ML.