A/B-тест — самый часто неправильно используемый инструмент в продуктовой разработке. Не потому что он сложный. Потому что его используют как подтверждение решения, которое уже принято, а не как инструмент поиска истины.
«Мы провели A/B-тест — победил красный вариант». Через месяц выясняется: тест шёл 4 дня, выборка была 200 человек, статистической значимости не было, а «победа» красного — случайный шум.
В этой статье — алгоритм, который даёт честные результаты. Не быстрые. Не удобные. Честные.
Что такое A/B-тест и зачем он нужен
A/B-тест — контролируемый эксперимент, в котором две версии продукта (или одного элемента) показываются двум случайным группам пользователей, и результаты сравниваются.
Вариант A (control) — текущая версия. Вариант B (treatment) — новая версия с изменением.
Цель — выяснить, какой вариант лучше по заранее выбранной метрике. Не «кажется лучше». Не «команде нравится». А с измеримой уверенностью, что разница не случайна.
Когда A/B-тест нужен:
- Когда есть конкретная гипотеза о том, что можно улучшить
- Когда изменение достаточно маленькое, чтобы тестировать один элемент
- Когда есть достаточный трафик для статистически значимого результата
- Когда метрика чётко определена до начала теста
Когда A/B-тест НЕ нужен:
- Когда проблема очевидна без теста (broken UX, ошибки)
- Когда изменение радикальное (полный редизайн) — тут нужны юзабилити-тесты
- Когда трафика слишком мало (риск получить случайный результат)
- Когда нет ресурсов правильно провести тест
Шаг 1: Гипотеза — самый важный шаг
Большинство плохих A/B-тестов провалены ещё до запуска — на этапе гипотезы.
Плохая гипотеза: «Попробуем синюю кнопку вместо зелёной».
Хорошая гипотеза: «Мы думаем, что пользователи не нажимают на кнопку CTA, потому что она визуально не выделяется. Если мы увеличим её и сделаем более контрастной, click-through rate вырастет на 15%+».
Структура хорошей гипотезы: [Наблюдение проблемы] + [Предполагаемая причина] + [Предложенное решение] + [Ожидаемый эффект].
Почему это важно: гипотеза с причиной, а не просто с изменением, позволяет учиться независимо от результата. Тест не сработал? Значит, причина была другой — это тоже знание. Тест с гипотезой «попробуем синюю кнопку» ничему не учит, если не сработал.
Шаг 2: Метрика — только одна основная
Перед запуском теста нужно выбрать одну первичную метрику. Именно одну. По этой метрике будет принято решение.
Первичная метрика — та, которую ты хочешь улучшить. Это должна быть метрика из дерева метрик продукта, связанная с реальным бизнес-результатом.
Примеры:
- Конверсия из просмотра лендинга в регистрацию
- Click-through rate на CTA-кнопку
- Completion rate формы регистрации
- Task success rate на ключевом флоу
Вторичные метрики (guardrail) — те, за которыми нужно следить, чтобы вариант B не «победил» за счёт ухудшения чего-то другого.
Пример: тестируешь упрощение формы регистрации. Первичная метрика — completion rate формы. Guardrail — D7 retention. Иначе можно получить больше регистраций, но менее качественных пользователей.
Никогда не выбирай победителя по вторичной метрике, если первичная не показала результата. Это называется «p-hacking» — и это ложный вывод.
Шаг 3: Размер выборки — считай до запуска
Это шаг, который пропускают чаще всего. И именно он определяет, будет ли тест честным.
Почему нельзя просто «посмотреть через неделю»:
Если тест остановить в удобный момент (когда один вариант «выиграл»), с высокой вероятностью это случайный шум. Это называется «peek problem» или «optional stopping bias».
Как считать нужный размер выборки:
Нужны три параметра:
- Baseline conversion rate — текущее значение метрики (например, 5%)
- Minimum detectable effect (MDE) — минимальное изменение, которое тебя интересует (например, +20% → 6%)
- Статистическая мощность — обычно 80%, уровень значимости α = 0.05
Используй калькулятор выборки: Evan's Awesome A/B Tools или Optimizely Sample Size Calculator.
Пример расчёта:
- Текущий conversion rate: 5%
- Ожидаемый эффект: +20% (то есть 6%)
- Статистическая мощность: 80%, α = 0.05
- Нужная выборка: ~3 800 пользователей на каждую группу (итого ~7 600)
Если ваш сайт получает 200 пользователей в день — тест нужно держать минимум 38 дней. Если это неприемлемо — нужно либо тестировать что-то с большим эффектом, либо принимать решение другим способом.
Шаг 4: Разделение трафика
Стандартное разделение — 50/50. Каждый пользователь случайно попадает в группу A или B.
Важные условия:
- Разделение должно быть случайным (не «чётные vs. нечётные ID», если ID не случайны)
- Один пользователь всегда видит один и тот же вариант (не меняется при каждом визите)
- Группы должны быть изолированы: пользователи группы A не должны взаимодействовать с группой B способами, которые влияют на результат (сложно для social-продуктов)
Инструменты для разделения:
- Google Optimize (стандарт для веба, но отключён в 2023, нужны альтернативы)
- Amplitude Experiment
- LaunchDarkly
- GrowthBook (опенсорс)
- VWO
- Optimizely
Или собственная реализация через feature flags, если есть инфраструктура.
Шаг 5: Длительность теста
Минимальный срок — до достижения расчётного размера выборки. Плюс несколько правил:
Минимум 1–2 полных недели. Поведение пользователей в понедельник и в воскресенье разное. Нужно захватить полный недельный цикл хотя бы раз.
Не останавливай раньше. Даже если кажется, что победитель определился. «Peek problem» — реальная угроза достоверности.
Учитывай сезонность. Тест во время праздников, распродаж, или значимых внешних событий — нерепрезентативен.
Не меняй тест в процессе. Если в середине теста поменял дизайн варианта B — данные до и после несравнимы.
Шаг 6: Анализ результатов
После завершения теста — анализ. Не раньше.
Статистическая значимость
Тест «значим» при p-value < 0.05. Это означает: вероятность того, что разница случайна, меньше 5%.
Большинство инструментов считают это автоматически. Но нужно понимать, что это значит:
- p < 0.05 — можно говорить о результате
- p = 0.07 — нет статистической значимости, нельзя делать выводы
- p = 0.01 — сильный результат, очень маловероятно что случаен
Размер эффекта
Статистическая значимость говорит «это не случайно». Размер эффекта говорит «насколько важно».
Повышение конверсии с 5% до 5.1% при p < 0.05 — статистически значимо, но практически незначимо. Повышение с 5% до 7% — и статистически, и практически значимо.
Всегда смотри на оба параметра.
Доверительный интервал
Результат теста — не точная цифра, а диапазон. «Конверсия выросла на 20% ± 8%» означает: реальный эффект скорее всего между 12% и 28%.
Узкий доверительный интервал — большая уверенность. Широкий — много неопределённости.
Шаг 7: Принятие решения
После анализа — один из трёх исходов:
Вариант B победил (p < 0.05, практически значимый эффект): Внедряй. Но зафиксируй победившие параметры, обнови базлайн для будущих тестов.
Вариант A и B не отличаются (нет значимой разницы): Это не провал — это результат. Гипотеза не подтвердилась. Нужно разобраться, почему и сформулировать новую гипотезу.
Вариант B проиграл (конверсия упала): Не внедряй. Разберись почему — это особенно ценный результат, он говорит о том, что интуиция была неверной.
Частые ошибки A/B-тестов
Ошибка 1: Остановка по «пику»
Смотришь на данные каждый день. Видишь, что в среду вариант B уже «выигрывает». Останавливаешь тест.
В 50% случаев это случайное колебание. К пятнице картина могла измениться.
Решение: определи размер выборки до старта и не смотри на промежуточные результаты.
Ошибка 2: Слишком много вариантов
Тест A/B/C/D/E — пять вариантов одновременно. Чем больше вариантов, тем выше вероятность ложно-положительного результата (multiple comparison problem).
Если тестируешь 5 вариантов с α = 0.05 — вероятность хотя бы одного ложного «победителя» около 23%.
Решение: тестируй максимум 2–3 варианта. Если нужно больше — используй поправку Бонферрони или снижай α.
Ошибка 3: Тестирование слишком маленького изменения
Изменил цвет кнопки с #007AFF на #0070F3. Разница почти невидима. Для её обнаружения нужны миллионы пользователей.
Решение: тестируй изменения с ожидаемым эффектом минимум 10–20%. Если меньше — не стоит времени.
Ошибка 4: Игнорирование сегментации
«Вариант B победил» — но выигрыш весь за счёт мобильных пользователей, а на десктопе результат нейтральный или хуже.
Решение: после завершения теста сегментируй результаты: мобайл/десктоп, новые/вернувшиеся, разные тарифы. Инсайты часто в сегментах, а не в агрегированных данных.
Ошибка 5: Новинки-эффект (Novelty effect)
Пользователи кликают на вариант B просто потому что он новый. Эффект проходит через 2–3 недели.
Для продуктов с большой долей постоянных пользователей это реальная проблема. Тест нужно держать достаточно долго, чтобы novelty effect прошёл.
Ошибка 6: Нет обучения из теста
Тест закончился. Победитель внедрён. Никто не задался вопросом «почему так получилось».
Решение: каждый тест должен заканчиваться записью в базе знаний: что тестировали, гипотеза, результат, объяснение почему так.
Альтернативы A/B-тесту
A/B-тест — не единственный способ проверить гипотезу.
Для малого трафика: пятисекундный тест (пользователь смотрит на экран 5 секунд и отвечает что запомнил), tree test (проверка навигации), first-click test.
Для качественного понимания: юзабилити-тест с 5 пользователями выявит 80% проблем за 2 дня. Не даёт статистики, но даёт понимание «почему».
Для радикальных изменений: shadow test — показываешь новый дизайн небольшому проценту реальных пользователей, но без полноценного A/B-анализа.
Для быстрой проверки: Fake door test — добавляешь в интерфейс кнопку фичи, которой нет, и смотришь сколько людей нажимает. Если много — фича нужна.
Алгоритм A/B-теста: шпаргалка
1. ГИПОТЕЗА
[Наблюдение] → [Причина] → [Решение] → [Ожидаемый эффект]
2. МЕТРИКА
Одна первичная + 1–3 guardrail метрики
3. РАЗМЕР ВЫБОРКИ
Рассчитай через калькулятор до запуска
Baseline CR + MDE + мощность 80% + α 0.05
4. ЗАПУСК
50/50 split, случайное разделение
Один пользователь = один вариант
5. ДЛИТЕЛЬНОСТЬ
Не меньше расчётного объёма
Не меньше 2 полных недель
Не смотреть на промежуточные результаты
6. АНАЛИЗ
p-value < 0.05?
Практически значимый эффект?
Guardrail метрики не пострадали?
Разбивка по сегментам?
7. РЕШЕНИЕ
Победил B → внедряй + записывай вывод
Нет разницы → новая гипотеза
Проиграл → разбирай почему
8. ДОКУМЕНТАЦИЯ
Гипотеза + результат + объяснение → в базу знаний
Когда тест «нечестный»: красные флаги
- Размер выборки не рассчитан заранее
- Тест остановлен «потому что уже видно победителя»
- Метрика выбрана после запуска или изменена в процессе
- Результаты выбраны из нескольких метрик (победитель — тот, который показал нужный результат)
- Тест шёл менее 7 дней
- Трафик перераспределялся в процессе
- Нет разбивки по сегментам
Если что-то из этого — тест нечестный. Его результат нельзя использовать как основание для решения.
Как формировать культуру A/B-тестирования в команде
A/B-тест — это не разовый эксперимент. Это образ мышления. Команды, у которых высокая скорость экспериментирования, стабильно опережают конкурентов — потому что они учатся быстрее.
Amazon, по легенде, проводит тысячи A/B-тестов в год. Это не специальная команда «тестировщиков» — это культура, где каждое изменение — эксперимент, а не акт веры.
Как это выглядит на практике
Velocity as a metric. Команды с высокой культурой тестирования отслеживают не только результаты тестов, но и их количество. Больше тестов = больше возможностей найти улучшение.
Learning repository. Все тесты, включая провальные, документируются. Через год это превращается в бесценную базу знаний: «Мы уже пробовали убрать поле Phone — конверсия упала, потому что наши пользователи хотят звонок».
Democratization. Не только аналитик может запустить тест. Дизайнер с гипотезой идёт к аналитику с инструкцией, а не ждёт в очереди. Шаблон гипотезы + чеклист запуска снижают барьер.
No-blame culture. Тест, который не сработал — это не провал. Это знание, которого не было до теста. Команды, где «плохой результат теста = кто-то облажался», перестают экспериментировать с рискованными гипотезами.
Приоритизация: какие гипотезы тестировать первыми
Идей для тестов всегда больше чем ресурсов. Нужна система приоритизации.
Фреймворк ICE
ICE = Impact × Confidence × Ease
Каждую гипотезу оцени по трём параметрам от 1 до 10:
- Impact: насколько большой эффект при успехе? (влияет на главную метрику)
- Confidence: насколько уверен что это сработает? (данные, аналоги, исследования)
- Ease: насколько просто запустить? (технически и ресурсно)
Умножь три числа — получи приоритет. Начинай с высоких.
Пример:
Гипотеза Impact Confidence Ease ICE Score Убрать поле «Телефон» из формы 7 8 9 504 Добавить социальный proof на лендинг 6 7 8 336 Полностью переделать onboarding 9 5 3 135 Изменить цвет кнопки 3 4 9 108
Начинай с первых двух — высокий ICE и реально запустить.
Дополнительный фильтр: стратегическая важность
ICE — тактический инструмент. Иногда нужно тестировать не то, что легче, а то, что важнее стратегически.
Если бизнес-приоритет — снизить CAC, то даже тест с низким Ease, который потенциально улучшает лендинг — важнее «лёгкого» теста в другом месте воронки.
Типы тестов: за пределами классического A/B
Классический A/B (один элемент, два варианта) — не единственный формат.
Многовариантный тест (MVT)
Тестируешь несколько элементов одновременно и все их комбинации.
Когда использовать: когда нужно проверить взаимодействие элементов. Например, как заголовок и изображение влияют друг на друга.
Проблема: нужен значительно больший трафик (число вариантов растёт мультипликативно). Для 3 вариантов заголовка × 3 варианта изображения = 9 комбинаций.
Split URL тест
Две разные страницы на разных URL. Более радикальное изменение, чем замена одного элемента.
Когда использовать: для тестирования разных концепций лендинга, разных онбординг-флоу, разных структур страниц.
Bandit-алгоритм
Вместо фиксированного 50/50 split система автоматически перераспределяет трафик в пользу побеждающего варианта.
Плюс: минимизирует потери от показа хуже работающего варианта. Минус: сложнее интерпретировать результаты статистически. Подходит для быстрых решений, не для фундаментальных выводов.
Когда остановить тест раньше срока (и когда это допустимо)
Стандартное правило: «не останавливай тест до получения расчётного размера выборки». Но бывают исключения.
Допустимо остановить раньше:
- Вариант B явно наносит вред: конверсия упала на 50%+, пользователи жалуются, сломались ключевые флоу. В этом случае продолжать тест неэтично и убыточно.
- Внешнее событие сделало данные нерелевантными: сбой платёжной системы, вирусная публикация, технический инцидент. Данные скомпрометированы — тест нужно остановить и перезапустить.
Недопустимо останавливать раньше:
- «Кажется, уже видно результат»
- Давление менеджмента («нам нужно решение к пятнице»)
- Промежуточный p-value < 0.05 до достижения расчётной выборки
Если нужно «решение к пятнице» — A/B-тест не подходит. Используй экспертную оценку (PURE) или юзабилити-тест.
Метаобучение: что делать когда большинство тестов не показывают эффекта
Стандартная картина в зрелых продуктах: 20–30% тестов показывают значимый эффект. Остальные — нет.
Это нормально. Более зрелый продукт сложнее улучшить — все «очевидные» проблемы уже исправлены.
Что делать:
- Работай с более крупными гипотезами. Мелкие изменения (цвет кнопки, формулировка) всё меньше дают эффект. Нужны гипотезы уровня «изменить структуру онбординга» или «протестировать другую value proposition».
- Ищи инсайты в сегментах. Тест без общего эффекта может дать сильный эффект для конкретного сегмента. Разбивай результаты.
- Выход на качественные исследования. Когда A/B-тесты «молчат» — это сигнал, что нужны более глубокие исследования: интервью, юзабилити-тесты, анализ customer journey.
- Пересмотри метрику. Возможно, метрика теста не та. Тестируешь click rate на CTA, но на самом деле важна конверсия в платящих через 30 дней. Улучшение click rate без связи с реальным результатом — ложная победа.
ИИ и A/B-тесты: как Claude помогает на каждом этапе эксперимента
A/B-тест проходит через несколько этапов — гипотеза, расчёт, анализ, решение. На каждом ИИ ускоряет работу.
Промпт: сформулировать гипотезу правильно
Я заметил: [наблюдение из данных или исследования]
Помоги сформулировать A/B-гипотезу по структуре:
[Наблюдение проблемы] → [Предполагаемая причина] → [Предложенное решение] → [Ожидаемый измеримый эффект]
Также предложи:
— Первичную метрику теста
— 2–3 guardrail метрики (что нельзя ухудшить)
— Потенциальные риски гипотезы (почему может не сработать)
Промпт: рассчитать размер выборки и длительность теста
Мне нужно рассчитать параметры A/B-теста:
Текущий baseline conversion rate: [%]
Минимальный интересный эффект (MDE): [%] (например, хочу поднять с 5% до 6% — MDE = 20%)
Статистическая мощность: 80% (стандарт)
Уровень значимости: 0.05 (стандарт)
Текущий суточный трафик на тест: [число пользователей]
Рассчитай:
1. Нужный размер выборки на каждую группу
2. Минимальная длительность теста в днях
3. На что влияет если я захочу уловить более маленький эффект (например, +0.5% вместо +1%)?
4. Стоит ли вообще проводить тест при таком трафике, или лучше использовать другой метод?
Промпт: проанализировать результаты теста
После получения данных:
Результаты A/B-теста:
Вариант A (control):
— Пользователей: [число]
— Конверсий: [число]
— Conversion rate: [%]
Вариант B (treatment):
— Пользователей: [число]
— Конверсий: [число]
— Conversion rate: [%]
Рассчитай:
1. Статистическую значимость (p-value)
2. Размер эффекта (относительный прирост в %)
3. Доверительный интервал для разницы
4. Является ли результат статистически значимым при α = 0.05?
5. Является ли размер эффекта практически значимым для нашего бизнеса?
Дай рекомендацию: внедрять B, оставить A, или нужно больше данных?
Промпт: провести post-hoc анализ по сегментам
Тест завершён: [итоги]
Теперь помоги проанализировать результаты по сегментам.
У нас есть разбивка:
— Мобайл: [данные A и B]
— Десктоп: [данные A и B]
— Новые пользователи: [данные]
— Вернувшиеся: [данные]
Для каждого сегмента:
1. Есть ли статистически значимая разница?
2. Если общий результат незначим, есть ли сегмент где B явно выигрывает?
3. Нет ли heterogeneous treatment effect (B хорошо для одного сегмента, плохо для другого)?
Что это означает для решения о внедрении?
Промпт: задокументировать тест для базы знаний
Помоги оформить результаты A/B-теста в виде карточки для базы знаний команды.
Данные теста:
— Гипотеза: [формулировка]
— Что тестировали: [описание изменения]
— Период: [даты]
— Выборка: [числа]
— Результат: [победил A / B / нет разницы]
— Статистика: [p-value, размер эффекта]
Оформи как карточку с разделами:
Гипотеза | Изменение | Метрика | Результат | Вывод | Следующий шаг
Вывод должен объяснять не только ЧТО произошло, но и ПОЧЕМУ (или почему скорее всего).
Источник и полная версия: VibeCode Wiki