A/B टेस्टिंग की मदद से, Firebase रिमोट कॉन्फ़िगरेशन के प्रयोग बनाना

ध्यान दें: यह सुविधा Android, iOS, और वेब ऐप्लिकेशन के लिए उपलब्ध है.

जब Firebase Remote Config का इस्तेमाल करके, किसी ऐसे ऐप्लिकेशन के लिए सेटिंग डिप्लॉय की जाती हैं जिसके उपयोगकर्ताओं का ग्रुप सक्रिय है, तो आपको यह पक्का करना होगा कि सेटिंग सही तरीके से डिप्लॉय की गई हों. A/B Testing एक्सपेरिमेंट का इस्तेमाल करके, इन चीज़ों का बेहतर तरीके से पता लगाया जा सकता है:

• उपयोगकर्ता अनुभव को ऑप्टिमाइज़ करने के लिए, किसी सुविधा को लागू करने का सबसे अच्छा तरीका. अक्सर, ऐप्लिकेशन डेवलपर को तब तक यह पता नहीं चलता कि उपयोगकर्ताओं को कोई नई सुविधा या अपडेट किया गया उपयोगकर्ता अनुभव पसंद नहीं आया, जब तक कि ऐप स्टोर में उनके ऐप्लिकेशन की रेटिंग कम नहीं हो जाती. A/B Testing से यह मेज़र करने में मदद मिल सकती है कि आपके उपयोगकर्ताओं को सुविधाओं के नए वैरिएंट पसंद हैं या वे ऐप्लिकेशन को पहले जैसा ही रखना चाहते हैं. इसके अलावा, ज़्यादातर उपयोगकर्ताओं को बेसलाइन ग्रुप में रखने से यह पक्का होता है कि आपके ज़्यादातर उपयोगकर्ता, प्रयोग के खत्म होने तक आपके ऐप्लिकेशन का इस्तेमाल जारी रख सकते हैं. इस दौरान, उन्हें ऐप्लिकेशन के काम करने के तरीके या लुक में कोई बदलाव नहीं दिखेगा.
• कारोबार के लक्ष्य के लिए, उपयोगकर्ता अनुभव को ऑप्टिमाइज़ करने का सबसे अच्छा तरीका. कभी-कभी, रेवेन्यू या उपयोगकर्ता को बनाए रखने जैसी मेट्रिक को बढ़ाने के लिए, प्रॉडक्ट में बदलाव किए जाते हैं. A/B Testing की मदद से, अपने कारोबार का लक्ष्य सेट किया जा सकता है. साथ ही, Firebase आंकड़ों का विश्लेषण करके यह तय करता है कि कोई वैरिएंट, आपके चुने गए लक्ष्य के लिए बेसलाइन से बेहतर परफ़ॉर्म कर रहा है या नहीं.

ध्यान दें: रीयल-टाइम अपडेट की सुविधा, A/B Testing एक्सपेरिमेंट के लिए उपलब्ध है. इस सुविधा का फ़ायदा पाने के लिए, पक्का करें कि आपका ऐप्लिकेशन, ज़रूरी एसडीके के सबसे नए वर्शन का इस्तेमाल करता हो. जैसे, Android के लिए Firebase SDK का 34.13.0 या इसके बाद का वर्शन, Apple प्लैटफ़ॉर्म के लिए Firebase SDK का 12.13.0 या इसके बाद का वर्शन, और Firebase JavaScript SDK का 12.15.0 या इसके बाद का वर्शन.

किसी बेसलाइन के साथ सुविधा के वैरिएंट की A/B टेस्टिंग करने के लिए, यह तरीका अपनाएं:

1. अपना एक्सपेरिमेंट तैयार करें.
2. अपने एक्सपेरिमेंट को मैनेज करें.

अहम जानकारी: पक्का करें कि आपके पास A/B Testing के लिए SDK टूल का कम से कम यह वर्शन हो: Android के लिए Firebase SDK टूल का वर्शन 17.1.1+, Apple प्लैटफ़ॉर्म के लिए Firebase SDK टूल का वर्शन 4.5.0, और Firebase JavaScript SDK टूल का वर्शन 12.8.0.

एक प्रयोग बनाएं

Remote Config एक्सपेरिमेंट की मदद से, एक या उससे ज़्यादा Remote Config पैरामीटर पर कई वैरिएंट का आकलन किया जा सकता है.

1. पुष्टि करें कि आपके प्रोजेक्ट में Google Analytics चालू है, ताकि एक्सपेरिमेंट के पास Analytics डेटा का ऐक्सेस हो.

   अगर आपने प्रोजेक्ट बनाते समय Google Analytics को चालू नहीं किया है, तो इसे Firebase कंसोल के सेटिंग > इंटिग्रेशन टैब में जाकर चालू किया जा सकता है.

2. Firebase कंसोल में, DevOps और यूज़र ऐक्टिविटी > A/B Testing पर जाएं

3. एक्सपेरिमेंट बनाएं पर क्लिक करें. इसके बाद, जिस सेवा के लिए एक्सपेरिमेंट करना है उसके बारे में पूछे जाने पर, Remote Config को चुनें.

4. वैरिएंट सेक्शन में, एक्सपेरिमेंट के लिए एक बेसलाइन और कम से कम एक वैरिएंट चुनें. एक्सपेरिमेंट करने के लिए, एक या उससे ज़्यादा पैरामीटर जोड़े जा सकते हैं. अपने एक्सपेरिमेंट में कई पैरामीटर जोड़ने के लिए, यह तरीका दोहराया जा सकता है.

5. (ज़रूरी नहीं) अपने एक्सपेरिमेंट में एक से ज़्यादा वैरिएंट जोड़ने के लिए, एक और वैरिएंट जोड़ें पर क्लिक करें.

6. खास वैरिएंट के लिए, एक या उससे ज़्यादा पैरामीटर बदलें. जिन पैरामीटर में बदलाव नहीं किया गया है वे उन उपयोगकर्ताओं के लिए भी एक जैसे ही रहते हैं जो एक्सपेरिमेंट में शामिल नहीं हैं.

7. एक्सपेरिमेंट के लिए वैरिएंट का ट्रैफ़िक देखने या बदलने के लिए, वैरिएंट का ट्रैफ़िक को बड़ा करें. डिफ़ॉल्ट तौर पर, सभी वैरिएंट का वेट एक बराबर होता है. ध्यान दें, वैरिएंट के वेट को घटाने या बढ़ाने से डेटा कलेक्शन में लगने वाला समय बढ़ सकता है और एक्सपेरिमेंट शुरू होने के बाद, वेट में बदलाव नहीं किया जा सकता.

8. Remote Config शर्तों का इस्तेमाल करके, अपने एक्सपेरिमेंट के लिए टारगेटिंग की शर्तें तय करें:

   • किसी मौजूदा शर्त का फिर से इस्तेमाल करना: अगर आपके Remote Config टेंप्लेट में मौजूद कोई शर्त, आपकी टारगेट ऑडियंस से पहले से ही मैच करती है, तो उसे सूची से चुनें.

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

   • शर्तों के आकलन के क्रम की पुष्टि करना: पक्का करें कि शर्तें पेज पर मौजूद शर्तें, प्राथमिकता के सही क्रम में व्यवस्थित हों. Remote Config, शर्तों का आकलन ऊपर से नीचे के क्रम में करता है. इसलिए, ज़्यादा प्राथमिकता वाली अन्य शर्तें, ज़रूरी संख्या में उपयोगकर्ताओं को आपके एक्सपेरिमेंट से जुड़ी शर्त तक पहुंचने से रोक सकती हैं.

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

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

     • वर्शन: आपके ऐप्लिकेशन का एक या उससे ज़्यादा वर्शन
     • बिल्ड नंबर: आपके ऐप्लिकेशन का बिल्ड नंबर (Apple) या वर्शन कोड (Android)
     • प्लैटफ़ॉर्म: टारगेट करने के लिए एक या उससे ज़्यादा प्लैटफ़ॉर्म (iOS, Android या वेब)
     • ऑपरेटिंग सिस्टम: वेब ऐप्लिकेशन के उपयोगकर्ताओं को उनके ऑपरेटिंग सिस्टम और वर्शन के आधार पर टारगेट करें
     • ब्राउज़र: वेब ऐप्लिकेशन के उपयोगकर्ताओं को उनके वेब ब्राउज़र और ब्राउज़र के वर्शन के आधार पर टारगेट करें
     • डिवाइस की कैटगरी: वेब ऐप्लिकेशन के उपयोगकर्ताओं को इस आधार पर टारगेट करें कि उनका डिवाइस मोबाइल है या नहीं
     • भाषाएं: एक या उससे ज़्यादा भाषाएं और स्थान-भाषाएं, जिनका इस्तेमाल करके उन उपयोगकर्ताओं को चुना जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
     • देश/इलाका: एक या इससे ज़्यादा देश या इलाके, ताकि उन उपयोगकर्ताओं को चुना जा सके जिन्हें एक्सपेरिमेंट में शामिल करना है
     • उपयोगकर्ता ऑडियंस: Analytics ऑडियंस का इस्तेमाल, उन उपयोगकर्ताओं को टारगेट करने के लिए किया जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
     • उपयोगकर्ता प्रॉपर्टी: एक या उससे ज़्यादा Analytics उपयोगकर्ता प्रॉपर्टी, ताकि उन उपयोगकर्ताओं को चुना जा सके जिन्हें प्रयोग में शामिल किया जा सकता है
     • उपयोगकर्ताओं का रैंडम प्रतिशत: तय की गई पर्सेंटाइल रेंज में, उपयोगकर्ताओं के रैंडम तरीके से चुने गए प्रतिशत को टारगेट करें
     • इंपोर्ट किया गया सेगमेंट: उन उपयोगकर्ताओं को टारगेट करें जो आपके प्रोजेक्ट में अपलोड किए गए, कस्टम तौर पर इंपोर्ट किए गए सेगमेंट से जुड़े हैं
     • तारीख/समय: तय की गई तारीख और समय के आधार पर उपयोगकर्ताओं को टारगेट करना
     • पहली बार ऐप्लिकेशन खोलने के आधार पर: उपयोगकर्ताओं को इस आधार पर टारगेट करें कि उन्होंने पहली बार आपका ऐप्लिकेशन कब खोला था
     • इंस्टॉलेशन आईडी: Firebase इंस्टॉलेशन आईडी (FID) का इस्तेमाल करके, खास टेस्ट डिवाइसों या क्लाइंट इंस्टेंस को टारगेट करें
     • उपयोगकर्ता मौजूद है: प्रोजेक्ट में मौजूद सभी ऐप्लिकेशन के सभी उपयोगकर्ताओं को टारगेट करें
     • कस्टम सिग्नल: रनटाइम के दौरान पास किए गए कस्टम क्लाइंट-साइड की-वैल्यू सिग्नल के आधार पर उपयोगकर्ताओं को टारगेट करें
   ध्यान दें: Google Analytics डेटा प्रोसेसिंग में लगने वाले समय की वजह से, Analytics उपयोगकर्ता ऑडियंस को टारगेट करने वाले एक्सपेरिमेंट को डेटा इकट्ठा करने में ज़्यादा समय लग सकता है. इस बारे में और टारगेटिंग के अन्य विकल्पों के बारे में ज़्यादा जानने के लिए, उपयोगकर्ता टारगेटिंग देखें.

9. एक्सपोज़र: टारगेट किए गए उपयोगकर्ताओं के लिए तय की गई शर्तों को पूरा करने वाले, अपने ऐप्लिकेशन के उपयोगकर्ताओं का प्रतिशत डालें. इन उपयोगकर्ताओं को, अपने एक्सपेरिमेंट में बेसलाइन और एक या उससे ज़्यादा वैरिएंट के बीच बराबर बांटना होगा. यह 0% से 100% के बीच का कोई भी प्रतिशत हो सकता है. उपयोगकर्ताओं को हर एक्सपेरिमेंट के लिए, किसी भी क्रम में असाइन किया जाता है. इसमें डुप्लीकेट एक्सपेरिमेंट भी शामिल हैं.

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

    ध्यान दें: A/B Testing वेब लागू करने के लिए, ऐक्टिवेशन इवेंट का इस्तेमाल नहीं किया जा सकता.

    यह पक्का करने के लिए कि एक्सपेरिमेंट मान्य है, पक्का करें कि चुना गया इवेंट, आपके ऐप्लिकेशन में फ़ेच की गई कॉन्फ़िगरेशन वैल्यू के चालू होने के बाद हो. इसके अलावा, इन इवेंट का इस्तेमाल नहीं किया जा सकता, क्योंकि ये फ़ेच की गई वैल्यू के चालू होने से पहले ही ट्रिगर हो जाते हैं:

    • app_install
    • app_remove
    • app_update

    ऐक्टिवेशन इवेंट के तौर पर चुना गया Analytics इवेंट, उसी एक्सपेरिमेंट में प्राइमरी मेट्रिक या अतिरिक्त मेट्रिक के तौर पर इस्तेमाल नहीं किया जाना चाहिए. ऐसा करने पर, Firebase कंसोल में पुष्टि करने से जुड़ी गड़बड़ी ट्रिगर होगी. साथ ही, आपका एक्सपेरिमेंट लॉन्च नहीं हो पाएगा.

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

12. अपने एक्सपेरिमेंट को सेव करने के लिए, सेव करें पर क्लिक करें. एक्सपेरिमेंट शुरू करने के लिए, आपको टेंप्लेट पब्लिश करना होगा.

ध्यान दें: एक्सपेरिमेंट शुरू होने के बाद, Firebase कंसोल के DevOps और यूज़र ऐक्टिविटी > Remote Config > पैरामीटर पेज पर जाकर, टेस्ट वैरिएंट के लिए फ़ेच किए गए प्रतिशत को डिफ़ॉल्ट वैल्यू के मुकाबले मॉनिटर किया जा सकता है.

हर प्रोजेक्ट के लिए, ज़्यादा से ज़्यादा 300 एक्सपेरिमेंट किए जा सकते हैं. इनमें रोल आउट भी शामिल हैं. इनमें, ज़्यादा से ज़्यादा 24 एक्सपेरिमेंट और रोल आउट चालू हो सकते हैं. बाकी एक्सपेरिमेंट पूरे हो चुके होने चाहिए.

एक्सपेरिमेंट मैनेज करना

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

एक्सपेरिमेंट पूरा होने के बाद, सबसे अच्छा परफ़ॉर्म करने वाले वैरिएंट की सेटिंग को नोट किया जा सकता है. इसके बाद, उन सेटिंग को सभी उपयोगकर्ताओं के लिए रोल आउट किया जा सकता है. इसके अलावा, कोई दूसरा एक्सपेरिमेंट चलाया जा सकता है.

किसी एक्सपेरिमेंट में बदलाव करना

1. Firebase कंसोल के नेविगेशन मेन्यू में, DevOps और यूज़र ऐक्टिविटी सेक्शन में जाकर, Remote Config पर क्लिक करें.
2. A/B टेस्ट टैब पर क्लिक करें.
3. चल रहा है पर क्लिक करें. इसके बाद, उस एक्सपेरिमेंट पर क्लिक करें जिसमें आपको बदलाव करना है.
4. कॉन्टेक्स्ट मेन्यू () पर क्लिक करें. इसके बाद, चल रहे एक्सपेरिमेंट में बदलाव करें पर क्लिक करें.
5. यह पुष्टि करने के लिए कि आपके ऐप्लिकेशन के पास ऐसे उपयोगकर्ता हैं जिन्हें आपके एक्सपेरिमेंट में शामिल किया जाएगा, ज़्यादा जानकारी को बड़ा करें. इसके बाद, टारगेटिंग और डिस्ट्रिब्यूशन सेक्शन में 0% से ज़्यादा संख्या देखें. उदाहरण के लिए, शर्तों को पूरा करने वाले 1% उपयोगकर्ता.

किसी एक्सपेरिमेंट को मॉनिटर करना

प्रयोग को कुछ समय तक चलाने के बाद, उसकी प्रोग्रेस देखी जा सकती है. साथ ही, यह देखा जा सकता है कि प्रयोग में हिस्सा लेने वाले उपयोगकर्ताओं के लिए, आपके नतीजे कैसे दिखते हैं.

1. Firebase कंसोल के नेविगेशन मेन्यू में, DevOps और यूज़र ऐक्टिविटी सेक्शन में जाकर, Remote Config पर क्लिक करें.
2. A/B टेस्ट टैब पर क्लिक करें.

3. चल रहा है पर क्लिक करें. इसके बाद, अपने एक्सपेरिमेंट के टाइटल पर क्लिक करें या उसे खोजें. इस पेज पर, चल रहे एक्सपेरिमेंट के बारे में मॉनिटर किए गए और अनुमानित आंकड़ों को देखा जा सकता है. इनमें ये शामिल हैं:

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

4. एक्सपेरिमेंट के कुछ समय तक चलने के बाद (Remote Config के लिए 14 दिन), इस पेज पर मौजूद डेटा से पता चलता है कि कौनसा वैरिएंट "लीडर" है. कुछ मेज़रमेंट के साथ एक बार चार्ट होता है, जो डेटा को विज़ुअल फ़ॉर्मैट में दिखाता है.

सलाह: आपके पास कॉलम के हिसाब से क्रम में लगाने और A/B टेस्टिंग के एक्सपेरिमेंट को नाम और एक्सपेरिमेंट की स्थिति के हिसाब से फ़िल्टर करने का विकल्प होता है.

सभी उपयोगकर्ताओं के लिए एक्सपेरिमेंट रोल आउट करना

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

1. Firebase कंसोल के नेविगेशन मेन्यू में, DevOps और यूज़र ऐक्टिविटी सेक्शन में जाकर, Remote Config पर क्लिक करें.
2. A/B टेस्ट टैब पर क्लिक करें.
3. पूरा हो गया या चल रहा है पर क्लिक करें. इसके बाद, उस एक्सपेरिमेंट पर क्लिक करें जिसे आपको सभी उपयोगकर्ताओं के लिए रिलीज़ करना है. फिर, कॉन्टेक्स्ट मेन्यू () वैरिएंट रोल आउट करें पर क्लिक करें.
4. सभी उपयोगकर्ताओं के लिए अपना एक्सपेरिमेंट रोल आउट करने के लिए, यह तरीका अपनाएं:
   • Remote Config एक्सपेरिमेंट के लिए, कोई वैरिएंट चुनें, ताकि यह तय किया जा सके कि Remote Config के किन पैरामीटर वैल्यू को अपडेट करना है. एक्सपेरिमेंट बनाते समय तय की गई टारगेटिंग की शर्तों को नई शर्त के तौर पर आपके टेंप्लेट में जोड़ दिया जाता है, ताकि यह पक्का किया जा सके कि रोल आउट, सिर्फ़ एक्सपेरिमेंट के लिए चुने गए उपयोगकर्ताओं को दिखे. बदलावों को देखने के लिए, रिमोट कॉन्फ़िगरेशन में देखें पर क्लिक करें. इसके बाद, बदलावों को पब्लिश करें पर क्लिक करके, रोल आउट को पूरा करें.

एक्सपेरिमेंट को बड़ा करना

अगर आपको लगता है कि किसी एक्सपेरिमेंट में A/B Testing को लीडर घोषित करने के लिए ज़रूरत के मुताबिक उपयोगकर्ता नहीं मिल रहे हैं, तो एक्सपेरिमेंट को ज़्यादा लोगों तक पहुंचाया जा सकता है. इससे ऐप्लिकेशन के उपयोगकर्ताओं के ज़्यादा प्रतिशत तक पहुंचा जा सकता है.

1. Firebase कंसोल के नेविगेशन मेन्यू में, DevOps और यूज़र ऐक्टिविटी सेक्शन में जाकर, Remote Config पर क्लिक करें.
2. A/B टेस्ट टैब पर क्लिक करें.
3. चल रहे उस एक्सपेरिमेंट को चुनें जिसमें आपको बदलाव करना है.
4. एक्सपेरिमेंट की खास जानकारी में, कॉन्टेक्स्ट मेन्यू () पर क्लिक करें. इसके बाद, चल रहे एक्सपेरिमेंट में बदलाव करें पर क्लिक करें.
5. टारगेटिंग डायलॉग बॉक्स में, चल रहे एक्सपेरिमेंट में शामिल उपयोगकर्ताओं का प्रतिशत बढ़ाने का विकल्प दिखता है. मौजूदा प्रतिशत से ज़्यादा की कोई संख्या चुनें और पब्लिश करें पर क्लिक करें. एक्सपेरिमेंट को आपके तय किए गए प्रतिशत उपयोगकर्ताओं को दिखाया जाएगा.

किसी एक्सपेरिमेंट का डुप्लीकेट बनाना

1. Firebase कंसोल के नेविगेशन मेन्यू में, DevOps और यूज़र ऐक्टिविटी सेक्शन में जाकर, Remote Config पर क्लिक करें.
2. A/B टेस्ट टैब पर क्लिक करें.
3. चल रहे या पूरे हो चुके उस एक्सपेरिमेंट को चुनें जिसे आपको रोकना है.
4. पूरा हो गया या चल रहा है पर क्लिक करें. इसके बाद, अपने एक्सपेरिमेंट पर पॉइंटर को रखें, कॉन्टेक्स्ट मेन्यू () पर क्लिक करें. इसके बाद, एक्सपेरिमेंट का डुप्लीकेट बनाएं या एक्सपेरिमेंट रोकें पर क्लिक करें.

किसी एक्सपेरिमेंट को रोकना

1. Firebase कंसोल के नेविगेशन मेन्यू में, DevOps और यूज़र ऐक्टिविटी सेक्शन में जाकर, Remote Config पर क्लिक करें.
2. A/B टेस्ट टैब पर क्लिक करें.
3. चल रहे या पूरे हो चुके उस एक्सपेरिमेंट को चुनें जिसे आपको रोकना है.
4. पूरा हो गया या चल रहा है पर क्लिक करें. इसके बाद, अपने एक्सपेरिमेंट पर पॉइंटर को रखें, कॉन्टेक्स्ट मेन्यू () पर क्लिक करें, और फिर एक्सपेरिमेंट रोकें पर क्लिक करें.

वेब क्लाइंट की पहचान और एक्सपेरिमेंट की परसिस्टेंस

ध्यान दें: यह सेक्शन सिर्फ़ वेब ऐप्लिकेशन के लिए है.

जब कोई उपयोगकर्ता पहली बार किसी ब्राउज़र में Firebase A/B Testing का इस्तेमाल करके कोई वेब ऐप्लिकेशन लॉन्च करता है, तो एक यूनीक Firebase इंस्टॉलेशन आईडी (FID) जनरेट होता है. यह एफ़आईडी, ब्राउज़र के IndexedDB में सेव रहता है, ताकि अलग-अलग सेशन में ऐप्लिकेशन के इंस्टेंस की पहचान की जा सके.

Firebase A/B Testing, उपयोगकर्ताओं को एक्सपेरिमेंट के वैरिएंट असाइन करने के लिए एफ़आईडी का इस्तेमाल करता है. वहीं, Google Analytics इसका इस्तेमाल इवेंट एग्रीगेशन के लिए करता है, ताकि हर वैरिएंट में उपयोगकर्ता के व्यवहार को मेज़र और उसका विश्लेषण किया जा सके.

IndexedDB में एफ़आईडी सेव होने की वजह से, Firebase A/B Testing किसी उपयोगकर्ता को नया उपयोगकर्ता तब मानता है, जब वह आपके ऐप्लिकेशन को किसी दूसरे ब्राउज़र या गुप्त विंडो से ऐक्सेस करता है या अपने ब्राउज़र के IndexedDB को मिटा देता है. इसका मतलब है कि अलग-अलग ब्राउज़र या ब्राउज़िंग सेशन का इस्तेमाल करने पर, किसी उपयोगकर्ता को एक्सपेरिमेंट के अलग-अलग वैरिएंट में शामिल किया जा सकता है.

उपयोगकर्ता को टारगेट करना

उपयोगकर्ता को टारगेट करने की इन शर्तों का इस्तेमाल करके, अपने एक्सपेरिमेंट में शामिल करने के लिए उपयोगकर्ताओं को टारगेट किया जा सकता है.

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

नियम का प्रकार	ऑपरेटर	वैल्यू	ध्यान दें
ऐप्लिकेशन	==	अपने Firebase प्रोजेक्ट से जुड़े ऐप्लिकेशन के लिए, ऐप्लिकेशन आईडी की सूची में से चुनें.	Firebase में कोई ऐप्लिकेशन जोड़ने पर, आपको बंडल आईडी या Android पैकेज का नाम डालना होता है. इससे एक एट्रिब्यूट तय होता है, जो Remote Config के नियमों में ऐप्लिकेशन आईडी के तौर पर दिखता है. इस एट्रिब्यूट का इस्तेमाल इस तरह करें: Apple प्लैटफ़ॉर्म के लिए: ऐप्लिकेशन के CFBundleIdentifier का इस्तेमाल करें. Xcode में अपने ऐप्लिकेशन के मुख्य टारगेट के लिए, General टैब में बंडल आइडेंटिफ़ायर देखा जा सकता है. Android के लिए: ऐप्लिकेशन के applicationId का इस्तेमाल करें. applicationId को ऐप्लिकेशन-लेवल की build.gradle(.kts) फ़ाइल में देखा जा सकता है.
ऐप्लिकेशन वर्शन	स्ट्रिंग वैल्यू के लिए: एग्ज़ैक्ट मैच करता है, शामिल है, शामिल नहीं है, रेगुलर एक्सप्रेशन शामिल है संख्या वाली वैल्यू के लिए: <, <=, =, !=, >, >=	अपने ऐप्लिकेशन के उन वर्शन के बारे में बताएं जिन्हें टारगेट करना है. इस नियम का इस्तेमाल करने से पहले, आपको ऐप्लिकेशन आईडी नियम का इस्तेमाल करके, अपने Firebase प्रोजेक्ट से जुड़ा Android/Apple ऐप्लिकेशन चुनना होगा.	Apple प्लैटफ़ॉर्म के लिए: ऐप्लिकेशन के CFBundleShortVersionString का इस्तेमाल करें. ध्यान दें: पक्का करें कि आपका Apple ऐप्लिकेशन, Firebase Apple प्लैटफ़ॉर्म SDK टूल के 6.24.0 या इसके बाद के वर्शन का इस्तेमाल कर रहा हो. ऐसा इसलिए, क्योंकि CFBundleShortVersionString को पुराने वर्शन में नहीं भेजा जा रहा है. ज़्यादा जानकारी के लिए, रिलीज़ नोट देखें. Android के लिए: ऐप्लिकेशन के versionName का इस्तेमाल करें. ध्यान दें: संख्याओं की तुलना करने वाले ऑपरेटर (<, <=, =, !=, >, >=) सिर्फ़ संख्याओं वाले सिमैंटिक वर्शन (जैसे कि 1.2.3) के साथ काम करते हैं. ये रिलीज़ से पहले वाले सफ़िक्स या हाइफ़न (जैसे कि -beta या -rc) के साथ काम नहीं करते. बिना संख्याओं वाले सफ़िक्स या हाइफ़न (जैसे कि 1.5-beta) वाली वर्शन स्ट्रिंग के लिए, स्ट्रिंग ऑपरेटर का इस्तेमाल करें. जैसे, रेगुलर एक्सप्रेशन शामिल है, शामिल है या एग्ज़ैक्ट मैच. इस नियम के लिए स्ट्रिंग की तुलनाएं केस-सेंसिटिव होती हैं. पूरी तरह मेल खाने वाले, इसमें शामिल है, इसमें शामिल नहीं है या इसमें रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, कई वैल्यू चुनी जा सकती हैं. रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के सभी या कुछ हिस्से से मैच हो सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरी स्ट्रिंग से मैच करने के लिए, ^ और $ ऐंकर का भी इस्तेमाल किया जा सकता है.
बिल्ड नंबर	स्ट्रिंग वैल्यू के लिए: पूरी तरह से मैच करता है, शामिल है, शामिल नहीं है, रेगुलर एक्सप्रेशन संख्या वाली वैल्यू के लिए: =, ≠, >, ≥, <, ≤	अपने ऐप्लिकेशन के उन बिल्ड के बारे में बताएं जिन्हें टारगेट करना है. इस नियम का इस्तेमाल करने से पहले, आपको ऐप्लिकेशन आईडी नियम का इस्तेमाल करके, अपने Firebase प्रोजेक्ट से जुड़ा कोई Apple या Android ऐप्लिकेशन चुनना होगा.	यह ऑपरेटर सिर्फ़ Apple और Android ऐप्लिकेशन के लिए उपलब्ध है. यह Apple के लिए ऐप्लिकेशन के CFBundleVersion और Android के लिए versionCode से मेल खाता है. इस नियम के लिए स्ट्रिंग की तुलनाएं केस-सेंसिटिव होती हैं. एग्ज़ैक्ट मैच, इसमें शामिल है, इसमें शामिल नहीं है या इसमें रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, कई वैल्यू चुनी जा सकती हैं. रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के सभी या कुछ हिस्से से मैच हो सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरी स्ट्रिंग से मैच करने के लिए, ^ और $ ऐंकर का भी इस्तेमाल किया जा सकता है.
प्लेटफ़ॉर्म	==	iOS Android वेब
ऑपरेटिंग सिस्टम	==	टारगेट करने के लिए, ऑपरेटिंग सिस्टम तय करें. इस नियम का इस्तेमाल करने से पहले, आपको ऐप्लिकेशन आईडी नियम का इस्तेमाल करके, अपने Firebase प्रोजेक्ट से जुड़ा कोई वेब ऐप्लिकेशन चुनना होगा.	अगर ऑपरेटिंग सिस्टम और उसका वर्शन, दी गई सूची में मौजूद टारगेट वैल्यू से मैच करता है, तो यह नियम किसी वेब ऐप्लिकेशन इंस्टेंस के लिए true दिखाता है.
ब्राउज़र	==	टारगेट करने के लिए ब्राउज़र तय करें. इस नियम का इस्तेमाल करने से पहले, आपको ऐप्लिकेशन आईडी नियम का इस्तेमाल करके, अपने Firebase प्रोजेक्ट से जुड़ा कोई वेब ऐप्लिकेशन चुनना होगा.	अगर ब्राउज़र और उसका वर्शन, दी गई सूची में मौजूद टारगेट वैल्यू से मैच करता है, तो यह नियम किसी वेब ऐप्लिकेशन इंस्टेंस के लिए true के तौर पर लागू होता है.
डिवाइस श्रेणी	है, नहीं है	मोबाइल	यह नियम यह आकलन करता है कि आपके वेब ऐप्लिकेशन को ऐक्सेस करने वाला डिवाइस, मोबाइल है या नहीं (डेस्कटॉप या कंसोल). इस तरह का नियम सिर्फ़ वेब ऐप्लिकेशन के लिए उपलब्ध है.
भाषाएं	में है	एक या इससे ज़्यादा भाषाएं चुनें.	अगर किसी ऐप्लिकेशन इंस्टेंस को ऐसे डिवाइस पर इंस्टॉल किया गया है जिसमें सूची में शामिल भाषाओं में से किसी एक का इस्तेमाल किया जाता है, तो उस ऐप्लिकेशन इंस्टेंस के लिए इस नियम की वैल्यू true होगी.
देश/क्षेत्र	में है	एक या इससे ज़्यादा देश या इलाके चुनें.	अगर ऐप्लिकेशन का इंस्टेंस, सूची में दिए गए किसी भी देश या इलाके में मौजूद है, तो यह नियम उस इंस्टेंस के लिए true का आकलन करता है. डिवाइस के देश का कोड, अनुरोध में मौजूद डिवाइस के आईपी पते या Firebase Analytics से तय किए गए देश के कोड का इस्तेमाल करके तय किया जाता है. ऐसा तब होता है, जब Analytics का डेटा Firebase के साथ शेयर किया जाता है.
उपयोगकर्ता ऑडियंस	कम से कम एक शामिल है	आपने अपने प्रोजेक्ट के लिए जो Google Analytics ऑडियंस सेट अप की हैं उनकी सूची में से एक या उससे ज़्यादा ऑडियंस चुनें.	इस नियम के लिए, ऐप्लिकेशन आईडी का नियम ज़रूरी है, ताकि आपके Firebase प्रोजेक्ट से जुड़े ऐप्लिकेशन को चुना जा सके. ध्यान दें: कई Analytics ऑडियंस को इवेंट या उपयोगकर्ता प्रॉपर्टी के हिसाब से तय किया जाता है. ये प्रॉपर्टी, ऐप्लिकेशन के उपयोगकर्ताओं की कार्रवाइयों पर आधारित हो सकती हैं. इसलिए, किसी ऐप्लिकेशन इंस्टेंस के लिए, ऑडियंस में शामिल उपयोगकर्ता नियम को लागू होने में कुछ समय लग सकता है. इसका मतलब है कि अगर कोई उपयोगकर्ता तकनीकी तौर पर किसी ऑडियंस में शामिल होने की ज़रूरी शर्तें पूरी करता है, लेकिन fetchAndActivate() के लागू होने के समय Analytics ने उस उपयोगकर्ता को ऑडियंस में नहीं जोड़ा है, तो वह उपयोगकर्ता शर्त को पूरा नहीं करेगा.
उपयोगकर्ता प्रॉपर्टी	स्ट्रिंग वैल्यू के लिए: शामिल है, शामिल नहीं है, एग्ज़ैक्ट मैच, रेगुलर एक्सप्रेशन शामिल है संख्या वाली वैल्यू के लिए: =, ≠, >, ≥, <, ≤ ध्यान दें: क्लाइंट पर, उपयोगकर्ता प्रॉपर्टी के लिए सिर्फ़ स्ट्रिंग वैल्यू सेट की जा सकती हैं. न्यूमेरिक ऑपरेटर का इस्तेमाल करने वाली शर्तों के लिए, Remote Config संबंधित उपयोगकर्ता प्रॉपर्टी की वैल्यू को इंटीजर/फ़्लोट में बदल देता है.	उपलब्ध Google Analytics उपयोगकर्ता प्रॉपर्टी की सूची में से चुनें.	उपयोगकर्ता प्रॉपर्टी का इस्तेमाल करके, अपने उपयोगकर्ताओं के किसी खास सेगमेंट के लिए ऐप्लिकेशन को पसंद के मुताबिक बनाने का तरीका जानने के लिए, Remote Config और उपयोगकर्ता प्रॉपर्टी देखें. उपयोगकर्ता प्रॉपर्टी के बारे में ज़्यादा जानने के लिए, ये गाइड देखें: Apple पर उपयोगकर्ता प्रॉपर्टी सेट करना Android पर उपयोगकर्ता प्रॉपर्टी सेट करना एग्ज़ैक्ट मैच, इसमें शामिल है, इसमें शामिल नहीं है या इसमें रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, कई वैल्यू चुनी जा सकती हैं. रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के सभी या कुछ हिस्से से मैच हो सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरी स्ट्रिंग से मैच करने के लिए, ^ और $ ऐंकर का भी इस्तेमाल किया जा सकता है. ध्यान दें: Remote Config शर्तें बनाते समय, अपने-आप इकट्ठा होने वाली उपयोगकर्ता प्रॉपर्टी उपलब्ध नहीं होती हैं.
उपयोगकर्ताओं का रैंडम प्रतिशत	स्लाइडर (Firebase कंसोल में. REST API, <=, >, और between ऑपरेटर का इस्तेमाल करता है.	0-100	इस फ़ील्ड का इस्तेमाल करके, ऐप्लिकेशन के इंस्टेंस के रैंडम सैंपल में बदलाव लागू करें. सैंपल का साइज़ .0001% जितना छोटा हो सकता है. स्लाइडर विजेट का इस्तेमाल करके, रैंडम तरीके से शफ़ल किए गए उपयोगकर्ताओं (ऐप्लिकेशन के इंस्टेंस) को ग्रुप में बांटें. हर ऐप्लिकेशन इंस्टेंस को किसी रैंडम पूर्णांक या भिन्न संख्या के साथ लगातार मैप किया जाता है. ऐसा उस प्रोजेक्ट में तय किए गए सीड के हिसाब से किया जाता है. सीड वैल्यू में एक से 32 वर्ण हो सकते हैं. इनमें अक्षर और अंक, बिंदु, हाइफ़न, और/या अंडरस्कोर शामिल हो सकते हैं. जब तक सीड वैल्यू में बदलाव नहीं किया जाता, तब तक नियम डिफ़ॉल्ट कुंजी का इस्तेमाल करेगा. यह कुंजी, Firebase कंसोल में सीड में बदलाव करें के तौर पर दिखती है. सीड फ़ील्ड को मिटाकर, किसी नियम को डिफ़ॉल्ट कुंजी का इस्तेमाल करने के लिए वापस लाया जा सकता है. दिए गए प्रतिशत की रेंज में, एक ही ऐप्लिकेशन इंस्टेंस को लगातार टारगेट करने के लिए, सभी शर्तों में एक ही सीड वैल्यू का इस्तेमाल करें. इसके अलावा, किसी तय प्रतिशत रेंज के लिए, ऐप्लिकेशन इंस्टेंस के रैंडम तरीके से असाइन किए गए नए ग्रुप को चुना जा सकता है. इसके लिए, नया सीड तय करना होगा. उदाहरण के लिए, एक-दूसरे से जुड़ी दो ऐसी शर्तें बनाने के लिए जो किसी ऐप्लिकेशन के 5% उपयोगकर्ताओं पर अलग-अलग लागू होती हैं, एक शर्त को 0% से 5% के बीच के प्रतिशत से मैच करने के लिए कॉन्फ़िगर किया जा सकता है. साथ ही, दूसरी शर्त को 5% से 10% के बीच की रेंज से मैच करने के लिए कॉन्फ़िगर किया जा सकता है. कुछ उपयोगकर्ताओं को दोनों ग्रुप में रैंडम तरीके से शामिल करने के लिए, हर शर्त के नियमों के लिए अलग-अलग सीड वैल्यू का इस्तेमाल करें.
इंपोर्ट किया गया सेगमेंट	में है	इंपोर्ट किए गए एक या उससे ज़्यादा सेगमेंट चुनें.	इस नियम के लिए, कस्टम इंपोर्ट किए गए सेगमेंट सेट अप करने होंगे.
तिथि/समय	पहले, बाद में	डिवाइस के टाइमज़ोन या किसी तय किए गए टाइमज़ोन में, तय की गई तारीख और समय. जैसे, "(GMT+11) सिडनी का समय."	यह मौजूदा समय की तुलना, डिवाइस से फ़ेच किए गए समय से करता है.
फ़र्स्ट ओपन रिपोर्ट	पहले, बाद में	उपयोगकर्ताओं को पहली बार आपका ऐप्लिकेशन खोलने के आधार पर टारगेट करें: आने वाले समय में, किसी तय तारीख और समय के बाद पहली बार आपका ऐप्लिकेशन खोलने वाले उपयोगकर्ताओं को टारगेट करने के लिए, नए उपयोगकर्ता चुनें. समयसीमा चुनें. इससे उन उपयोगकर्ताओं को टारगेट किया जा सकता है जो आपकी तय की गई तारीख और समय से पहले या बाद में, पहली बार आपका ऐप्लिकेशन खोलते हैं. किसी खास समयसीमा के अंदर उपयोगकर्ताओं को टारगेट करने के लिए, इससे पहले और इसके बाद की शर्तों को जोड़ें.	पहली बार ऐप्लिकेशन खोलने के आधार पर उपयोगकर्ताओं को टारगेट करने की सुविधा, Android, iOS या वेब ऐप्लिकेशन चुनने के बाद उपलब्ध होती है. इन एसडीके की ज़रूरत होती है: Google Analytics के लिए Firebase SDK Apple प्लैटफ़ॉर्म SDK v9.0.0+ या Android SDK v21.1.1+ (Firebase BoM v30.3.0+), और JavaScript SDK v12.8.0+. फ़र्स्ट ओपन इवेंट के दौरान, क्लाइंट पर Analytics भी चालू होना चाहिए.
इंस्टॉलेशन आईडी	में है	टारगेट करने के लिए, एक या उससे ज़्यादा इंस्टॉलेशन आईडी (ज़्यादा से ज़्यादा 50) डालें.	अगर किसी इंस्टॉलेशन का आईडी, कॉमा लगाकर अलग की गई वैल्यू की सूची में मौजूद है, तो यह नियम उस इंस्टॉलेशन के लिए true का आकलन करता है. इंस्टॉलेशन आईडी पाने का तरीका जानने के लिए, क्लाइंट आइडेंटिफ़ायर वापस पाना लेख पढ़ें.
उपयोगकर्ता मौजूद है	(कोई ऑपरेटर नहीं)	यह मौजूदा प्रोजेक्ट के सभी ऐप्लिकेशन के सभी उपयोगकर्ताओं को टारगेट करता है.	इस शर्त वाले नियम का इस्तेमाल करके, प्रोजेक्ट के सभी उपयोगकर्ताओं को मैच करें. इससे कोई फ़र्क़ नहीं पड़ता कि वे किस ऐप्लिकेशन या प्लैटफ़ॉर्म का इस्तेमाल कर रहे हैं. Remote Config को मनमुताबिक बनाने की सुविधा का इस्तेमाल करते समय, इस ऑपरेटर का इस्तेमाल करके यह पक्का किया जा सकता है कि प्रोजेक्ट के सभी उपयोगकर्ताओं को उनकी पसंद के मुताबिक वैल्यू मिलें.
कस्टम सिग्नल	स्ट्रिंग वैल्यू के लिए: शामिल है, शामिल नहीं है, एग्ज़ैक्ट मैच, रेगुलर एक्सप्रेशन शामिल है संख्या वाली वैल्यू के लिए: =, ≠, >, ≥, <, ≤ वर्शन वैल्यू के लिए: =, ≠, >, ≥, <, ≤	इस नियम के लिए स्ट्रिंग की तुलनाएं केस-सेंसिटिव होती हैं. 'पूरी तरह से मैच करता है', 'इसमें शामिल है', 'इसमें शामिल नहीं है' या 'इसमें रेगुलर एक्सप्रेशन ऑपरेटर शामिल है' का इस्तेमाल करते समय, कई वैल्यू चुनी जा सकती हैं. 'रेगुलर एक्सप्रेशन शामिल है' ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के सभी या कुछ हिस्से से मैच हो सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरी स्ट्रिंग को मैच करने के लिए, ^ और $ ऐंकर का भी इस्तेमाल किया जा सकता है. क्लाइंट एनवायरमेंट के लिए, इस तरह के डेटा का इस्तेमाल किया जा सकता है: iOS: int, double Android: int, long, double वेब: नंबर वह संख्या जो मैच करने के लिए वर्शन नंबर दिखाती है. उदाहरण के लिए, 2.1.0.	कस्टम सिग्नल की शर्तों और इस्तेमाल किए जाने वाले कंडिशनल एक्सप्रेशन के बारे में ज़्यादा जानने के लिए, कस्टम सिग्नल की शर्तें और शर्तें बनाने के लिए इस्तेमाल किए जाने वाले एलिमेंट लेख पढ़ें.

ध्यान दें: Analytics उपयोगकर्ता ऑडियंस को टारगेट करने वाले एक्सपेरिमेंट, Analytics डेटा प्रोसेसिंग में लगने वाले समय के हिसाब से होते हैं. भले ही, कोई उपयोगकर्ता तकनीकी तौर पर किसी ऑडियंस में शामिल होने की ज़रूरी शर्तें पूरी करता हो, लेकिन अगर fetchAndActivate() के लागू होने पर Analytics ने अब तक उस उपयोगकर्ता को ऑडियंस में नहीं जोड़ा है, तो उसे एक्सपेरिमेंट में शामिल नहीं किया जाएगा.

A/B Testing मेट्रिक

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

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

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

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

यहां दी गई टेबल में, लक्ष्य मेट्रिक और अन्य मेट्रिक का हिसाब लगाने के तरीके के बारे में जानकारी दी गई है.

लक्ष्य मेट्रिक

मेट्रिक	ब्यौरा
वे उपयोगकर्ता जिनके ऐप बंद नहीं हुए	उन उपयोगकर्ताओं का प्रतिशत जिन्हें आपके ऐप्लिकेशन में ऐसी गड़बड़ियों का सामना नहीं करना पड़ा जिनका पता एक्सपेरिमेंट के दौरान Firebase Crashlytics SDK टूल ने लगाया था. ध्यान दें: Firebase Crashlytics का इस्तेमाल वेब ऐप्लिकेशन के लिए नहीं किया जा सकता.
विज्ञापन से मिलने वाला अनुमानित रेवेन्यू	विज्ञापन से होने वाली अनुमानित आय.
अनुमानित कुल रेवेन्यू	खरीदारी और विज्ञापन से मिलने वाले अनुमानित रेवेन्यू की कुल वैल्यू.
खरीदारी से हुई आय	सभी purchase और in_app_purchase इवेंट की कुल वैल्यू.
रिटेंशन (1 दिन)	ऐसे उपयोगकर्ताओं की संख्या जो रोज़ाना आपके ऐप्लिकेशन पर वापस आते हैं.
रिटेंशन (दो से तीन दिन)	ऐसे उपयोगकर्ताओं की संख्या जो दो से तीन दिनों के अंदर आपके ऐप्लिकेशन पर वापस आते हैं.
रिटेंशन (चार से सात दिन)	ऐसे उपयोगकर्ताओं की संख्या जो चार से सात दिनों के अंदर आपके ऐप्लिकेशन पर वापस आते हैं.
रिटेंशन (8 से 14 दिन)	ऐसे उपयोगकर्ताओं की संख्या जो 8 से 14 दिनों के अंदर आपके ऐप्लिकेशन पर वापस आते हैं.
रिटेंशन (15 दिन से ज़्यादा)	ऐसे उपयोगकर्ताओं की संख्या जो आपके ऐप्लिकेशन को आखिरी बार इस्तेमाल करने के 15 या उससे ज़्यादा दिनों के बाद, उस पर वापस आते हैं.
first_open	Analytics इवेंट, जो तब ट्रिगर होता है, जब कोई उपयोगकर्ता किसी ऐप्लिकेशन को इंस्टॉल या फिर से इंस्टॉल करने के बाद, उसे पहली बार खोलता है. कन्वर्ज़न फ़नल के हिस्से के तौर पर इस्तेमाल किया जाता है.

दूसरे मेट्रिक

मेट्रिक	ब्यौरा
notification_dismiss	Analytics इवेंट, जो सूचना बनाने की सुविधा से भेजी गई सूचना को खारिज करने पर ट्रिगर होता है. यह सिर्फ़ Android पर काम करता है.
notification_receive	Analytics इवेंट, जो तब ट्रिगर होता है, जब ऐप्लिकेशन के बैकग्राउंड में होने के दौरान, सूचना बनाने की सुविधा से भेजी गई सूचना मिलती है (सिर्फ़ Android के लिए).
os_update	Analytics इवेंट, जो यह ट्रैक करता है कि डिवाइस का ऑपरेटिंग सिस्टम किसी नए वर्शन में कब अपडेट किया गया.ज़्यादा जानने के लिए, अपने-आप इकट्ठा होने वाले इवेंट देखें. यह मेट्रिक, वेब ऐप्लिकेशन के लिए काम नहीं करती.
screen_view	Analytics इवेंट, जो आपके ऐप्लिकेशन में देखी गई स्क्रीन को ट्रैक करता है. ज़्यादा जानने के लिए, स्क्रीन व्यू ट्रैक करना देखें.
session_start	यह एक Analytics इवेंट है, जो आपके ऐप्लिकेशन में उपयोगकर्ता सेशन की गिनती करता है. ज़्यादा जानने के लिए, अपने-आप इकट्ठा होने वाले इवेंट देखें.

BigQuery डेटा एक्सपोर्ट

Firebase कंसोल में A/B Testing एक्सपेरिमेंट का डेटा देखने के अलावा, BigQuery में एक्सपेरिमेंट के डेटा की जांच और विश्लेषण किया जा सकता है. A/B Testing में BigQuery के लिए कोई अलग टेबल नहीं होती है. एक्सपेरिमेंट और वैरिएंट की मेंबरशिप, Analytics इवेंट टेबल में मौजूद हर Google Analytics इवेंट में सेव की जाती हैं.

एक्सपेरिमेंट की जानकारी वाली उपयोगकर्ता प्रॉपर्टी, userProperty.key like "firebase_exp_%" या userProperty.key = "firebase_exp_01" फ़ॉर्मैट में होती हैं. यहां 01, एक्सपेरिमेंट आईडी है और userProperty.value.string_value में एक्सपेरिमेंट के वैरिएंट का (शून्य पर आधारित) इंडेक्स होता है.

एक्सपेरिमेंट का डेटा निकालने के लिए, एक्सपेरिमेंट की इन उपयोगकर्ता प्रॉपर्टी का इस्तेमाल किया जा सकता है. इससे आपको अपने एक्सपेरिमेंट के नतीजों को कई अलग-अलग तरीकों से बांटने और A/B Testing के नतीजों की पुष्टि करने की सुविधा मिलती है.

शुरू करने के लिए, इस गाइड में बताए गए तरीके से ये काम करें:

1. Firebase कंसोल में, Google Analytics के लिए BigQuery एक्सपोर्ट करने की सुविधा चालू करें
2. BigQuery का इस्तेमाल करके A/B Testing डेटा ऐक्सेस करना
3. क्वेरी के उदाहरण देखें

Firebase कंसोल में, Google Analytics के लिए BigQuery एक्सपोर्ट करने की सुविधा चालू करें

अगर आपके पास Spark प्लान है, तो BigQuery सैंडबॉक्स का इस्तेमाल करके, BigQuery को बिना किसी शुल्क के ऐक्सेस किया जा सकता है. हालांकि, इसके लिए सैंडबॉक्स की सीमाएं लागू होंगी. ज़्यादा जानकारी के लिए, कीमत और BigQuery सैंडबॉक्स देखें.

सबसे पहले, पक्का करें कि Analytics का डेटा BigQuery में एक्सपोर्ट किया जा रहा हो:

1. Firebase कंसोल में, सेटिंग > इंटिग्रेशन टैब पर जाएं.

2. BigQuery कार्ड में, मैनेज करें पर क्लिक करें. इसके बाद, पुष्टि करें कि आपका प्रोजेक्ट, BigQuery में Analytics डेटा एक्सपोर्ट कर रहा है.

   अगर कार्ड पर लिंक करें लिखा है, तो आपको एक्सपोर्ट सेट अप करना होगा. इसके लिए, अगले चरण पर जाएं.

3. अगर आपको एक्सपोर्ट की सुविधा सेट अप करनी है, तो:

   1. Firebase को BigQuery से लिंक करने के बारे में जानकारी पढ़ें. इसके बाद, आगे बढ़ें पर क्लिक करें.

   2. इंटिग्रेशन कॉन्फ़िगर करें सेक्शन में, Google Analytics को चालू करें.

   3. कोई क्षेत्र चुनें और एक्सपोर्ट सेटिंग चुनें.

      ध्यान दें: Firebase की सेटिंग के लिए, Google Analytics के बारे में ज़्यादा जानकारी पाने के लिए, डेटा कलेक्शन लेख पढ़ें.

   4. BigQuery से लिंक करें पर क्लिक करें.

डेटा एक्सपोर्ट करने के लिए चुने गए तरीके के आधार पर, टेबल उपलब्ध होने में एक दिन लग सकता है. BigQuery में प्रोजेक्ट डेटा एक्सपोर्ट करने के बारे में ज़्यादा जानने के लिए, BigQuery में प्रोजेक्ट डेटा एक्सपोर्ट करना लेख पढ़ें.

BigQuery में A/B Testing का डेटा ऐक्सेस करना

किसी खास एक्सपेरिमेंट के डेटा के लिए क्वेरी करने से पहले, आपको अपनी क्वेरी में इस्तेमाल करने के लिए, इनमें से कुछ या सभी चीज़ें हासिल करनी होंगी:

• एक्सपेरिमेंट आईडी: इसे एक्सपेरिमेंट की खास जानकारी वाले पेज के यूआरएल से हासिल किया जा सकता है. उदाहरण के लिए, अगर आपका यूआरएल https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25 जैसा दिखता है, तो एक्सपेरिमेंट आईडी 25 है.
• Google Analytics प्रॉपर्टी आईडी: यह आपका नौ अंकों वाला Google Analytics प्रॉपर्टी आईडी है. यह आपको Google Analytics में मिल सकता है. यह BigQuery में भी दिखता है. इसके लिए, आपको अपने प्रोजेक्ट के नाम को बड़ा करके, Google Analytics इवेंट टेबल (project_name.analytics_000000000.events) का नाम दिखाना होगा.
• एक्सपेरिमेंट की तारीख: तेज़ और ज़्यादा असरदार क्वेरी बनाने के लिए, अपनी क्वेरी को Google Analytics रोज़ के इवेंट टेबल पार्टिशन तक सीमित रखना एक अच्छा तरीका है. इनमें आपके एक्सपेरिमेंट का डेटा होता है. इन टेबल की पहचान YYYYMMDD सफ़िक्स से की जाती है. इसलिए, अगर आपका एक्सपेरिमेंट 2 फ़रवरी, 2026 से 2 मई, 2026 तक चला, तो आपको _TABLE_SUFFIX between '20260202' AND '20260502' तय करना होगा. उदाहरण के लिए, किसी खास एक्सपेरिमेंट की वैल्यू चुनें देखें.
• इवेंट के नाम: आम तौर पर, ये आपकी उन लक्ष्य मेट्रिक से मेल खाते हैं जिन्हें आपने एक्सपेरिमेंट में कॉन्फ़िगर किया है. उदाहरण के लिए, in_app_purchase इवेंट, ad_impression या user_retention इवेंट.

सलाह: अगर आपने ब्लेज़ प्लान लिया है, तो Firebase आपके चुने गए एक्सपेरिमेंट के लिए, सैंपल क्वेरी जनरेट कर सकता है. इससे एक्सपेरिमेंट का नाम, वैरिएंट, इवेंट का नाम, और इवेंट की संख्या निकाली जा सकती है. Firebase कंसोल के अपने-आप जनरेट होने वाले क्वेरी का इस्तेमाल करके, एक्सपेरिमेंट के डेटा के बारे में क्वेरी करने

के बारे में ज़्यादा जानें

क्वेरी जनरेट करने के लिए ज़रूरी जानकारी इकट्ठा करने के बाद:

1. Google Cloud कंसोल में, BigQuery पर जाएं.
2. अपना प्रोजेक्ट चुनें. इसके बाद, एसक्यूएल क्वेरी बनाएं को चुनें.
3. अपनी क्वेरी जोड़ें. क्वेरी के उदाहरण देखने के लिए, क्वेरी के उदाहरण एक्सप्लोर करें पर जाएं.
4. Run पर क्लिक करें.

अहम जानकारी: यहां दिए गए चरणों में, Google Cloud कंसोल का इस्तेमाल करने का तरीका बताया गया है. हालांकि, BigQuery से क्वेरी करने के लिए, सीएलआई या क्लाइंट लाइब्रेरी का भी इस्तेमाल किया जा सकता है. ज़्यादा जानने के लिए, BigQuery दस्तावेज़ पढ़ें.

Firebase कंसोल की अपने-आप जनरेट हुई क्वेरी का इस्तेमाल करके, एक्सपेरिमेंट का डेटा देखना

अगर Blaze प्लान का इस्तेमाल किया जा रहा है, तो एक्सपेरिमेंट की खास जानकारी वाले पेज पर एक सैंपल क्वेरी मिलती है. इससे, आपको एक्सपेरिमेंट का नाम, वैरिएंट, इवेंट के नाम, और एक्सपेरिमेंट के लिए इवेंट की संख्या की जानकारी मिलती है.

अपने-आप जनरेट हुई क्वेरी पाने और उसे चलाने के लिए:

1. Firebase कंसोल में, DevOps और यूज़र ऐक्टिविटी > A/B टेस्टिंग पर जाएं.
2. A/B Testing का वह एक्सपेरिमेंट चुनें जिसकी क्वेरी करनी है. इसके बाद, एक्सपेरिमेंट की खास जानकारी खोलें.
3. विकल्प मेन्यू में, BigQuery इंटिग्रेशन के नीचे, एक्सपेरिमेंट के डेटा के लिए क्वेरी करें को चुनें. इससे Google Cloud कंसोल में BigQuery में आपका प्रोजेक्ट खुल जाता है. साथ ही, आपको एक बुनियादी क्वेरी मिलती है. इसका इस्तेमाल करके, एक्सपेरिमेंट के डेटा के बारे में क्वेरी की जा सकती है.

यहां दिए गए उदाहरण में, "विंटर वेलकम एक्सपेरिमेंट" नाम के एक्सपेरिमेंट के लिए जनरेट की गई क्वेरी दिखाई गई है. इसमें तीन वैरिएंट (बेसलाइन के साथ) शामिल हैं. यह हर इवेंट के लिए, चालू एक्सपेरिमेंट का नाम, वैरिएंट का नाम, यूनीक इवेंट, और इवेंट की संख्या दिखाता है. ध्यान दें कि क्वेरी बिल्डर, टेबल के नाम में आपके प्रोजेक्ट का नाम नहीं बताता है, क्योंकि यह सीधे आपके प्रोजेक्ट में खुलता है.

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20260202' AND '20260502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

क्वेरी के अन्य उदाहरणों के लिए, क्वेरी के उदाहरण एक्सप्लोर करें पर जाएं.

क्वेरी के उदाहरण एक्सप्लोर करें

यहां दिए गए सेक्शन में, उन क्वेरी के उदाहरण दिए गए हैं जिनका इस्तेमाल करके, Google Analytics इवेंट टेबल से A/B Testing एक्सपेरिमेंट का डेटा निकाला जा सकता है.

सभी एक्सपेरिमेंट से, खरीदारी और एक्सपेरिमेंट के स्टैंडर्ड डेविएशन की वैल्यू निकालना

एक्सपेरिमेंट के नतीजों के डेटा का इस्तेमाल करके, Firebase A/B Testing के नतीजों की पुष्टि की जा सकती है. यहां दिया गया BigQuery एसक्यूएल स्टेटमेंट, एक्सपेरिमेंट के वैरिएंट और हर वैरिएंट में यूनीक उपयोगकर्ताओं की संख्या को एक्सट्रैक्ट करता है. साथ ही, in_app_purchase और ecommerce_purchase इवेंट से मिले कुल रेवेन्यू को जोड़ता है. इसके अलावा, यह _TABLE_SUFFIX के तौर पर तय की गई शुरू और खत्म होने की तारीखों के बीच, सभी एक्सपेरिमेंट के लिए स्टैंडर्ड डेविएशन को भी एक्सट्रैक्ट करता है. इस क्वेरी से मिले डेटा का इस्तेमाल, वन-टेल्ड टी-टेस्ट के लिए सांख्यिकीय महत्व जनरेटर के साथ किया जा सकता है. इससे यह पुष्टि की जा सकती है कि Firebase से मिले नतीजे, आपके विश्लेषण से मैच करते हैं या नहीं.

A/B Testing अनुमान कैसे लगाता है, इस बारे में ज़्यादा जानने के लिए, टेस्ट के नतीजे समझना लेख पढ़ें.

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

किसी खास एक्सपेरिमेंट की वैल्यू चुनना

यहां दी गई क्वेरी के उदाहरण से, BigQuery में किसी खास एक्सपेरिमेंट का डेटा पाने का तरीका पता चलता है. इस सैंपल क्वेरी से, एक्सपेरिमेंट का नाम, वैरिएंट के नाम (इनमें बेसलाइन भी शामिल है), इवेंट के नाम, और इवेंट की संख्या का पता चलता है.

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName