IOS के लिए ब्राउज़र ने A / B परीक्षण में सुधार कैसे किया। यैंडेक्स रिपोर्ट

बहुत पहले नहीं, हमने देखा कि खोज में A / B प्रयोगों को कैसे व्यवस्थित किया जाता है। कोकोआइड्स रूस की पिछली बैठक में , यैंडेक्स.ब्रोज़र, आंद्रेई सिकरीन सवि 42 के आईओएस संस्करण के लिए विकास टीम के प्रमुख ने भी ए / बी परीक्षण बुनियादी ढांचे के बारे में बात की, केवल उनकी परियोजना में।



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

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



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

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

आइए हम उस मूल प्रयोग प्रणाली के बारे में बात करें जिसका हमने उपयोग किया था। वह पहले से ही काफी विकसित थी। फिर मैं आपको बताऊंगा कि हमें क्या पसंद नहीं आया।



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

प्रयोग प्रणाली में ही एक फाइल होती है जिसमें प्रयोगों के विन्यास का वर्णन होता है। यही है, एक प्रयोग के लिए एक साथ कई विन्यास हो सकते हैं। यह फ़ाइल एक टेक्स्ट फ़ाइल है, इसे प्रोटोबॉफ़ में संकलित किया गया है और सर्वर पर रखा गया है।

प्रत्येक कॉन्फ़िगरेशन में समूह होते हैं। एक प्रयोग है, इसमें कई विन्यास हैं, और उनमें से प्रत्येक में कई समूह हैं। कोड में सुविधा सक्रिय कॉन्फ़िगरेशन के सक्रिय समूह के नाम से जुड़ी हुई है। यह काफी जटिल लग सकता है, लेकिन अब मैं विस्तार से बताऊंगा कि यह क्या है।



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

जो कॉन्फ़िगरेशन निर्दिष्ट शर्तों के लिए उपयुक्त है और उसमें वर्णित है वह सक्रिय हो सकता है। यदि कई सक्रिय कॉन्फ़िगरेशन हैं जो निर्दिष्ट शर्तों को फिट करते हैं, तो फ़ाइल में उच्चतर कॉन्फ़िगरेशन को सक्रिय किया जाएगा।

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

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



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

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

ya_min_version का अर्थ है कि अनुप्रयोग के न्यूनतम संस्करण 19.3.4.43 के साथ यह कॉन्फ़िगरेशन सक्रिय हो सकता है। दरअसल, एप्लिकेशन के इस संस्करण में, फीचर ने पहले से ही ऐसा फॉर्म हासिल कर लिया है जिससे आप इसे सक्षम कर सकते हैं।

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

यहां एक प्रयोग समूह सक्षम किया गया है, और इसमें संभाव्यता भार टैग है, प्रयोग समूह का वजन। यह एक गैर-नकारात्मक पूर्णांक है जिसका उपयोग सक्रिय समूह को उस समय निर्धारित करने के लिए किया जाता है जब सिक्का पॉप अप होता है।

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

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

हम कोड में प्रयोगों के सक्रिय समूह का नाम पूछ सकते हैं और इस तरह पहुंच का निर्धारण कर सकते हैं - क्या हमें सुविधा को सक्षम करने की आवश्यकता है या नहीं।



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

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

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

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

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



आइए इस प्रयोग को देखें। हम निम्नलिखित प्रयोग विन्यास देखते हैं - ऐप स्टोर के लिए अनुवादक, नए उपयोगकर्ता। ब्लॉक अध्ययन, नाम अनुवादक, समूह enable_new। उपसर्ग नया का अर्थ है कि हम कई उपयोगकर्ताओं के लिए कॉन्फ़िगरेशन का वर्णन करते हैं जो नए हैं। वजन 500 (यदि सभी वजन का योग 1000 है, तो इस सेट की शक्ति 50% है)। Control_new, वजन 500, यह दूसरा समूह है। और सबसे दिलचस्प बात STABLE चैनल के लिए फिल्टर है, यानी उत्पादन के लिए इकट्ठे किए गए असेंबली के लिए। संस्करण जिसमें सुविधा दिखाई दी: 19.4.1। और यहाँ पर min_install_date टैग है। यहां, यूनिक्स समय प्रारूप में, इसे 18 अप्रैल, 2019 को एन्क्रिप्ट किया गया है। यह संस्करण 19.4.1 की रिलीज़ के कुछ दिनों बाद है।

नए उपसर्ग के अलावा यहां एक और हिस्सा है, यह सक्षम और नियंत्रण है। यहाँ नियंत्रण उपसर्ग है; यह आकस्मिक नहीं है। और इस तथ्य के अलावा कि हम उपयोगकर्ताओं को नए और पुराने में तोड़ते हैं, हम उन्हें कई भागों में प्रयोग के समूहों में तोड़ते हैं।



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



आइए देखें, कहते हैं, पुराने उपयोगकर्ताओं के लिए कॉन्फ़िगरेशन। हम यहां एक फीचर और कंट्रोल ग्रुप देखेंगे। enable_old - चित्रित किया गया। control_old, - नियंत्रण, 10%। default_old - डिफ़ॉल्ट, 80%।

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

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

इस प्रकार, हम अलग-अलग उपयोगकर्ता समूहों, पुराने और नए के लिए विश्लेषिकी में नियंत्रण और सुविधा समूहों की तुलना करते हैं। यदि हम सब कुछ पेंट करते हैं, तो हम सुविधा को 100% तक रोल करते हैं।



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

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



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

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

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

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

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

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

हमने परामर्श किया और तय किया कि इसे सहना पर्याप्त है। इसलिए मेक एक्सपेरिमेंट्स ग्रेट अगेन प्रोजेक्ट का जन्म हुआ।



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

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



प्रयोग कॉन्फ़िगरेशन फ़ाइल में यह कैसा दिखता है? यहाँ हम प्रयोग समूह को देखते हैं। नाम सक्षम किया गया है, एक वैकल्पिक feature_association टैग जोड़ा गया है, इस enable_feature या disable_feature कमांड टैग में, और पहचानकर्ता जोड़े जाते हैं।

एक पैराम ब्लॉक भी है, जिसमें से कई हो सकते हैं। यहां, भी, एक नाम है - टाइमआउट, और सेट करने के लिए आवश्यक मान जोड़ा गया है।



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

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

-, , , , . , , , , .

. , , translator, , , . TranslateServiceAPITimeout, , timeout API . , , , , : 300 600.

. . (FeatureParam).

, , , . , , . , , . . ?



, : Feature FeatureParam. Feature FeatureParam . , Feature FeatureParam, , . . - , , .

-, Feature&FeatureParam. , «», , , . FeatureParam , , API — 300 600 ?

. . - , . public beta, . , .

, : .



? , , .

: . URL, , .

: browser://version — show-variations-cmd. : cheat-, . : .



. , . proto- - , study-, . , . Feature&FeatureParam, . , , . , , Feature&FeatureParam .

. proto- . . , . , , .



दूसरा वाला। Feature&FeatureParam? Chromium, . Chromium browser://version, show-variations-cmd.

: enabled-features, force-fieldtrials force-fieldtrials-params, . , . ? , . , Feature1 trial1. Feature2 trial2. Feature3 .

trial1 group1. trial2 group2. force-fieldtrials-params, , trial1 group1, p1 v1, p2 v2. trial2 group2, p3 v3, p4 v4.

, . Chromium, iOS. , .

. --force-fieldtrials=translator/enabled_new/ enabled_new translator.

--force-fieldtrial-params==translator.enablew_new:timeout/5000, translator enabled_new, , , translator, enabled_new timeout, 5 000 .

--enabled-features=TranslateServiceAPITimeout<translator , - translator translator , , , TranslateServiceAPITimeout. , , , , .



(cheat urls). , , , , , , . . . .

yandexbrowser:// (.), , . . my_pet_experiment=group_name. , enable-features=, , disable-features=, . , &.

(cheat url), . , , , . , , . filter, my_pet_experiment , . 1000, feature_association, , .

, . , , . , — my_pet_experiment — , , . , , study .



, . — , . . , .

, .



, , , , . , . , .

. . , , ? , . , ?

. .

, . , , UUID, application Identifier, . . hash .

? ? , , UUID, . ? , , . . ? hash hash , . , Google, An Efficient Low-Entropy Provider.

, — UUID, , , . , , Chromium.

, , ? ? :

1. : , -. .
2. . , , , .
3. टेस्ट। आपके पास ऐसे तंत्र होने चाहिए जो आपको समूहों, सुविधाओं, मापदंडों, या अन्य संस्थाओं के मूल्यों को फिर से परिभाषित करने की अनुमति दें जिनकी आपको आवश्यकता है।
4. एक जहां एनालिटिक्स के लिए और प्रोग्रामिंग के लिए विभिन्न प्राइमिटिव्स का उपयोग किया जाता है।
5. विस्तार योग्य। आपके पास यह देखने का अवसर होना चाहिए कि यह कैसे काम करता है और इसे आपकी आवश्यकताओं के अनुकूल बनाता है ( क्रोमियम भिन्नता सेवा देखें )।

क्रोमियम सिस्टम, जिसे हम iOS के लिए Yandex.Browser में विस्तारित कर रहे हैं, में ऐसे मानदंड हैं। अपने प्रयोगों का संचालन करें, उनका विश्लेषण करें और अनुप्रयोगों को बेहतर बनाएं। आपका धन्यवाद