Для многих IT-компаний, занимающихся разработкой и продвижением продуктов, А/В-тестирование стало не просто важным аналитическим инструментом, но скорее отправной точкой для развития продукта. Без использования А/В-тестов может быть трудно оценить и определить, какие изменения необходимы и как они будут влиять на поведение пользователей.
Про статистику и про то, как делать А/В-тесты, информация в изобилии, но в большинство источников фокусируются на «технике», подсчете выборки, проблеме подглядывания, правильной интерпретации p-value… А вот практических советов по менеджменту А/В-тестов не так уж и много.
Развитие продукта происходит благодаря изменениям, а чтобы понять, насколько эффективны эти изменения, нужно быть сильным в аналитике, должно быть понимание того, как считаются метрики. Так продакт-менеджер не просто будет сидеть и ждать от аналитика подтверждения своих решений, а сможет с ним общаться, понимать, как изменения влияют на продукт и находить новые пути развития на основе прошлого опыта.
Зачем нужны чек-листы
Чек-листы — важная опора во всех сферах, если мы стремимся к минимизации вероятности ошибки, и нам важно грамотно выстроить процесс. Некоторые шаги по ходу выполнения задач могут быть неодинаково понятны для каждого члена команды, даже самые важные из них. Если вы работаете в одной команде над одним проектом, то вполне вероятно, что у вас найдется много общих шагов в процессе работы, которые можно вынести в отдельный чек-лист, и это сократит время на их обсуждение.
План чек-листа:
- Формулировка гипотезы
- Нужен ли А/В-тест?
- Определяем метрики
- Определяем путь разделения на группы
- Определяем целевую группу
- Определяем ключевую метрику
- Определяем размер выборки
- Утверждаем критерии успеха и действий по итогам
- Описываем необходимый трекинг для оценки теста
- Проверка технической реализации функционала
- Запуск теста
- Проверка теста после запуска
- Следим за метриками
- Выявляем характерные временные эффекты в рамках изменения
- После накопления выборки принимаем решение
- Закрываем тест
- Оцениваем полезность теста
- Записываем характеристики и результаты теста в историю
Рассмотрим каждый пункт детальнее.
✓ Формулировка гипотезы
Формулировка гипотезы – залог правильного теста. Гипотеза поможет определить цели эксперимента, выбрать метрики и интерпретировать результаты. При наличии чётких целей на этом этапе уже будет отсекаться много гипотез.
Построение гипотезы строится следующим образом:
✓ Нужен ли А/В-тест?
Аргументы за:
Тестирование дает наиболее точную оценку внесенных изменений.
Основной альтернативой является анализ динамики, то есть сравнение периодов до и после применения изменений. Такой метод подходит для определенных случаев, однако сталкивается с проблемами в некоторых ситуациях:
- Множество факторов одновременно влияют на метрики. Чем больше факторов воздействуют на метрики вашего продукта, тем актуальнее оценивать внесенные изменения с помощью А/В-тестирования. Факторы могут включать постоянные изменения в структуре пользователей по ключевым параметрам (пол, возраст, источник трафика и т.д.), а также одновременное проведение других тестов в вашем продукте или других продуктах компании. Даже тщательное наблюдение за динамикой по всем сегментам не гарантирует, что именно затрагиваемое изменение повлияло на метрику, а не другой фактор. Вы никогда не будете владеть всей информацией о всех факторах, оказывающих влияние на продукт в данный момент. Случайное распределение групп в А/В-тестах позволяет избежать влияния всех факторов, даже тех, которые непосредственно не видны.
- От внесенных изменений ожидается минимальное влияние на метрики, которое может быть незаметным в динамике из-за естественной волатильности метрики. БОльшая часть тестов на продуктах, особенно на более поздних стадиях развития, именно таковы. Проводя десятки подобных тестов, можно сдвинуть общую динамику в плюс или минус, не понимая при этом, что именно привело к этому и как продолжать работу. На графике ниже представлен гипотетический пример выручки продукта, где было 5 изменений без А/В-теста в разное время, но из-за общей волатильности невозможно определить, какие именно из них привели к снижению выручки:
При использовании А/В-тестирования для оценки изменений на аналогичном графике с добавлением разделения по группам можно было бы увидеть, что отрицательную динамику вызвали только два изменения, от которых следовало отказаться (синяя линия – контрольная группа, желтые – группы с примененными изменениями):
А/В-тестирование позволяет с уверенностью отказаться от неудачного изменения, которое может нравиться команде, но не пользователям.
Зачастую изменение кажется изначально верным. Например, обновление дизайна ключевого элемента вашего продукта в соответствии с передовыми практиками от ведущих дизайнеров индустрии. От таких изменений ожидается положительная динамика метрик или, в худшем случае, отсутствие динамики с возможностью успокоить себя тем, что дизайн теперь выглядит привлекательнее. Однако на практике такие изменения могут существенно влиять на метрики в негативном ключе. Все изменения в критически важных для вашего продукта областях рекомендуется оценивать с использованием А/В-теста.
Тестирование облегчает работу аналитика при оценке внесенных изменений.
При налаженной работе с А/В-тестами для аналитика гораздо легче оценить очередной А/В-тест, нежели разбираться с динамикой десятков факторов.
В рамках А/В-тестирования значительно упрощается поиск ошибок и несоответствий заложенной изначально логике изменений.
Без проведения тестов существует высокая вероятность того, что мы не узнаем:
- были ли изменения эффективными;
- степень влияния конкретного изменения;
- реальные причины снижения или роста общей динамики;
- корректно ли реализована логика;
- стоит ли продолжать работу в данном направлении.
Аргументы против:
- Тестирование усложняет разработку.
- Если изменение небольшое, могут быть израсходованы лишние ресурсы (хотя не всегда очевидно, что изменение малозначительное – любое изменение в области продукта с большим количеством посетителей стоит считать важным).
- Если выборка слишком мала или недостаточно релевантна, А/В-тест не предоставит надежный или долгосрочно актуальный результат. Либо потребуется слишком много времени на тестирование, что приведет к потере возможностей альтернативного решения в течение этого периода.
- Долгосрочная концепция продукта основана на рассматриваемом изменении и не предполагает альтернатив в зависимости от результатов.
✓ Определяем метрики
Метрика А/В-теста – это показатель, с помощью которого оцениваются результаты и доказательство гипотезы.
- На каких метриках ожидаются изменения как в положительную, так и в отрицательную стороны? Стремимся перечислить все возможные метрики, даже если они не являются основными. Это поможет в будущем убедиться в корректной работе функционала.
- Основываясь на каких метриках будет приниматься решение и какие метрики можно проигнорировать, даже если на них будет влияние? Чем больше метрик задействуется при принятии решений, тем выше вероятность получить неверный результат хотя бы по одной из них. Поэтому оптимально руководствоваться лишь несколькими ключевыми метриками при принятии решений.
- В рамках теста можно отслеживать сотни и тысячи метрик, некоторые из которых могут впоследствии стать метриками для принятия решений при неожиданном влиянии на них. Полезно заранее определить все важные для вашего продукта метрики и проверять их в каждом тесте, даже если вы не ожидаете увидеть влияние на большинство из них.
- Каковы текущие значения потенциальных метрик для принятия решений и какова их динамика? Какие факторы оказывают влияние на них?
- Какие метрики помогут подтвердить корректность работы логики теста? Принимаем во внимание не только обычные метрики, но и те, которые можно будет вычислить после внедрения соответствующего отслеживания.
- Какие метрики являются наиболее критическими для нас, чтобы избежать негативного воздействия на них? Такие предупредительные метрики важны для того, чтобы не ухудшить стратегически важные аспекты продукта, такие как производительность приложения, жалобы пользователей и прочее.
✓ Определяем путь разделения на группы
- Разделение на две равные группы: 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 тесты были помощью, а не обузой.
