ए / बी परीक्षण में क्या गलत है

हमने हेब्रा के पाठकों के लिए हैरी के विश्लेषण के पूर्व निदेशक माइकल कमिंस्की के एक लेख का अनुवाद तैयार किया है। वह ए / बी परीक्षण के बारे में क्या गलत है के बारे में बात करता है। स्काईेंग में एनालिटिक्स के निदेशक ग्लीब कोलोग द्वारा सामग्री पर टिप्पणियाँ।

ए / बी परीक्षण की अवधारणा मौलिक रूप से गलत धारणा पर आधारित है कि एक एकल समाधान है जो सभी ग्राहकों के लिए औसतन बेहतर है। विश्लेषकों को यह धारणा छोड़ देनी चाहिए कि उनके दर्शक सजातीय हैं और उन प्रणालियों को विकसित करना शुरू करते हैं जो द्विआधारी के अलावा अन्य परीक्षणों के परिणामों के उपयोग (और प्रोत्साहित) की अनुमति देते हैं।

पिछले कुछ हफ्तों में, ए / बी परीक्षणों की गैर-मानक व्याख्याओं पर दो बहुत ही रोचक लेख प्रकाशित हुए हैं। उबेर इंजीनियरिंग ब्लॉग के लेखों में से एक क्वांटाइल्स द्वारा प्रभाव के प्रभाव की गणना के बारे में है, और दूसरा ( लगातार उत्कृष्ट स्टिचफिक्स डेटा साइंस ब्लॉग से ) निजीकरण को प्राप्त करने के लिए प्रासंगिक दस्यु एल्गोरिदम का उपयोग करने के बारे में है।

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

पारंपरिक ए / बी परीक्षण मौलिक रूप से गलत धारणा पर आधारित है। ज्यादातर मामलों में, विकल्प ए कुछ उपसमूहों के लिए बेहतर होगा, और दूसरों के लिए विकल्प बी। A या B चुनना शुरू में A और B का सावधानीपूर्वक चयनित संयोजन खो देता है।

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

प्रेरक उदाहरण

आपको यह समझाने के लिए कि यह महत्वपूर्ण है, आइए एक छोटा उदाहरण देखें। हालांकि ये आंकड़े काल्पनिक हैं, वे पूरी तरह से प्रतिनिधित्व करते हैं कि मैंने ए / बी परीक्षणों के वास्तविक समय के मूल्यांकन में अनगिनत बार क्या देखा है।

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

टीम परीक्षण शुरू करती है और निम्नलिखित परिणाम प्राप्त करती है:

धिक्कार है, कोई फर्क नहीं! सहज रूप से, आप अपने मोबाइल और पीसी पर ट्रैफ़िक साझा करने का निर्णय लेते हैं।

वाह! नया संस्करण ... वास्तव में डिजाइनरों ने क्या उम्मीद की थी! मोबाइल डिवाइस उपयोगकर्ताओं के लिए स्थिति बेहतर हो गई है और पीसी उपयोगकर्ताओं के लिए बदतर हो गई है।

यह बुरा है कि हमारे ए / बी परीक्षण ने कोई प्रभाव नहीं दिखाया। शायद हमें अपने डिजाइनरों को ऑर्डर फॉर्म के नए संस्करण के बारे में सोचने के लिए भेजना चाहिए।

लेकिन रुकिए! क्या होगा यदि हम उन उपयोगकर्ताओं के लिए एक अनुकूलित मोबाइल संस्करण का समर्थन करते हैं जो टेलीफोन के माध्यम से साइट का उपयोग करते हैं? और डेस्कटॉप कंप्यूटर पर उपयोगकर्ताओं के लिए अनुकूलित डेस्कटॉप संस्करण? क्या होगा यदि हमने एक लैंडिंग पृष्ठ बनाया है जो लोगों के पढ़ने के लिए अधिक समय होने पर सप्ताहांत पर बेहतर काम करेगा? क्या होगा अगर हमने मैसाचुसेट्स के बजाय कैलिफोर्निया में बेहतर काम करने वाला विज्ञापन बनाया?

क्या होगा यदि वेबपेज एक ही बार में सभी के अनुरूप न हो?

कार्य

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

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

ग्राहकों और उपयोगकर्ताओं की सभी विविधता को कवर करने के लिए, सॉफ्टवेयर समाधान को मौलिक रूप से अलग तरीके से विकसित करना आवश्यक है। हमें नए और अधिक उन्नत उपकरणों की आवश्यकता है, और हमें एक नए तरीके से हितधारकों को प्रशिक्षित करने की भी आवश्यकता है।

आज, इतने सारे चर के साथ उपयोग परिदृश्यों को प्रबंधित करने की कोशिश करना बहुत मुश्किल है (यदि संभव हो तो)। चूंकि बहुत सारे विकल्प प्रबंधित करना महंगा है, कई कंपनियां अपने ग्राहक अनुभव को निजीकृत करने की कोशिश भी नहीं करती हैं। आगे, मैं समस्याओं और उन्हें हल करने के तरीकों के बारे में अधिक बात करूंगा।

प्रोग्रामिंग उपकरण

हमारी बहादुर नई दुनिया में, जहाँ हम विभिन्न श्रेणियों के उपयोगकर्ताओं को विभिन्न प्रकार की सामग्री प्रदान करते हैं (अनुपात में जो समय के साथ बदल सकते हैं), हमें अपने सॉफ़्टवेयर के विकास और विश्लेषण दोनों के लिए उपकरणों की आवश्यकता होती है।

ऐसा लगता है कि इस तरह के प्रतिमान का उपयोग करने का सबसे स्पष्ट परिणाम परियोजना में कोड की मात्रा में महत्वपूर्ण वृद्धि होगी। परीक्षण के बाद अप्रचलित कोड शाखाओं को हटाने के बजाय, हमें उनका समर्थन करना होगा (शायद हमेशा के लिए)। यह भयानक है!

वास्तव में, हमें अनुप्रयोगों को अधिक मॉड्यूलर बनाने की आवश्यकता है ताकि हम नई कोड शाखाओं को विकसित, परीक्षण, तैनात और बनाए रख सकें (उदाहरण के लिए, परीक्षण के लिए नए संस्करण)।

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

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

संचार और प्रशिक्षण

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

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

सांख्यिकीय उपकरण

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

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

निष्कर्ष

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

लेखक का ध्यान दें:
मैं सादगी के लिए आत्मविश्वास अंतराल और सांख्यिकीय महत्व की सभी चर्चाओं को बाहर करता हूं। मैं माफी चाहता हूँ।

स्काईेंग में एनालिटिक्स के निदेशक ग्लीब कोलोग से टिप्पणी

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

अब तक, हमने सीखा है कि कैसे दो तरीकों से वैयक्तिकृत किया जा सकता है: पहला, उपयोगकर्ताओं के विभिन्न क्षेत्रों के लिए अलग-अलग परिदृश्य बनाकर, दूसरा, फ़नल के व्यक्तिगत चरणों में व्यक्तिगत सामग्री प्रदर्शित करने के लिए एल्गोरिथम समाधान विकसित करके।

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

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

हालांकि, यह सब पुराने विकास के तरीकों और एनालिटिक्स का उपयोग जारी रखते हुए किया जा सकता है।

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

हम स्काईेंग में पहले से ही हैं और शोधकर्ताओं और विश्लेषकों की एक टीम का विस्तार कर रहे हैं जो इन रुझानों का अध्ययन कर रहे हैं और हमारे उत्पादों को बेहतर बनाने के लिए उन्हें लागू करने की कोशिश कर रहे हैं।