एक उत्पाद स्वामी के रूप में, इस सवाल का सामना करना आम है कि विकल्प ए या विकल्प बी के साथ आगे बढ़ना है या बेहतर परिणाम प्राप्त करने के लिए स्क्रीन के किस संस्करण को लागू किया जाना चाहिए? इस तरह के निर्णय लेना चुनौतीपूर्ण हो सकता है, खासकर जब आप सीमित संसाधनों के साथ तंग समय सीमा के अंतर्गत हों। इसके अलावा, इस तरह के निर्णय व्यक्तिगत निर्णय या प्रतिस्पर्धी के दृष्टिकोण की नकल के आधार पर किए जाते हैं, जिससे उप-इष्टतम परिणाम हो सकते हैं।
अच्छी खबर यह है कि एक साधारण प्रयोग वातावरण स्थापित करके इस तरह के नुकसान से बचा जा सकता है जिसके लिए अपेक्षाकृत कम प्रयास की आवश्यकता होती है। इस लेख में, हम वर्णन करेंगे कि आप इसे कैसे प्राप्त कर सकते हैं।
प्रयोग परिवेश की स्थापना दो कारणों से महत्वपूर्ण है:
सबसे पहले, यह आपको यह सुनिश्चित करने की अनुमति देता है कि एक बार जब आप नई कार्यक्षमता लागू करते हैं, तो आप डेटा-संचालित दृष्टिकोण के आधार पर सबसे अच्छा विकल्प चुनते हैं।
दूसरे, यह आपको 'जैसा है' की काल्पनिक 'टू-बी' विकल्पों से तुलना करके और 'क्या होगा अगर' विश्लेषण करके अपने उत्पाद की मौजूदा कार्यक्षमता में लगातार सुधार करने की अनुमति देता है।
इससे पहले कि हम दृष्टिकोण पर आगे बढ़ें, आइए कुछ ऐसे मिथकों को दूर करें जो आमतौर पर उत्पाद मालिकों को गुमराह करते हैं:
मुझे एक जटिल वातावरण स्थापित करने के लिए बहुत सारे संसाधनों की आवश्यकता है जो प्रयोग और ए/बी परीक्षण करने की अनुमति देता है
गलत : वर्णित दृष्टिकोण में आपके सॉफ़्टवेयर इंजीनियर के संसाधनों का एक सप्ताह से भी कम समय लगता है।
मुझे एक अच्छी तरह से स्थापित डेटा एकत्र करने की प्रक्रिया और विस्तृत घटना ट्रैकिंग की आवश्यकता है
गलत : आप मौजूदा डेटाबेस पर भरोसा कर सकते हैं जो आपके उत्पाद की मुख्य इकाई के जीवनचक्र के बारे में जानकारी संग्रहीत करता है। उदाहरण के लिए, यदि आप डिलीवरी सेवा हैं तो ऑर्डर की स्थिति।
मुझे विश्लेषकों की एक समर्पित टीम की आवश्यकता है जो दैनिक आधार पर मेरे अनुरोधों को संभाल सके
गलत : एक बार जब आप अपने प्रयोग के दृष्टिकोण और मेट्रिक्स को समझ जाते हैं, तो आप एक साधारण SQL क्वेरी का उपयोग करके नियमित रूप से डेटा प्राप्त कर सकते हैं।
अपने प्रयोग के माहौल को स्थापित करने के लिए, इन चरणों का पालन करने की सलाह दी जाती है:
इससे पहले कि आप अपने उत्पाद डिज़ाइनर से संपर्क करें, अपने प्रयोग के भाग के रूप में मापे जाने वाले लक्ष्यों और मीट्रिक को परिभाषित करें। क्लासिक 'विकल्प ए या विकल्प बी' प्रश्न के मामले में, आमतौर पर यह स्पष्ट होता है कि आप किसी बदलाव को लागू करके क्या हासिल करना चाहते हैं। उदाहरण के लिए, हो सकता है कि आप फ़नल के किसी विशिष्ट भाग को संबोधित कर रहे हों।
व्याख्यात्मक उद्देश्यों के लिए मान लें कि आप एक डिलीवरी कंपनी में काम कर रहे हैं और वर्तमान में ऑर्डर निर्माण फॉर्म पर ध्यान केंद्रित कर रहे हैं। आप अपेक्षाकृत कम प्रतिशत उपयोगकर्ताओं को संबोधित करना चाहते हैं जो अपना शिपिंग पता प्रदान करते हैं और फिर शिपिंग विधि का चयन करते हैं। साथ ही, कल्पना करें कि आपके पास यात्रा के दो नए संस्करण हैं:
वर्तमान संस्करण : एक स्क्रीन पर पतों को इनपुट करने और प्रदान किए गए पते के आधार पर पिन के साथ मानचित्र दिखाने की आवश्यकता होती है। अगली स्क्रीन प्रदान किए गए पते के आधार पर शिपिंग विधि का चयन करने की अनुमति देती है।
नया संस्करण : सिंगल स्क्रीन के लिए इनपुट पता और वहां शिपिंग विधि का चयन करने की आवश्यकता होती है।
लक्ष्य यह निर्धारित करना है कि कौन से विकल्प उपयोगकर्ताओं के उच्च हिस्से की ओर ले जाते हैं जिन्होंने अपना पता प्रदान किया और शिपिंग विधि का चयन किया। मेट्रिक्स बल्कि सीधे हैं: % उपयोगकर्ता जिन्होंने अपना पता प्रदान किया और शिपिंग विधि का चयन किया।
वास्तव में, ऐसे डेटा को मापने के 2 तरीके हैं :
आपके बैकएंड के डिज़ाइन द्वारा पहले से उपलब्ध डेटा के आधार पर। उदाहरण के लिए, एक डेटाबेस पर विचार करें जिसमें ऑर्डर के जीवनचक्र के बारे में जानकारी है। आपके आदेश में निम्न स्थितियाँ या स्थितियाँ हो सकती हैं:
ड्राफ्ट बनाया गया
शिपिंग विधियों को खोजने का प्रयास करें
शिपिंग विकल्प मिले / शिपिंग विकल्प नहीं मिले
ईवेंट ट्रैकिंग - यह कुछ ऐसा नहीं है जो लीक से हटकर काम करेगा और इसलिए इसे लागू करने के लिए अतिरिक्त प्रयास की आवश्यकता है। हालाँकि, ईवेंट ट्रैकिंग आपके लिए अधिक विस्तृत विश्लेषण को सक्षम करेगी, उदाहरण के लिए डिवाइस का प्रकार और ब्राउज़र का नाम आपके ईवेंट के पैरामीटर के रूप में पारित किया जा सकता है।
इस लेख के अगले खंडों में, हम पहले दृष्टिकोण पर ध्यान केंद्रित करेंगे, यानी बिना इवेंट ट्रैकिंग के मौजूदा डेटा आर्किटेक्चर।
प्रयोग प्रवाह के भीतर 2 मुख्य चरण पूरे किए जाने चाहिए:
विचार एक हल्के ए/बी परीक्षण ढांचे के साथ आने का है जो जितना संभव हो उतना सरल होना चाहिए और आपको निम्नलिखित मापदंडों के साथ प्रयोग करने की अनुमति देनी चाहिए:
इन मापदंडों को कॉन्फ़िगर करने में सक्षम होने से आप एक नमूना सीमा निर्धारित कर सकते हैं और वांछित नमूना आकार तक पहुंचने तक बेतरतीब ढंग से प्रयोग के लिए उम्मीदवारों को चुन सकते हैं।
क्लाइंट और सर्वर दोनों को इसके लिए परिवर्तन की आवश्यकता है: सर्वर को प्रति प्रयोग उम्मीदवारों की संख्या को ट्रैक करना चाहिए और बैकएंड तय करेगा कि वर्तमान उपयोगकर्ता को प्रयोग का हिस्सा होना चाहिए या नहीं। बैकएंड तय करेगा कि प्रमाणित उपयोगकर्ता को वर्तमान नमूना आकार और एक निश्चित संभावना के आधार पर प्रयोग का हिस्सा होना चाहिए या नहीं। इसके अलावा, बैकएंड को उपयोगकर्ताओं का एक संग्रह बनाए रखना चाहिए जो उपयोगकर्ताओं को लगातार अनुभव प्रदान करने और प्रयोग के परिणामों की ठीक से गणना करने के लिए दिए गए प्रयोग का हिस्सा हैं।
प्रयोग के विन्यास के लिए समापन बिंदु ऐसा दिखाई दे सकता है:
पोस्ट /api/your-service/experiment-create
अनुरोध:
{ experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}
जवाब:
{
200,
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
आपको एक अलग समापन बिंदु की आवश्यकता होगी जो एक विशिष्ट उपयोगकर्ता को प्रयोग और संबंधित समूह को निर्दिष्ट करने के लिए जिम्मेदार होगा। आइए इसे experiment-enrollments
कहते हैं।
पूरे वातावरण को डिजाइन करते समय आपको स्पष्ट समझ होनी चाहिए कि उपयोगकर्ता यात्रा experiment-enrollments
समापन बिंदु के किस चरण पर कॉल किया जाना चाहिए। इसके अलावा, यह मामला हो सकता है कि सभी उपयोगकर्ता प्रयोग में भाग न लें। यही कारण है कि उपयोगकर्ता-प्रमाणीकरण टोकन को समापन बिंदु में भी प्रदान करना उपयोगी होगा।
हमारे उदाहरण में, यदि हम केवल नए उपयोगकर्ताओं पर ध्यान केंद्रित करना चाहते हैं जो अपना पहला ऑर्डर कर रहे हैं, तो उपयोगकर्ता-प्रमाणीकरण हमें यह निर्धारित करने की अनुमति देगा कि यह किस प्रकार का उपयोगकर्ता है और क्या किसी को प्रयोग में नामांकित किया जाना चाहिए। साथ ही, सुनिश्चित करें कि समापन बिंदु पर कॉल करने के बाद सभी आवश्यक जानकारी उपलब्ध है और आपकी यात्रा और जीवनचक्र की बारीकियों पर विचार करता है।
experiment-enrollments
समापन बिंदु नीचे वर्णित है। इसे विशिष्ट प्रकार के उपयोगकर्ताओं (जैसे केवल नए उपयोगकर्ता जिन्होंने अभी तक पता प्रदान नहीं किया है) के लिए यात्रा के एक विशिष्ट चरण में (उदाहरण के लिए शिपिंग पते की आवश्यकता वाले स्क्रीन पर उतरने से पहले) कॉल किया जा सकता है और यह गणना करेगा कि वर्तमान उपयोगकर्ता को भाग लेना चाहिए या नहीं किसी दिए गए प्रयोग में या नहीं:
पोस्ट /api/your-service/experiment-enrollments
, उपयोगकर्ता-प्रमाणीकरण टोकन आवश्यक है
अनुरोध:
\ {
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
जवाब:
{200, enrolled: true/false, group_name: group_1,}
यह समझाने के लिए कि सैद्धांतिक डेटा प्रवाह कैसा दिखेगा, वितरण कंपनी में ऑर्डर निर्माण प्रवाह का एक ही उदाहरण मान लें। आप ऑर्डर क्रिएशन स्क्रीन के 2 विकल्पों में से चयन कर रहे हैं।
नीचे दिए गए आरेख में निम्नलिखित समापन बिंदुओं का उल्लेख किया गया है, अर्थात:
/ क्रिएट-ऑर्डर-ड्राफ्ट (चरण 3)
/ खोज-शिपिंग-विधि (चरण 16)
/ सबमिट-ऑर्डर (चरण 20)
व्याख्यात्मक उदाहरण का समर्थन करने के लिए प्रदान किए जाते हैं और प्रयोग पर्यावरण के आवश्यक भाग नहीं हैं
इसके अलावा, डेटाबेस का उदाहरण और सरलीकृत आर्किटेक्चर नीचे दिया गया है।
3 मुख्य तालिकाएँ हैं:
Experiments set
- इसमें आपके द्वारा पहले बनाए गए सभी प्रयोग शामिल हैं। हर बार जब आप /experiment-create
समापन बिंदु को कॉल करते हैं तो डेटाबेस अपडेट किया जाता है।
Experiments database
- इसमें किसी विशिष्ट उपयोगकर्ता के प्रत्येक नामांकन से जुड़े सभी रिकॉर्ड होते हैं। हर बार जब आप experiment-enrollments
समापन बिंदु को कॉल करते हैं तो डेटाबेस अपडेट हो जाता है
Order lifecycle database
- यह प्रयोग से संबंधित डेटा को कैसे संग्रहीत किया जा सकता है, इसके सचित्र उदाहरण का समर्थन करने के लिए प्रदान किया गया है। मुद्दा यह है कि यह तालिका (या कोई भी समान तालिका जो आपके उत्पाद की बारीकियों से मेल खाती है) आपको यह देखने की अनुमति देगी कि क्या प्रविष्टि (उदाहरण के लिए ऑर्डर निर्माण) आपके द्वारा किसी एक प्रयोगात्मक समूह में नामांकित विशिष्ट उपयोगकर्ता के लिए सफल रही या नहीं। सेट। हमारे उदाहरण में, हम शिपिंग विधि चयनित स्थिति पर भरोसा कर सकते हैं जो यह निष्कर्ष निकालने की अनुमति देती है कि उपयोगकर्ता ने सफलतापूर्वक शिपिंग विवरण प्रदान किया और फिर सुझाए गए शिपिंग तरीकों में से एक का चयन किया।
पेशेवरों:
दोष:
कार्य और सांकेतिक अनुमान:
एक बार जब आप अपने बैकएंड को डिज़ाइन कर लेते हैं, तो अपनी फ्रंटएंड टीम के साथ सूचना प्राप्त करने के सर्वोत्तम तरीके और प्रवाह के किस चरण में संरेखित करें।
मुख्य निर्भरता को ध्यान में रखें और कम करें:
एक बार आपका प्रयोग पर्याप्त समय तक चलने के बाद, सार्थक निष्कर्ष निकालने के लिए परिणामों का विश्लेषण और व्याख्या करना महत्वपूर्ण है।
उन फ़ील्ड्स की सूची निर्धारित करें, जिन पर आपने पहले ध्यान केंद्रित करने का निर्णय लिया था।
ऊपर दिए गए निदर्शी उदाहरण से डेटा स्रोत 2 तालिकाएँ होंगी:
Experiments database
:इनपुट : प्रयोग आईडी जिसके लिए आप परिणाम खोज रहे हैं
आउटपुट : सभी उपयोगकर्ता आईडी की सूची जो विशिष्ट प्रयोग के प्रतिभागी हैं, वह समूह जिसमें प्रत्येक उपयोगकर्ता को असाइन किया गया था और टाइमस्टैम्प जब उपयोगकर्ता को असाइन किया गया था
Order lifecycle database
इस डेटा के आधार पर आप प्रत्येक प्रयोग समूह के लिए सफलतापूर्वक बनाए गए % ऑर्डर की गणना कर सकते हैं.
अपने परिणामों का विश्लेषण करते समय, केवल अपरिष्कृत संख्याओं से परे देखना महत्वपूर्ण है। आप यह सुनिश्चित करने के लिए सांख्यिकीय महत्व भी देखना चाहेंगे कि आपके द्वारा अपने परीक्षण समूहों के बीच कोई भी अंतर केवल यादृच्छिक अवसर के कारण नहीं है। मैं इस हिस्से पर बहुत अधिक ध्यान केंद्रित नहीं करूंगा क्योंकि मैं पहले से ही इस विषय से संबंधित बहुत सारे लेख इस और अन्य ऑनलाइन संसाधनों के साथ देख चुका हूं। वैसे भी, यहां अत्यधिक ज्ञान की आवश्यकता नहीं है: मेरी राय में, 2 समूहों के बीच अंतर के महत्व की जांच के लिए जेड-टेस्ट या टी-टेस्ट लागू करने में सक्षम होना पर्याप्त होगा।
फिर भी, एक बार जब आप यह निर्धारित कर लेते हैं कि आपके परिणाम सांख्यिकीय रूप से महत्वपूर्ण हैं, तो आप निष्कर्ष निकालना शुरू कर सकते हैं कि आपके उत्पाद के किस विकल्प ने बेहतर प्रदर्शन किया।
जब आप एक प्रयोग सफलतापूर्वक चला लेते हैं और सर्वोत्तम विकल्प के संबंध में पर्याप्त मात्रा में विश्वास प्राप्त कर लेते हैं, तो अगला कदम अपने उत्पाद में अपने परिवर्तनों को बढ़ाना है। कई दृष्टिकोण हो सकते हैं:
अपने प्रयोग के कॉन्फ़िगरेशन को समायोजित करना सबसे आसान है ताकि 100% उपयोगकर्ता बेहतर परिणाम दिखाने वाले समूह के अंतर्गत आ जाएं। आपको भविष्य में कोड को साफ़ करने के लिए कुछ समय आरक्षित रखना होगा ताकि UI के इस विशिष्ट भाग को प्रदर्शित करना प्रयोग परिवेश से स्वतंत्र हो
अगर आपका उत्पाद कई प्लेटफॉर्म पर उपलब्ध है तो यह कम स्पष्ट है। यह मानने में अतिरिक्त सावधानी बरतें कि वेब प्रवाह पर प्रयोगों के परिणाम मोबाइल ऐप प्रवाह (और इसके विपरीत) पर लागू होते हैं। कभी-कभी पछताने के बजाय सुरक्षित रहना बेहतर होता है और इसी तरह एक अलग प्रयोग चलाते हैं, लेकिन दूसरे प्लेटफॉर्म पर।
किसी भी उत्पाद प्रबंधक के लिए अपना खुद का प्रयोग परिवेश होना एक बहुत ही उपयोगी उपकरण है। भले ही आपका वर्तमान उत्पाद परिपक्वता के किसी भी चरण में हो, एक प्रयोग परिवेश बनाने में बहुत अधिक समय नहीं लगना चाहिए। इसे काम करने के लिए काफी कम एकमुश्त लागत का भुगतान करने से आपको निवेश पर प्रतिफल काफी जल्दी दिखाई देगा।
अंत में, यह सुनिश्चित करने के लिए यहां कुछ युक्तियां दी गई हैं कि प्रयोग के परिणाम सार्थक हों:
इन सर्वोत्तम प्रथाओं का पालन करके, आप एक प्रभावी प्रयोग वातावरण स्थापित कर सकते हैं जो आपको डेटा-संचालित निर्णय लेने में मदद कर सकता है और समय के साथ आपकी रूपांतरण दरों को बढ़ा सकता है।