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

Коротко

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

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

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

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

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

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

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

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

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

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

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

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

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

• Какое наблюдение привело к гипотезе?
• Почему выбранный сегмент должен реагировать иначе?
• Какое действие изменится, если механизм верен?
• Что увидим в primary metric и за какой срок?
• Что сделаем при положительном, нейтральном и вредном результате?

Как проверить гипотезу до A/B-теста

Не каждая гипотеза заслуживает сразу инженерного эксперимента. Сначала проверь, действительно ли наблюдение устойчиво: посмотри динамику, сегменты, записи сессий, обращения в поддержку и качество события. Если падение возникает только в одном браузере или после одного релиза, это может быть багом трекинга, а не продуктовой проблемой.

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

Примеры хороших гипотез

Для onboarding гипотеза может звучать так: “Новые пользователи не создают первый отчёт, потому что до подключения данных не видят, какой результат получат. Если показать интерактивный пример и список шагов, activation rate за 24 часа вырастет минимум на 2 п.п., потому что снизится неопределённость первого действия”. Здесь есть сегмент, проблема, изменение, механизм, метрика и порог.

Для checkout: “Покупатели на мобильных устройствах бросают оплату после ввода адреса, потому что стоимость доставки появляется слишком поздно. Если показать диапазон доставки до формы, checkout completion вырастет на 0,5 п.п., а refund rate не увеличится более чем на 0,2 п.п.” Основной результат отделён от защитного показателя.

Для retention не стоит писать “увеличим вовлечение”. Лучше связать действие и окно: “Пользователи, которые не создали второй проект в первые два дня, не возвращаются на D7. Если добавить подсказку с готовым шаблоном после первого проекта, доля пользователей с двумя проектами за 48 часов вырастет на 3 п.п., а D7 retention не снизится”.

Если гипотез несколько

Команда часто приносит список из десяти идей и просит “проверить всё”. Это не означает, что нужно сразу делать десять тестов. Сначала сгруппируй идеи по механизму: доверие, понимание ценности, скорость, цена, риск ошибки. Несколько вариантов одного механизма можно объединить в один эксперимент или выбрать самый дешёвый способ проверить его первым.

Приоритизацию полезно связывать не только с потенциальным uplift. Учитывай силу наблюдения, охват сегмента, стоимость реализации, скорость получения сигнала и риск для пользователя. Простая гипотеза с хорошим измерением часто полезнее амбициозной идеи, для которой команда не умеет определить результат.

Гипотеза должна заканчиваться решением

Запись “посмотрим, что получится” оставляет команду без правил на день окончания теста. До запуска определи три сценария: что делаем при заметном положительном эффекте, что делаем при вреде и что делаем при нейтральном результате. Нейтральный результат тоже имеет варианты: продолжить сбор данных, признать крупный эффект маловероятным или изменить механизм в следующей гипотезе.

Не смешивай результат теста с объяснением причины. Если primary metric выросла, это ещё не доказывает, что сработал именно тот психологический механизм, который команда предполагала. Запиши, какие промежуточные сигналы помогут понять механизм, но не превращай их в незапланированные условия победы.

• Positive: primary выше MDE, guardrails в пределах порогов — раскатить или провести staged rollout.
• Negative: primary ухудшился или guardrail пересёк риск — откатить и разобрать сегмент.
• Neutral and wide: данных мало — продолжить, если срок и MDE всё ещё имеют смысл.
• Neutral and narrow: крупный эффект маловероятен — закрыть гипотезу и перейти к следующему механизму.

Откуда берётся уверенность в гипотезе

Наблюдение в метрике — только один источник сигнала. Добавь к нему качественные данные: записи сессий, интервью, обращения в поддержку и разговоры с операционной командой. Если несколько источников указывают на одну проблему, механизм становится убедительнее. Если они противоречат друг другу, следующий шаг может быть исследованием, а не тестом.

Разделяй факт и интерпретацию в заметках. “42% пользователей остановились на шаге доставки” — наблюдение. “Им непонятна цена” — объяснение, которое нужно проверить. “Покажем стоимость раньше” — решение. Такая последовательность не даёт перескочить от красивой идеи к эксперименту без проверки причины.

Одна гипотеза — не всегда один элемент интерфейса

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

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

• Один механизм: проще понять причинную цепочку.
• Пакетное изменение: быстрее проверить готовый сценарий.
• Факторный дизайн: нужен трафик и заранее продуманная модель взаимодействий.
• Несколько последовательных тестов: полезны, если каждый результат меняет следующий.

Проверь реализуемость до красивой формулировки

Гипотеза может быть логичной, но непригодной для эксперимента. Спроси, можно ли случайно назначить вариант, сохранить его, отследить нужное действие и получить достаточный поток пользователей за разумный срок. Если нет, измени уровень проверки: прототип, анализ наблюдательных данных, интервью или тест на более частой прокси-метрике.

Не обещай точный uplift только потому, что шаблон требует число. Если данных мало, задай минимально полезный порог и направление. Потом согласуй MDE, размер выборки и guardrails с владельцем решения. Гипотеза без плана измерения остаётся хорошей мыслью, но не становится экспериментом.

Что записать после эксперимента

После теста вернись к исходной формулировке и проверь каждый элемент отдельно. Подтвердилась ли проблема? Получили ли пользователи изменение? Изменилось ли ожидаемое действие? Совпала ли primary metric с порогом? Не ухудшился ли guardrail? Такой разбор помогает не перепутать “вариант победил” с “механизм подтверждён”.

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

Такой журнал делает следующую гипотезу продолжением исследования, а не повторным запуском той же идеи с новым названием.

Мини-кейс: от “улучшить onboarding” к тесту

Размытый запрос “улучшить onboarding” можно разобрать за несколько шагов. Сначала в данных видно, что 48% новых пользователей не создают первый проект в первые 24 часа. По срезам проблема сильнее на мобильных устройствах. В записях сессий люди открывают экран импорта, но не понимают, что можно начать с готового шаблона. Это ещё не доказанная причина, но хорошее направление для проверки.

Рабочая формулировка: “Если показать на первом экране два готовых шаблона и пример результата, доля новых пользователей, создавших проект за 24 часа, вырастет с 35% минимум до 38%. Механизм — снижение неопределённости первого шага. Primary — project_created_24h, guardrail — доля пользователей, удаливших проект в первые семь дней”. Теперь можно оценить MDE, размер выборки и состояние событий.

Если тест даст нейтральный результат, это не означает, что onboarding в целом бесполезен. Возможно, пользователи не заметили шаблоны, причина была в импорте или метрика слишком далека от ценности. Следующая гипотеза должна уточнить именно этот неопределённый участок, а не снова обещать “рост вовлечения”.

Проверь, что гипотеза не маскирует решение

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

Такой вопрос не тормозит работу. Он помогает выбрать меньший прототип, добавить правильное событие или отказаться от дорогого теста до того, как решение станет необратимым.

Чем дороже изменение, тем важнее отделить проверку причины от защиты уже выбранного решения.

Именно это превращает гипотезу в рабочий контракт команды.

Как сделать гипотезу понятной для всей команды

Гипотеза нужна не только аналитику. Дизайнер должен понимать, что именно меняется и почему. Разработчик — какие события и состояния нужно сохранить. Product manager — какое решение будет принято. Если каждый читает формулировку по-своему, эксперимент превращается в спор о реализации после запуска.

Перед стартом попроси команду пересказать гипотезу своими словами. Если аналитик говорит про project_created_24h, дизайнер — про клики по шаблону, а менеджер — про “вовлечение”, контракт ещё не согласован. Уточни терминологию, добавь словарь и закрепи один источник для primary и guardrails.

Согласованный словарь обычно экономит больше времени, чем ещё один график в финальном отчёте.

• Product: какой вопрос и какое решение?
• Design: какой механизм должен измениться в интерфейсе?
• Engineering: какие варианты, события и ограничения нужны?
• Analytics: какой знаменатель, окно и порог?
• Operations: какой риск и кто владеет rollout?

Сделай формулировку короткой, а подготовку глубокой

Финальная гипотеза может занимать два предложения, хотя за ней стоят данные, исследование и обсуждение рисков. Не нужно переносить весь discovery в заголовок эксперимента. Сохрани подробный brief отдельно, а в карточке оставь компактную цепочку: наблюдение, причина, изменение, метрика, порог и решение.

Так документ остаётся читаемым для команды и пригодным для поиска. Если через месяц кто-то увидит результат, он сможет быстро понять вопрос, а по ссылке открыть детали: сегментацию, источники, расчёт MDE, события и ограничения. Хорошая гипотеза не длинная сама по себе — она хорошо связана с контекстом.