Если в вашей платформе экспериментов нет этих 7 слоёв, A/B быстро превращается в спор “верю/не верю”.
Типичный сценарий: запустили тест, дашборд “показывает рост”, продукт уже готов выкатывать, а аналитик внезапно задаёт неудобные вопросы: “а кто реально видел вариант?”, “а почему группы разные?”, “а метрика точно считается одинаково везде?”. И дальше начинается не анализ, а переговоры. Цена — решения на шуме, откаты, потеря доверия к экспериментам как к инструменту.
Почему так происходит: A/B — это не только статистика и кнопка “split 50/50”. Это цепочка договорённостей и технических гарантий от назначения пользователя до того, как метрика попала в отчёт. Если хотя бы одно звено не фиксируется и не мониторится, вы не отличите эффект от артефакта.
Минимальный стандарт платформы (удобный чек-лист для build-vs-buy):
- Рандомизация. Детерминированная, воспроизводимая, с понятной единицей (user/device/account). Красный флаг — “рандом” на фронте или смена варианта при разлогине.
- Назначение (assignment). Единый сервис/правило, которое решает, кто в каком варианте, и хранит это решение. Красный флаг — несколько источников правды и разные варианты в разных системах.
- Трекинг экспозиции. Лог “пользователь реально увидел изменение”, а не “попал в группу”. Красный флаг — анализ по assigned, когда половина людей не экспонировалась.
- Витрины метрик. Единые определения, версии, окна, фильтры, проверяемые источники данных. Красный флаг — “метрика в продукте одна, в DWH другая, в BI третья”.
- SRM и AA. Автоматические проверки перекоса трафика и “нулевые” тесты, чтобы ловить баги в назначении/логах. Красный флаг — SRM узнают постфактум из чата.
- Guardrails. Набор метрик безопасности (качество данных, перфоманс, ошибки, выгорание юнит-экономики) и правила остановки. Красный флаг — обсуждают только целевую метрику, пока ломается опыт.
- Репортинг. Не “скрин даша”, а повторяемый отчёт: экспозиция, окна, сегменты, фильтры, правила исключений, корректная интерпретация. Красный флаг — каждое резюме теста делается вручную “по вдохновению”.
В правильной практике это выглядит скучно: большая часть работы — не в p-value, а в гарантиях, что сравниваются сопоставимые группы и одинаково посчитанные события. Обычно спорят про то, “нужно ли столько инфраструктуры”, но без неё вы покупаете не эксперименты, а бесконечные разборы причин, почему “на проде не повторилось”. Для разовых небольших запусков можно упростить, но тогда честно называйте это проверкой гипотезы, а не системой экспериментов.
