<b>CRO ломается не в тесте, а в постановке: 6 ошибок, которые искажают вывод</b>

<b>CRO ломается не в тесте, а в постановке: 6 ошибок, которые искажают вывод</b>

Почти любой «лифт» в CRO выглядит убедительно, пока не проверить дизайн эксперимента. Если у вас разная длительность трафика, смешаны новые и возвращающиеся пользователи или в тест попали параллельные изменения, вы измеряете шум, а не эффект.

— Не фиксируют <i>primary metric</i> заранее: потом выбирают ту, где «победило».
— Делают вывод по одной метрике и игнорируют guardrails: AOV, refund rate, time to purchase.
— Не считают размер выборки и останавливают тест на первом всплеске.
— Сравнивают сегменты без контроля множественных проверок: ложноположительные находки растут.

Ещё две частые ошибки: тестируют на слишком коротком окне, где weekday/weekend уже меняют картину, и не проверяют SRM — sample ratio mismatch, когда трафик между вариантами распределился не так, как ожидалось. В таком случае даже «значимый» результат может быть технически сломан.

Рабочее правило простое: сначала гипотеза и метрика, потом калькулятор выборки, затем sanity-check перед интерпретацией. Если эксперимент нельзя объяснить в одном абзаце без оговорок, его рано объявлять победой.