रिमोट कॉन्फ़िगरेशन को उपयोगकर्ता के मनमुताबिक बनाने की सुविधा के बारे में जानकारी

उपयोगकर्ता के हिसाब से अनुभव देने के लिए, मशीन लर्निंग का इस्तेमाल किया जाता है. खास तौर पर, कॉन्टेक्चुअल मल्टी-आर्म्ड बैंडिट एल्गोरिदम का इस्तेमाल किया जाता है. इससे, किसी लक्ष्य को हासिल करने के लिए, हर उपयोगकर्ता के लिए सबसे अच्छा अनुभव तय किया जाता है. हमारे मामले में, लक्ष्य यह है कि खास Google Analytics इवेंट की कुल संख्या या कुल पैरामीटर वैल्यू को ऑप्टिमाइज़ किया जाए.

कॉन्टेक्चुअल मल्टी-आर्म्ड बैंडिट एल्गोरिदम क्या है?

"मल्टी-आर्म्ड बैंडिट" एक मेटाफ़र है. इसका इस्तेमाल, ऐसी स्थिति के बारे में बताने के लिए किया जाता है जहां हमें लगातार ऐसा पाथ चुनना होता है जिससे कई पाथ की सूची में से सबसे ज़्यादा और भरोसेमंद इनाम मिलें. इसे समझने के लिए, स्लॉट मशीन की लाइन के सामने खड़े जुआरी के मेटाफ़र का इस्तेमाल किया जा सकता है. स्लॉट मशीन को आम तौर पर "वन-आर्म्ड बैंडिट" कहा जाता है, क्योंकि स्लॉट मशीन में एक हैंडल (या आर्म) होता है और वह आपका पैसा ले लेती है. हमें कई "आर्म" के लिए समस्या हल करनी है. इसलिए, वन-आर्म्ड बैंडिट, मल्टी-आर्म्ड बैंडिट बन जाता है.

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

इसलिए, एल्गोरिदम को ज़्यादा असरदार बनाने के लिए, उसमें कॉन्टेक्स्ट जोड़ा जाता है. Remote Config के लिए, उपयोगकर्ता के हिसाब से अनुभव देने के लिए, शुरुआती कॉन्टेक्स्ट रैंडम सैंपलिंग, या अनिश्चितता होती है. इससे, प्रयोग में कुछ एंट्रॉपी मिलती है. इससे "कॉन्टेक्चुअल मल्टी-आर्म्ड बैंडिट" लागू होता है. प्रयोग जारी रहने पर, लगातार एक्सप्लोरेशन और ऑब्ज़र्वेशन से मॉडल को यह पता चलता है कि किन आर्म से इनाम मिलने की संभावना सबसे ज़्यादा है. इससे, मॉडल ज़्यादा असरदार बनता है.

इसका मतलब मेरे ऐप्लिकेशन के लिए क्या है?

अब बात करते हैं कि आपके ऐप्लिकेशन के संदर्भ में, मल्टी-आर्म्ड बैंडिट एल्गोरिदम का क्या मतलब है. मान लें कि आपने बैनर विज्ञापन के क्लिक के लिए ऑप्टिमाइज़ किया है. इस मामले में, उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा के "आर्म", वैकल्पिक वैल्यू होंगी. ये वैल्यू, उन अलग-अलग बैनर विज्ञापनों को दिखाने के लिए तय की जाती हैं जो आपको उपयोगकर्ताओं को दिखाने हैं. बैनर विज्ञापन पर क्लिक को इनाम माना जाता है. इसे हम लक्ष्य कहते हैं.

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

उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा, 24 घंटे की स्टिकीनेस विंडो का इस्तेमाल करती है. यह वह समय होता है जब उपयोगकर्ता के हिसाब से अनुभव देने का एल्गोरिदम, किसी एक वैकल्पिक वैल्यू को एक्सप्लोर करता है. आपको उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा को, हर वैकल्पिक वैल्यू को कई बार एक्सप्लोर करने के लिए काफ़ी समय देना चाहिए. आम तौर पर, यह समय 14 दिन होता है. सबसे अच्छा तरीका यह है कि इन्हें हमेशा चालू रखा जाए, ताकि आपके ऐप्लिकेशन और उपयोगकर्ता के व्यवहार में बदलाव होने पर, ये लगातार बेहतर हो सकें और अडजस्ट हो सकें.

अन्य मेट्रिक ट्रैक करना

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

इस मामले में, किसी Analytics इवेंट, जैसे कि link_received के लिए ऑप्टिमाइज़ किया जा सकता है. साथ ही, user_engagement और link_opened के लिए दो मेट्रिक सेट की जा सकती हैं. इससे यह समझा जा सकता है कि उपयोगकर्ता का जुड़ाव और उपयोगकर्ता के खोले गए लिंक की संख्या बढ़ती है (असल जुड़ाव) या कम होती है (संभव है कि स्पैम वाले बहुत ज़्यादा लिंक हों).

इन अन्य मेट्रिक को, उपयोगकर्ता के हिसाब से अनुभव देने के एल्गोरिदम में शामिल नहीं किया जाएगा. हालांकि, इन्हें उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा के नतीजों के साथ ट्रैक किया जा सकता है. इससे, उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा के ज़रिए, अपने कुल लक्ष्यों को हासिल करने की क्षमता के बारे में अहम जानकारी मिलती है.

उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा के नतीजे समझना

उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा के नतीजे देखे जा सकते हैं. इसके लिए, ज़रूरी है कि यह सुविधा काफ़ी समय तक चालू रही हो, ताकि डेटा इकट्ठा किया जा सके.

उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा के नतीजे देखने के लिए:

  1. Firebase console में, DevOps और जुड़ाव > Remote Config > उपयोगकर्ता के हिसाब से अनुभव देने की सुविधाएं पेज पर जाएं.

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

नतीजों वाले पेज पर, कुल लिफ़्ट या परफ़ॉर्मेंस में अंतर का प्रतिशत दिखता है. यह अंतर, उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा से मिला है.

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

  • यह दिखता है कि उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा ने, बेसलाइन के मुकाबले हर दिन और कुल मिलाकर कैसा परफ़ॉर्म किया.

  • यह दिखता है कि बेसलाइन ग्रुप में, हर वैल्यू ने कुल मिलाकर कैसा परफ़ॉर्म किया.

  • लक्ष्य के नतीजे और चुनी गई अन्य मेट्रिक के मुकाबले परफ़ॉर्मेंस दिखती है. इन्हें, खास जानकारी के सबसे ऊपर मौजूद टैब का इस्तेमाल करके ऐक्सेस किया जा सकता है.

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

उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा को मिटाने के बारे में जानकारी

उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा को, Firebase console का इस्तेमाल करके मिटाया जा सकता है. इसके अलावा, personalization parameter को अपने टेंप्लेट से Firebase Remote Config API का इस्तेमाल करके हटाकर भी इसे मिटाया जा सकता है. उपयोगकर्ता के हिसाब से अनुभव देने की मिटाई गई सुविधाओं को वापस नहीं लाया जा सकता. डेटा के रखरखाव के बारे में जानने के लिए, डेटा मिटाना लेख पढ़ें.

टेंप्लेट को रोल बैक करके या इंपोर्ट करके भी, उपयोगकर्ता के हिसाब से अनुभव देने की सुविधाओं को मिटाया जा सकता है टेंप्लेट.

रोलबैक

अगर आपके मौजूदा टेंप्लेट में, उपयोगकर्ता के हिसाब से अनुभव देने की सुविधाएं हैं और आपने किसी ऐसे टेंप्लेट पर रोल बैक किया है जिसमें ये सुविधाएं नहीं हैं, तो उपयोगकर्ता के हिसाब से अनुभव देने की सुविधाएं मिट जाती हैं. पिछले टेंप्लेट पर वापस जाने के लिए, Firebase console का इस्तेमाल करें या Firebase Remote Config API का इस्तेमाल करके, roll back करें.

जब उपयोगकर्ता के हिसाब से अनुभव देने की किसी सुविधा को मिटाया जाता है और पिछले टेंप्लेट पर रोल बैक किया जाता है, तो एक उपयोगकर्ता के हिसाब से अनुभव देने की अमान्य सुविधा का रेफ़रंस Firebase console में दिखता है. Firebase console से अमान्य सुविधा को हटाया जा सकता है. इसके लिए, Remote Config पेज के पैरामीटर टैब में, उपयोगकर्ता के हिसाब से अनुभव देने की सुविधा में बदलाव करें.

इंपोर्ट

किसी ऐसे टेंप्लेट को इंपोर्ट करने पर भी, उपयोगकर्ता के हिसाब से अनुभव देने की मौजूदा सुविधाएं मिट जाती हैं जिनमें ये सुविधाएं शामिल नहीं हैं. किसी टेंप्लेट को इंपोर्ट करने के लिए, Firebase console का इस्तेमाल करें या Remote Config REST API का इस्तेमाल करें.

अगले चरण