Как провести A/B-тест без ложных результатов: правила настройки и частые ошибки

Что такое A/B-тест

A/B-тест — это контролируемый эксперимент, в рамках которого участников делят на две или несколько групп и показывают им разные версии продукта, страницы, функции, отдельного элемента интерфейса. Одна группа видит текущий вариант — версию А, другая изменённый — версию B. Затем команда сравнивает поведение пользователей и оценивает, как изменения повлияли на целевую метрику.

Как объясняет директор по продукту медиа Russian Business Александр Ремезов, метод используют, чтобы снизить риск неудачного запуска, проверить гипотезу цифрами, выбрать вариант дизайна, текста или цены и оценить влияние изменения на бизнес-показатели.

Продуктовый руководитель платформы для A/B-тестирования Trisigma Искандер Мирмахмадов добавляет, что главная задача A/B-тестирования — проверить гипотезу до внедрения изменения для всей аудитории. Такой подход, по мнению эксперта, помогает принимать решения на основе данных, а не предположений.

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

Почему A/B-тест может дать ложный результат

A/B-тест даёт ложный результат, когда команда принимает случайное колебание в поведении пользователей — естественные «скачки» метрик, которые возникают сами по себе, техническую ошибку или локальный эффект — за значимое изменение, а затем останавливает тест раньше времени или делает неверные выводы.

Директор по продукту медиа Russian Business Александр Ремезов связывает ложные результаты с неправильно подготовленными параметрами эксперимента и человеческим фактором. Перед запуском нужно заранее определить условия завершения теста, учесть технические и сезонные факторы, а после — не менять правила оценки результата.

Ошибка подглядывания

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

Продуктовый руководитель платформы для A/B-тестирования Trisigma Искандер Мирмахмадов отмечает, что следить за ходом теста всё равно нужно: команда должна видеть технические сбои, проблемы в продукте и резкие отклонения в данных, но при этом не останавливать тест раньше времени.

Эффект новизны

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

Директор по продукту медиа Russian Business Александр Ремезов приводит пример с введением новой версии поиска: если старая версия была неудобной, и пользователи редко ей пользовались, то после улучшения эффект может проявиться не сразу. Людям нужно время, чтобы привыкнуть и начать пользоваться поиском чаще.

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

Некорректно выбранные метрики

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

Технические ошибки

Технические ошибки могут полностью исказить результат. Например, кеш может показать пользователю старую версию страницы, блокировщик рекламы — не дать отправить событие в аналитику, сбой в cookie — заново распределить человека в другую группу, а разрыв сессии или ошибка в передаче идентификатора между доменами — учесть одного пользователя несколько раз. Ещё одна частая проблема — событие уходит в аналитику раньше, чем система назначила пользователю вариант теста.

Чтобы исключить искажение результатов из-за технических ошибок и убедиться в корректности работы аналитики, директор по продукту медиа Russian Business Александр Ремезов рекомендует вначале проводить A/A-тест: пользователям показывают одинаковые версии продукта и смотрят, появляются ли значимые расхождения в результатах там, где изменений не было. Если различия возникают, скорее всего, проблема в настройке эксперимента или сборе данных.

Директор по аналитике соцсети «ВКонтакте» Максим Крылов выделяет такую ошибку, как Sample Ratio Mismatch (SRM), или несоответствие пропорции выборок. Если группы должны делиться 50 на 50, но одна стабильно получает больше пользователей, результатам теста доверять нельзя. Причиной может быть ошибка в распределении трафика, идентификаторе пользователя или трекинге событий.

Различия между сегментами аудитории

Изменение может улучшить метрику на мобильных устройствах и ухудшить на десктопе, сработать в одном регионе и не дать эффекта в другом, помочь новым пользователям и помешать постоянным. Продуктовый руководитель платформы для A/B-тестирования Trisigma Искандер Мирмахмадов отмечает, что решение не всегда должно быть одинаковым для всей аудитории. Если изменение хорошо работает только для одного сегмента, его можно внедрить именно там. Тщательный анализ результатов помогает не потерять полезный эффект и не раскатить изменение на пользователей, для которых продукт ухудшится.

Что проверить до запуска A/B-теста

Тест действительно необходим

Перед запуском A/B-теста в первую очередь нужно понять, действительно ли он нужен и не будут ли другие методы анализа более эффективными. По словам директора по аналитике соцсети «ВКонтакте» Максима Крылова, в некоторых случаях гипотезы проще и быстрее проверить через постепенную раскатку изменений, экспертную оценку или другими аналитическими инструментами.

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

Максим Крылов Директор по аналитике соцсети ВКонтакте

Гипотеза сформулирована конкретно

Лучше стараться избегать расплывчатых формулировок. Например, утверждение «новая кнопка лучше старой» не подходит для A/B-теста, потому что из него непонятно, какой результат считается улучшением и как его измерить. Рабочая гипотеза должна содержать конкретное предположение о том, как изменение повлияет на поведение пользователей и какую метрику это затронет. Например: «Новый дизайн кнопки увеличит конверсию в оформление заказа».

Выборка рассчитана до запуска

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

Размер выборки напрямую влияет на способность теста обнаружить эффект. Чем меньше ожидаемые изменения, тем больше пользователей потребуется для их обнаружения. Например, зафиксировать рост конверсии с 10 до 11% значительно сложнее, чем с 10 до 15%. Если данных недостаточно, тест может не показать существующий эффект и ошибочно привести к выводу, что между вариантами нет значимых различий.

До запуска фиксируют нужное число пользователей, длительность теста и условия остановки.

Метрики закреплены в плане теста

По словам директора по аналитике социальной сети «ВКонтакте» Максима Крылова, ключевые метрики необходимо определить и зафиксировать ещё до запуска эксперимента. В противном случае после завершения теста команда может начать выбирать только те показатели, которые подтверждают ожидаемый результат. Обычно набор метрик закрепляют в плане тестирования — документе, где описаны цели эксперимента, методика его проведения, ожидаемый эффект и критерии оценки результатов.

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

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

Рандомизация проверена

Рандомизация в A/B-тестировании — это случайное распределение пользователей по группам. Одни попадают в группу A и видят старую версию, другие — в группу B и видят новый вариант.

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

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

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

Трекинг данных работает без сбоев

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

Директор по продукту Russian Business Александр Ремезов относит к наиболее типовым техническим ошибкам ситуацию, когда событие отправляется в аналитику до назначения пользователю варианта теста, а также сбои в работе cookie, блокировку скрипта эксперимента, проблемы с передачей данных между доменами и повторный учёт одного и того же пользователя. Такие ошибки нарушают случайное распределение аудитории между группами и делают результаты теста недостоверными.

Внешний шум учтён в календаре

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

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

План решения подготовлен заранее

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

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

Как выбрать способ A/B-тестирования и настроить сплит

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

Сплит — это разделение аудитории между вариантами. Например, 50% пользователей видят текущую страницу, ещё 50% — новую. Разметка сплита показывает системе аналитики, кто в какую группу попал и какие действия совершил после этого.

Клиентское тестирование

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

Плюсы клиентского тестирования: можно применять готовые платформы, это быстрее, не нужен релиз*Релиз — это официальный выпуск новой версии программного продукта.. Минусы: оно влияет на производительность сайта, сильнее зависит от технических факторов — кеша, блокировщиков и других ограничений. Есть ещё flicker effect (эффект мерцания): пользователь на долю секунды может увидеть оригинальный вариант, а затем — вариант B.

Александр Ремезов Директор по продукту Russian Business

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

Серверное тестирование

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

Директор по продукту Russian Business Александр Ремезов говорит, что серверное тестирование даёт более надёжную рандомизацию и меньше визуальных артефактов, но запуск занимает больше времени, а команда должна поддерживать инфраструктуру экспериментов.

Готовые платформы и собственная система

Для проведения простых A/B-тестов обычно используют Google Tag Manager или встроенные инструменты аналитики. Они позволяют быстро запустить эксперимент через веб-интерфейс без сложной разработки. Однако по мере усложнения задач такие решения начинают ограничивать: не все сценарии можно корректно реализовать и проверить.

Более продвинутый вариант — специализированные платформы для A/B-тестирования. Они дают больше возможностей: помогают распределять трафик, сегментировать аудиторию, отслеживать метрики и фиксировать результаты. При этом их внедрение требует интеграции с сайтом, приложением и системами аналитики, а также дополнительных затрат. Крупные продукты с большим количеством экспериментов используют собственные системы A/B-тестирования. Такой подход даёт полный контроль и гибкость, поскольку система встраивается во внутренние процессы компании. Но он требует отдельной разработки, поддержки и команды, которая отвечает за качество данных.

Какие ошибки ломают разметку

Разметка в A/B-тесте — это процесс, который определяет, к какой группе относится пользователь и какие события о его действиях фиксируются в аналитике. Даже хорошо спланированный эксперимент может дать искажённые результаты, если разметка работает некорректно. Самые частые проблемы связаны с тем, как система назначает вариант, хранит идентификатор пользователя и отправляет события в аналитику.

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

Запуск и мониторинг: что делать в первые 72 часа после запуска A/B-теста

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

Первые 72 часа — это время, когда следует проверять, что тест настроен технически корректно. Это не время принимать решение по эксперименту, если только не выявлено багов или нарушений условий эксперимента.

Александр Ремезов Директор по продукту Russian Business

Что проверять после запуска

Сначала нужно убедиться, что пользователи попадают в группы в нужной пропорции. Если тест настроен как 50 на 50, но одна группа стабильно получает больше трафика, результат будет недостоверным. Такая ошибка называется Sample Ratio Mismatch, или несоответствие пропорции выборок.

Директор по аналитике соцсети «ВКонтакте» Максим Крылов отмечает, что первые дни нужны для проверки стабильности данных. Команда смотрит, корректно ли собираются события, нет ли резких скачков в метриках и не ломает ли эксперимент пользовательский сценарий.

Когда тест можно остановить раньше

Досрочная остановка оправдана, если эксперимент вредит продукту: ломает ключевой сценарий, ухудшает важные метрики, вызывает технические ошибки или заметно портит пользовательский опыт. В таком случае тест прекращают не потому, что один вариант «победил», а потому, что продолжать эксперимент рискованно.

Как вести лог аномалий

Лог аномалий — это журнал, в котором фиксируют все внешние события и отклонения, способные повлиять на результаты A/B-теста. Без такого журнала после завершения эксперимента сложно понять, почему изменилась метрика.

Директор по продукту Russian Business Александр Ремезов предлагает простой формат лога: дата, событие, затронутая аудитория, возможное влияние и принятое решение. В такой журнал можно заносить сбои на сайте, резкие изменения трафика, рекламные запуски, изменения цен, праздники, релизы и другие события, которые могли повлиять на поведение пользователей.

Продуктовый руководитель платформы для A/B-тестирования Trisigma Искандер Мирмахмадов отмечает, что часть мониторинга можно автоматизировать через системы аналитики и платформы A/B-тестирования. Но даже при автоматическом сборе данных команде всё равно нужно понимать, какие события могли повлиять на интерпретацию результата.

Что делать, если появилась аномалия

Если аномалия затронула обе группы одинаково, тест можно продолжить, но событие нужно зафиксировать в логе. Если проблема повлияла только на одну группу, эксперимент теряет чистоту: например, вариант B загружался медленнее, часть событий в нём не отправлялась или отдельный источник трафика попал только в одну группу.

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

Анализ и бизнес-решение: интерпретация без статистического фанатизма

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

Статистическая значимость не равна пользе для бизнеса

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

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

Как посчитать экономику теста

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

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

Александр Ремезов Директор по продукту Russian Business

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

Что делать, если тест показал положительный результат

Если тест показывает положительный результат, это не означает, что изменение можно сразу раскатывать на всю аудиторию. Сначала нужно проверить дополнительные и защитные метрики, убедиться, что в данных не было технических сбоев. Только после этого изменение внедряют постепенно, начиная с небольшой доли пользователей и поэтапно увеличивая охват. Например, сначала для 10% пользователей, затем для 20, 50 и 100%. После каждого этапа нужно следить, сохраняется ли эффект и не появляются ли новые проблемы.

Что делать, если тест провалился

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

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

Что делать, если получилась «ничья»

«Ничья» в A/B-тесте означает, что значимого различия между вариантами не обнаружено. Причин может быть несколько: изменение действительно не влияет на поведение, эффект слишком мал для текущей выборки или тест не смог его обнаружить из-за слабой чувствительности метрик.

Если изменение не даёт заметного результата и требует ресурсов на поддержку, внедрять его нет смысла. Исключение — дешёвое изменение с другой понятной пользой: например, оно упрощает поддержку, снижает внутренние издержки или закрывает одну из потребностей бизнеса без ухудшения метрик.

Продуктовый руководитель платформы для A/B-тестирования Trisigma Искандер Мирмахмадов приводит ориентир по результатам экспериментов: около 10% гипотез дают значимый положительный результат, ещё около 10% — значимый негативный, а примерно 80% не показывают значимого эффекта. Поэтому «ничья» в A/B-тестах — рабочий результат, который помогает не внедрять изменения без доказанной пользы.

Если продуктовая метрика выросла, а бизнес-метрика — нет

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

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

Искандер Мирмахмадов Продуктовый руководитель Trisigma

Директор по аналитике соцсети «ВКонтакте» Максим Крылов обращает внимание, что часть бизнес-метрик видна с задержкой. Пожизненная ценность клиента (LTV) и возврат инвестиций (ROI) могут проявиться позже стандартного срока теста. В таких случаях заранее выбирают промежуточные метрики, которые по историческим данным связаны с долгосрочным результатом.

Когда A/B-тест не сработает

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

Мало трафика

При малом трафике тесту нужно больше времени, чтобы накопить нужную выборку. Если остановить эксперимент раньше, он может не заметить реальный эффект и показать «ничью». Ещё одна проблема — мелкие изменения. Чем меньше ожидаемый эффект, тем больше данных нужно для проверки.

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

Малый объём трафика не означает, что проводить A/B-тесты невозможно. Сегодня существует множество статистических методов, которые помогают получать надёжные результаты быстрее и повышать чувствительность экспериментов. Среди них — CUPED*CUPED — это статистический метод, который помогает сделать A/B-тест более точным. Он учитывает прошлое поведение пользователей и помогает понять, сработало ли изменение., последовательное тестирование*Поп-ап: Последовательное тестирование — подход, при котором результат A/B-теста проверяют не один раз в конце, а несколько раз по ходу эксперимента. Подход позволяет раньше заметить сильный эффект или понять, что тест не даёт результата., постстратификация*Постстратификация — способ уточнить результат A/B-теста после сбора данных. Пользователей дополнительно делят на группы, например по стране, устройству или активности, чтобы случайный перекос не исказил вывод. и другие подходы.

Искандер Мирмахмадов Продуктовый руководитель Trisigma

Длинный цикл покупки

По словам опрошенных Russian Business экспертов, A/B-тест сложнее проводить, если решение о покупке занимает недели или месяцы. Пользователь может увидеть вариант B сегодня, а купить сильно позже. В таком случае стандартный срок теста не покажет полный эффект, а быстрые метрики могут не совпасть с итоговыми бизнес-показателями.

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

Нельзя корректно измерить ключевую метрику

A/B-тест теряет смысл, если команда не может надёжно измерить показатель, ради которого запускает эксперимент. Например, часть событий не попадает в аналитику, пользователи переходят между устройствами без единого идентификатора, офлайн-продажи не связаны с онлайн-действиями или итоговая бизнес-метрика считается в другой системе.

Нельзя показывать разные условия разным пользователям

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

В таких случаях A/B-тест заменяют другими способами проверки: историческим анализом, постепенной раскаткой, качественными исследованиями, экспертной оценкой или синтетическими моделями.

Изменение слишком большое или стратегическое

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

Директор по продукту Russian Business Александр Ремезов относит к ограничениям стратегические изменения, длинный цикл покупки, малый трафик, сильную волатильность и ситуации, когда ключевую метрику нельзя измерить корректно. В таких случаях A/B-тест может быть только одним из источников данных, а не единственным основанием для решения.