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

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

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

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

1. Технические фичи не влияют на продуктовые и бизнес-метрики, они обходятся без АБ-теста.
2. Очень мелкие изменения, не влияющие на продукт.
3. Проблема, которую мы хотим решить, незначительная.
4. Изменения редко попадают в поле зрения пользователя, например, на третьем экране или в подвале сайта, из-за этого резко сокращается аудитория.
5. Слабая гипотеза
6. Гипотеза не подходит под критерии хорошей гипотезы (расскажу чуть ниже).
7. Когда ты просто делаешь жизнь пользователя чуть лучше:
- ускорение загрузки страницы
- что-то починили, исправили баг, поправили дизайн
8. Небольшой стартап растет на десятки-сотни процентов и в нем постоянно происходит много изменений.
10. Есть очень сильный продукт (например, главный экран приложения) и небольшие изменения не смогут ухудшить пользовательский опыт.
11. Когда охват фичи минимальный и он не масштабируется.
12. Не нужно тестировать базовый функционал в индустрии, например, в соцсети внедрение комментариев или реакций к постам.
13. На этапе дизайна оказалось, что нам потребуется 1-2-100500 лет, чтобы протестировать гипотезу.
14. Не удается подобрать метрику, которая поможет.
15. Ресурсы, которые нужно потратить на эксперимент, будут больше выгоды, которую ожидаем получить.

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

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

Для себя сформулировал набор вопросов, которые помогают понять, правильные ли метрики выбраны. Не идеально, но работает.
1. Какова цель нашего эксперимента?
2. На какую часть пути пользователя на нашем сайте / в приложении мы воздействуем?
3. Что пользователь в этом сценарии делает сейчас?
4. Какое поведение мы ожидаем от пользователя в тестовой группе, внося свои изменения?
5. Что в этом поведении должно измениться, чтобы мы поняли, что наш эксперимент приносит желаемый результат?
6. Можем ли мы какой-то метрикой оценить это изменение? Это и будет главная метрика эксперимента.
7. А можем зафиксировать такое изменение? Если нет, то нужно искать косвенные метрики (возвращаемся назад на пару шагов), которые могут нам помочь понять, что мы добиваемся необходимого результата.
8. Насколько мы предполагаем увеличить (уменьшить) нашу метрику.

В Linkedin у коллеги Романа Смирнова из Ламоды подсмотрел ссылку на его же статью по сравнению методов удаления выбросов при анализе A/B тестов. Тема интересная и чувствительная - случалось, что выбросы разворачивали результаты наоборот. Собственно, статья

Одноклассники на Хабре рассказали про свою платформу экспериментов - https://habr.com/ru/companies/odnoklassniki/articles/772958/

Как и говорил, о некоторых докладах с Матемаркетинга буду писать.

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

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

Ребята из продуктовой аналитики Mail.ru в VK рассказали о своей расчетной архитектуре платформы для A/B-тестов Mail.Ru и ее недавнем обновлении, поделились опытом и инсайтами. Они создали архитектуру метрик для A/B-тестов, которая позволяет масштабировать сложность расчетов.

Сама статья - https://habr.com/ru/companies/vk/articles/781300/

Прочитал заметку от Spotify - Choosing a Sequential Testing Framework — Comparisons and Discussions

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

Group sequential tests
Плюсы: подход с alpha-spending функцией, которая тратится, только когда мы проверяем результаты, позволяет принимать решение, готовые ли мы сейчас подглядывать или лучше подождем. Если не подсматривать - тест сходится до традиционного z-test.
Легко объяснить - по факту z-test.
Минусы: нужно знать предельное количество данных, которое мы можем собрать, если что то пойдет не так в обе стороны, то тест может иметь как заниженный, так и завышенный false positive rate
Нужно выбирать alpha-spending, если мы заранее знаем сколько данных, то это не проблема, а если не знаем - underpower
Подглядывать можно не более пары сотен раз
Заметка для себя: Надо посмотреть пересекается ли как то с этим - Increase A/B Testing Power by Combining Experiments & Weighted Z-test

Always valid inference - куда входит любимый нами mSPRT The Mixture Sequential Probability Ratio Test
Плюсы: Легко воплотить
Можно сколько удобно данных скормить и не нужно знать размер данных заранее
Можно задать любое правило для остановки
Работает как с батчами так и со стримингом (в отличии от пункта выше)
Минусы: Нужно описывать параметры распределения для успеха, как некоторую смесь распределений
Тяжелее понять для челов, которые не понимают
Underpowered если батч а не стриминг, потому что обновляются данные сразу куском, а не по итерации
Заметка для себя: - Давно такой лажи надуманной я не читал, челы сразу сказали в начале статьи, что выбирают GST и начали выдумывать какие-то дурацкие причины почему mSPRT плох. Ну то есть, да, есть некоторая смесь распределений, но даже смесь распределений это распределение, на практике мы всегда делаем какое-то допущение, это в принципе тоже самое как задавание MDE, которые мы хотим поймать. То, что кому-то тяжелее это понять, удивительная причина, там все довольно просто на пальцах показать, для многих будет даже проще z-testа, ну а то - что underpowered для батчей - вообще ерунда. Кто вам мешает взять батч и прогнать его последовательно как будто это стриминг, ведь timestamp для каждого события есть, а обновление - это операция умножения двух циферок, то есть по факту вы это итак делаете с батчем, просто докинуть один sort
Bonferroni corrections - куда-же без нее
Плюсы - легко закодить
Минусы - заранее решаем сколько раз будем подсматривать
Если подсматривать много раз, скорее всего ничего не найдем

Проверили эти подходы на симуляции
Bounded false positive rate - держится у всех
GST всех побил по чувствительности на батчах, правда на стриминге он просто не работает и пойди тут сравни теперь, судя по всему mSPRT они не обработали в батчах через таймстемпы и должного сравнения мы не получим (если только их графики батча и стрима это не один и те-же данные, тогда худо бедно можно сравнить Можно пойти и посмотреть код - оставляю это на вашу совесть, код написан в R)

Описали свои выводы - что и когда брать. В целом читать можно и нужно, но с осторожностью
#ArticleReview

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

Наиболее цитируемые статьи по экспериментам

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

Иногда мы заглядываем в открытые сборники с пейперами. Ниже дана ссылка на сборник от Ронни Кохави со списком наиболее цитируемых статей от авторитетных авторов.

Эта коллекция регулярно обновляется, поэтому рекомендую также добавить к себе в закладки:

https://docs.google.com/spreadsheets/d/1PAWG7NWVEwAwwfrd9b-V5o5q4nB6i67N2ITrzyrIdP0/edit#gid=224694437

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

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

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

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

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

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

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

И вот что некоторые из них про это рассказывают:
- Авито раз и два
- Ozon раз и два
- Lamoda
- Сбер
- Х5 про оффлайн-эксперименты

Сбермаркет продолжает тему про платформы для A/B-тестов и проводит 28 марта митап.
Помимо Сбермаркета участвуют EXPF (легендарные легенды индустрии) и Авито (не менее легендарные легенды в своей индустрии).
Ссылка на регистрацию

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

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

Из интересных библиотек могу выделить две:
- Ambrosia от коллег из МТС
- Kolmogorov ABacus

Недавно потестировал Kolmogorov ABacus, очень даже неплохо. Основные особенности:
- Оценка результатов эксперимента с помощью многих стат. критериев, в том числе бустрапа - собственно, ожидаемо
- Инструмент для деления на группы с оценкой качества деления
- Подготовка эксперимента - ошибки 1 и 2 рода, mde, расчет необходимой выборки

Ссылки:
- Гитхаб
- Примеры оценки результатов эксперимента на гитхабе
- Документация
- Канал в телеграме
- Чат поддержки в телеграме
- Статья на Хабре об использовании

Есть прекрасная поговорка - завтра в 6. Митап перенесен на завтра, 4 апреля, 18.00.
Ссылка актуальна.

На хабре вышла большая статья с подробным разбором нескольких стат. критериев:
- z-статистика
- t-статистика
- критерий хи-квадрат
- f-статистика

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

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

И еще прикладываю несколько материалов на тему дельта-метода и ratio-метрик:
- раз
- два
- три
- четыре
- пять

Если вдруг кто-то пропустил митап от EXPF, запись здесь.
Темы:
- Как из подручных средств организовать процесс А/В тестирования
- Критерии валидности АБ-тестов
- Поиск Эффективных Прокси-Метрик
- Сбор качественных данных для проведения А/Б тестов

Тут очень интересный доклад легендарного в некоторых кругах Анатолия Карпова про оценку продолжительности АБ-теста. Это одна из самых интересных и проблемных вопросов при проведении экспериментов. Внутри подглядывание, т-тесты, mde, fixed horizon.
Отдельно рекомендую к просмотру раздел со штрафами за подглядывание - менеджерам может понравиться...
Статья EXPF, о которой говорит Анатолий, здесь.

Интересный разговор Александра Игнатенко (телеграм-канал Модель атрибуции) и Виталия Черемисинова (EXPF) про:
- альтернативы закрывшемуся Google Optimize
- особенности интерфейса GA4
- внедрение Сигмы от EXPF
- метрики экспериментов
- распространенные ошибки в командах, работающих с АБ-тестами
- нужно ли очень глубоко закапываться в исследования данных при АБ-тестах
- прочие важные вопросы про АБ-тесты и эксперименты от зрителей стрима

Незаслуженно мало просмотров у ролика как-то.