Уровень аналитика в A/B-тестах видно не по p-value, а по тому, где ломается доверие к выводу.
Самая частая картина: отчёт “выиграли”, команда уже катит фичу, а через месяц метрика откатывается или в саппорте пожар. Цена ошибки тут не в статистике, а в решениях: продукт тратит время, маркетинг разгоняет не то, инженерка фиксит последствия.
Почему так происходит: A/B почти никогда не падает из-за “не той формулы”. Он падает из-за контроля качества, постановки метрик и рамок решения. Чем выше уровень, тем больше фокуса не на расчёте, а на дизайне и защите причинно-следственной логики.
Минимальный стандарт по уровням выглядит так.
- Junior
- Корректно считает метрики и сегменты, не путает юнит (user vs session vs order)
- Делает базовые проверки качества данных и рандомизации, в том числе SRM
- Понимает, что нельзя смотреть на 20 метрик и выбрать “которая выросла”, и не приносит такой вывод в чат
- Middle
- Проектирует эксперимент: гипотеза, primary metric, период, критерий остановки, план разрезов до старта
- Умеет объяснить, что именно является эффектом, а что артефактом логирования, сезонности, каналов, перерасхода стимулов
- Выбирает guardrails и умеет сказать “в primary плюс, но откатываем из-за риска” без истерики и магии
- Senior
- Строит систему: правила метрик, иерархию целей, библиотеку проверок, единые дефиниции, ownership по качеству
- Заранее договаривается с бизнесом о том, какое решение считается валидным, и что будет считаться “неопределённо”
- Защищает выводы на уровне решений: почему такой дизайн, какие риски, какие альтернативные объяснения отброшены, что делаем при конфликте метрик
В правильной практике A/B выглядит как заранее зафиксированное решение с условиями, а не как “посчитали и поверили”. Обычно спорят про статистику, но чаще всего проваливаются на постановке метрик, guardrails и дисциплине данных. Граница применимости простая: если нет стабильного логирования и контроля экспозиций, сначала чините измерение, потом экспериментируйте.
