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

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

सैंपल साइज़

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

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

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

• प्रयोग का नाम
• जानकारी
• टारगेटिंग (विज्ञापन के लिए सही दर्शक चुनना) की शर्तें
• वैरिएंट की वैल्यू

प्रयोग में बदलाव करने के लिए:

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

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

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

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

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

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

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

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

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

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

वैरिएंट का वेट

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

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

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

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

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

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

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

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

देखा गया डेटा

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

अनुमान डेटा

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

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

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

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

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

Google Optimize की मदद से काम करने वाले प्रयोगों के नतीजों को समझना

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

नतीजों को "निगरानी से जुड़ा डेटा" और "मॉडल किया गया डेटा" में बांटा जाता है. मॉनिटर किए गए डेटा को सीधे तौर पर ऐनलिटिक्स डेटा से कैलकुलेट किया गया है. साथ ही, मॉडल किए गए डेटा को हमारे बेज़ियन मॉडल के ऐप्लिकेशन से मॉनिटर किए गए डेटा पर लिया गया है.

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

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

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

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

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

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

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

लीडर तय करना

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

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

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

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

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

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

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

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

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

BigQuery स्कीमा

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

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

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

शुरू करने के लिए, इस गाइड में बताए गए निर्देशों का पालन करें:

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

Firebase कंसोल में, Google Analytics के लिए BigQuery Export चालू करें

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

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

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

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

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

6. BigQuery से जोड़ें पर क्लिक करें.

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

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

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

• एक्सपेरिमेंट आईडी: इसे एक्सपेरिमेंट की खास जानकारी पेज के यूआरएल से देखा जा सकता है. उदाहरण के लिए, अगर आपका यूआरएल 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 इवेंट.

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

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

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

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

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

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

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

1. Firebase कंसोल में, A/B टेस्टिंग खोलें और एक्सपेरिमेंट की खास जानकारी खोलने के लिए, उस A/B टेस्टिंग एक्सपेरिमेंट को चुनें जिसके लिए आपको क्वेरी करनी है.
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 टेस्टिंग के एक्सपेरिमेंट का डेटा एक्सट्रैक्ट करने के लिए किया जा सकता है.

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

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

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

  /*
    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 टेस्टिंग कुल 300 प्रयोगों, 24 मौजूदा प्रयोगों, और 24 ड्राफ़्ट एक्सपेरिमेंट तक सीमित है. ये सीमाएं, रिमोट कॉन्फ़िगरेशन के रोल आउट के साथ शेयर की जाती हैं. उदाहरण के लिए, अगर आपके दो प्रयोग चल रहे हैं और तीन प्रयोग चल रहे हैं, तो आपके पास ज़्यादा से ज़्यादा 19 और रोल आउट या प्रयोग हो सकते हैं.

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

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

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