Близько 6% експериментів у Microsoft показують невідповідність співвідношення вибірок, що для продукту, який виконує 10 000 експериментів на рік, зводиться приблизно до одного виявлення на день (Фабіян та ін., KDD 2019). Команди, які проводять набагато менше тестів, рідко бачать таке число, оскільки перевірка, яку проводить їхня платформа, не може досягти значущості за їхнього обсягу трафіку. Тест виглядає чистим, повідомляє про зростання на 4% і все одно помилковий.
Цей посібник призначений для особи, яка читає результати експерименту та має вирішити, чи варто його відправляти. Зрештою, ви зможете визначити, чи достатньо великий ваш тест, щоб перевірка на невідповідність мала якесь значення, виконати п'ять гілок діагностики в порядку найшвидшого знаходження причини та відокремити дисбаланс, який анулює результати, від того, який можна сегментувати та зберегти.
Що насправді повідомляє вам сигналізація SRM
Невідповідність коефіцієнта вибірки – це розрив між налаштованим вами розподілом і розподілом, який ви спостерігаєте: ви встановили 50/50 і отримали 50.8/49.2. Стандартною перевіркою є тест на відповідність хі-квадрат Пірсона для кількості експозицій, один ступінь свободи для двокомпонентного тесту.
Це важливо, тому що механізм втрати користувачів майже ніколи не є нейтральним щодо вашої метрики. Якщо перенаправлення призводить до втрати повільних з’єднань з варіанта, тими, хто вижив, є ті, хто має кращі з’єднання, і вони краще конвертують. Зростання реальне в даних і відсутнє в реальності.
Ось перша річ, яку помиляється більшість команд: немає галузевого порогу. Платформи розходяться в думках більш ніж на порядок.
| платформа | Перевірити | Прапори на | Примітка: |
|---|---|---|---|
| AB Tasty | Послідовний частотний (S-SRM) | р <0.01 | Створено для безперервного моніторингу, тому враховуються повторні перегляди |
| Статсіг | Хі-квадрат | р <0.01 | Ми вважаємо експозиції незбалансованими, якщо p-значення SRM нижче 0.01. |
| Книга зростання | Хі-квадрат | р <0.001 | Попередження пригнічується вище цього |
| Microsoft (робоча ілюстрація) | Хі-квадрат | ~1 з 139 838 160 | Розкол 50.2/49.8 при великому n вже вирішує цю проблему. |
Два наслідки. Тест, позначений на одній платформі, проходить на іншій з ідентичними даними, тому «наш інструмент нас не попередив» не є доказом чистого поділу. А поріг 0.01 позначає один зі ста справних тестів. Якщо щодня оцінювати p-значення протягом тритижневого тестування, то наївна незалежний погляд на хибну тривогу становитиме 19%; справжня цифра нижча, оскільки послідовні дні сильно корелюють, але вона не дорівнює 1%. Саме тому AB Tasty використовує послідовну процедуру. Якщо ваша платформа використовує хі-квадрат з фіксованим горизонтом, перегляньте один раз, в кінці, кумулятивні підрахунки.
Перевірте, чи може ваш тест взагалі виявити дисбаланс
Для розподілу 50/50 статистика хі-квадрат спрощується до 4n(p̂−0.5)², де n – загальна кількість експозицій. Інвертуйте її, і ви отримаєте найменший дисбаланс, який може виявити ваша перевірка:
| Загальна кількість експозицій | Найменший позначений розкол при p < 0.01 | при p < 0.001 |
|---|---|---|
| 5,000 | 51.8 / 48.2 | 52.3 / 47.7 |
| 10,000 | 51.3 / 48.7 | 51.6 / 48.4 |
| 30,000 | 50.7 / 49.3 | 51.0 / 49.0 |
| 100,000 | 50.4 / 49.6 | 50.5 / 49.5 |
| 1,000,000 | 50.13 / 49.87 | 50.16 / 49.84 |
Розумійте це як обмеження, а не як ліцензію. При 10 000 експозицій будь-який дисбаланс, менший за 1.3 пункту, є невидимим для чека, а ефекту відбору в 1.3 пункту більш ніж достатньо для невеликого збільшення конверсії. Це структурна проблема в більшій частині регіону. У 2025 році в Туреччині було зафіксовано близько 6 мільярдів транзакцій електронної комерції приблизно для 634 000 підприємств (Міністерство торгівлі, 12 травня 2026 року), в середньому близько 9,500 на рік кожен, і цей середній показник значно перевищується кількома торговельними майданчиками. Магазин середнього ринку, який тестує етап оформлення замовлення, працює з десятками тисяч викриттів, а не з мільйонами, тому його перевірка SRM виявляє грубі поломки та нічого більш тонкого.
За такого обсягу не покладайтеся на сигнал тривоги. Самостійно визначайте необроблені показники експозиції за днями та за сегментами, а постійний дрейф в одному напрямку розглядайте як підозрілий, навіть якщо p-значення не є помітним. Якщо ви не впевнені, де ваша платформа виявляє ці показники, Документація засобу перевірки SRM відображає їх для кожного інструменту.
П'ять гілок, у порядку найшвидшого знаходження причини
Таксономія KDD сортує причини SRM за етапами життєвого циклу: призначення, виконання, обробка журналу, аналіз, перешкоди. Діагностуйте їх у різному порядку, спочатку найдешевші та найпоширеніші.
- Аналіз та запуск. Симптом: розкол чіткий у журналі необроблених даних експозиції та пошкоджений у таблиці показників. Перевірка: перерахуйте співвідношення без вашої умови тригера, фільтра дати та об'єднань на рівні метрики. Підтвердьте його, якщо співвідношення повертається до очікуваного. Виправлення: оцініть спрацьовування однаково в обох групах, перш ніж будь-яка поведінка, специфічна для варіанта, може змінити придатність. Найпоширеніша хибна тривога, десять хвилин на виключення.
- Обробка колод. Симптом: кількість експозицій відрізняється між двома конвеєрами, або розрив з'являється після кроку ETL. Перевірка: порівняйте кількість на стороні SDK, кількість у сховищі та кількість звітів для одного й того ж вікна, потім порівняйте коефіцієнти виключення бот-фільтрами для кожної руки. Підтверджує це, якщо руки рівні вище за течією та нерівні нижче за течією. Виправлення: фільтруйте детерміновано та ідентично. Автоматизований трафік досяг 53% веб-трафіку у 2026 році, порівняно з 51% у 2024 році (Звіт про поганий бот Imperva, 29 квітня 2026 р.), тому евристичний фільтр, що базується на часі завантаження або поведінці користувацького агента, може виключати з різною швидкістю для кожного варіанта. Втрати, зумовлені згодою, також присутні тут: коли
ad_storageвідхилено, платформа тегів Google припиняє встановлення рекламних файлів cookie (Документація щодо згоди на платформу тегів Google), тому, якщо показники відмов відрізняються в різних географічних регіонах в одному тесті, будь-яке завдання, що спирається на ці ідентифікатори, нерівномірно втрачає користувачів. - Виконання. Симптом: дисбаланс зростає з вагою сторінки, посилюється на мобільних пристроях або починається під час розгортання. Перевірка: розділіть співвідношення за пристроєм, браузером, типом підключення та днем; порівняйте час до експозиції між групами. Підтверджує це, якщо дефіцит зосереджений на повільних сегментах або в одному браузері. Виправлення: саме тут тести переадресації гинуть. Переадресація додає повну навігацію лише до однієї групи, і кожен, хто покидає сторінку під час неї, є вибірковою втратою. Відрендеріть обидва варіанти на стороні сервера за однією URL-адресою або прийміть, що групи не можна порівнювати.
- Назначення. Ознака: співвідношення змінюється з першої години та залишається змінним на постійний коефіцієнт. Перевірка: запустіть алгоритм/аналіз (A/A) для того самого розподілу та переконайтеся, що хеш-сіль не була повторно використана з попереднього експерименту на цій популяції. Підтверджує це, якщо A/A також показує дисбаланс. Виправлення: перепризначте зі свіжою сіллю та перезапустіть. Перенесення з попереднього тесту є тихою версією цього, і лише A/A виявляє його.
- Втручання. Симптом: дисбаланс зосереджений у невеликій кількості ідентифікаторів з високою активністю або у внутрішніх діапазонах 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? Не завжди, але вони несуть структурний ризик, якого немає в жодному іншому дизайні, оскільки додаткова навігація існує лише в одному рукаві. Якщо вам все ж таки потрібно запустити його, перевірте співвідношення за швидкістю з’єднання та пристроєм, перш ніж зчитувати будь-який показник.
Мій трафік занадто низький, щоб чек мав якесь значення. Що тоді? Контролюйте кількість необроблених щоденних експозицій на наявність постійного дрейфу, періодично запускайте A/A на рівні призначення та попередньо реєструйте довший список перевірок на обґрунтованість. Ви замінюєте статистичну потужність процесом.
Фільтрування ботів має відбуватися до чи після завдання? Після реєстрації експозиції, перед аналізом, використання детермінованих правил, що застосовуються однаково до обох рук. Евристична фільтрація всередині 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, Лукас Вермеєр
