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

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

सैंपल साइज़

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

देखा गया डेटा

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

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

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

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

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

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

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

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

Firebase A/B Testing के नतीजे, Google Optimize की मदद से दिखाए जाते थे. ये नतीजे, 23 अक्टूबर, 2023 से पहले शुरू किए गए एक्सपेरिमेंट के लिए दिखाए जाते थे. 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 स्कीमा

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

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

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

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

  1. Firebase कंसोल में, A/B Testing खोलें. इसके बाद, वह A/B Testing एक्सपेरिमेंट चुनें जिसके बारे में आपको क्वेरी करनी है. इससे एक्सपेरिमेंट की खास जानकारी खुल जाएगी.
  2. विकल्प मेन्यू में, BigQuery इंटिग्रेशन के नीचे, क्वेरी एक्सपेरिमेंट डेटा चुनें. इससे आपका प्रोजेक्ट, BigQuery Google Cloud कंसोल में खुल जाता है. साथ ही, आपको एक बुनियादी क्वेरी मिलती है, जिसका इस्तेमाल करके अपने एक्सपेरिमेंट के डेटा के बारे में क्वेरी की जा सकती है.

यहां दिए गए उदाहरण में, "सर्दियों का स्वागत करने वाला एक्सपेरिमेंट" नाम के एक्सपेरिमेंट के लिए जनरेट की गई क्वेरी दिखाई गई है. इसमें तीन वैरिएंट (बेसलिन भी शामिल है) हैं. यह हर इवेंट के लिए, चालू एक्सपेरिमेंट का नाम, वैरिएंट का नाम, यूनीक इवेंट, और इवेंट की संख्या दिखाता है. ध्यान दें कि क्वेरी बिल्डर, टेबल के नाम में आपके प्रोजेक्ट का नाम नहीं दिखाता है, क्योंकि यह सीधे आपके प्रोजेक्ट में खुलता है.

  /*
    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

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

क्वेरी के उदाहरण एक्सप्लोर करना

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

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

एक्सपेरिमेंट के नतीजों के डेटा का इस्तेमाल करके, 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 केआईबी तक हो सकता है. इसमें वैरिएंट के नाम, वैरिएंट पैरामीटर, और कॉन्फ़िगरेशन का अन्य मेटाडेटा शामिल होता है.