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

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

सैंपल साइज़

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

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

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

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

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

1. उस एक्सपेरिमेंट के नतीजों का पेज खोलें जिसमें आपको बदलाव करना है.
2. ज़्यादा more_vert मेन्यू में जाकर, चल रहे एक्सपेरिमेंट में बदलाव करें को चुनें.
3. बदलाव करने के बाद, पब्लिश करें पर क्लिक करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

• 0.05 से कम p-value का मतलब है कि वैरिएंट के बीच आंकड़ों के हिसाब से अहम अंतर है. इसका मतलब है कि यह अंतर, किसी रैंडम चांस से नहीं हुआ है.
• 0.05 से ज़्यादा का p-value यह दिखाता है कि वैरिएंट के बीच का अंतर, आंकड़ों के हिसाब से अहम नहीं है.

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

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

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

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

देखा गया डेटा

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

अनुमान से जुड़ा डेटा

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

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

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

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

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

Google Optimize की मदद से चलाए जा रहे एक्सपेरिमेंट के नतीजों को समझना

Firebase A/B Testing 23 अक्टूबर, 2023 से पहले शुरू किए गए एक्सपेरिमेंट के नतीजे, Google Optimize से मिले थे. Google Optimize ने आपके प्रयोग के डेटा से अहम आंकड़े जनरेट करने के लिए, बेज़ियन अनुमान का इस्तेमाल किया.

नतीजों को "मॉनिटर किए गए डेटा" और "मॉडल किए गए डेटा" में बांटा जाता है. इकट्ठा किए गए डेटा का हिसाब, सीधे Analytics के डेटा से लगाया गया था. वहीं, मॉडल किए गए डेटा को पाने के लिए, इकट्ठा किए गए डेटा पर बेज़ियन मॉडल लागू किया गया था.

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

इकट्ठा किया गया डेटा

• कुल वैल्यू (वैरिएंट में मौजूद सभी उपयोगकर्ताओं के लिए मेट्रिक का योग)
• औसत वैल्यू (वैरिएंट में उपयोगकर्ताओं के लिए मेट्रिक की औसत वैल्यू)
• बेसलाइन से % का अंतर

मॉडल किया गया डेटा

• बेसलाइन को पीछे छोड़ने की संभावना: इस बात की कितनी संभावना है कि बेसलाइन की तुलना में, इस वैरिएंट के लिए मेट्रिक ज़्यादा हो
• बेसलाइन से प्रतिशत अंतर: यह वैरिएंट और बेसलाइन के लिए, मेट्रिक के मेडियन मॉडल के अनुमान के आधार पर होता है
• मेट्रिक की रेंज: ये ऐसी रेंज होती हैं जहां मेट्रिक की वैल्यू 50% और 95% के कॉन्फ़िडेंस के साथ मिलने की संभावना होती है

कुल मिलाकर, एक्सपेरिमेंट के नतीजों से हमें एक्सपेरिमेंट के हर वैरिएंट के लिए तीन अहम जानकारी मिलती है:

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

लीडर का पता लगाना

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

Google Optimize का इस्तेमाल करने वाले एक्सपेरिमेंट के लिए, Firebase ने बताया कि अगर किसी वैरिएंट की प्राइमरी मेट्रिक पर बेसलाइन वैरिएंट से बेहतर होने की संभावना 95% से ज़्यादा है, तो वह "सबसे बेहतर वैरिएंट" है. अगर कई वैरिएंट "क्लियर लीडर" की शर्तों को पूरा करते हैं, तो सिर्फ़ सबसे अच्छा परफ़ॉर्म करने वाले वैरिएंट को ही "क्लियर लीडर" के तौर पर लेबल किया जाएगा.

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

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

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

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

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

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

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

BigQuery स्कीमा

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 कंसोल में जाकर, settings > प्रोजेक्ट सेटिंग का इस्तेमाल करके ऐक्सेस किया जा सकता है.
2. अगर BigQuery का इस्तेमाल, Firebase की अन्य सेवाओं के साथ पहले से किया जा रहा है, तो मैनेज करें पर क्लिक करें. अगर ऐसा नहीं है, तो लिंक करें पर क्लिक करें.
3. BigQuery से Firebase को लिंक करने के बारे में जानकारी देखें. इसके बाद, आगे बढ़ें पर क्लिक करें.
4. इंटिग्रेशन कॉन्फ़िगर करें सेक्शन में, Google Analytics टॉगल को चालू करें.

5. कोई देश/इलाका चुनें और एक्सपोर्ट सेटिंग चुनें.

6. 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 फ़रवरी, 2024 से 2 मई, 2024 तक चला था, तो आपको _TABLE_SUFFIX between '20240202' AND '20240502' की जानकारी देनी होगी. उदाहरण के लिए, किसी खास एक्सपेरिमेंट की वैल्यू चुनना देखें.
• इवेंट के नाम: आम तौर पर, ये आपके उन लक्ष्य मेट्रिक के साथ जुड़े होते हैं जिन्हें आपने एक्सपेरिमेंट में कॉन्फ़िगर किया है. उदाहरण के लिए, in_app_purchase इवेंट, ad_impression या user_retention इवेंट.

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

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

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

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

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

1. Firebase कंसोल में, A/B Testing खोलें और वह A/B Testing एक्सपेरिमेंट चुनें जिसके लिए आपको क्वेरी करनी है, ताकि आप एक्सपेरिमेंट की खास जानकारी खोल सकें.
2. विकल्प मेन्यू में जाकर, 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 '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

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

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

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

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

एक्सपेरिमेंट के नतीजों के डेटा का इस्तेमाल करके, Firebase A/B Testing के नतीजों की स्वतंत्र रूप से पुष्टि की जा सकती है. यहां दिया गया BigQuery SQL स्टेटमेंट, एक्सपेरिमेंट के वैरिएंट और हर वैरिएंट में यूनीक उपयोगकर्ताओं की संख्या को निकालता है. साथ ही, 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 चल रहे प्रयोग, और 24 ड्राफ़्ट प्रयोग ही बनाए जा सकते हैं. ये सीमाएं, Remote Config के रोल आउट के साथ शेयर की जाती हैं. उदाहरण के लिए, अगर आपके दो प्रयोग चल रहे हैं और तीन प्रयोग चल रहे हैं, तो आपके पास ज़्यादा से ज़्यादा 19 और रोल आउट या प्रयोग हो सकते हैं.

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

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

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