CUPAC ломается не на модели, а на ковариатах: берёте «чуть-чуть после экспозиции» и получаете утечку вместо снижения дисперсии.

Типичная сцена: в RFC пишут «добавим CUPAC, чтобы быстрее увидеть эффект», и дальше в признаки летит всё, что красиво лежит в витрине. Эксперимент стартовал в понедельник, а фичи обновляются ежедневно. Итог: оценка эффекта становится хрупкой. Иногда «улучшается» значимость, но это не ускорение, а самообман, потому что ковариата частично уже несёт след лечения.

Механика простая: CUPAC использует предсказание целевой метрики как ковариату. Если признаки хоть как-то меняются из‑за назначения в тест или из‑за самого воздействия, модель начинает объяснять не базовую склонность пользователя, а кусок treatment effect. Дальше регрессия честно вычитает это из оценки, и вы получаете смещение.

Минимальный стандарт отбора ковариат и диагностики (то, что я бы требовал в RFC):

1. Жёсткая граница «до экспозиции»: для каждой единицы (юзер, аккаунт, сессия) фиксируете cutoff и строите признаки только из событий с timestamp строго раньше. Никаких «в день старта» и «за последние 7 дней», если окно пересекает запуск.
2. Только снапшоты, а не «живые» поля: last_seen, статус подписки, сегменты, LTV, скоринги, которые пересчитываются во время эксперимента, должны быть заморожены на cutoff. Иначе это скрытый пост-экспожер.
3. Признаки не должны зависеть от рандомизации и пайплайна эксперимента: всё, что появилось потому что вы включили флаг, завели новую разметку или поменяли трекинг, под запретом.
4. Валидация модели по времени: сплит по календарю (train на прошлом, test на будущем), плюс проверка стабильности качества по ключевым сегментам. Если качество «прыгает», CUPAC будет нестабильным усилителем шума.
5. Диагностики на самом эксперименте: баланс CUPAC-скора между группами, проверка что ковариата не «разъезжается» по времени после старта, и плацебо на pre-period (на окне до запуска эффект должен быть около нуля).

В правильной практике CUPAC выглядит как инженерное соглашение: фиксированный cutoff, воспроизводимая сборка фичей, версионирование модели, и отдельный блок в RFC с рисками утечки и проверками. Граница применимости простая: если лечение меняет измерение (трекер, атрибуцию, идентификаторы) или жизненный цикл данных, CUPAC сначала надо стабилизировать, а уже потом ускорять статистику. Обычно спорят про «можно ли брать фичи в день старта» — я бы считал это красным флагом по умолчанию.