Дерево решений для UX-экспериментов: не всё надо проверять A/B
Типичная картина: команда неделями готовит A/B “переставили кнопку”, а потом либо “нет эффекта”, либо “метрика пляшет”. Цена — потерянное время, ложная уверенность и отложенные реальные багфиксы. Самое обидное: часто правильный метод был проще и быстрее, просто вы выбрали не тот инструмент.
Почему так ломается: A/B отвечает на вопрос “что лучше” при стабильной измеримости и достаточном трафике. Но UX-изменения часто про “почему не получается” и “где ломается сценарий”. Там A/B превращается в дорогой рандом, который не объясняет причин. Плюс любой эксперимент уязвим к мусору в событиях, сезонности, новизне фичи, и к тому, что эффект меньше шума.
Минимальный стандарт выбора (if/then по риску, обратимости, охвату, эффекту):
- Если есть явная поломка или деградация, то просто фиксим.
- ошибки в логах, 4xx/5xx, падение конверсии после релиза, сломанная валидация, проблемы оплаты, недоступность, регрессии, “ничего не работает” на части устройств Тут A/B — красный флаг: вы тестируете баг, а не гипотезу.
- Если неизвестно, где именно люди застревают, то usability-тест или быстрые сессии.
- новый сценарий, сложная форма, непонятные тексты, первый экран, онбординг Цель — найти узкие места и язык пользователя. A/B без этого часто сравнивает две версии одной и той же проблемы.
- Если трафика мало или цикл решения длинный, то не A/B.
- редкие пользователи, B2B, долгие сделки, сильная зависимость от канала Лучше качественное исследование + диагностика по логам ошибок/событиям + последовательные итерации.
- Если риск высокий и откат дорогой, то сначала guardrails и поэтапный rollout.
- доверие, деньги, юридические тексты, приватность, цены, уведомления Даже при A/B нужны стоп-условия, мониторинг и план отката. Иногда безопаснее “10% rollout + наблюдение”, чем чистая рандомизация.
- Если эффект ожидается маленький, но охват большой и метрика честная, то A/B уместен.
- изменения, которые масштабируются на всех и бьют в конкретную метрику, которую вы реально контролируете событиями Перед запуском: проверка трекинга, единый primary metric, список guardrail-метрик, критерий остановки и правило “не смотреть каждый день”.
В правильной практике дерево выглядит так: сначала убираем очевидные поломки, потом выясняем причины через наблюдение и качественные тесты, и только затем масштабируем через A/B там, где есть трафик, обратимость и измеримость. Обычно спорят про “ожидаемый эффект”, но чаще всего ошибаются не в величине, а в выборе инструмента.
