Продуктовая аналитикагайдстарт

Как сформулировать гипотезу для A/B-теста: от наблюдения до решения

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

КПКейсПрактика23 июля 2026 г.10 мин

Эксперименты и измерение Продуктовая аналитика

Два продуктовых аналитика превращают наблюдение в проверяемую гипотезу эксперимента на доске.

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

Коротко

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

Наблюдение — это факт в данных или исследовании, а не объяснение.
Причина должна быть проверяемой: “люди не видят следующий шаг”, а не “UX плохой”.
Изменение должно быть конкретным и реализуемым в одном эксперименте.
Метрика должна измерять предполагаемый результат, а не удобство команды.

Не путай симптом, причину и решение

Падение conversion rate — симптом. “Пользователь не доверяет цене” — гипотеза о причине. “Добавим блок с условиями доставки” — решение. Если сразу перескочить от симптома к экрану, можно проверить красивую идею, не проверив, что именно мешает пользователю.

Как превратить размытое наблюдение в рабочую формулировку

Слабая формулировка	Что в ней не так	Рабочий вариант
Улучшим onboarding	неясно, какой шаг и какой результат	если показать пример результата до подключения данных, больше новых пользователей создадут первый отчёт за 24 часа
Сделаем поиск лучше	решение выдано вместо причины	если добавить фильтры по категории в выдачу, вырастет доля поисковых сессий с просмотром релевантного товара
Увеличим покупки скидкой	не указаны риск и сегмент	если показать персональный порог бесплатной доставки, checkout completion вырастет у новых покупателей без роста возвратов

Шаблон гипотезы

Удобный шаблон выглядит так: “Мы считаем, что [сегмент] не делает [действие], потому что [наблюдаемая причина]. Если мы [конкретное изменение], то [primary metric] изменится на [ожидаемый порог] за [окно], потому что [механизм]. Мы примем решение [правило]”.

Шаблон не обязан попадать в публикацию или тикет дословно. Его задача — заставить команду назвать то, что обычно прячется за словами “улучшить вовлечение”.

Структура гипотезы

наблюдение → причина → изменение → механизм → метрика → порог → решение

Если один элемент не помещается в одну-две фразы, гипотеза, возможно, слишком широкая для одного теста.

Одна гипотеза — один проверяемый механизм

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

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

Сформулируй, какое поведение должно измениться первым.
Проверь, что событие этого поведения логируется и не дублируется.
Укажи, какой результат будет считаться нейтральным.
Добавь guardrail, если у изменения есть понятная цена или риск.

До запуска спроси себя пять раз

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