Слабая гипотеза убивает A/B-тест ещё до первого пользователя

Гипотеза — не «поменяем кнопку и посмотрим». Нормальная формулировка отвечает на 4 вопроса: кого трогаем, какое поведение меняем, за счёт чего, в какой метрике увидим эффект.

Шаблон: «Если для [сегмента] сделать [изменение], то [целевая метрика] вырастет/снизится, потому что [механизм]». Без механизма это не гипотеза, а задача в бэклог. Без сегмента — средняя температура по воронке.

Плохой пример: «Упростить онбординг». Хороший: «Если убрать необязательный шаг выбора интересов для новых пользователей из платного трафика, completion onboarding вырастет, потому что меньше людей упрётся в решение без контекста».

Перед запуском проверь:
— есть одна главная метрика, а не пять равноправных;
— указан guardrail: retention, refund, ARPU, нагрузка на поддержку;
— результат можно интерпретировать: победа, провал или инконклюзив;
— команда заранее знает, какое решение примет при каждом исходе.

Если после теста можно спорить «и так, и так нормально» — гипотеза была мусором. Формулируй её так, чтобы эксперимент закрывал решение, а не открывал новый митинг.