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

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

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

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

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

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

देखा गया डेटा

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

अनुमान का डेटा

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

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

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

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

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

Google Optimize के ज़रिए बनाए गए प्रयोगों के नतीजों की व्याख्या करना

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

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

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

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

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

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

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

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

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

लीडर तय करना

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

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 चालू करना

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

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

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

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

  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 में मिल जाएगा. जब प्रोजेक्ट के नाम को बड़ा करके Google Analytics इवेंट टेबल (project_name.analytics_000000000.events) का नाम दिखाया जाता है, तब यह BigQuery में भी दिखता है.
  • प्रयोग की तारीख: ज़्यादा तेज़ी से और ज़्यादा असरदार क्वेरी बनाने के लिए, बेहतर होगा कि आप अपनी क्वेरी को Google Analytics के रोज़ के इवेंट टेबल के उन विभाजनों तक ही सीमित रखें जिनमें आपके प्रयोग डेटा—ऐसी टेबल शामिल हैं जिनकी पहचान YYYYMMDD सफ़िक्स से की जाती है. इसलिए, अगर आपका एक्सपेरिमेंट 2 फ़रवरी, 2024 से 2 मई, 2024 तक चलाया गया था, तो आपको _TABLE_SUFFIX between '20240202' AND '20240502' तय करना होगा. उदाहरण के लिए, किसी खास एक्सपेरिमेंट की वैल्यू चुनें देखें.
  • इवेंट के नाम: आम तौर पर, ये उन लक्ष्य की मेट्रिक के मुताबिक होते हैं जिन्हें आपने प्रयोग में कॉन्फ़िगर किया है. उदाहरण के लिए, in_app_purchase इवेंट, ad_impression या user_retention इवेंट.
के बारे में ज़्यादा जानें

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

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

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

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

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

  1. Firebase कंसोल से, A/B टेस्टिंग खोलें. इसके बाद, प्रयोग की खास जानकारी खोलने के लिए, वह A/B टेस्टिंग एक्सपेरिमेंट चुनें जिसकी आपको क्वेरी करनी है.
  2. विकल्प मेन्यू में जाकर, BigQuery इंटिग्रेशन के नीचे मौजूद, क्वेरी प्रयोग का डेटा चुनें. इससे आपका प्रोजेक्ट Google Cloud Console में 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 केबी तक हो सकता है. इसमें वैरिएंट के नाम, वैरिएंट पैरामीटर, और अन्य कॉन्फ़िगरेशन मेटाडेटा शामिल हैं.