
A/B тест - это инструмент принятия решений под неопределённостью. Вы никогда не знаете «правду» о вашем продукте со 100% уверенностью: у вас есть только выборка данных. Именно поэтому в любом тесте возможны два типа ошибок - и задача хорошего дизайна эксперимента состоит не в том, чтобы их исключить (это невозможно), а в том, чтобы заранее договориться, какой риск допустим.

Тест идёт третий день. PM открывает дашборд — версия B ведёт с конверсией 6.8% против 5.9% у контроля. P-value — 0.04. Коллеги в Slack пишут «запускаем?». PM останавливает тест и отправляет версию B в прод.

Cколько должен стоить наш продукт? Занизишь — потеряешь выручку и доверие. Завысишь — потеряешь клиентов. Угадать интуитивно почти невозможно, а вот измерить — вполне реально.

Квартальный ревью. На экране — дашборд с активными пользователями, выручкой и NPS. Всё растёт. Инвесторы довольны. PM рассказывает про планы на новые фичи.

На очередном планировании команда показывает инвестору дашборд: MAU вырос на 22% за квартал, регистрации бьют рекорд. Инвестор доволен, разработчики получают задачи на новые фичи. Через квартал выясняется: retention на третий месяц — 9%. Большинство пользователей регистрировались, делали одно-два действия и навсегда исчезали.

Вы сидите на встрече по ценообразованию. На столе — три варианта тарифной сетки. Продакт говорит: «давайте добавим в средний план аналитику, клиенты точно за это заплатят». Маркетинг возражает: «клиенты хотят интеграции, а не отчёты». CEO резюмирует: «давайте просто поднимем цену на 15% и посмотрим».

Большинство A/B тестов в продуктовых командах технически корректны и концептуально неверны: они отвечают не на тот вопрос, измеряют не ту метрику или работают на выборке, которая не репрезентирует нужный сегмент