Если в A/B “взлетела” ключевая метрика, но у вас нет уверенности, что это эффект фичи, почти всегда это конфаундинг.

Типичный сценарий: выкатываем эксперимент, видим рост, бежим презентовать. Через неделю откат, а объяснение одно: в тест вместе с изменением попала скрытая переменная. Цена ошибки простая: продукт принимает решение, которое не воспроизводится, а доверие к экспериментам падает быстрее, чем метрика росла.

Механика у конфаундинга скучная, но жесткая: группы различаются не только вариантом, но и тем, как в них попали пользователи и что с ними происходило вокруг. Это может быть “умный” таргетинг, который подбирает аудиторию по поведению, ранжирование, которое меняет состав трафика, или операции, которые внезапно начали по-другому обслуживать поток (саппорт, модерация, доставка, лимиты, фрод).

Короткое дерево диагностики: симптом → вероятная причина → что проверить первым.

  1. Симптом: эффект есть только в одном сегменте (канал, платформа, гео) → причина: таргетинг/закупка/экспозиция менялись параллельно → проверить: распределение источников и долей сегментов между группами, плюс стабильность входного трафика по дням.

  2. Симптом: меняются “верхние” метрики (просмотры, клики), а “низ” ведет себя странно → причина: ранжирование/рекомендатель/частота показов подкрутилась вместе с тестом → проверить: инварианты по экспозиции (сколько показов, кому и где), и что логика назначения варианта не зависит от скоринга.

  3. Симптом: результат появляется скачком в конкретный день/час → причина: релиз, миграция, инцидент, внешняя кампания → проверить: pre-period, сравнение трендов до старта, и раздельно по датам включения варианта.

  4. Симптом: улучшение сопровождается ухудшением “странных” операционных метрик (отмены, тикеты, время ответа) → причина: саппорт/операции начали иначе обрабатывать часть пользователей → проверить: различия в очередях, SLA, ручных правилах, и пересечение экспериментальной группы с операционными флагами.

  5. Симптом: метрики пляшут, выборка “не сходится” → причина: проблемы назначения/логирования → проверить: sample ratio mismatch, дубли, пропуски событий, совпадение unit id, и что один пользователь не меняет вариант.

Правильная практика выглядит не как “посчитали p-value”, а как привычка держать набор инвариантов и контрольных срезов, которые обязаны быть стабильными, иначе эксперимент сразу в карантин. Обычно спорят про статистику, но чаще ломает не она, а незамеченная смена состава трафика или процесса вокруг. Граница применимости: в очень ранних прототипах можно жить без идеальной строгости, но нельзя делать продуктовые выводы без проверки конфаундинга.