Firebase A/B टेस्ट के बारे में जानकारी

टेस्ट के नतीजों को ज़्यादा से ज़्यादा काम का और मददगार बनाने के लिए, इस पेज पर Firebase A/B Testing के काम करने के तरीके के बारे में ज़्यादा जानकारी दी गई है.

सैंपल साइज़

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

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

चल रहे एक्सपेरिमेंट के चुने गए पैरामीटर में बदलाव किया जा सकता है. इनमें ये शामिल हैं:

• प्रयोग का नाम
• ब्यौरा
• टारगेटिंग की शर्तें
• वैरिएंट की वैल्यू

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

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

ध्यान दें कि एक्सपेरिमेंट के दौरान ऐप्लिकेशन के काम करने के तरीके में बदलाव करने से, नतीजों पर असर पड़ सकता है.

रिमोट कॉन्फ़िगरेशन के वैरिएंट असाइन करने का लॉजिक

एक्सपेरिमेंट को टारगेट करने की सभी शर्तों (इनमें, एक्सपोज़र की प्रतिशत शर्त भी शामिल है) को पूरा करने वाले उपयोगकर्ताओं को, वैरिएंट के वेट और एक्सपेरिमेंट आईडी के हैश और उपयोगकर्ता के Firebase इंस्टॉलेशन आईडी के हिसाब से, एक्सपेरिमेंट के वैरिएंट असाइन किए जाते हैं.

Google Analytics ऑडियंस के डेटा को प्रोसेस होने में समय लगता है. इसलिए, जब कोई उपयोगकर्ता पहली बार ऑडियंस की शर्तों को पूरा करता है, तो वह तुरंत उपलब्ध नहीं होता:

• नई ऑडियंस बनाने पर, नए उपयोगकर्ताओं को इकट्ठा करने में 24 से 48 घंटे लग सकते हैं.
• ज़रूरी शर्तें पूरी करने वाले नए उपयोगकर्ताओं को, आम तौर पर 24 से 48 घंटों के बाद ऑडियंस में शामिल किया जाता है.

समय के हिसाब से टारगेटिंग के लिए, Google Analytics उपयोगकर्ता प्रॉपर्टी या पहले से मौजूद टारगेटिंग विकल्पों का इस्तेमाल करें. जैसे, देश या इलाका, भाषा, और ऐप्लिकेशन का वर्शन.

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

ऐक्टिवेशन इवेंट

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

वैरिएंट के ट्रैफ़िक

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

टेस्ट के नतीजों को समझना

फ़्रीक्वेंटिस्ट इन्फ़्रेंस का इस्तेमाल करके, Firebase A/B Testing आपको यह समझने में मदद करता है कि आपके एक्सपेरिमेंट के नतीजे, सिर्फ़ संयोग से मिले हैं या नहीं. इस संभावना को संभावना की वैल्यू या p-वैल्यू से दिखाया जाता है. p-वैल्यू से पता चलता है कि दो वैरिएंट की परफ़ॉर्मेंस में इतना बड़ा या इससे ज़्यादा अंतर, इत्तिफ़ाक़ से हो सकता है. ऐसा तब होता है, जब असल में कोई असर न पड़ा हो. इसे 0 और 1 के बीच की वैल्यू से मेज़र किया जाता है. A/B Testing, 0.05 के सिग्निफ़िकेंस लेवल का इस्तेमाल करता है, ताकि:

• अगर p-वैल्यू 0.05 से कम है, तो इसका मतलब है कि अगर असल अंतर शून्य है, तो इस बात की संभावना 5% से कम है कि देखा गया अंतर इत्तिफ़ाक़ से हुआ हो. 0.05 थ्रेशोल्ड है. इसलिए, 0.05 से कम की कोई भी p-वैल्यू, वैरिएंट के बीच सांख्यिकीय तौर पर अहम अंतर दिखाती है.
• अगर p-वैल्यू 0.05 से ज़्यादा है, तो इसका मतलब है कि वैरिएंट के बीच का अंतर, सांख्यिकीय तौर पर अहम नहीं है.

एक्सपेरिमेंट का डेटा दिन में एक बार रीफ़्रेश किया जाता है. साथ ही, पिछली बार अपडेट किए जाने का समय, एक्सपेरिमेंट के नतीजों वाले पेज पर सबसे ऊपर दिखता है.

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

नतीजों को ऑब्ज़र्व किए गए डेटा और अनुमानित डेटा में बांटा जाता है. मॉनिटर किया गया डेटा, सीधे Google Analytics के डेटा से लिया जाता है. वहीं, अनुमानित डेटा से p-वैल्यू और कॉन्फ़िडेंस इंटरवल मिलते हैं. इनसे आपको मॉनिटर किए गए डेटा के सांख्यिकीय महत्व का आकलन करने में मदद मिलती है.

हर मेट्रिक के लिए, ये आंकड़े दिखाए जाते हैं:

देखा गया डेटा

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

अनुमानित डेटा

• 95% सीआई (औसत में अंतर) एक इंटरवल दिखाता है, जिसमें ट्रैक की गई मेट्रिक की "सही" वैल्यू 95% कॉन्फ़िडेंस के साथ होती है. उदाहरण के लिए, अगर आपके एक्सपेरिमेंट के नतीजे में, अनुमानित कुल रेवेन्यू के लिए 5 डॉलर से 10 डॉलर के बीच 95% सीआई मिलता है, तो इस बात की 95% संभावना है कि औसत में असल अंतर 5 डॉलर से 10 डॉलर के बीच हो. अगर सीआई रेंज में 0 शामिल है, तो वैरिएंट और बेसलाइन के बीच आंकड़ों के हिसाब से अहम अंतर का पता नहीं चलता.

  कॉन्फ़िडेंस इंटरवल की वैल्यू, ट्रैक की गई मेट्रिक से मैच होने वाले फ़ॉर्मैट में दिखती हैं. उदाहरण के लिए, उपयोगकर्ता को अपने साथ जोड़े रखने के लिए समय (HH:MM:SS में), हर उपयोगकर्ता से विज्ञापन से मिलने वाले रेवेन्यू के लिए डॉलर, और कन्वर्ज़न रेट के लिए प्रतिशत.

• P-वैल्यू, जो वैरिएंट और बेसलाइन के बीच कोई अंतर न होने पर, एक्सपेरिमेंट में मिले नतीजों के बराबर डेटा देखने की संभावना को दिखाती है. p-वैल्यू जितनी कम होगी, इस बात का भरोसा उतना ही ज़्यादा होगा कि अगर हम एक्सपेरिमेंट को दोहराते हैं, तो देखी गई परफ़ॉर्मेंस सही रहेगी. 0.05 या उससे कम वैल्यू का मतलब है कि दोनों वैरिएंट के बीच काफ़ी अंतर है और इस बात की संभावना कम है कि नतीजे इत्तिफ़ाक़ से मिले हैं. P-वैल्यू, वन-टेल्ड टेस्ट पर आधारित होती हैं. इसमें वैरिएंट की वैल्यू, बेसलाइन की वैल्यू से ज़्यादा होती है. Firebase, लगातार बदलने वाले वैरिएबल (संख्या वाली वैल्यू, जैसे कि रेवेन्यू) के लिए, अनइक्वल वैरिएंस टी-टेस्ट का इस्तेमाल करता है. साथ ही, कन्वर्ज़न डेटा (बाइनरी वैल्यू, जैसे कि उपयोगकर्ता को अपने साथ जोड़े रखना, क्रैश-फ़्री उपयोगकर्ता, और Google Analytics इवेंट को ट्रिगर करने वाले उपयोगकर्ता) के लिए, अनुपात का z-टेस्ट इस्तेमाल करता है.

एक्सपेरिमेंट के नतीजों से, एक्सपेरिमेंट के हर वैरिएंट के बारे में अहम जानकारी मिलती है. इसमें ये चीज़ें शामिल हैं:

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

लीडर तय करना

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

किस वैरिएंट की परफ़ॉर्मेंस बेहतर है, यह सिर्फ़ लक्ष्य की प्राइमरी मेट्रिक के हिसाब से तय होता है. इसलिए, आपको सभी वजहों पर ध्यान देना चाहिए और किसी बेहतर वैरिएंट को लॉन्च करना है या नहीं, यह तय करने से पहले सेकंडरी मेट्रिक के नतीजों की समीक्षा करनी चाहिए. आपको बदलाव करने से होने वाले फ़ायदे, नुकसान के जोखिम (जैसे, सुधार के लिए कॉन्फ़िडेंस इंटरवल का निचला हिस्सा), और मुख्य लक्ष्य के अलावा अन्य मेट्रिक पर पड़ने वाले असर पर विचार करना चाहिए.

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

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

प्रयोग की अवधि

Firebase का सुझाव है कि किसी एक्सपेरिमेंट को तब तक चलने दें, जब तक कि ये शर्तें पूरी न हो जाएं:

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

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

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

सीमाएं

A/B Testing में ज़्यादा से ज़्यादा 300 एक्सपेरिमेंट किए जा सकते हैं. इनमें 24 एक्सपेरिमेंट चालू हैं. ये सीमाएं, Remote Config रोलआउट के साथ शेयर की जाती हैं. उदाहरण के लिए, अगर आपके पास दो रोलआउट और तीन एक्सपेरिमेंट चल रहे हैं, तो आपके पास ज़्यादा से ज़्यादा 19 अतिरिक्त रोलआउट या एक्सपेरिमेंट हो सकते हैं.

• अगर आपने कुल 300 एक्सपेरिमेंट की सीमा पूरी कर ली है, तो नया एक्सपेरिमेंट बनाने से पहले आपको किसी मौजूदा एक्सपेरिमेंट को मिटाना होगा.

• अगर आपने 24 एक्सपेरिमेंट और रोलआउट की सीमा पूरी कर ली है, तो नया एक्सपेरिमेंट या रोलआउट शुरू करने से पहले, आपको किसी मौजूदा एक्सपेरिमेंट या रोलआउट को रोकना होगा.

किसी एक्सपेरिमेंट में ज़्यादा से ज़्यादा आठ वैरिएंट हो सकते हैं. इनमें बेसलाइन भी शामिल है. साथ ही, हर वैरिएंट के लिए ज़्यादा से ज़्यादा 25 पैरामीटर हो सकते हैं. किसी एक्सपेरिमेंट का साइज़, करीब 200 केआईबी तक हो सकता है. इसमें वैरिएंट के नाम, वैरिएंट के पैरामीटर, और कॉन्फ़िगरेशन का अन्य मेटाडेटा शामिल है.