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

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

सैंपल साइज़

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

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

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

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

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

  1. Firebase कंसोल में, DevOps और जुड़ाव > A/B टेस्टिंग पर जाएं.
  2. वह एक्सपेरिमेंट खोलें जिसमें आपको बदलाव करना है. इसके लिए, उसके नतीजों वाले पेज पर जाएं.
  3. ज़्यादा मेन्यू में जाकर, चल रहे एक्सपेरिमेंट में बदलाव करें को चुनें.
  4. बदलाव करने के बाद, पब्लिश करें पर क्लिक करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 एक्सपेरिमेंट का डेटा Firebase कंसोल में देखने के अलावा, एक्सपेरिमेंट के डेटा की जांच और विश्लेषण BigQuery में किया जा सकता है. A/B Testing के लिए, BigQuery में अलग से कोई BigQuery टेबल नहीं होती. हालांकि, एक्सपेरिमेंट और वैरिएंट की सदस्यता, Analytics के इवेंट टेबल में, Google Analytics के हर Google Analytics इवेंट में सेव की जाती है.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. का इस्तेमाल करके, A/B Testing के डेटा को ऐक्सेस करना BigQuery
  3. क्वेरी के उदाहरण देखना

Firebase कंसोल में, Google Analytics के लिए BigQuery एक्सपोर्ट की सुविधा चालू करना

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

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

  1. Firebase कंसोल में, सेटिंग सेटिंग > इंटिग्रेशन टैब पर जाएं.

  2. BigQuery कार्ड में, मैनेज करें पर क्लिक करें और पुष्टि करें कि आपका प्रोजेक्ट, Analytics का डेटा BigQuery में एक्सपोर्ट कर रहा है.

    अगर कार्ड में लिंक करें दिखता है, तो आपको एक्सपोर्ट की सुविधा सेट अप करनी होगी. इसके लिए, अगले चरण पर जाएं.

  3. अगर आपको एक्सपोर्ट की सुविधा सेट अप करनी है, तो:

    1. Firebase को BigQuery से लिंक करने के बारे में जानकारी देखें. इसके बाद, आगे बढ़ें पर क्लिक करें.

    2. इंटिग्रेशन कॉन्फ़िगर करें सेक्शन में, Google Analytics को चालू करें.

    3. कोई इलाका चुनें और एक्सपोर्ट की सेटिंग चुनें.

    4. Link to BigQuery पर क्लिक करें.

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

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

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

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

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

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

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

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

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

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