CUPED/CUPAC — красный флаг, если вы ждёте “ускорения A/B” без идеальных входных данных.

Типичная сцена: команда устала от долгих экспериментов, слышит “снизим дисперсию, быстрее увидим эффект” и тащит CUPED или модельку для CUPAC в пайплайн. В итоге сроки не сокращаются, а доверие к тестам падает: результаты начинают “плавать” между пересчётами, спорят не про продукт, а про то, какая версия датасета правильная.

Почему так происходит. Снижение дисперсии работает только когда ковариата реально объясняет поведение метрики в тестовом периоде и делает это стабильно. Если связь слабая, нестабильная или ковариата грязная, вы добавляете не сигнал, а новый источник шума: пропуски, смещения, переобучение, утечки, разные правила отсева. И это ещё до того, как вы упираетесь в оргреальность: кто-то меняет логирование, окно пред-периода, дедупликацию, и “корректировка” перестаёт быть сопоставимой.

Минимальный стандарт “внедрять или нет” такой:

  1. Есть стабильное поведение. Пред-периодная метрика или признаки должны быть связаны с пост-периодом для большинства пользователей, а не только для активных “хардкорщиков”. Иначе выигрыш будет локальным и спорным.

  2. Ковариата измеряется качественно. Пропуски, задержки, смена схемы событий, разные устройства/каналы, проблемы с идентификацией — всё это превращает CUPED/CUPAC в генератор артефактов. Если базовая data quality не под контролем, рано.

  3. Нет утечки. Никаких признаков, которые могут “узнать” про участие в эксперименте или про воздействие фичи. Любая зависимость от лечения убивает смысл корректировки.

  4. Достаточно данных для дисциплины. CUPAC с моделью оправдан, когда есть кому поддерживать обучение, мониторинг дрейфа и воспроизводимость. Если у вас один аналитик на всё, цена поддержки съест выигрыш.

  5. Есть критерий успеха, кроме “красиво на графике”. Вы должны заранее решить, что именно ускоряется: меньше дисперсия в ключевой метрике, меньше required sample size, меньше длительность при тех же guardrails. Если это нельзя померить и зафиксировать — это не инженерия, а вера.

В правильной практике CUPED/CUPAC выглядит скучно: сначала стабилизируют трекинг и окна, проверяют корреляцию и пропуски, делают воспроизводимый расчёт и регрессионные проверки, и только потом включают в “боевой” A/B. Граница применимости простая: если у вас частые изменения продукта/логирования и метрики сами ещё не устоялись, variance reduction чаще усложняет жизнь, чем ускоряет выводы. Обычно спорят про “модель лучше/хуже”, но почти всегда проблема не в модели, а в данных и дисциплине пайплайна.