Прежде чем выбрасывать результаты теста, выявите несоответствие в выборочных соотношениях в пяти ветвях.

Примерно в 6% экспериментов в Microsoft обнаруживается несоответствие соотношения выборок, что для продукта, проводящего 10 000 экспериментов в год, составляет примерно одно обнаружение в день.Фабиджан и др., KDD 2019Команды, проводящие гораздо меньше тестов, редко видят такое число, потому что проверка, выполняемая их платформой, не может достичь статистической значимости при их объеме трафика. Тест выглядит чистым, показывает прирост в 4%, но все равно оказывается неверным.

Это руководство предназначено для тех, кто читает результаты эксперимента и должен решить, стоит ли отправлять образец на тестирование. К концу вы сможете определить, достаточно ли велик ваш тест, чтобы проверка на несоответствие имела смысл, запустить пять ветвей диагностики в порядке, который быстрее всего выявит причину, и отделить дисбаланс, который делает результаты эксперимента недействительными, от дисбаланса, который можно выделить и сохранить.

Что на самом деле сообщает сигнал тревоги SRM?

Несоответствие соотношения выборок — это разрыв между заданным вами разделением и наблюдаемым разделением: вы установили 50/50, а получили 50.8/49.2. Стандартной проверкой является критерий согласия Пирсона хи-квадрат для количества облученных, с одной степенью свободы для двухгруппового теста.

Это важно, потому что механизм потери пользователей почти никогда не бывает нейтральным по отношению к вашим показателям. Если перенаправление разрывает медленные соединения с вариантом, то остаются те, у кого лучшее соединение, и они конвертируются лучше. Рост посещаемости реален в данных, но отсутствует в реальности.

Вот первая ошибка, которую допускает большинство команд: в отрасли нет единого порогового значения. Различия между платформами превышают порядок величины.

Два следствия. Тест, отмеченный на одной платформе, проходит проверку на другой с идентичными данными, поэтому фраза «наш инструмент нас не предупредил» не является доказательством чистого разделения. А пороговое значение 0.01 указывает на один из ста успешных тестов. Если ежедневно оценивать значение p на протяжении трехнедельного теста, то наивная граница независимого пика для ложной тревоги составляет 19%; истинная цифра ниже, поскольку последовательные дни сильно коррелируют, но она не равна 1%. Именно поэтому AB Tasty использует последовательную процедуру. Если ваша платформа использует критерий хи-квадрат с фиксированным горизонтом, посмотрите один раз, в конце, на кумулятивные значения.

Проверьте, может ли ваш тест вообще выявить дисбаланс.

При разделении 50/50 статистика хи-квадрат упрощается до 4n(p̂−0.5)², где n — общее количество случаев воздействия. Если инвертировать её, вы получите наименьший дисбаланс, который может выявить ваша проверка:

Воспринимайте это как ограничение, а не как лицензию. При 10 000 показов любое отклонение менее 1.3 пункта незаметно для проверки, а эффекта отбора в 1.3 пункта более чем достаточно, чтобы создать небольшой прирост конверсии. В этом заключается структурная проблема большей части региона. В Турции в 2025 году было зарегистрировано около 6 миллиардов транзакций в сфере электронной коммерции примерно через 634 000 предприятий.Министерство торговли, 12 мая 2026 г.В среднем около 9,500 в год на каждый, и этот средний показатель значительно завышается из-за нескольких торговых площадок. Магазин среднего размера, тестирующий этап оформления заказа, работает с десятками тысяч просмотров, а не с миллионами, поэтому его проверка SRM выявляет только серьезные ошибки и ничего более незаметного.

При таком объеме не стоит полагаться на сигнал тревоги. Самостоятельно собирайте данные о количестве просмотров по дням и сегментам, и рассматривайте устойчивое движение в одном направлении как подозрительное, даже если значение p не вызывает опасений. Если вы не уверены, где ваша платформа отображает эти данные, Документация SRM Checker отображает их по каждому инструменту.

Пять ветвей, в порядке, который позволяет быстрее найти причину.

В таксономии KDD причины SRM классифицируются по этапам жизненного цикла: назначение, выполнение, обработка журналов, анализ, помехи. Диагностику следует проводить в другом порядке, начиная с самых дешевых и наиболее распространенных.

1. Анализ и запуск. Симптом: разделение корректно в исходном журнале воздействия, но нарушено в оценочной таблице. Проверка: пересчитайте соотношение без условия срабатывания, фильтра по дате и объединений на уровне метрик. Подтвердите, если соотношение вернется к ожидаемому значению. Исправление: оцените срабатывание одинаково в обеих группах, прежде чем любое поведение, специфичное для варианта, сможет изменить критерии отбора. Наиболее распространенная ложная тревога, на ее исключение уходит десять минут.
2. Обработка журналов. Симптом: количество запросов различается между двумя конвейерами обработки, или расхождение появляется после этапа ETL. Проверка: сравните количество запросов на стороне SDK, количество запросов в хранилище и количество запросов в отчете за один и тот же период, затем сравните коэффициенты исключения ботов-фильтров для каждой ветви. Подтвердите, равны ли ветви обработки на входе и неравны на выходе. Решение: фильтруйте детерминированно и идентично. Автоматизированный трафик достиг 53% веб-трафика в 2026 году, по сравнению с 51% в 2024 году.Отчет Imperva о некорректно работающих ботах, 29 апреля 2026 г.Таким образом, эвристический фильтр, основанный на времени загрузки или поведении пользовательского агента, может исключать варианты с разной степенью вероятности. Здесь также присутствует функция потерь, обусловленная согласием: когда ad_storage Если это будет отклонено, платформа тегов Google прекратит установку рекламных файлов cookie.Документы Google по согласию на использование платформы теговТаким образом, если в одном тесте показатели отказов различаются в зависимости от географического региона, любое назначение, основанное на этих идентификаторах, приводит к неравномерной потере пользователей.
3. Исполнение. Симптом: дисбаланс увеличивается с весом страницы, ухудшается на мобильных устройствах или начинается на этапе развертывания. Проверка: разделите соотношение по устройству, браузеру, типу подключения и дню; сравните время отображения между вариантами. Подтвердите, если дефицит сосредоточен в медленных сегментах или в одном браузере. Решение: здесь тесты перенаправлений терпят неудачу. Перенаправление добавляет полную навигацию только к одному варианту, и каждый, кто покидает страницу во время перенаправления, представляет собой избирательную потерю. Отображайте оба варианта на стороне сервера по одному URL или смиритесь с тем, что варианты несопоставимы.
4. Назначение. Симптом: соотношение нарушено с первого часа и остается нарушенным на постоянный коэффициент. Проверка: запустите A/A на том же распределении и убедитесь, что хеш-соль не была повторно использована из предыдущего эксперимента на этой популяции. Подтверждает это, если A/A также показывает дисбаланс. Решение: переназначьте с новой солью и перезапустите. Перенос данных из предыдущего теста — это скрытая версия проблемы, и только A/A выявляет её.
5. Вмешательство. Симптом: дисбаланс сосредоточен в небольшом количестве идентификаторов с высокой активностью или во внутренних диапазонах IP-адресов. Проверка: распределение количества раскрытий по пользователям и 1% самых активных идентификаторов по объему событий. Подтверждает, восстанавливает ли удаление этих идентификаторов соотношение. Исправление: исключать внутренний и скриптовый трафик с помощью документированного правила, а не вручную, чтобы исключение было идентичным в следующий раз.

Пошаговое руководство с подробным разбором процесса.

Приведенные ниже цифры являются иллюстративными и не отражают данные клиента. Тест проверки показывает 61 480 контрольных и 58 520 вариантов заражения: 51.2/48.8 на 120 000 пользователей, p-значение хи-квадрат ниже 0.001. Ветвь 1: отмена условия запуска возвращает 60 020 / 59 980, поэтому назначение корректно, и потеря происходит после заражения. Ветвь 2: подсчеты в конвейере совпадают, исключение ботов составляет 0.9% в обеих группах. Ветвь 3: на настольных компьютерах — 50.1/49.9, на мобильных — 52.4/47.6, а медианное время до заражения варианта на мобильных устройствах на 900 мс выше. Диагноз: вариант отправляет дополнительный блокирующий рендеринг запрос, мобильные пользователи покидают сайт во время его выполнения, у пользователей, сохранивших вирус, лучшее соединение. Результат недействителен. Исправление касается производительности, и тест запускается повторно, а не переинтерпретируется.

Что можно спасти, а что нет.

• Аннулировать показания когда механизм потерь может правдоподобно коррелировать с метрикой. Каждая причина выполнения и назначения по умолчанию считается допустимой.
• Утилизация по сегментам Только если дисбаланс ограничен сегментом, который можно однозначно исключить, этот сегмент был определен до того, как вы проанализировали метрику, и оставшаяся часть проходит собственную проверку SRM. Двух из трех недостаточно.
• Сохраните тест Когда причина заключалась исключительно в анализе, и скорректированная система оценки проходит проверку. Вы перечитываете те же данные с фиксированным фильтром, а не пытаетесь их отфильтровать.
• В любом случае, зарегистрируйте это. Запишите категорию причины для эксперимента. Таксономия приносит кумулятивные результаты: если три из ваших последних десяти тестов не прошли проверку в ветке 3, проблема не в экспериментах, а во фронтенд-разработке. [НЕОБХОДИМЫ ВНУТРЕННИЕ ДАННЫЕ: доля экспериментов, проведенных Switas за последние 24 месяца, которые не прошли проверку SRM, с разбивкой по веткам таксономии, чтобы заменить показатель Microsoft в 6% на данные с этого рынка]

Где это происходит сбой

Это дерево предполагает двухгрупповой тест с фиксированным, известным распределением и рандомизацией на уровне пользователя. Оно не охватывает многогрупповые тесты, для которых требуется полный критерий хи-квадрат по всем группам плюс последующая проверка того, какая пара не совпадает, или тесты с постепенным изменением распределения, где ожидаемое соотношение меняется в течение теста, и кумулятивный критерий хи-квадрат является изначально неверным тестом. Оно не применяется к кластерным или географически рандомизированным схемам, где единицей является не пользователь, а существенный дисбаланс заключается в характеристиках кластера. Оно ничего не говорит о правильности определения вашей метрики. И оно не поможет, когда данные о воздействии не регистрируются, и вы делаете вывод о назначении на основе события метрики, что является не проверкой разделения, а предположением.

FAQ

Всегда ли разделение 51/49 является проблемой? Это полностью зависит от n. При 5,000 экспозициях это обычный шум; при 500 000 — почти наверняка дефект. Оценивайте соотношение по таблице обнаруживаемости, а не по фиксированному процентному правилу.

Могу ли я просто статистически пересчитать вес групп вместо повторного проведения эксперимента? Нет. Перевзвешивание корректирует подсчеты и сохраняет выборку неизменной. Пользователи, которых вы потеряли, исчезли, и они не были случайной выборкой из группы.

Как часто следует проверять значение p в SRM? Один раз, в конце, по суммарным показателям, если только ваша платформа не использует последовательную процедуру. Ежедневный просмотр критерия хи-квадрат с фиксированным горизонтом существенно завышает количество ложных срабатываний.

А SRM делает недействительными и метрики защитных механизмов? Да, по той же причине. Если в выборках участвуют разные группы населения, то плоская шкала оценки не более надежна, чем скользящий основной показатель.

Что если тест A/A также покажет несоответствие? Тогда ошибка кроется в назначении переменных или в конвейере логирования, а не в вашей обработке. Исправьте это, прежде чем запускать что-либо еще, потому что это загрязняет все тесты на этой платформе.

Всегда ли перенаправленные тесты приводят к SRM? Не всегда, но они несут в себе структурный риск, которого нет у других конструкций, поскольку дополнительная навигация реализована только в одном плече. Если вам необходимо использовать такой модуль, проверьте соотношение скорости соединения и типа устройства, прежде чем считывать какие-либо показатели.

У меня слишком низкий трафик, чтобы эта проверка что-либо значила. Что тогда? Отслеживайте ежедневные данные о воздействии на предмет устойчивого отклонения, периодически проводите анализ и оценку уровня распределения и предварительно регистрируйте более длинный список проверок на корректность. Вы заменяете статистическую мощность процессом.

Фильтрация ботов должна происходить до или после назначения? После регистрации воздействия, перед анализом, используются детерминированные правила, применяемые одинаково к обеим группам. Эвристическая фильтрация внутри SDK — это то, как сам фильтр становится причиной несоответствия.

Проведите проверку в собственной экспериментальной программе.

Если вам нужен дополнительный взгляд на неоднозначное состояние запущенных вами тестов или проверка уровня назначения команд и логирования, от которых они зависят, то именно для этого мы и предоставляем такую ​​возможность. Услуги CRO и проведения экспериментов делает.

Источники

• Фабиджан, Гупчуп, Гупта, Омховер, Вермеер, Дмитриев, «Диагностика несоответствия соотношений выборок в онлайн-контролируемых экспериментах: таксономия и практические правила для практиков», KDD 2019
• Документация AB Tasty, несоответствие соотношения образцов (последовательный S-SRM, пороговое значение 0.01)
• Statsig, «Краткое руководство по несоответствию выборочных соотношений», 31 августа 2023 г. (критерий хи-квадрат, пороговое значение 0.01)
• Документация GrowthBook, Эксперименты (критерий хи-квадрат, предупреждение ниже 0.001)
• Imperva, «Отчет о вредных ботах 2026: Боты в эпоху агентов», 29 апреля 2026 г.
• Министерство торговли Республики Турция, данные по электронной коммерции за 2025 год, 12 мая 2026 года.
• Платформа тегов Google, режим согласия и поведение при хранении данных.
• Документация и часто задаваемые вопросы по SRM Checker, Лукас Вермеер