इस पेज पर, Firebase A/B Testing के काम करने के तरीके के बारे में पूरी जानकारी दी गई है. इससे आपको टेस्ट के नतीजों को ज़्यादा काम का और काम के हिसाब से बनाने में मदद मिलेगी.
सैंपल साइज़
Firebase A/B Testing अनुमान लगाने के लिए, किसी प्रयोग को शुरू करने से पहले, कम से कम सैंपल साइज़ की पहचान करने की ज़रूरत नहीं होती. आम तौर पर, आपको एक्सपेरिमेंट के लिए उतना एक्सपोज़र लेवल चुनना चाहिए जितना आपके लिए सही हो. सैंपल साइज़ ज़्यादा होने पर, आंकड़ों के हिसाब से अहम नतीजे मिलने की संभावना बढ़ जाती है. ऐसा तब ज़्यादा होता है, जब वैरिएंट के बीच परफ़ॉर्मेंस में काफ़ी कम अंतर होता है. अपने एक्सपेरिमेंट की विशेषताओं के आधार पर, सैंपल साइज़ का सुझाव पाने के लिए, ऑनलाइन सैंपल साइज़ कैलकुलेटर का इस्तेमाल भी किया जा सकता है.
एक्सपेरिमेंट में बदलाव करना
चल रहे एक्सपेरिमेंट के चुने गए पैरामीटर में बदलाव किया जा सकता है. इनमें ये पैरामीटर शामिल हैं:
- प्रयोग का नाम
- ब्यौरा
- टारगेटिंग की शर्तें
- वैरिएंट की वैल्यू
किसी एक्सपेरिमेंट में बदलाव करने के लिए:
- उस एक्सपेरिमेंट के नतीजों का पेज खोलें जिसमें आपको बदलाव करना है.
- ज़्यादा मेन्यू में जाकर, चल रहे एक्सपेरिमेंट में बदलाव करें को चुनें.
- बदलाव करने के बाद, पब्लिश करें पर क्लिक करें.
ध्यान दें कि किसी चल रहे एक्सपेरिमेंट के दौरान, ऐप्लिकेशन के व्यवहार में बदलाव करने से नतीजों पर असर पड़ सकता है.
रिमोट कॉन्फ़िगरेशन के वैरिएंट असाइनमेंट का लॉजिक
एक्सपेरिमेंट की टारगेटिंग की सभी शर्तों (जैसे कि एक्सपोज़र का प्रतिशत) से मैच करने वाले उपयोगकर्ताओं को, वैरिएंट के वज़न और एक्सपेरिमेंट आईडी और उपयोगकर्ता के Firebase इंस्टॉलेशन आईडी के हैश के हिसाब से एक्सपेरिमेंट के वैरिएंट असाइन किए जाते हैं.
Google Analytics ऑडियंस के लिए इंतज़ार करना पड़ता है. जब कोई उपयोगकर्ता ऑडियंस की ज़रूरी शर्तों को पूरा करता है, तब भी ऑडियंस तुरंत उपलब्ध नहीं होती:
- नई ऑडियंस बनाने पर, नए उपयोगकर्ताओं को इकट्ठा करने में 24 से 48 घंटे लग सकते हैं.
- ज़रूरी शर्तें पूरी करने के 24 से 48 घंटे बाद, आम तौर पर नए उपयोगकर्ताओं को ज़रूरी शर्तें पूरी करने वाली ऑडियंस में शामिल कर लिया जाता है.
समय के हिसाब से टारगेटिंग के लिए, Google Analytics उपयोगकर्ता प्रॉपर्टी या पहले से मौजूद टारगेटिंग के विकल्पों का इस्तेमाल करें. जैसे, देश या इलाका, भाषा, और ऐप्लिकेशन वर्शन.
जब कोई उपयोगकर्ता किसी एक्सपेरिमेंट में शामिल होता है, तो उसे अपने एक्सपेरिमेंट वैरिएंट में हमेशा के लिए असाइन कर दिया जाता है. साथ ही, जब तक एक्सपेरिमेंट चालू रहता है, तब तक उसे एक्सपेरिमेंट से पैरामीटर वैल्यू मिलती रहती हैं. भले ही, उसकी उपयोगकर्ता प्रॉपर्टी बदल जाएं और वह एक्सपेरिमेंट की टारगेटिंग की ज़रूरी शर्तों को पूरा न करता हो.
ऐक्टिवेशन इवेंट
एक्सपेरिमेंट ऐक्टिवेशन इवेंट, एक्सपेरिमेंट के मेज़रमेंट को उन ऐप्लिकेशन उपयोगकर्ताओं तक सीमित कर देते हैं जो ऐक्टिवेशन इवेंट को ट्रिगर करते हैं. एक्सपेरिमेंट चालू करने वाले इवेंट का, ऐप्लिकेशन से फ़ेच किए गए एक्सपेरिमेंट पैरामीटर पर कोई असर नहीं पड़ता. एक्सपेरिमेंट टारगेटिंग की ज़रूरी शर्तें पूरी करने वाले सभी उपयोगकर्ताओं को एक्सपेरिमेंट पैरामीटर मिलेंगे. इसलिए, ऐसा ऐक्टिवेशन इवेंट चुनना ज़रूरी है जो एक्सपेरिमेंट पैरामीटर फ़ेच और चालू होने के बाद, लेकिन ऐप्लिकेशन के व्यवहार में बदलाव करने के लिए एक्सपेरिमेंट पैरामीटर का इस्तेमाल करने से पहले होता है.
वैरिएंट के ट्रैफ़िक के महत्व
प्रयोग बनाते समय, डिफ़ॉल्ट वैरिएंट के वेट में बदलाव किया जा सकता है, ताकि प्रयोग में शामिल उपयोगकर्ताओं का ज़्यादा से ज़्यादा प्रतिशत किसी वैरिएंट में शामिल किया जा सके.
टेस्ट के नतीजों को समझना
Firebase A/B Testing, फ़्रीक्वेंटिस्ट इंफ़रेंस का इस्तेमाल करता है, ताकि आपको यह समझने में मदद मिल सके कि आपके एक्सपेरिमेंट के नतीजे, सिर्फ़ रैंडम चांस की वजह से मिल सकते हैं. इस संभावना को प्रोबैबिलिटी वैल्यू या p-value से दिखाया जाता है. p-value से यह पता चलता है कि दो वैरिएंट के बीच परफ़ॉर्मेंस में अंतर, रैंडम चांस की वजह से हो सकता है. इसे 0 से 1 के बीच की वैल्यू से मेज़र किया जाता है. A/B Testing, 0.05 के सिग्निफ़िकेंस लेवल का इस्तेमाल करता है, ताकि:
- 0.05 से कम p-value का मतलब है कि वैरिएंट के बीच आंकड़ों के हिसाब से अहम अंतर है. इसका मतलब है कि यह अंतर, किसी रैंडम चांस से नहीं हुआ है.
- 0.05 से ज़्यादा का p-value यह दिखाता है कि वैरिएंट के बीच का अंतर, आंकड़ों के हिसाब से अहम नहीं है.
एक्सपेरिमेंट का डेटा दिन में एक बार रीफ़्रेश किया जाता है. साथ ही, आखिरी अपडेट का समय, एक्सपेरिमेंट के नतीजों वाले पेज पर सबसे ऊपर दिखता है.
एक्सपेरिमेंट के नतीजों का ग्राफ़, चुनी गई मेट्रिक की कुल औसत वैल्यू दिखाता है. उदाहरण के लिए, अगर हर उपयोगकर्ता से मिलने वाले विज्ञापन रेवेन्यू को मेट्रिक के तौर पर ट्रैक किया जा रहा है, तो यह हर उपयोगकर्ता से मिलने वाला रेवेन्यू दिखाता है. वहीं, अगर क्रैश-फ़्री उपयोगकर्ताओं को ट्रैक किया जा रहा है, तो यह उन उपयोगकर्ताओं का प्रतिशत ट्रैक करता है जिन्हें क्रैश का कोई अनुभव नहीं हुआ है. यह डेटा, एक्सपेरिमेंट के शुरू होने से लेकर अब तक का कुल डेटा होता है.
नतीजों को निगरानी में रखा गया डेटा और अनुमानित डेटा में बांटा जाता है. निगरानी किए गए डेटा का हिसाब सीधे Google Analytics के डेटा से लगाया जाता है. साथ ही, अनुमानित डेटा से p-वैल्यू और कॉन्फ़िडेंस इंटरवल मिलते हैं. इनकी मदद से, निगरानी किए गए डेटा के आंकड़ों के महत्व का आकलन किया जा सकता है.
हर मेट्रिक के लिए, ये आंकड़े दिखते हैं:
देखा गया डेटा
- ट्रैक की गई मेट्रिक की कुल वैल्यू (बने रहने वाले उपयोगकर्ताओं की संख्या, क्रैश होने वाले उपयोगकर्ताओं की संख्या, कुल आय)
- मेट्रिक के हिसाब से रेट (उपयोगकर्ता को जोड़े रखने की दर, कन्वर्ज़न रेट, हर उपयोगकर्ता से होने वाली आय)
- वैरिएंट और बेसलाइन के बीच का प्रतिशत अंतर (लिफ़्ट)
अनुमान से जुड़ा डेटा
95% कॉन्फ़िडेंस इंटरवल (औसत में अंतर), एक ऐसा इंटरवल दिखाता है जिसमें ट्रैक की गई मेट्रिक की "सही" वैल्यू 95% कॉन्फ़िडेंस के साथ होती है. उदाहरण के लिए, अगर आपके एक्सपेरिमेंट के नतीजों में, अनुमानित कुल आय के लिए 95% सीआई, 50 से 100 डॉलर के बीच है, तो इस बात की 95% संभावना है कि माध्य में असल अंतर 50 से 100 डॉलर के बीच है. अगर सीआई रेंज में 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% के कॉन्फ़िडेंस के साथ मिल सकती है
कुल मिलाकर, एक्सपेरिमेंट के नतीजों से हमें एक्सपेरिमेंट के हर वैरिएंट के लिए तीन अहम जानकारी मिलती है:
- बेसलाइन की तुलना में, हर एक्सपेरिमेंट मेट्रिक कितनी ज़्यादा या कम है. इसे सीधे तौर पर मेज़र किया जाता है (यानी, असल डेटा)
- बेयसियन इंफ़्यूरेंस (बेहतर / सबसे अच्छा होने की संभावना) के आधार पर, यह कितनी संभावना है कि हर एक्सपेरिमेंट मेट्रिक, बेसलाइन / सबसे अच्छी मेट्रिक से ज़्यादा हो
- बेज़ियन इंफ़्यूज़न के आधार पर, हर एक्सपेरिमेंट मेट्रिक के लिए संभावित रेंज--"सबसे अच्छा" और "सबसे खराब" स्थिति (क्रेडिबल इंटरवल)
लीडर का पता लगाना
फ़्रीक्वेंटिस्ट इनफ़रेंस का इस्तेमाल करने वाले प्रयोगों के लिए, Firebase के मुताबिक वैरिएंट की परफ़ॉर्मेंस अहम होती है. हालांकि, ऐसा तब होता है, जब लक्ष्य मेट्रिक पर वैरिएंट और बेसलाइन के बीच आंकड़ों के महत्व के मुताबिक परफ़ॉर्मेंस में अंतर होता है. अगर एक से ज़्यादा वैरिएंट यह शर्त पूरी करते हैं, तो सबसे कम p-वैल्यू वाला वैरिएंट चुना जाता है.
Google Optimize का इस्तेमाल करने वाले एक्सपेरिमेंट के लिए, Firebase ने बताया कि अगर किसी वैरिएंट की प्राइमरी मेट्रिक पर बेसलाइन वैरिएंट से बेहतर होने की संभावना 95% से ज़्यादा है, तो वह "सबसे बेहतर वैरिएंट" है. अगर कई वैरिएंट "साफ़ तौर पर लीडर" की शर्तें पूरी करते हैं, तो सबसे अच्छा परफ़ॉर्म करने वाले वैरिएंट को ही "साफ़ तौर पर लीडर" के तौर पर लेबल किया जाता है.
किसी वैरिएंट की परफ़ॉर्मेंस बेहतर है, यह सिर्फ़ लक्ष्य की प्राइमरी मेट्रिक के हिसाब से तय होता है. इसलिए, आपको सभी वजहों पर ध्यान देना चाहिए और किसी बेहतर वैरिएंट को लॉन्च करना है या नहीं, यह तय करने से पहले सेकंडरी मेट्रिक के नतीजों की समीक्षा करनी चाहिए. आपके पास बदलाव करने से होने वाले फ़ायदे, नुकसान (जैसे, बेहतर बनाने के लिए कॉन्फ़िडेंस इंटरवल का निचला हिस्सा) और मुख्य लक्ष्य के अलावा अन्य मेट्रिक पर पड़ने वाले असर को ध्यान में रखने का विकल्प है.
उदाहरण के लिए, अगर आपकी मुख्य मेट्रिक, क्रैश हुए बिना ऐप्लिकेशन इस्तेमाल करने वाले उपयोगकर्ता हैं और वैरिएंट A, आधारभूत वैल्यू के मुकाबले बेहतर परफ़ॉर्म कर रहा है, लेकिन वैरिएंट A के उपयोगकर्ता बनाए रखने की मेट्रिक, आधारभूत वैल्यू के मुकाबले खराब परफ़ॉर्म कर रही हैं, तो हो सकता है कि आप वैरिएंट A को ज़्यादा बड़े पैमाने पर रोल आउट करने से पहले, इसकी और जांच करना चाहें.
प्राइमरी और सेकंडरी, दोनों मेट्रिक की परफ़ॉर्मेंस के आधार पर, किसी भी वैरिएंट को रोल आउट किया जा सकता है.
प्रयोग की अवधि
Firebase का सुझाव है कि किसी एक्सपेरिमेंट को तब तक चलाएं, जब तक कि ये शर्तें पूरी न हो जाएं:
- काम का नतीजा देने के लिए, एक्सपेरिमेंट में ज़रूरत के मुताबिक डेटा इकट्ठा हो गया है. एक्सपेरिमेंट और नतीजों का डेटा, दिन में एक बार अपडेट किया जाता है. अपने एक्सपेरिमेंट के लिए सुझाए गए सैंपल साइज़ का आकलन करने के लिए, सैंपल साइज़ के ऑनलाइन कैलकुलेटर का इस्तेमाल किया जा सकता है.
- एक्सपेरिमेंट को ज़रूरत के मुताबिक चलाया गया हो, ताकि आपके उपयोगकर्ताओं का सही सैंपल मिल सके और लंबे समय तक की परफ़ॉर्मेंस का आकलन किया जा सके. हमारा सुझाव है कि किसी सामान्य रिमोट कॉन्फ़िगरेशन एक्सपेरिमेंट के लिए, कम से कम दो हफ़्ते का रनटाइम तय करें.
एक्सपेरिमेंट शुरू होने के बाद, उसके डेटा को ज़्यादा से ज़्यादा 90 दिनों तक प्रोसेस किया जाता है. 90 दिनों के बाद, एक्सपेरिमेंट अपने-आप बंद हो जाता है. एक्सपेरिमेंट के नतीजे अब Firebase कंसोल में अपडेट नहीं किए जाते. साथ ही, एक्सपेरिमेंट से जुड़ी पैरामीटर वैल्यू भेजना भी बंद हो जाता है. इस बिंदु पर, क्लाइंट Remote Config टेंप्लेट में सेट की गई शर्तों के आधार पर पैरामीटर वैल्यू फ़ेच करना शुरू कर देते हैं. एक्सपेरिमेंट का पुराना डेटा तब तक सेव रहता है, जब तक आप उसे मिटा नहीं देते.
BigQuery स्कीमा
A/B Testing कंसोल में एक्सपेरिमेंट का डेटा देखने के अलावा, BigQuery में एक्सपेरिमेंट के डेटा की जांच की जा सकती है और उसका विश्लेषण किया जा सकता है.Firebase 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 के नतीजों की स्वतंत्र रूप से पुष्टि करने की सुविधा मिलती है.
शुरू करने के लिए, इस गाइड में बताए गए तरीके से यह प्रोसेस पूरी करें:
- Firebase कंसोल में, Google Analytics के लिए BigQuery एक्सपोर्ट की सुविधा चालू करना
- BigQuery का इस्तेमाल करके A/B Testing डेटा ऐक्सेस करना
- उदाहरण के तौर पर दी गई क्वेरी एक्सप्लोर करना
Firebase कंसोल में, Google Analytics के लिए BigQuery एक्सपोर्ट की सुविधा चालू करना
Spark प्लान का इस्तेमाल करने पर, BigQuery सैंडबॉक्स का इस्तेमाल करके, BigQuery को बिना किसी शुल्क के ऐक्सेस किया जा सकता है. हालांकि, इसके लिए सैंडबॉक्स की सीमाएं लागू होती हैं. ज़्यादा जानकारी के लिए, कीमत और BigQuery सैंडबॉक्स देखें.
सबसे पहले, पक्का करें कि आपने Analytics डेटा को BigQuery में एक्सपोर्ट किया हो:
- इंटिग्रेशन टैब खोलें. इसे Firebase कंसोल में > प्रोजेक्ट सेटिंग का इस्तेमाल करके ऐक्सेस किया जा सकता है.
- अगर BigQuery का इस्तेमाल, Firebase की अन्य सेवाओं के साथ पहले से किया जा रहा है, तो मैनेज करें पर क्लिक करें. अगर ऐसा नहीं है, तो लिंक करें पर क्लिक करें.
- BigQuery से Firebase को लिंक करने के बारे में जानकारी देखें. इसके बाद, आगे बढ़ें पर क्लिक करें.
- इंटिग्रेशन कॉन्फ़िगर करें सेक्शन में, Google Analytics टॉगल को चालू करें.
कोई देश/इलाका चुनें और एक्सपोर्ट सेटिंग चुनें.
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इवेंट.
ज़रूरी जानकारी इकट्ठा करने के बाद, क्वेरी जनरेट करने के लिए:
- Google Cloud कंसोल में, BigQuery खोलें.
- अपना प्रोजेक्ट चुनें. इसके बाद, SQL क्वेरी बनाएं को चुनें.
- अपनी क्वेरी जोड़ें. क्वेरी चलाने के उदाहरण के लिए, क्वेरी के उदाहरण एक्सप्लोर करें देखें.
- चालू करें पर क्लिक करें.
Firebase कंसोल की अपने-आप जनरेट हुई क्वेरी का इस्तेमाल करके, एक्सपेरिमेंट के डेटा को क्वेरी करना
अगर Blaze प्लान का इस्तेमाल किया जा रहा है, तो एक्सपेरिमेंट की खास जानकारी पेज पर एक सैंपल क्वेरी दिखती है. इससे, देखे जा रहे एक्सपेरिमेंट का नाम, वैरिएंट, इवेंट के नाम, और इवेंट की संख्या दिखती है.
अपने-आप जनरेट हुई क्वेरी पाने और उसे चलाने के लिए:
- Firebase कंसोल में, A/B Testing खोलें और वह A/B Testing एक्सपेरिमेंट चुनें जिसके लिए आपको क्वेरी करनी है, ताकि आप एक्सपेरिमेंट की खास जानकारी खोल सकें.
- विकल्प मेन्यू में, 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 केबी तक हो सकता है. इसमें वैरिएंट के नाम, वैरिएंट पैरामीटर, और कॉन्फ़िगरेशन के अन्य मेटाडेटा शामिल होते हैं.