नमूना अनुपात बेमेल (एसआरएम)

सैंपल रेश्यो मिसमैच (SRM) तब होता है जब प्रयोग के विभिन्न रूपों के बीच ट्रैफ़िक का वास्तविक विभाजन, इच्छित विभाजन से इतना अधिक भिन्न होता है कि उसे यादृच्छिक भिन्नता से स्पष्ट नहीं किया जा सकता। एक परीक्षण जिसे 50/50 के समान विभाजन के लिए कॉन्फ़िगर किया गया है और जो नियंत्रण समूह को 51,200 आगंतुक और दूसरे रूप को 48,800 आगंतुक देता है, वह महज़ एक संयोग नहीं है; इतनी अधिक संख्या में, इतने बड़े अंतर का होना, सही यादृच्छिकीकरण के तहत सांख्यिकीय रूप से असंभव है। SRM का पता अपेक्षित आवंटन के विरुद्ध ची-स्क्वायर परीक्षण द्वारा लगाया जाता है, और जब तक इसका कारण पता नहीं चल जाता, तब तक इसे दर्शाने वाले किसी भी परीक्षण को अमान्य माना जाना चाहिए।

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

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

सही तरीका यह है कि टेस्ट को रोक दिया जाए, कारण का पता लगाया जाए, उसे ठीक किया जाए और फिर से शुरू किया जाए। SRM से प्रभावित टेस्ट को बचाने के लिए समूहों का पुनर्भार तय करना या किसी उपसमूह का विश्लेषण करना शायद ही कभी उचित होता है, क्योंकि गायब या गलत तरीके से आवंटित ट्रैफ़िक यादृच्छिक रूप से गायब नहीं होता है। तीन सप्ताह का ट्रैफ़िक इस्तेमाल कर चुके टेस्ट को बचाने की प्रवृत्ति प्रबल होती है, खासकर जब ऐसा लगता है कि इससे सफलता मिल रही है, लेकिन गलत रैंडमाइजेशन से प्राप्त परिणाम का कोई प्रमाणिक मूल्य नहीं होता और इसके आधार पर टेस्ट जारी करना, टेस्ट न करने से भी बदतर है।

क्योंकि SRM तब तक अदृश्य रहता है जब तक कोई इसकी जाँच न करे, इसलिए इसकी जाँच स्वचालित होनी चाहिए। उन्नत प्रोग्राम मानक विश्लेषण प्रक्रिया के हिस्से के रूप में प्रत्येक प्रयोग पर SRM परीक्षण करते हैं, एक निश्चित सीमा से अधिक किसी भी विचलन को चिह्नित करते हैं, और जब तक यह चिह्नित त्रुटि दूर नहीं हो जाती तब तक परिणाम प्रकाशित करने से इनकार करते हैं। पिछले प्रयोगों के पूर्वव्यापी ऑडिट में अक्सर ऐतिहासिक परीक्षणों का एक महत्वपूर्ण हिस्सा प्रभावित पाया जाता है, जो किसी परीक्षण प्रोग्राम के लिए सबसे असहज खोजों में से एक है, और साथ ही सबसे मूल्यवान भी, क्योंकि यह बताता है कि अतीत में प्राप्त कुछ सफलताएँ व्यावसायिक परिणामों में क्यों नहीं बदल पाईं।

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

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