परीक्षण को खारिज करने से पहले पांच शाखाओं में नमूना अनुपात बेमेल का निदान करें

परीक्षण को खारिज करने से पहले पांच शाखाओं में नमूना अनुपात बेमेल का निदान करें

माइक्रोसॉफ्ट में लगभग 6% प्रयोगों में नमूना अनुपात बेमेल पाया गया, जो कि एक ऐसे उत्पाद में जहां प्रति वर्ष 10,000 प्रयोग किए जाते हैं, लगभग प्रति दिन एक बेमेल का पता चलता है।फैबिजन एट अल., केडीडी 2019जिन टीमों द्वारा बहुत कम परीक्षण किए जाते हैं, उन्हें शायद ही कभी यह संख्या देखने को मिलती है, क्योंकि उनके प्लेटफ़ॉर्म द्वारा किया जाने वाला परीक्षण उनके ट्रैफ़िक वॉल्यूम पर सार्थक परिणाम नहीं दे पाता। परीक्षण देखने में तो सही लगता है, 4% की वृद्धि दिखाता है, लेकिन फिर भी वह गलत होता है।

यह मार्गदर्शिका उन लोगों के लिए है जो प्रयोग के परिणामों को पढ़ते हैं और यह तय करते हैं कि परीक्षण को आगे भेजा जाए या नहीं। इसके अंत तक आप यह पता लगा पाएंगे कि क्या आपका परीक्षण इतना बड़ा है कि बेमेल जांच का कोई महत्व है, निदान की पांच शाखाओं को उस क्रम में चला पाएंगे जिससे कारण का सबसे तेजी से पता चल सके, और उस असंतुलन को अलग कर पाएंगे जो परिणाम को अमान्य कर देता है, उससे जिसे आप विभाजित करके रख सकते हैं।

एसआरएम अलार्म वास्तव में आपको क्या बताता है

नमूना अनुपात बेमेल का अर्थ है आपके द्वारा निर्धारित विभाजन और प्राप्त विभाजन के बीच का अंतर: आपने 50/50 निर्धारित किया और आपको 50.8/49.2 प्राप्त हुआ। मानक जाँच के लिए एक्सपोज़र गणनाओं पर पियर्सन का ची-स्क्वायर गुडनेस-ऑफ-फिट परीक्षण किया जाता है, जिसमें दो-आर्म परीक्षण के लिए एक डिग्री ऑफ़ फ़्रीडम होती है।

यह इसलिए मायने रखता है क्योंकि उपयोगकर्ताओं को खोने का तंत्र आपके मेट्रिक के संबंध में लगभग कभी भी तटस्थ नहीं होता। यदि रीडायरेक्ट किसी वेरिएंट से धीमे कनेक्शन को हटा देता है, तो बचे हुए उपयोगकर्ता बेहतर कनेक्शन वाले होते हैं, और उनका रूपांतरण बेहतर होता है। डेटा में यह लाभ वास्तविक होता है, लेकिन वास्तविकता में नहीं।

यहां पहली बात जो ज्यादातर टीमें गलत समझती हैं, वह यह है कि कोई उद्योग सीमा नहीं है। प्लेटफॉर्म इस बात से काफी हद तक असहमत हैं।

मंचटेस्टझंडेनोट
एबी स्वादिष्टअनुक्रमिक आवृत्तिवादी (एस-एसआरएम)पी <0.01निरंतर निगरानी के लिए बनाया गया है, इसलिए बार-बार देखने को भी ध्यान में रखा जाता है।
आलीशानची-वर्गपी <0.01"यदि एसआरएम पी-वैल्यू 0.01 से कम है तो हम जोखिमों को असंतुलित मानते हैं।"
ग्रोथबुकची-वर्गपी <0.001इसके ऊपर चेतावनी को दबा दिया गया है
माइक्रोसॉफ्ट (उदाहरण सहित)ची-वर्ग~1 में 500,000बड़े पैमाने पर 50.2/49.8 का विभाजन पहले ही इसे पार कर लेता है।

इसके दो परिणाम होते हैं। एक प्लेटफ़ॉर्म पर त्रुटिपूर्ण पाया गया परीक्षण समान डेटा के साथ दूसरे प्लेटफ़ॉर्म पर सही पाया जाता है, इसलिए "हमारे टूल ने हमें चेतावनी नहीं दी" यह स्पष्ट विभाजन का प्रमाण नहीं है। और 0.01 की सीमा सौ सही परीक्षणों में से एक को त्रुटिपूर्ण मानती है। यदि आप तीन सप्ताह के परीक्षण में प्रतिदिन पी-वैल्यू पर नज़र डालें, तो गलत अलार्म की सामान्य स्वतंत्र-पीक सीमा 19% है; वास्तविक आंकड़ा कम है क्योंकि लगातार दिनों के बीच मजबूत सहसंबंध है, लेकिन यह 1% नहीं है। यही कारण है कि एबी टेस्टी एक अनुक्रमिक प्रक्रिया चलाता है। यदि आपका प्लेटफ़ॉर्म एक निश्चित-क्षितिज ची-स्क्वायर परीक्षण चलाता है, तो अंत में एक बार संचयी गणनाओं पर ध्यान दें।

जाँच करें कि आपका परीक्षण असंतुलन का पता लगा सकता है या नहीं।

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 में लगभग 634,000 व्यवसायों में लगभग 6 बिलियन ई-कॉमर्स लेनदेन दर्ज किए गए।व्यापार मंत्रालय, 12 मई 2026औसतन प्रति वर्ष लगभग 9,500, और यह औसत कुछ चुनिंदा बाज़ारों के कारण काफी बढ़ जाता है। चेकआउट चरण का परीक्षण करने वाली एक मध्यम आकार की दुकान लाखों नहीं, बल्कि दसियों हज़ार ग्राहकों के साथ काम करती है, इसलिए उसका SRM चेक केवल बड़ी खामियों को पकड़ता है, सूक्ष्म खामियों को नहीं।

इतनी अधिक मात्रा में, अलार्म पर भरोसा न करें। प्रतिदिन और प्रत्येक सेगमेंट के लिए कच्चे एक्सपोज़र काउंट स्वयं प्राप्त करें, और लगातार एक ही दिशा में होने वाले बदलाव को संदिग्ध मानें, भले ही पी-वैल्यू सामान्य हो। यदि आप निश्चित नहीं हैं कि आपका प्लेटफ़ॉर्म उन काउंट्स को कहाँ प्रदर्शित करता है, तो एसआरएम चेकर दस्तावेज़ीकरण उन्हें उपकरण के अनुसार मैप करता है।

कारण का सबसे शीघ्र पता लगाने के क्रम में पाँच शाखाएँ।

KDD वर्गीकरण SRM के कारणों को जीवनचक्र के चरणों के अनुसार वर्गीकृत करता है: असाइनमेंट, निष्पादन, लॉग प्रोसेसिंग, विश्लेषण, हस्तक्षेप। इनका निदान एक अलग क्रम में करें, सबसे सस्ते और सबसे आम कारणों से शुरुआत करें।

  1. विश्लेषण और सक्रियण। लक्षण: रॉ एक्सपोज़र लॉग में विभाजन स्पष्ट है, लेकिन स्कोरकार्ड में टूटा हुआ है। जाँच: ट्रिगर स्थिति, दिनांक फ़िल्टर और मीट्रिक-स्तर के जॉइन के बिना अनुपात की पुनः गणना करें। यदि अनुपात अपेक्षा के अनुरूप हो जाता है, तो इसकी पुष्टि करें। समाधान: पात्रता में किसी भी प्रकार-विशिष्ट व्यवहार के परिवर्तन से पहले, दोनों समूहों में समान रूप से ट्रिगरिंग का मूल्यांकन करें। यह सबसे आम गलत चेतावनी है, जिसे दूर करने में दस मिनट का समय लगता है।
  2. लॉग प्रोसेसिंग। लक्षण: दो पाइपलाइनों के बीच एक्सपोज़र गणना भिन्न होती है, या ETL चरण के बाद अंतर दिखाई देता है। जाँच: एक ही विंडो के लिए SDK-साइड गणना, वेयरहाउस गणना और रिपोर्टिंग गणना की तुलना करें, फिर प्रति आर्म बॉट-फ़िल्टर बहिष्करण दरों की तुलना करें। यदि अपस्ट्रीम आर्म बराबर हैं और डाउनस्ट्रीम असमान हैं तो इसकी पुष्टि करें। समाधान: फ़िल्टर को निश्चित और समान रूप से फ़िल्टर करें। स्वचालित ट्रैफ़िक 2026 में वेब ट्रैफ़िक का 53% तक पहुँच गया, जो 2024 में 51% था।इम्परवा बैड बॉट रिपोर्ट, 29 अप्रैल 2026), इसलिए लोड टाइमिंग या यूजर-एजेंट व्यवहार पर आधारित एक ह्यूरिस्टिक फ़िल्टर प्रत्येक वेरिएंट के लिए अलग-अलग दरों पर बहिष्करण कर सकता है। सहमति-आधारित हानि भी यहीं पर लागू होती है: जब ad_storage यदि अनुरोध अस्वीकार कर दिया जाता है, तो Google का टैग प्लेटफ़ॉर्म विज्ञापन कुकीज़ सेट करना बंद कर देता है (गूगल टैग प्लेटफ़ॉर्म सहमति दस्तावेज़इसलिए, यदि किसी एक परीक्षण में भौगोलिक क्षेत्रों में अस्वीकृति दरें भिन्न होती हैं, तो उन पहचानकर्ताओं पर आधारित कोई भी असाइनमेंट उपयोगकर्ताओं को असमान रूप से खो देता है।
  3. निष्पादन। लक्षण: पेज के भार के साथ असंतुलन बढ़ता है, मोबाइल पर स्थिति और खराब हो जाती है, या तैनाती के समय से शुरू हो जाता है। जाँच: अनुपात को डिवाइस, ब्राउज़र, कनेक्शन प्रकार और दिन के अनुसार विभाजित करें; दोनों समूहों के बीच एक्सपोज़र समय की तुलना करें। यदि कमी धीमे सेगमेंट या किसी एक ब्राउज़र में केंद्रित है, तो इसकी पुष्टि हो जाती है। समाधान: यहीं पर रीडायरेक्ट परीक्षण विफल हो जाते हैं। रीडायरेक्ट केवल एक समूह में पूर्ण नेविगेशन जोड़ता है, और इसके दौरान जो भी उपयोगकर्ता सेवा छोड़ देता है, वह चयनात्मक हानि होती है। दोनों विकल्पों को सर्वर-साइड पर एक ही URL पर प्रदर्शित करें, या यह स्वीकार करें कि दोनों समूह तुलनीय नहीं हैं।
  4. असाइनमेंट. लक्षण: अनुपात पहले घंटे से ही गड़बड़ा जाता है और एक स्थिर कारक से गड़बड़ा बना रहता है। जाँच: उसी आवंटन पर एक A/A परीक्षण चलाएँ और सत्यापित करें कि क्या हैश सॉल्ट का उपयोग इस आबादी पर पहले किए गए किसी प्रयोग से दोबारा नहीं किया गया था। यदि A/A परीक्षण में भी असंतुलन दिखाई देता है, तो इसकी पुष्टि हो जाती है। समाधान: एक नए सॉल्ट के साथ पुनः आवंटन करें और पुनः आरंभ करें। पिछले परीक्षण से बचा हुआ प्रभाव इसका छिपा हुआ रूप है, और केवल A/A परीक्षण ही इसे उजागर करता है।
  5. दखल अंदाजी। लक्षण: असंतुलन कुछ ही उच्च-गतिविधि वाले पहचानकर्ताओं या आंतरिक आईपी श्रेणियों में केंद्रित है। जाँच: प्रति उपयोगकर्ता एक्सपोज़र गणना वितरण और घटना मात्रा के आधार पर शीर्ष 1% पहचानकर्ताओं की जाँच करें। यदि इन्हें हटाने से अनुपात बहाल हो जाता है, तो इसकी पुष्टि करें। समाधान: आंतरिक और स्क्रिप्टेड ट्रैफ़िक को मैन्युअल रूप से नहीं, बल्कि दस्तावेजित नियम द्वारा बाहर रखें, ताकि अगली बार बहिष्करण समान हो।

एक विस्तृत प्रक्रिया

नीचे दिए गए आंकड़े केवल उदाहरण के लिए हैं, ग्राहक डेटा नहीं। चेकआउट परीक्षण में 61,480 नियंत्रण और 58,520 वेरिएंट एक्सपोज़र रिपोर्ट किए गए: 120,000 उपयोगकर्ताओं पर 51.2/48.8, ची-स्क्वायर p 0.001 से कम। शाखा 1: ट्रिगर स्थिति को हटाने पर 60,020/59,980 परिणाम प्राप्त होते हैं, इसलिए असाइनमेंट ठीक है और एक्सपोज़र के बाद नुकसान होता है। शाखा 2: पाइपलाइन गणनाएँ मेल खाती हैं, दोनों शाखाओं में बॉट बहिष्करण 0.9% है। शाखा 3: डेस्कटॉप पर 50.1/49.9, मोबाइल पर 52.4/47.6 है, और वेरिएंट का औसत एक्सपोज़र समय मोबाइल पर 900 मिलीसेकंड अधिक है। निदान: वेरिएंट एक अतिरिक्त रेंडर-अवरोधक अनुरोध भेजता है, मोबाइल उपयोगकर्ता इसके दौरान छोड़ देते हैं, बचे हुए उपयोगकर्ताओं का कनेक्शन बेहतर होता है। परिणाम अमान्य है। समाधान प्रदर्शन में सुधार है, और परीक्षण को पुनः चलाया जाता है, पुनर्व्याख्या नहीं की जाती।

आप क्या बचा सकते हैं और क्या नहीं

  • रीडआउट को रद्द करें जब हानि तंत्र मीट्रिक के साथ संभावित रूप से सहसंबंध स्थापित कर सकता है। निष्पादन और असाइनमेंट का प्रत्येक कारण डिफ़ॉल्ट रूप से योग्य माना जाता है।
  • खंड के अनुसार बचाव असंतुलन केवल तभी लागू होता है जब वह किसी ऐसे खंड तक सीमित हो जिसे आप स्पष्ट रूप से बाहर कर सकते हैं, वह खंड मीट्रिक को देखने से पहले परिभाषित किया गया हो, और शेष भाग अपनी SRM जांच को पास कर ले। इनमें से दो पर्याप्त नहीं हैं।
  • परीक्षण जारी रखें जब कारण पूरी तरह से विश्लेषण में निहित था और संशोधित स्कोरकार्ड पास हो गया। आप एक निश्चित फ़िल्टर के साथ उसी डेटा को दोबारा पढ़ रहे हैं, न कि अनावश्यक डेटा की खोज कर रहे हैं।
  • इसे दोनों ही स्थितियों में दर्ज करें। प्रयोग पर कारण श्रेणी दर्ज करें। वर्गीकरण का लाभ संचयी रूप से मिलता है: यदि आपके पिछले दस परीक्षणों में से तीन शाखा 3 में विफल रहे, तो आपकी समस्या प्रयोग में नहीं, बल्कि फ्रंट-एंड डिलीवरी में है। [आंतरिक डेटा की आवश्यकता: पिछले 24 महीनों में स्विटास द्वारा संचालित प्रयोगों का वह हिस्सा जो एसआरएम जांच में विफल रहा, वर्गीकरण शाखा के अनुसार विभाजित, ताकि माइक्रोसॉफ्ट के 6% बेंचमार्क को इस बाजार के आंकड़े से बदला जा सके]

जहां यह टूट जाता है

यह ट्री एक निश्चित, ज्ञात आवंटन और उपयोगकर्ता-स्तर के यादृच्छिकीकरण के साथ दो-आर्म परीक्षण को मानता है। यह बहु-आर्म परीक्षणों को कवर नहीं करता है, जिनके लिए सभी आर्म्स में पूर्ण ची-स्क्वायर की आवश्यकता होती है, साथ ही यह पता लगाने के लिए अनुवर्ती विश्लेषण की भी आवश्यकता होती है कि कौन सा जोड़ा गलत है, या रैम्प्ड आवंटन, जहां अपेक्षित अनुपात परीक्षण के दौरान बदलता रहता है और संचयी ची-स्क्वायर एक गलत परीक्षण है। यह क्लस्टर या भू-यादृच्छिक डिज़ाइनों पर लागू नहीं होता है, जहां इकाई उपयोगकर्ता नहीं है और महत्वपूर्ण असंतुलन क्लस्टर विशेषताओं में है। यह इस बारे में कुछ नहीं कहता कि आपकी मीट्रिक परिभाषा सही है या नहीं। और यह तब भी मददगार नहीं है जब एक्सपोज़र लॉग नहीं किए गए हों और आप किसी मीट्रिक घटना से असाइनमेंट का अनुमान लगा रहे हों, जो कि एक स्प्लिट चेक नहीं बल्कि एक अनुमान है।

सामान्य प्रश्न

क्या 51/49 का अनुपात हमेशा समस्या पैदा करता है? यह पूरी तरह n पर निर्भर करता है। 5,000 एक्सपोज़र पर यह सामान्य शोर है; 500,000 पर यह लगभग निश्चित दोष है। अनुपात का आकलन पता लगाने की क्षमता तालिका के आधार पर करें, न कि किसी निश्चित प्रतिशत नियम के आधार पर।

क्या मैं दोबारा रन करने के बजाय सांख्यिकीय रूप से हथियारों का भार बदल सकता हूँ? नहीं। रीवेटिंग से गणनाओं में सुधार होता है और चयन अपरिवर्तित रहता है। जो उपयोगकर्ता आपने खो दिए हैं, वे जा चुके हैं, और वे समूह के यादृच्छिक नमूने नहीं थे।

मुझे एसआरएम पी-वैल्यू को कितनी बार देखना चाहिए? अंत में, संचयी गणनाओं के आधार पर, जब तक कि आपका प्लेटफ़ॉर्म एक अनुक्रमिक प्रक्रिया नहीं चलाता है। एक निश्चित समयावधि वाले ची-स्क्वायर पर प्रतिदिन नज़र डालने से गलत अलार्म की संख्या काफी बढ़ जाती है।

क्या एसआरएम गार्डरेल मेट्रिक्स को भी अमान्य कर देता है? हाँ, उसी कारण से। यदि हथियारों में अलग-अलग आबादी है, तो एक सपाट सुरक्षा रेलिंग गतिशील प्राथमिक मीट्रिक की तुलना में अधिक भरोसेमंद नहीं है।

यदि A/A परीक्षण में भी बेमेल पाया जाए तो क्या होगा? तो गलती असाइनमेंट या लॉगिंग पाइपलाइन में है, न कि आपके ट्रीटमेंट में। कुछ भी चलाने से पहले इसे ठीक करें, क्योंकि यह उस प्लेटफॉर्म पर चल रहे हर टेस्ट को प्रभावित कर रहा है।

क्या रीडायरेक्ट टेस्ट हमेशा एसआरएम का कारण बनते हैं? हमेशा नहीं, लेकिन इनमें एक ऐसा संरचनात्मक जोखिम होता है जो किसी अन्य डिज़ाइन में नहीं होता, क्योंकि अतिरिक्त नेविगेशन केवल एक ही भुजा में होता है। यदि आपको इसे चलाना ही है, तो किसी भी मीट्रिक को पढ़ने से पहले कनेक्शन गति और डिवाइस के आधार पर अनुपात की जांच कर लें।

मेरे ट्रैफिक इतना कम है कि चेक का कोई मतलब ही नहीं है। तो फिर क्या करें? निरंतर विचलन के लिए दैनिक एक्सपोज़र गणनाओं की निगरानी करें, असाइनमेंट लेयर पर आवधिक तुलनात्मक विश्लेषण (A/A) चलाएं, और सटीकता जांचों की एक लंबी सूची को पहले से पंजीकृत करें। आप सांख्यिकीय शक्ति के स्थान पर प्रक्रिया का उपयोग कर रहे हैं।

क्या बॉट फ़िल्टरिंग असाइनमेंट से पहले होनी चाहिए या बाद में? एक्सपोज़र लॉगिंग के बाद, विश्लेषण से पहले, दोनों भुजाओं पर समान रूप से लागू किए गए नियतात्मक नियमों का उपयोग किया जाता है। SDK के भीतर ह्यूरिस्टिक फ़िल्टरिंग ही वह तरीका है जिससे फ़िल्टर स्वयं बेमेल का कारण बनता है।

अपने स्वयं के प्रयोग कार्यक्रम पर जांच चलाएं

यदि आप अपने द्वारा चलाए जा रहे परीक्षणों के स्वास्थ्य की स्थिति पर किसी दूसरे व्यक्ति की राय लेना चाहते हैं, या उन सभी परीक्षणों के असाइनमेंट और लॉगिंग लेयर की समीक्षा करना चाहते हैं जिन पर वे निर्भर करते हैं, तो यही हमारी सेवा है। सीआरओ और प्रयोग सेवा करता है.

सूत्रों का कहना है


संबंधित आलेख

स्विटास जैसा कि देखा गया

मैग्नीफाई: इंगिन युर्टडाकुल के साथ इन्फ्लुएंसर मार्केटिंग का विस्तार

हमारी माइक्रोसॉफ्ट क्लैरिटी केस स्टडी देखें

हमने Microsoft Clarity को एक ऐसे उत्पाद के रूप में प्रस्तुत किया है जिसे व्यावहारिक, वास्तविक उपयोग के मामलों को ध्यान में रखते हुए उन वास्तविक उत्पाद विशेषज्ञों द्वारा बनाया गया है जो Switas जैसी कंपनियों के सामने आने वाली चुनौतियों को समझते हैं। रेज क्लिक्स और जावास्क्रिप्ट त्रुटि ट्रैकिंग जैसी सुविधाएँ उपयोगकर्ता की परेशानियों और तकनीकी समस्याओं की पहचान करने में अमूल्य साबित हुईं, जिससे लक्षित सुधार संभव हुए जिन्होंने उपयोगकर्ता अनुभव और रूपांतरण दरों पर सीधा प्रभाव डाला।