🤾🏿 🤢 👲🏻 ए / जेड से एंड्रॉइड पर ए / बी परीक्षण ☝🏾 📷 😻

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

ए / बी परीक्षण अवधारणा

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

कार्यान्वयन

1. उपयोगकर्ताओं को समूहों में विभाजित करें

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

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

Firebase कंसोल में, ग्रो ग्रुप में एक रिमोट कॉन्फिग टैब होता है, जहाँ आप अपना स्वयं का कॉन्फिगरेशन बना सकते हैं जो फायरबेस आपके एप्लिकेशन के उपयोगकर्ताओं तक पहुंचाएगा।

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

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

लगभग। नियंत्रण समूह को आमतौर पर समूह ए कहा जाता है, प्रयोगात्मक समूह को बी कहा जाता है। जैसा कि आप स्क्रीनशॉट में देख सकते हैं, फायरबेस में डिफ़ॉल्ट प्रयोगात्मक समूह को "वेरिएंट ए" कहा जाता है, जो कुछ भ्रम का परिचय देता है। लेकिन कुछ भी इसका नाम बदलने से रोकता है।

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

2. कोड

हम सीधे फायरबेस रिमोट कॉन्फ़िगरेशन के साथ एकीकरण पर ध्यान केंद्रित नहीं करेंगे - यह यहां विस्तार से वर्णित है ।

आइए जानें कि ए / बी परीक्षण के लिए कोड को कैसे व्यवस्थित किया जाए। यदि हम केवल बटन का रंग बदलते हैं, तो संगठन के बारे में बात करने का कोई मतलब नहीं है, क्योंकि व्यवस्थित करने के लिए कुछ भी विशेष नहीं है। हम एक वेरिएंट पर विचार करेंगे, जिसमें रिमोट कॉन्फ़िगरेशन से पैरामीटर के आधार पर, वर्तमान (नियंत्रण समूह के लिए) या नया (प्रयोगात्मक के लिए) स्क्रीन प्रदर्शित किया जाता है।

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

यदि हम प्रेजेंटेशन लेयर में MVP के बारे में बात करते हैं, तो यह कुछ इस तरह दिखाई देगा:

सबसे लचीला और पारदर्शी वर्ग पदानुक्रम लगता है:

BaseOrderStatusFragment में आर्किटेक्चर सीमाओं के कारण एक अमूर्त वर्ग में नहीं रखे जा सकने वाले तरीकों को छोड़कर, वर्तमान कार्यान्वयन की सभी कार्यक्षमता शामिल होगी। वे ऑर्डरस्टैटस फ़्रेग्मेंट में स्थित होंगे।

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

नोट: यदि आर्किटेक्चर और विशिष्ट मामला अनुमति देता है, तो आप बिना किसी आधार वर्ग के बना सकते हैं और सीधे क्रम में AbOrderStatusFragment OrderStatusFragment कर सकते हैं।

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

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

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

ठीक है, और निश्चित रूप से, यह महत्वपूर्ण है कि पैरामीटर मान को एनालिटिक्स ईवेंट पैरामीटर में कॉन्फ़िगरेशन से फेंकना न भूलें, ताकि आप मैट्रिक्स की तुलना कर सकें

परिणाम विश्लेषण

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

नुकसान

1. दूरस्थ कॉन्फ़िगरेशन प्राप्त करने में त्रुटि

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

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

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

नोट। पिछले 30 दिनों के लिए डेटा। अनुरोधों की कुल संख्या 673 529 । पहले कॉलम, नेटवर्क अनुरोधों के अलावा, कैश से कॉन्फिग की रसीद होती है, इसलिए इसे सामान्य वितरण फॉर्म से बाहर खटखटाया जाता है।

ग्राफ़ डेटा:

मिलीसेकंड	अनुरोधों की संख्या
200	227,485
400	51038
600	59,249
800	84,516
1000	63,891
1200	39115
1400	24,889
1600	16,763
1800	12410
2000	9502
2200	7636
2400	6357
2600	5409
2800	4545
3000	3963
3200	2699
3400	3184
3600	2755
3800	2431
4000	2176
4200	1950
4400	1804
4600	1607
4800	1470
5000	1310
> 5000 रु	35,375

2. सुदूर अद्यतन विन्यास कॉन्फ़िगर करना

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

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

इस समस्या का समाधान बहुत सरल है - आपको कैश जीवनकाल को रीसेट करके एप्लिकेशन संस्करण को अपडेट करते समय कॉन्फ़िगरेशन अनुरोध को मजबूर करने की आवश्यकता है:

val cacheExpiration = if (isAppNewVersion) 0L else TWELVE_HOURS_IN_SECONDS FirebaseRemoteConfig.getInstance().fetch(cacheExpiration)

चूंकि अद्यतन अक्सर जारी नहीं किए जाते हैं, हम सीमा से अधिक नहीं होंगे
इन मुद्दों के बारे में यहाँ और पढ़ें।

निष्कर्ष

फायरबेस एक बहुत सुविधाजनक और सरल ए / बी परीक्षण उपकरण प्रदान करता है जिसका उपयोग किया जाना चाहिए, ऊपर वर्णित बाधाओं पर विशेष ध्यान देना। कोड का प्रस्तावित संगठन ए / बी परीक्षणों के चक्र से जुड़े बदलाव करते समय त्रुटियों की संख्या को कम कर देगा।

सभी को शुभकामनाएँ, सफल ए / बी परीक्षण और रूपांतरणों में 100.5% की वृद्धि।

ए / जेड से एंड्रॉइड पर ए / बी परीक्षण