Плохие A/B тесты

Тест идёт третий день. PM открывает дашборд — версия B ведёт с конверсией 6.8% против 5.9% у контроля. P-value — 0.04. Коллеги в Slack пишут «запускаем?». PM останавливает тест и отправляет версию B в прод.

Через три недели конверсия возвращается к исходной. Эффект испарился. Команда объясняет это «сезонностью» и переходит к следующему тесту. Никто не задаёт вопрос, который разрушил бы картину: а был ли эффект вообще?

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

Ловушка 01 — Peeking: остановка теста в удобный момент

Интуитивное решение. Смотреть на результаты каждый день — это разумно. Если разница уже значима, зачем ждать? Мы сэкономим время и быстрее внедрим улучшение.

Почему это ломает систему. Статистическая значимость — не стабильная характеристика. Это значение, которое флуктуирует в течение теста. В самом начале, когда данных мало, разница между группами может случайно оказаться большой — и вернуться к норме через несколько дней. Когда команда смотрит на данные каждый день и останавливается, как только p < 0.05, она систематически ловит именно эти флуктуации.

Математика беспощадна. Если смотреть на тест каждый день в течение 20 дней, вероятность хотя бы раз увидеть p < 0.05 при отсутствии реального эффекта вырастает с 5% до 54%. Это не теоретический риск — это то, что происходит в большинстве продуктовых команд, у которых нет жёсткого протокола.

Ключевая метрика-индикатор. Процент экспериментов в команде, где фактическая длительность совпадает с запланированной до запуска. Если больше половины тестов останавливаются раньше — система заражена peeking-ом.

Пример. Команда роста e-commerce тестирует новую форму чекаута. На пятый день версия B показывает конверсию +11%, p = 0.031. Тест останавливают и запускают в прод. Через две недели аналитик замечает, что эффект исчез. Ретроспективный анализ показывает: на пятый день в тест попали данные выходных — паттерн поведения принципиально другой. Будь тест запущен ещё семь дней, результат оказался бы незначимым.

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

Плохой тест (peeking): Команда запускает тест кнопки «Начать бесплатно» против «Попробовать 14 дней». День 4: конверсия +9%, p = 0.048. PM пишет в Slack «значимо, запускаем». Тест остановлен. Итог через месяц: конверсия вернулась к исходной, потому что эффект был случайным выбросом первых выходных.

Хороший тест (тот же вопрос): До запуска зафиксировано: длительность — 21 день, первичная метрика — конверсия в регистрацию, минимальный эффект — +5%. Day 4 PM видит p = 0.048, но дашборд заблокирован от промежуточных проверок через Statsig. На день 21 результат — p = 0.31: нет значимой разницы. Команда не внедряет изменение и переходит к следующей гипотезе — вместо того чтобы откатывать прод через месяц.

Ловушка 02 - P-hacking: перебор метрик до победного

Интуитивное решение. Тест не показал роста конверсии — но, может, мы смотрим не на ту метрику? Проверим retention. Или средний чек. Или количество шагов в онбординге. Наверняка что-то выросло.

Почему это ломает систему. Если проверить достаточно метрик, одна из них окажется «значимой» случайно. При пороге p < 0.05 это происходит примерно в каждом двадцатом случае. Проверьте двадцать метрик — получите одну «победу» просто по теории вероятности, без всякого реального эффекта.

Это называется проблемой множественных сравнений (multiple comparisons problem). В медицинских исследованиях она регулируется корректировкой Бонферрони в публичных реестрах. В продуктовых командах — почти никогда ничем не регулируется.

Особенно опасен вариант, когда первичная метрика определяется после просмотра данных. Команда запускает тест «посмотреть», а потом выбирает метрику, по которой версия B выиграла. Это уже не эксперимент — это поиск удобного нарратива в шуме.

Ключевая метрика-индикатор. Соотношение количества «победивших» тестов к общему числу запущенных. Если в команде побеждает больше 40–50% тестов — это статистически подозрительно. В хорошо устроенных экспериментальных системах побеждает 10–30%.

Кейс. Spotify и другие компании с зрелой культурой экспериментирования публично говорили о том, что их win rate на ранних этапах был слишком высоким — и это было плохим знаком, а не хорошим. Команды научились «побеждать» в тестах через выбор метрики после факта. Решение — обязательная фиксация primary metric до запуска в специальном документе, к которому нет доступа на редактирование после старта теста.

Когда процент побед в тестировании выше 60% — это не признак хорошей команды. Это признак того, что команда научилась находить победу там, где её нет. Хороший аналитик воспринимает высокий win rate как красный флаг.

Плохой тест (p-hacking): Тестируется новый экран онбординга. До запуска метрика не зафиксирована. После двух недель смотрят на 12 метрик: activation rate, time-to-first-action, retention day 1, retention day 7, NPS, средний чек, количество созданных проектов... Retention day 1 вырос на 4%, p = 0.049. Команда объявляет победу именно по этой метрике. В следующем квартале retention day 7 не изменился — потому что реального улучшения не было.

Хороший тест (тот же онбординг): До запуска зафиксировано: первичная метрика — activation rate (пользователь создал первый проект в течение 48 часов). Вторичные метрики — только для диагностики, не для вынесения вердикта. После двух недель: activation rate +6%, p = 0.03. Вторичные метрики не противоречат — retention day 7 тоже немного вырос. Вывод однозначен, потому что вопрос был задан до получения данных.

Ловушка 03 - Novelty Effect: иллюзия улучшения от новизны

Интуитивное решение. Версия B получила на 15% больше кликов в первую неделю — значит, изменение работает. Запускаем.

Почему это ломает систему. Пользователи реагируют на новое просто потому что оно новое. Изменённый элемент интерфейса привлекает внимание в первые дни — потом поведение возвращается к норме. Это хорошо задокументированный феномен: novelty effect систематически завышает измеренный эффект для изменений интерфейса, особенно в первые 3–7 дней.

Команды, которые запускают тесты на короткий период, систематически переоценивают улучшения. Через месяц после выкатки в прод «улучшение» бесследно исчезает — и его объясняют внешними факторами, не возвращаясь к вопросу о качестве теста.

Ключевая метрика-индикатор. Сравнение размера эффекта на первой и второй неделях теста. Если эффект резко падает между первой и второй неделей — это novelty, а не реальное улучшение.

Кейс. Команда мобильного приложения меняет расположение кнопки основного действия. Первые пять дней: +22% кликов на кнопку, конверсия в завершение задачи +8%. Тест останавливают. Через две недели после выкатки в прод конверсия возвращается к исходной — пользователи привыкли к новому месту кнопки и перестали замечать изменение. Если бы тест шёл три недели, данные второй недели показали бы возврат к норме.

Плохой тест (novelty): SaaS-продукт тестирует новую навигационную панель. Неделя 1: +18% кликов по ключевым разделам. Тест останавливают на 8-й день. Запускают в прод. Через три недели метрика возвращается к исходному уровню — пользователи исследовали новый интерфейс из любопытства, а потом вернулись к привычному поведению.

Хороший тест (та же навигация): Длительность — 28 дней. После теста аналитик смотрит данные понедельно: неделя 1 — +19%, неделя 2 — +11%, неделя 3 — +9%, неделя 4 — +8%. Эффект стабилизировался, а не исчез. Это реальное улучшение: пользователи не просто изучили новое, а стали использовать его системно. Решение о внедрении принимается с пониманием реального масштаба эффекта — не +19%, а +8%.

Ловушка 04 - Загрязнение выборки: когда группы не изолированы

Интуитивное решение. Мы распределяем пользователей случайно — 50% видят версию A, 50% — версию B. Это же и есть корректный эксперимент.

Почему это ломает систему. Случайное распределение не гарантирует изоляцию. Пользователь может увидеть версию B на работе и версию A дома с другого устройства. В B2B продуктах один аккаунт могут использовать несколько человек - и они попадут в разные группы. В социальных продуктах поведение пользователей влияет друг на друга: если пользователь из группы B делится контентом с пользователем из группы A, эффект переходит между группами. Это называется network interference - и делает результат теста нечитаемым.

Отдельная проблема - Simpson's Paradox: когда в обеих группах разный состав подгрупп, агрегированный результат может говорить одно, а поведение каждой подгруппы - прямо противоположное.

Ключевая метрика-индикатор. Доля пользователей, которые видели обе версии за период теста (cross-contamination rate). Если она выше 5% - результат теста под вопросом.

Кейс. LinkedIn тестировал изменение алгоритма ленты. Стандартное A/B распределение давало искажённые результаты, потому что контент, созданный пользователями из группы B, попадал в ленту пользователей группы A. Решение - переход к кластерному рандомизированию (cluster randomization): группы разделяются не по пользователям, а по изолированным сетевым кластерам. Этот подход сложнее в реализации, но даёт чистые результаты.

Плохой тест (загрязнение): B2B-продукт для совместной работы тестирует новый интерфейс комментариев. Пользователи разделены 50/50 по user ID. Но в одном аккаунте работают пятеро коллег — трое попали в группу A, двое в группу B. Они видят разные интерфейсы одновременно, путаются, обсуждают это между собой. Поведение группы B искажено за счёт постоянного взаимодействия с группой A. Результат теста нечитаем, хотя p-value выглядит красиво.

Хороший тест (та же фича): Рандомизация — по аккаунту (company ID), а не по пользователю. Все сотрудники одной компании видят одну версию. Контаминация исключена. Дополнительно: перед анализом запускается SRM-тест — проверка, что в обе группы попало ожидаемое количество аккаунтов. Результат теста чист и интерпретируем.

Анатомия двух тестов: разбор от начала до конца

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

❌ Плохой тест

Гипотеза = «Email-напоминание улучшит онбординг»
Первичная метрика = Не зафиксирована заранее
Длительность = «Пока не наберём достаточно данных»
Размер выборки = Не рассчитан
Рандомизация = По User ID
Промежуточные проверки = Каждый день

Как разворачивается: на 6-й день PM видит, что у получивших письмо activation rate выше на 12%, p = 0.038. Объявляется победа. В прод уходит рассылка на всех новых пользователей. Через месяц аналитик замечает: рост был только в первую неделю. Дополнительный анализ показывает: в группу «получили письмо» случайно попало больше пользователей из корпоративного сегмента — они в принципе активируются лучше. Эффект письма был равен нулю.

✅ Хороший тест

Гипотеза = «Email на день 3 с конкретным следующим шагом увеличит долю пользователей, создавших первый проект в течение 7 дней»
Первичная метрика = % пользователей, создавших первый проект в течение 7 дней от регистрации
Вторичные метрики = Retention day 14, время до первого действия — только для контекста, не для вердикта
Минимальный эффект = +5 п.п. (с 30% до 35%) — порог бизнес-значимости
Размер выборки = ~3 200 чел. в каждой группе (power 80%, alpha 0.05)
Плановая длительность = 21 день
Рандомизация = По user ID + SRM-тест после завершения
Промежуточные проверки = Запрещены; платформа — Statsig с блокировкой ранней остановки

Как разворачивается: на 21-й день открывают данные. Первичная метрика: 33.4% в группе B против 30.1% в группе A, p = 0.018. SRM-тест пройден. Состав групп по сегментам одинаков. Анализ по неделям: неделя 1 — +4%, неделя 2 — +3.5%, неделя 3 — +3.3%. Эффект стабилен — не novelty. Решение принято с уверенностью. Рассылка запускается с реалистичным ожиданием +3–3.5%, а не обманчивым +12%.

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

Конкурентный контекст

Крупный игрок с миллионной базой запускает тест и получает статистически значимый результат за 48 часов — при любом уровне дисциплины. Малая выборка не позволяет ждать: если тест требует 50 000 пользователей в группе, а продукт набирает 3 000 новых пользователей в неделю — корректный тест займёт 8+ месяцев.

Это структурное неравенство. Стартап либо тестирует с недостаточной выборкой и получает ненадёжные результаты, либо ждёт слишком долго и теряет скорость. Третий путь - понять, какие вопросы решаются A/B тестом, а какие — качественными методами, custdev или поведенческим наблюдением.

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

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

Цена ошибок

Ложноположительный результат (false positive) — команда внедряет изменение, которое не работает. Прямые потери: время разработки, время на анализ, задержка в очереди настоящих улучшений. Косвенные: накопленные неверные решения создают технический долг понимания — команда строит следующие гипотезы на неверных основаниях.
Ложноотрицательный результат (false negative) — команда отклоняет изменение, которое реально работало. Особенно опасно, когда тест был остановлен слишком рано при недостаточной мощности. Хорошая идея объявляется неработающей — и к ней не возвращаются.
Накопленный эффект. Команда, которая проводит 50 тестов в год с peeking и p-hacking, принимает десятки решений на основе шума. Продукт оптимизируется в случайном направлении. При этом внутри - ощущение data-driven культуры и скорости. Это хуже, чем отсутствие данных: данные создают уверенность там, где её не должно быть.

Что происходит на рынке

Зрелые экспериментальные платформы — Optimizely, Statsig, Eppo — за последние пять лет сместились от «просто запусти тест» к built-in statistical guardrails. Они автоматически предупреждают о peeking, предлагают sequential testing вместо fixed-horizon и ведут реестр первичных метрик.

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

Как делать правильно: 6 шагов

Шаг 01. Зафиксируйте все параметры теста до запуска До старта — в письменном виде, с датой: первичная метрика (одна), вторичные метрики (только для контекста), плановая длительность, минимальный детектируемый эффект, размер выборки. Документ закрывается от редактирования после запуска теста. Инструмент: Google Doc с историей версий или специализированная платформа (Statsig, Eppo). Критерий успеха: невозможно законно изменить параметры после просмотра промежуточных данных.

Шаг 02. Рассчитайте размер выборки, а не угадывайте его Используйте калькулятор размера выборки (Evan Miller's A/B test calculator, calculators от Statsig или любой другой). Входные данные: базовая конверсия, минимальный эффект, который важен для бизнеса, statistical power 80%, alpha 0.05. Если нужная выборка недостижима за разумный срок — A/B тест не подходит для этого вопроса. Критерий успеха: расчётное время достижения выборки ≤ 4 недель. Если больше — переключайтесь на качественные методы.
Шаг 03. Установите фиксированный горизонт и не смотрите раньше Плановая длительность — минимум два полных бизнес-цикла (обычно 14 дней). Это покрывает эффект дня недели и даёт стабилизацию novelty effect. Промежуточные проверки — только через статистический метод для repeated testing (см. шаг 04). Случайные просмотры дашборда в середине теста — ровно то, что создаёт peeking. Критерий успеха: дата окончания теста зафиксирована в календаре до его запуска.
Шаг 04. Используйте sequential testing, если нужна гибкость Sequential testing (последовательное тестирование) — математически корректная альтернатива fixed-horizon для случаев, когда нужно смотреть на данные по ходу теста. Метод SPRT (Sequential Probability Ratio Test) и его современные варианты (mSPRT, Always Valid Inference от Ramesh Johari et al.) позволяют смотреть на данные в любой момент — без inflation ошибки первого рода. Это реализовано в Statsig (continuous monitoring), Optimizely (Stats Engine) и VWO. Если платформа не поддерживает sequential testing — не смотрите на данные раньше срока. Критерий успеха: если нужны промежуточные проверки — используется platform с built-in sequential testing, а не ручная интерпретация p-value.
Шаг 05. Проверьте загрязнение выборки перед интерпретацией После завершения теста — до анализа результата — проверьте: есть ли пользователи, которые попали в обе группы (cross-contamination). Есть ли признаки network interference (в социальных или коллаборативных продуктах). Одинаков ли состав групп по ключевым сегментам (SRM — Sample Ratio Mismatch - тест). Если SRM есть — результаты теста ненадёжны, даже если p-value красивый. Критерий успеха: cross-contamination rate < 5%, SRM тест пройден.
Шаг 06. Анализируйте эффект по неделям, не только итоговый Разбейте данные по неделям: если эффект в первую неделю в два раза больше, чем во вторую — это сигнал novelty effect, а не реального улучшения. Настоящий эффект должен стабилизироваться или расти по мере того, как пользователи привыкают к изменению. Если эффект падает со временем — внедрение в прод не даст обещанного результата. Критерий успеха: размер эффекта на неделе 2 ≥ 70% от размера эффекта на неделе 1.

Литература и источники

Ron Kohavi, Diane Tang, Ya Xu — «Trustworthy Online Controlled Experiments» (2020) Авторы — бывшие руководители экспериментальных платформ в Microsoft, Google и Airbnb. Это самая полная практическая книга по A/B тестированию, включая разбор всех четырёх ловушек из этой статьи. Что взять: главы о SRM (sample ratio mismatch), novelty effect и корректных методах multiple testing correction.
Ramesh Johari et al. — «Peeking at A/B Tests» (2017, Stanford / Optimizely) Оригинальное академическое исследование, которое математически описало peeking problem и предложило always-valid inference как решение. Бесплатно доступно на arXiv. Что взять: конкретные формулы роста ошибки первого рода при repeated peeking.
Evan Miller — «How Not To Run an A/B Test» (блог, 2010) Короткая, классическая статья, которая объяснила проблему peeking для широкой аудитории PM и основателей. До сих пор актуальна. Что взять: интуитивное объяснение того, почему «остановиться, когда значимо» — это ошибка.
Statsig Blog — «Sequential Testing at Scale» (2022) Технический разбор того, как Statsig реализовал continuous monitoring без peeking problem. Практично для команд, которые выбирают платформу. Что взять: описание mSPRT и когда sequential testing уместен.
Senn, Stephen — «Statistical Issues in Drug Development» (2007) Классика медицинской статистики, из которой пришли концепции power, alpha и beta ошибок. Тяжёлое чтение, но фундаментальное. Что взять: интуиция о том, почему неправильно выбранный sample size делает тест бессмысленным в обоих направлениях — не только в сторону ложных позитивов.