Дизайн A/B эксперимента: как спроектировать тест, который даст честный ответ

Команда запускает A/B тест - две версии онбординга. Через две недели версия B побеждает: конверсия выше на 8%. Решение принято, версия B едет в прод. Через квартал retention падает. Выясняется, что версия B активировала больше пользователей, но привлекала менее качественный сегмент. Тест дал статистически значимый результат — и при этом привёл к неверному решению.

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

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

Что такое дизайн эксперимента

Дизайн эксперимента — структура, которая определяет: что меняем, что измеряем, на ком проверяем и как интерпретируем результат. Не сам тест, а логика до него.

Понятие пришло из медицины и агрономии — Рональд Фишер формализовал принципы контролируемого эксперимента ещё в 1920-х. В продуктовую разработку они пришли через веб-аналитику: Google, Amazon и Booking начали проводить тысячи A/B тестов в год, когда поняли, что интуиция не масштабируется. Booking.com в какой-то момент проводил более 1000 параллельных тестов — это стало возможным только потому что у каждого теста была чёткая структура.

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

Когда нужен правильный дизайн

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

Когда внутри есть сильное мнение. Если CPO убеждён, что «новая версия лучше», тест проектируется под подтверждение, а не под проверку. Хороший дизайн эксперимента — защита от этого.

При масштабировании: когда небольшое улучшение конверсии стоит миллионы. В продуктах с большой базой ошибка в 2% конверсии — это реальные деньги. Чем больше ставка, тем важнее чистота метода.

При запуске новой фичи на часть базы. Feature flag с постепенным rollout — это тоже эксперимент. Без явного дизайна команды часто не знают, что именно они измеряют.

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

Как спроектировать тест: 5 шагов

01 Сформулируйте один вопрос

Тест отвечает ровно на один вопрос — не «какая версия лучше в целом», а «версия B увеличивает конверсию на этапе X среди сегмента Y?»

Хороший вопрос теста выглядит так: «Приводит ли замена текстовой формы на интерактивный квиз на этапе регистрации к росту activation rate среди пользователей из сегмента SMB?»
Плохой вопрос: «Какая версия онбординга лучше?» Лучше — по какой метрике, для какого сегмента, в каком временном окне?
Бенчмарк: если вопрос теста нельзя записать в одно предложение — значит, проверяется сразу несколько гипотез. Разбейте на отдельные тесты.

02 Изолируйте одну переменную

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

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

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

03 Выберите первичную метрику заранее

До запуска теста — не после просмотра результатов. Одна первичная метрика, которая отвечает на вопрос теста. Остальные — наблюдательные, для контекста.

Типичная ошибка: тест запущен «посмотреть на разные метрики». После двух недель из восьми метрик три показывают рост — команда выбирает именно их. Это называется p-hacking: когда достаточно долго смотреть на данные, всегда найдётся что-то значимое. Это не открытие — это шум.

Критерий выбора первичной метрики: какое изменение этой метрики изменит следующее решение команды? Если рост activation rate с 40% до 48% — это порог для принятия решения, это и есть первичная метрика.

04 Рассчитайте размер выборки

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

Размер выборки рассчитывается заранее на основе трёх параметров:

базовая конверсия (текущий показатель),
минимальный детектируемый эффект (насколько значимо изменение для бизнеса)
статистическая мощность (обычно 80%). Для этого существуют калькуляторы - Evan Miller's A/B test calculator, например.

Практический ориентир: если базовая конверсия 5% и вы хотите зафиксировать улучшение до 6%, нужно около 15 000 пользователей в каждой группе. Меньше — и тест не имеет достаточной мощности, чтобы отличить сигнал от шума.

Бенчмарк: если ваш продукт не набирает нужную выборку за разумный период (2–4 недели) — A/B тест не подходит как метод. Используйте качественные сигналы: custdev, пользовательское тестирование, поведенческие данные.

05 Определите период наблюдения до запуска

Тест длится фиксированный срок — не «пока результат не станет значимым». Остановка теста в момент, когда результат понравился, называется peeking (подглядывание): статистическая значимость флуктуирует в начале теста, и если смотреть на данные каждый день и останавливать в удобный момент, вероятность ложноположительного результата вырастает кратно.

Стандартный минимум: полный бизнес-цикл, обычно 2 недели. Это покрывает эффект дня недели (поведение пользователей в понедельник и пятницу разное) и даёт стабилизацию новизны — когда пользователи перестают реагировать на изменение просто потому что оно новое.

Типы переменных: что тестируют и как

Разные гипотезы требуют разных видов переменных:

Поверхностные переменные — текст, цвет, изображение, порядок элементов. Быстро тестируются, легко изолируются. Эффект обычно небольшой, но накопительный. Подходят для оптимизации существующего пути.
Структурные переменные — онбординг-флоу, pricing page, navigation. Больший потенциальный эффект, но требуют большей выборки и более длительного периода. Часто нужен holdout-группа — пользователи, которые не видят ни одну версию, для измерения base rate.
Ценностные переменные — тарифы, фичи в планах, бесплатный период. Высокорисковые тесты: неправильный результат может стоить дорого. Для B2B часто нецелесообразны на малой базе — используется presell или прямой разговор вместо теста.

Результат: что меняется в команде

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

Это меняет и культуру: решения перестают быть «мнением CPO vs. мнением PM». Они становятся «что говорит тест». Это не устраняет суждения — вопрос, какой тест запустить, по-прежнему требует стратегического мышления. Но устраняет непродуктивные споры о том, что произошло.

Команды Booking.com, Airbnb и Spotify давно используют принцип: нет решения без теста, нет теста без дизайна. Это не бюрократия — это способ масштабировать обучение.

Вспомните последний A/B тест в вашей команде: была ли первичная метрика определена до запуска или выбрана после просмотра результатов? Если второе — тест ответил не на вопрос, а на ожидание. Это не маленькая проблема — это системный паттерн, который умножается на каждое следующее решение.