Диагностицирайте несъответствие на съотношението на извадките в пет клона, преди да изхвърлите теста

Около 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 пункта е повече от достатъчен, за да се получи малък ръст на конверсията. Това е структурният проблем в по-голямата част от региона. Турция е регистрирала около 6 милиарда транзакции в електронната търговия в приблизително 634 000 бизнеса през 2025 г. (Министерство на търговията, 12 май 2026 г.), средно близо 9,500 годишно всяка, и тази средна стойност е силно надвишена от шепа пазари. Магазин от среден клас, който тества стъпка на плащане, работи с десетки хиляди експозиции, а не с милиони, така че неговата SRM проверка улавя груби повреди и нищо по-фини.

При този обем не разчитайте на алармата. Изтеглете сами суровите данни за експозиции по ден и по сегмент и третирайте постоянното отклонение в една и съща посока като подозрително, дори когато p-стойността е незабележима. Ако не сте сигурни къде вашата платформа излага тези данни, Документация за SRM Checker картографира ги за всеки инструмент.

Петте клона, в реда, в който най-бързо се открива причината

Таксономията на KDD сортира причините за SRM по етап от жизнения цикъл: присвояване, изпълнение, обработка на лог файлове, анализ, смущения. Диагностицирайте ги в различен ред, като първо се подредят най-евтините и най-често срещаните.

1. Анализ и задействане. Симптом: разделянето е чисто в дневника на суровата експозиция и е нарушено в картата с резултати. Проверка: преизчислете съотношението без условието за задействане, филтъра за дата и съединенията на ниво метрика. Потвърждава го, ако съотношението се върне към очакваното. Корекция: оценете задействането идентично и в двете групи, преди специфично за варианта поведение да може да промени допустимостта. Най-често срещаната фалшива тревога, десет минути за изключване.
2. Обработка на дневници. Симптом: броят на експозициите се различава между два конвейера или разликата се появява след стъпката ETL. Проверка: сравнете броя от страната на SDK, броя от хранилището и броя на отчетите за един и същ прозорец, след което сравнете процентите на изключване от бот филтър за всяка ръка. Потвърждава се, ако ръкавите са равни нагоре по веригата и неравномерни надолу по веригата. Корекция: филтрирайте детерминистично и идентично. Автоматизираният трафик достигна 53% от уеб трафика през 2026 г., в сравнение с 51% през 2024 г.Доклад за лош бот на Imperva, 29 април 2026 г.), така че евристичен филтър, насочен към времето за зареждане или поведението на потребителския агент, може да изключва с различна честота за всеки вариант. Загубата, обусловена от съгласие, също е тук: когато ad_storage е отказано, платформата за тагове на Google спира да задава рекламни бисквитки (Документи за съгласие за платформата Google Tag), така че ако процентите на откази се различават в различните географски области в един тест, всяко задание, основаващо се на тези идентификатори, губи потребители неравномерно.
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 ms по-високо на мобилни устройства. Диагноза: вариантът изпраща допълнителна заявка за блокиране на рендерирането, мобилните потребители изоставят по време на нея, оцелелите имат по-добри връзки. Отчитането е невалидно. Корекцията е корекция на производителността и тестът се изпълнява отново, а не се интерпретира отново.

Какво можете да спасите и какво не можете

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

Къде се разпада това

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

Често задавани въпроси

Разделянето 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, Лукас Вермеер