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

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

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

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

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