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

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

Статья · Алексей Ишманов · 2 июня 2026 · https://aleksishmanov.ru/blog/a-b-leaks/

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

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

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

![](/media/blog/a-b-leaks/e394332a5e391815.png)

### Ловушка 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 делает тест бессмысленным в обоих направлениях — не только в сторону ложных позитивов.