Для многих IT-компаний, занимающихся разработкой и продвижением продуктов, А/В-тестирование стало не просто важным аналитическим инструментом, но скорее отправной точкой для развития продукта. Без использования А/В-тестов может быть трудно оценить и определить, какие изменения необходимы и как они будут влиять на поведение пользователей.
Про статистику и про то, как делать А/В-тесты, информация в изобилии, но в большинство источников фокусируются на «технике», подсчете выборки, проблеме подглядывания, правильной интерпретации p-value… А вот практических советов по менеджменту А/В-тестов не так уж и много.
Развитие продукта происходит благодаря изменениям, а чтобы понять, насколько эффективны эти изменения, нужно быть сильным в аналитике, должно быть понимание того, как считаются метрики. Так продакт-менеджер не просто будет сидеть и ждать от аналитика подтверждения своих решений, а сможет с ним общаться, понимать, как изменения влияют на продукт и находить новые пути развития на основе прошлого опыта.
Зачем нужны чек-листы
Чек-листы — важная опора во всех сферах, если мы стремимся к минимизации вероятности ошибки, и нам важно грамотно выстроить процесс. Некоторые шаги по ходу выполнения задач могут быть неодинаково понятны для каждого члена команды, даже самые важные из них. Если вы работаете в одной команде над одним проектом, то вполне вероятно, что у вас найдется много общих шагов в процессе работы, которые можно вынести в отдельный чек-лист, и это сократит время на их обсуждение.
План чек-листа:
- Формулировка гипотезы
- Нужен ли А/В-тест?
- Определяем метрики
- Определяем путь разбивки на группы
- Определяем целевую группу
- Определяем ключевую метрику
- Определяем размер выборки
- Утверждаем критерии успеха и действий по итогам
- Описываем необходимый трекинг для оценки теста
- Проверка технической реализации функционала
- Запуск теста
- Проверка теста после запуска
- Следим за метриками
- Выявляем характерные временные эффекты в рамках изменения
- После накопления выборки принимаем решение
- Закрываем тест
- Оцениваем полезность теста
- Записываем характеристики и результаты теста в историю
Рассмотрим каждый пункт детальнее.
✓ Формулировка гипотезы
Формулировка гипотезы – залог правильного теста. Гипотеза поможет определить цели эксперимента, выбрать метрики и интерпретировать результаты. При наличии чётких целей на этом этапе уже будет отсекаться много гипотез.
Построение гипотезы строится следующим образом:
✓ Нужен ли А/В-тест?
Доводы за:
Тест дает наиболее объективную оценку изменения.
Основная альтернатива — смотреть на динамику во времени, то есть сравнивать периоды до/после изменения. Такой подход в определённых ситуациях жизнеспособен, но становится проблематичным в нескольких кейсах:
- На метрики одновременно влияет много факторов. Чем больше факторов влияют на метрики вашего продукта — тем актуальнее оценивать изменение с помощью А/В-теста. Факторами могут быть как постоянное изменение структуры ваших пользователей по ключевым параметрам (полу/возрасту/источнику трафика и так далее), так и одновременное проведение других тестов внутри вашего продукта/других продуктов компании. Даже скрупулезно наблюдая динамику в разрезе всех сегментов, можно не получить свидетельства того, что именно интересующее вас изменение повлияло на метрику, а не другой фактор. Вы никогда не будете обладать полной информацией о всех факторах, влияющих на продукт в конкретный момент. Рандомизированное назначение групп в А/В-тестах позволяет уйти от влияния всех факторов, в том числе невидимых для вас.
- От изменения ожидается лишь незначительное влияние на метрики, которое в динамике можно не заметить за обычной волатильностью метрики. Большинство тестов на продуктах, особенно не на начальных стадиях развития, именно такие. Проведя десяток таких тестов, можно загнать общую динамику как в плюс, так и минус, не поняв при этом, что конкретно к этому привело и как двигаться дальше. На графике ниже гипотетический пример с выручкой продукта, на котором было 5 изменений без А/В-теста в разное время, но из-за общей волатильности нет возможности понять, какие именно из них приводили к уменьшению выручки:
Если бы изменения оценивались А/В-тестированием, на таком же графике с добавленной разбивкой по группам можно было бы заметить, что негативную динамику дали только два изменения, от которых стоило отказаться (синяя линия — контрольная группа, желтые — группы с изменениями):
А/В-тест позволит без лишних сомнений отказаться от неудачного изменения, которое нравится всей команде, но не вашим пользователям.
Часто изменение кажется заведомо правильным. Например, переработка дизайна важного для вашего продукта элемента в соответствии с лучшими практиками от топовых дизайнеров в индустрии. От таких изменений ожидают позитивной динамики по метрикам, в худшем случае — отсутствия динамики с возможностью успокоить себя тем, что хоть на дизайн теперь не стыдно смотреть. По факту такие изменения могут существенно влиять на метрики в негативную сторону. Все изменения на важных для вашего продукта местах стоит оценивать при помощи А/В-теста.
Тест требует меньше работы от аналитика при оценке изменения.
При условии, что налажен процесс работы с А/В-тестированием, для аналитика гораздо проще оценить очередной А/В-тест, чем возиться с динамикой десятков факторов.
В условиях А/В-теста на порядок проще находить баги и несоответствия задуманной изначально логике изменения.
Без теста высока вероятность, что мы не узнаем:
- было ли изменение эффективным;
- степень влияния этого изменения;
- реальных причин падения/роста общей динамики;
- корректно ли работает задуманная логика;
- стоит ли дальше работать в этом направлении.
Доводы против:
- Тест немного сложнее для разработки.
- Если изменение незначительное, тратится лишний ресурс (но не всегда очевидно, что изменение незначительное — изменение на любых местах продукта с большим посещением стоит считать значительным).
- Если выборка заведомо малая/недостаточно релевантная, А/В-тест не даст достоверного/долгосрочно актуального результата. Либо потребуется слишком много времени на тестирование с утратой возможностей альтернативного развития на этот период.
- Долгосрочная концепция продукта строится на рассматриваемом изменении и не подразумевает альтернатив в зависимости от результатов изменения.
✓ Определяем метрики
Метрика A/B-теста — показатель, по которому оценивается, подтвердилась гипотеза или нет.
- На каких метриках мы ожидаем увидеть влияние как в лучшую, так и в худшую сторону? Стараемся перечислить все метрики, на которые изменение может повлиять, даже не самые важные. Они могут помочь в будущем убедиться, что функционал работает корректно.
- На основании каких метрик будет приниматься решение и какими метриками мы можем пренебречь, даже если на них будет влияние? Чем больше метрик принятия решения, тем выше вероятность получить ошибочный результат в хотя бы одной из них. Поэтому оптимально ориентироваться в решении лишь на несколько ключевых метрик.
- Смотреть в рамках теста можно на сотни и тысячи метрик, некоторые из них могут впоследствии стать метриками решения при неожиданном на них влиянии. Полезно выделить все важные для вашего продукта метрики заранее и в каждом тесте проверять их, даже если вы не ожидаете увидеть на большинство из них влияния.
- Каково текущее значение потенциальных метрик решения и какова их динамика? Какие факторы на них влияют?
- Какие метрики помогут нам убедиться в том, что логика теста работает корректно? Учитываем не только те метрики, на которые обычно смотрим, но и те, которые можно будет рассчитать после добавления соответствующего трекинга.
- Какие метрики для нас максимально критичны, чтобы их не задеть? Такие предохранительные метрики важны, чтобы не загнать в минус стратегически важные аспекты продукта, например скорость работы приложения, жалобы пользователей и другие.
✓ Определяем путь разбивки на группы
- Разбивка на две равные группы, 50% юнитов с изменением и 50% контрольная группа без изменений. Эта разбивка наиболее быстрая с точки зрения получения результатов, но рискованная, если изменение существенное и если запуск теста включает в себя пользователей, которые уже использовали ранее продукт.
- Разбивка на неравные группы. Например, группа на 5% юнитов с изменением и контрольная группа из 95% юнитов. Применяется зачастую тогда, когда под риск изменения мы хотим подставить лишь небольшую их часть. Также многие тесты есть смысл проводить не менее одной недели вне зависимости от выборки, чтобы уловить особенности изменения в рамках вариативности по дням недели, которая характерна для большинства продуктов. Долгосрочной оценки (2–3 недели и более) требуют тесты, в которых функционал проявляет своё влияние на более поздних этапах жизни юзера. В таких условиях бывает рискованно надолго подставлять под изменение значительную часть аудитории, и даже на проектах с более скромной аудиторией бывает уместнее выделить 5–10% для группы с изменением.
✓ Определяем целевую группу для А/В-теста (сегментация)
Здесь речь идет о том, все ли аудитории должны видеть тест или нужно выбрать только какое-то конкретное устройство/регион/десктопная или мобильная версия сайта/приложение/источник трафика. Сразу вся активная аудитория — просто и быстро, но может быть небезопасно. Применимо к функционалу, который не должен резко вызвать отторжение. Но иногда даже малые изменения могут принести существенные баги и негативно повлиять на вашу ключевую аудиторию.
Либо на стороне разработки можно запустить тест только на новых пользователей и сравнивать результаты групп среди них. По завершению теста в случае позитивного результата запускаем второй такой же тест, но в этот раз включаем в него нашу старую аудиторию. Это безопасная, но достаточно долгая стратегия для большинства существенных изменений. Если тест покажет себя хорошо для новой аудитории и плохо для старой — окончательное решение понадобится прикидывать в зависимости от структуры аудитории и ваших приоритетов. Или только на новых пользователей, эта стратегия подходит, когда по результату теста на новых юзерах функционал дает серьезный позитивный эффект, а риск получить негативный эффект на старых юзерах крайне мал.
✓ Определяем точку чувствительности оценки теста (ключевую метрику) — место в продукте, на котором происходит разделение логики
Опыт для пользователей из контрольной группы и группы с изменением не должен отличаться нигде вплоть до этой точки. Когда мы убедились в том, что метрики до «места с изменением» аналогичны между вариантами теста, можем оценивать ключевую метрику.
Если в рамках теста мы поменяли функционал, до которого доходит лишь часть пользователей — к примеру, изменили дизайн выдачи, то и сравнивать результаты стоит между пользователями, которые дошли до выдачи как в контрольной группе, так и в группе с изменением. Выборкой для такого теста будет не вся аудитория, а лишь её часть — это стоит учитывать в дальнейшем при оценке времени, необходимого для набора выборки.
Если не обозначить точку чувствительности, а просто сравнивать всю аудиторию — эффект от изменения будет размыт данными, которые не несут в себе никакой информации. Если до функционала доходят почти все пользователи, может появиться искушение сравнить всю выборку, поскольку эффект, к примеру, и так заметен. Это всё равно некорректно, если есть несколько процентов шума, от которых вы можете избавиться — избавляйтесь. При этом отдельно смотреть на то, что должно быть шумом, исходя из вашей точки чувствительности тоже нужно — чтобы проверить корректность работы функционала и обозначенной вами точки.
✓ Определяем необходимый размер выборки
Контрольная и экспериментальная выборка — пользователи, которые будут участвовать в эксперименте. Проверять можно как на всех пользователях, так и на группах, которые объединены по определенному показателю: местоположение, пол, возраст и так далее.
Минимальный размер выборки — минимальное количество пользователей, которые должны увидеть тестируемые версии, чтобы результаты были статистически значимы. Этот показатель можно рассчитать специальными калькуляторами, например, калькулятором Эвана Миллера.
Показатель статистической значимости — разница между метриками контрольной и экспериментальной выборки, при которой маловероятно, что это случайный результат.
Длительность тестирования — количество дней, когда будет идти эксперимент. Показатель зависит от минимального размера выборки и текущего трафика. Рассчитать длительность тестирования можно по формуле: выборка / трафик = количество дней.
Допустим, минимальный размер выборки для статистически значимых результатов теста — 10 000 уникальных посетителей. У сайта в среднем 1 000 посетителей в день. Значит длительность теста — 10 дней.
На что опираться при определении размера выборки:
- Точки чувствительности (ключевая метрика), в том числе в рамках жизненного цикла юзера — выборку стоит рассчитывать на основе той доли юзеров, которая доходит до места изменения.
- Учитывать важные сегменты, в рамках которых мы хотим проверить влияние — каждый сегмент расцениваем как отдельный тест со своей выборкой, своими ошибками первого и второго рода и так далее, но делать это аккуратно, чтобы не привести к p-hacking’у, о котором упоминалось в предыдущей статье. Нужно обязательно делать статистические поправки при таком анализе (например, поправку Бонферрони: делить выбранный уровень значимости (5%) на количество сравнений в тесте.
- Учитывать минимальный эффект влияния на метрику, который удастся обнаружить тестом (minimum detectable effect). Чем большего влияния мы ожидаем, тем меньше выборка потребуется. Если вы не ожидаете конкретного влияния, а лишь бы стало лучше от изменения — можно определить другие приемлемые для вас параметры, включая количество пользователей, на сбор которых готовы потратить время и узнать ту минимальную степень влияния, которую на момент завершения фактически сможете уловить, проведя тест. Если на этот момент разница между вариантами теста окажется бОльшей, чем фактический эффект, который может обнаружить стат. значимое изменение – тест проведен успешно, минимальная выборка точно набралась и можно смотреть на результат. В обратном же случае можно увидеть только отсутствие статистической значимости.
- Учитывать количество дней недели, которые нужно охватить тестом для получения данных по метрикам, показывающим волатильность в зависимости от дня недели. Иногда продукт может собрать внушительную выборку за полдня, но для получения объективной картины по дням недели его всё равно лучше проводить не менее 7 дней.
✓ Принимаем окончательное решение, нужен ли А/В-тест, утверждаем критерии успеха и действий по итогам
- Взвешиваем все плюсы и минусы;
- Оцениваем потенциальные сложности в запуске и интерпретации;
- Определяемся, готовы ли мы выделить время для сбора необходимого размера выборки.
Обязательно заранее продумываем, какой рост/падение, и каких конкретно метрик будет решающим для принятия решения о выкатке изменения в продакшн. Конверсия в следующий шаг выросла, а выручка нет, или наоборот, какие действия будут в данном случае?
✓ Описываем, какой трекинг необходим для оценки теста
Какие новые данные необходимо записывать по событиям продукта:
- Чем больше событий вокруг функционала трекаются, тем легче заметить проблемы с функционалом и выловить потенциальные баги.
- Лучше избыточный трекинг, чем недостаточный — в случае, если это не вызывает технических проблем и не влияет на опыт использования продукта (это необходимо проверять).
- С помощью трекинга должна быть возможность как минимум ответить на базовые вопросы по использованию функционала: какой процент юзеров хоть раз попробовал начать использовать функционал, какой процент юзеров успешно воспользовался функционалом, на каких шагах юзера проводили больше времени и отваливались и так далее.
- Не забывать добавлять трекинг на контрольной группе в том же месте и в тех же условиях, в которых к ним могла бы применяться логика группы с изменением (но не применяется). И наоборот.
✓ Проверка технической реализации функционала
Очень важно проверять техническую реализацию на стороне изменения, а также перепроверять, что все механизмы работы контрольной группы совпадают с механизмами работы тестовой группы (за исключением изменяемого элемента), чтобы не допускать случаев, которые я описывала в примерах некорректных тестов и не допускать бесполезных потерь в выручке продукта.
✓ Запуск теста
Главное, что нужно сделать при запуске, — проверить, что A/B-тест идет корректно. Например, кнопка, которая тестируется, работает, события отправляются с верным вариантом теста, а на варианте A мы никаких изменений не видим (как и должно быть). Если сразу появилась большая разница в конверсии версий A и B или наоборот, разницы нет вообще — это сигнал, что что-то идет не так.
Если же тест работает правильно, то не пытайтесь анализировать результаты до его окончания или вносить изменения в настройки теста в процессе. В первый день победителем может оказаться один вариант, а на следующий день — другой. Нужно дождаться окончания теста, чтобы получить достоверные результаты.
✓ Первая проверка после запуска или как выявлять технические недоработки / аномалии сразу после запуска
Её стоит делать сразу же в течении первых дней после запуска, как только появляются первые данные.
Проверяем:
- Наличие и корректность запланированного трекинга.
- Соответствуют ли назначенным группам варианты логики.
- Выборка равномерно распределена по вариантам, как запланировано (50/50 к примеру). При наборе достаточной выборки не должно быть статистически значимого отличия между группами в фактическом распределении количества юзеров от запланированного (sample ratio mismatch) — как для всей выборки, так и в рамках точки чувствительности.
Пример такой ситуации изображен на графике ниже. До момента запуска группы показывали очень схожую динамику по выручке, после запуска группа В выросла по выручке, но группа А тоже явно вышла на более высокий уровень. Такое могло произойти из-за увеличения в группе В не только выручки, но и активности в продукте. Это позитивно отобразилась на активности и выручке группы А.
- Вне точки чувствительности теста не должно быть разницы между А/В-группами. Если она есть, нужно разбираться почему — неправильно определенная точка чувствительности или некорректно работающая логика. Иногда точку чувствительности может сдвигать техническая проблема, связанная с изменением, которая проявляет себя ещё до столкновения пользователей с ним.
✓ Следим за метриками по сегментам и по общей динамике. Когда нужно останавливать тест досрочно
Смотрим не только на обобщённые метрики, но и на конкретные кейсы использования функционала, распределения значений метрик и на аутлаеров. Досрочное закрытие теста (до момента набора достаточной выборки) уместно в следующих случаях:
- Тест работает некорректно.
- Тест работает корректно, но
- Показывает очевидно плохой результат. Грань того, что считать очевидно плохим, решаете вы сами отдельно для каждого кейса. Естественно разница в худшую сторону должна быть определённой на выборке адекватного размера и сопоставленной с историческим значением метрики и её обычной волатильности. Если есть сомнения — ждите предопределенного заранее размера выборки и тогда принимаете решение. Здесь речь в основном про кейсы, когда изначально рискованный тест показывает очевидно плохой результат именно там, где его логично было ожидать, а на позитивное влияние нет и намека. И в которых вы готовы не получать полноценный отчёт по всем плюсам и минусам изменения, а просто отказаться от изменений.
- Рядовые изменения и добавления новых вспомогательных функционалов редко дают сильно хороший/плохой результат — как только замечаем такие результаты в динамике теста, стоит смотреть на них как на потенциальную ошибку и стараться найти проблему. Если проблему найти не удаётся, но результаты вызывают подозрения — можно провести новый тест на другой разбивке групп, но важно найти логичные обоснования неожиданно сильному влиянию.
- Функционал может показать себя хорошо, но в обход изначально запланированной логики — к примеру, ошибочные дубликаты уведомлений могут привести к краткосрочно положительному эффекту и крайне негативному долгосрочно. Или показать себя плохо не из-за своей сути, а к примеру из-за негативного влияния на скорость работы и других факторов, которые можно было исправить.
- Ложноотрицательный результат (вероятность того, что вы не увидите стат.значимый результат там, где он, на самом деле, есть – зависит от выбранной мощности теста, по умолчанию она равна 80%, т.е, в 80% случаев мы увидим стат.значимый результат, если он есть, но в 20% таких случаев будем ошибаться) может скрыть для вас потенциально перспективные направления в развитии продукта.
✓ Выявляем характерные временные эффекты в рамках изменения
Новизна (для старых пользователей)
Юзеры видят новый функционал и пробуют его, в итоге, в первые дни добавления функционала наблюдается высокий конверт в пользование, но со временем он снижается. На графике ниже изображена ситуация, когда на продукте 29 апреля был добавлен новый более заметный дизайн фичи. В первые дни стремительно повысился процент активных ежедневных юзеров (DAU) с хотя бы одним использованием фичи, но дальше группа с изменением опустилась по уровню этой метрики ниже контрольной группы из-за негативного влияния, так как новый дизайн менее удобен.
Привычка (для старых пользователей)
Юзеры привыкают к определенному функционалу и сразу после его изменения может наблюдаться временная негативная динамика.
Кумуляция
Со временем юзер начинает использовать функционал чаще, либо постепенное массовое принятие функционала одними пользователями приводит к более частому использованию функционала другими. Пример из практики компаний — дали пользователям возможность добавлять линки на свои соцсети в профиле, в первые дни это делали только несколько процентов новых пользователей. Но когда новые пользователи начали часто видеть такие линки на других профилях, добавления выросли в 3-4 раза.
Долгосрочные эффекты
За короткий срок невозможно достоверно оценить большинство долгосрочных эффектов, но можно на основе каузальных взаимосвязей оценить, куда будет стремиться общая продуктовая динамика.
✓ После накопления достаточной выборки принимаем решение
Решение о закрытии нужно принимать одноразово в момент, когда соберется выборка необходимого размера, а не выжидать статистической значимости и тогда закрывать. Почему так не стоит делать – было описано в предыдущей статье в пункте про пи-хакинг. Если между группами нет значимого отличия — принимаем решение на основании других факторов, например, сложность поддержания функционала в будущем, возможности для его развития и так далее.
Представим пример:
Гипотеза: “Если мы поменяем цвет кнопки на красный, то конверсия улучшится с 1% до 1.1%”.
Нулевая гипотеза: “Смена цвета не улучшит конверсию (или вообще ухудшит).”
У нас может быть 3 исхода A/B теста:
- Гипотеза подтверждена – меняем цвет;
- Гипотеза опровергнута – это не значит, что красный цвет хуже, это значит, что он дает меньше чем 1.1% конверсии;
- Ничего не понятно (статистически незначимый результат). Результаты не дают ни достоверного подтверждения, ни опровержения гипотезы.
Если вы получили статистически незначимый результат, то это не значит, что изменение никак не влияет на выборку, это значит лишь то, что мы запланировали объем выборки под случай с более высокой разницей между вариантами, а на деле разница оказалась меньшей. Т.е что нужно больше пользователей, чтобы понять и увидеть фактическую разницу. Но ждать какое-то время до первого статистически значимого результата некорректно, ведь мы можем попасть на ошибку (про проблему подглядывания говорилось выше).
Поэтому, в третьем исходе, когда «ничего не понятно», принимая решение о том, выкатывать такой тест на прод или нет, нужно понимать, что в перспективе, с бОльшим количеством времени уже на проде, колебания метрики могут сыграть не в нашу пользу, т.к могут пойти как в позитивную, так и негативную сторону.
✓ Закрываем тест и убеждаемся, что он закрыт корректно
Либо можно раскатить изменение на всех пользователей и проследить за поведением пользователей в группах (разницу между ними, особенно на пользователях с варианта A). Это может помочь более выражено выявить и исследовать временные эффекты. Когда контрольная группа старых пользователей получит изменение, мы увидим ещё одну итерацию временных эффектов с момента старта изменения. Следим до тех пор, пока группы существенно отличаются.
На графике ниже изображён тест с сильным эффектом новизны во влиянии на использование фичи. Изменение в нём в итоге не приводит к ухудшению метрики, по сравнению с контрольной группой. Но когда решаем применить изменение ко всем пользователям, группа А показывает свой эффект новизны, так как сталкивается с функционалом впервые, в то время как пользователи группы В, к этому моменту, уже успели к нему привыкнуть и выйти на стабильный уровень по метрике.
✓ Решаем, полезным ли был для нас тест
Закрытие в варианте с изменением не всегда указывает на полезный тест, и наоборот. Неудачные тесты или тесты со слабым эффектом могут быть полезными, если дают нам лучшее понимание поведения пользователей, которое мы сможем применить в дальнейшем. Делаем выводы — стоит ли провести больше тестов в этом направлении, стоит ли дальше развивать этот функционал, для какого ещё функционала мы можем применить новые знания?
С каждым экспериментом вы получаете больше выводов и лучше понимаете, как пользователи взаимодействуют с сайтом. Это делает A/B тесты более ценными.
Очень важно изучать конверсии на разных частях воронки в каждом тесте, чтобы понимать, где стало хуже/лучше. Возможно, изменение заставило уйти часть незаинтересованных пользователей в месте изменения, но в дальнейших шагах повысило конверсии к оплате, т.к по дальнейшим шагам шли более заинтересованные в тестовом варианте пользователи.
✓ Записываем характеристики и результаты теста в историю проведения А/В-тестов
История тестов всегда крайне полезна, особенно, если:
- в продуктовую команду придет новый человек — для лучшего понимания продукта и чтобы не предлагать опробованные ранее идеи;
- вы столкнетесь с техническими проблемами — причиной может быть некорректно закрытый или скрыто забагованный тест в прошлом;
- вы столкнетесь с негативной динамикой по метрикам — причиной может быть неправильно или неполноценно проанализированный тест в прошлом;
- вы ищете точки для роста — история тестов поможет заметить направления работы, которые чаще приводили к хорошим или плохим результатам по конкретной метрике, были более и менее эффективны с точки зрения отдачи по ресурсам.
Выводы
- А/В-тест — лучший способ оценить эффективность изменений на вашем продукте.
- При продуманном подходе полезными могут быть и альтернативные тесты.
- Важно настроить систематический и гибкий подход к проведению тестов, когда оптимально тратится ресурс команды на обсуждение условий, запуск и аналитику. Для этого следовать пунктам чек-апа и стараться не совершать поспешных решений, чтобы A/B тесты были помощью, а не обузой.
