Firebase A/B Testing — यह क्या है, प्रयोगों के प्रकार और कैसे कॉन्फ़िगर करें

मोबाइल एप्लिकेशन के संदर्भ में A/B परीक्षण क्या है

A/B परीक्षण (स्प्लिट टेस्टिंग) एक तुलनात्मक विश्लेषण विधि है जिसमें उपयोगकर्ताओं के दो समूह (नियंत्रण और प्रायोगिक) एक ही एप्लिकेशन तत्व के विभिन्न संस्करण देखते हैं, जिसके बाद प्रत्येक संस्करण के चयनित मीट्रिक पर प्रभाव को मापा जाता है। मोबाइल डेवलपमेंट में, A/B परीक्षण का उपयोग UI परिवर्तनों, ऑनबोर्डिंग, मुद्रीकरण मैकेनिक्स, पुश नोटिफिकेशन और अनुशंसा एल्गोरिदम के बारे में परिकल्पनाओं का परीक्षण करने के लिए किया जाता है।

A/B परीक्षण और सरल अवलोकन के बीच मुख्य अंतर कार्य-कारण (causality) है। यदि चेकआउट स्क्रीन बदलने के बाद रूपांतरण दर 15% बढ़ गई, तो A/B परीक्षण साबित करता है कि इस विशेष परिवर्तन ने वृद्धि का कारण बना, न कि कोई बाहरी कारक (छुट्टी, विज्ञापन अभियान, मौसमी)। A/B परीक्षण के बिना, आप कारण संबंध का दावा नहीं कर सकते — केवल सहसंबंध। Optimizely (2025) के अनुसार, जो कंपनियाँ नियमित रूप से A/B परीक्षण करती हैं, वे प्रति वर्ष औसतन 30% रूपांतरण बढ़ाती हैं।

गुणवत्तापूर्ण A/B परीक्षण करने के लिए चार घटकों की आवश्यकता होती है: एक परिकल्पना (हम क्या बदलते हैं और क्यों), एक मीट्रिक (हम प्रभाव कैसे मापते हैं), एक नमूना आकार (विश्वसनीय परिणाम के लिए कितने उपयोगकर्ता चाहिए) और एक अवधि (डेटा कितने समय तक एकत्र करना है)। Firebase A/B Testing स्वचालित रूप से चारों घटकों को कवर करता है, लेकिन परिणामों की सही व्याख्या के लिए उनमें से प्रत्येक को समझना आवश्यक है।

मोबाइल एप्लिकेशन के लिए A/B परीक्षण क्यों महत्वपूर्ण हैं

मोबाइल एप्लिकेशन में विशिष्ट विशेषताएँ होती हैं जो A/B परीक्षण को विशेष रूप से मूल्यवान बनाती हैं। पहला, उच्च प्रतिस्पर्धा: Google Play पर 3 मिलियन से अधिक एप्लिकेशन हैं, और प्रत्येक UI निर्णय रिटेंशन और रूपांतरण को प्रभावित करता है। दूसरा, लंबा रिलीज़ चक्र: ऐप स्टोर के माध्यम से परिवर्तन प्रकाशित करने में समीक्षा के लिए 1 से 7 दिन लग सकते हैं। A/B परीक्षण आपको बिना रिलीज़ के (Remote Config के माध्यम से) एक परिकल्पना का परीक्षण करने और प्रभावशीलता की पुष्टि होने पर ही परिवर्तन लागू करने की अनुमति देता है।

दर्शक विभाजन A/B परीक्षणों का एक और लाभ है। एक परिवर्तन जो नए उपयोगकर्ताओं के लिए काम करता है वह पुराने उपयोगकर्ताओं के लिए हानिकारक हो सकता है। Firebase A/B Testing आपको ऐप संस्करण, देश, भाषा, पंजीकरण तिथि और उपयोगकर्ता गुणों द्वारा दर्शकों को विभाजित करने की अनुमति देता है। यह वैश्विक रोलआउट से पहले एक विशिष्ट उपसमूह पर परिवर्तनों का परीक्षण करना संभव बनाता है।

A/B परीक्षण और फ़ीचर फ़्लैग (Remote Config) के बीच अंतर

फ़ीचर फ़्लैग सभी उपयोगकर्ताओं या उनके प्रतिशत के लिए किसी सुविधा को सरल रूप से सक्षम या अक्षम करना है। A/B परीक्षण मीट्रिक माप और सांख्यिकीय महत्व गणना के साथ एक संरचित प्रयोग है। फ़ीचर फ़्लैग इस प्रश्न का उत्तर नहीं देता “क्या परिवर्तन ने मीट्रिक को प्रभावित किया?” — यह केवल सुविधा की उपलब्धता का प्रबंधन करता है। Firebase A/B Testing में, Remote Config का उपयोग मूल्य वितरण तंत्र के रूप में किया जाता है, लेकिन यह एनालिटिक्स और सांख्यिकी की एक परत जोड़ता है।

व्यवहार में: यदि आप केवल 20% उपयोगकर्ताओं के लिए धीरे-धीरे एक नई सुविधा रोल आउट करना चाहते हैं और सुनिश्चित करना चाहते हैं कि यह क्रैश न हो — random_percent स्थिति के साथ Remote Config का उपयोग करें। यदि आप साबित करना चाहते हैं कि एक नई सुविधा ने रूपांतरण दर 10% बढ़ा दी है — Firebase A/B Testing का उपयोग करें, जो स्वचालित रूप से मीट्रिक को मापेगा और p-value दिखाएगा।

Firebase A/B Testing कैसे काम करता है

Firebase A/B Testing Remote Config और Cloud Messaging के ऊपर एक ओवरले है, जो प्रयोग बनाने और निगरानी के लिए एक एकीकृत इंटरफ़ेस प्रदान करता है। वास्तुकला की दृष्टि से, सेवा में तीन घटक होते हैं: प्रबंधन कंसोल (Firebase Console में A/B Testing अनुभाग), वितरण इंजन (दिए गए प्रतिशत के आधार पर उपयोगकर्ताओं को समूहों में निर्दिष्ट करता है) और सांख्यिकीय इंजन (समूहों के बीच मीट्रिक में अंतर का विश्लेषण करता है)।

जब प्रयोग निर्माता परिवर्तन प्रकाशित करता है, Firebase Remote Config टेम्पलेट का एक नया संस्करण सहेजता है लेकिन विभिन्न उपयोगकर्ता समूहों के लिए विभिन्न पैरामीटर मान लागू करता है। क्लाइंट एप्लिकेशन, fetchAndActivate निष्पादित करने के बाद, अपने समूह के अनुरूप मान प्राप्त करता है। Firebase Analytics सभी समूहों से ईवेंट एकत्र करता है और उन्हें सांख्यिकीय इंजन को भेजता है, जो प्रतिदिन p-value और विश्वास अंतराल के साथ रिपोर्ट अपडेट करता है।

सांख्यिकीय मॉडल Firebase A/B Testing मीट्रिक के औसत मानों की तुलना करने के लिए t-परीक्षण के साथ फ्रीक्वेंटिस्ट दृष्टिकोण का उपयोग करता है। बाइनरी मीट्रिक (रूपांतरण, रिटेंशन) के लिए — अनुपात का दो-नमूना z-परीक्षण। डिफ़ॉल्ट महत्व स्तर (alpha) 0.05 है। यदि कई प्राथमिक मीट्रिक चुने जाते हैं तो Firebase Bonferroni सुधार का उपयोग करके कई तुलनाओं को समायोजित करता है। महत्वपूर्ण: सांख्यिकीय महत्व व्यावहारिक महत्व की गारंटी नहीं देता — p-value < 0.05 होने पर भी, पूर्ण सुधार आर्थिक रूप से अव्यवहारिक हो सकता है।

उपयोगकर्ताओं का समूहों में वितरण

Firebase A/B Testing उपयोगकर्ता पहचानकर्ता (Analytics App Instance ID) के आधार पर नियतात्मक वितरण का उपयोग करता है। इसका मतलब है कि एक ही उपयोगकर्ता हमेशा एक ही समूह में आता है, बशर्ते प्रयोग कॉन्फ़िगरेशन नहीं बदला हो। उपयोगकर्ता अनुभव की स्थिरता के लिए नियतत्ववाद महत्वपूर्ण है: उपयोगकर्ता को हर बार एप्लिकेशन लॉन्च करने पर इंटरफ़ेस के विभिन्न संस्करण नहीं देखने चाहिए।

प्रतिशत वितरण प्रयोग बनाते समय निर्धारित किया जाता है: उदाहरण के लिए, 50% नियंत्रण समूह, 50% प्रायोगिक समूह। Firebase एक यादृच्छिक बीज का उपयोग करके उपयोगकर्ताओं को समान रूप से वितरित करता है, संतुलित समूह आकार सुनिश्चित करता है। कई प्रायोगिक समूहों (A/B/n) का उपयोग करते समय, प्रतिशत उनके बीच समान रूप से विभाजित होता है। महत्वपूर्ण: प्रयोग शुरू होने के बाद वितरण प्रतिशत नहीं बदला जा सकता — प्रतिशत बदलने के लिए, आपको प्रयोग रोकना होगा और एक नया बनाना होगा।

Remote Config और Cloud Messaging के साथ एकीकरण

Remote Config प्रयोग में संशोधित पैरामीटर के लिए मानों के स्रोत के रूप में कार्य करता है। A/B परीक्षण बनाते समय, आप एक Remote Config पैरामीटर चुनते हैं और प्रत्येक समूह के लिए उसका मान निर्धारित करते हैं। Firebase स्वचालित रूप से प्रायोगिक मानों के साथ एक अस्थायी Remote Config टेम्पलेट शाखा बनाता है। एक समूह के पक्ष में प्रयोग रोकने के बाद, इसके मान को Firebase कंसोल के माध्यम से उत्पादन मान के रूप में लागू किया जा सकता है।

Cloud Messaging का उपयोग पुश नोटिफिकेशन भेजने के लिए किया जाता है जो प्रयोग का हिस्सा हैं। Firebase A/B Testing विभिन्न टेक्स्ट, इमेज और पुश नोटिफिकेशन के समय के साथ प्रयोग बनाने का समर्थन करता है। सेवा स्वचालित रूप से समूहों में नोटिफिकेशन वितरित करती है और मीट्रिक पर प्रभाव को मापती है: ओपन रेट, क्लिक के बाद रूपांतरण, अनइंस्टॉल रेट। यह मैन्युअल A/B परीक्षण के बिना उपयोगकर्ताओं के साथ संचार की इष्टतम मैकेनिक्स खोजने की अनुमति देता है।

प्रयोग बनाना और कॉन्फ़िगर करना

A/B परीक्षण बनाना Firebase Console में A/B Testing अनुभाग में “Create experiment” बटन के माध्यम से किया जाता है। निर्माण विज़ार्ड में कई चरण शामिल हैं: प्रयोग प्रकार चुनना (Remote Config या Notification), नियंत्रण और परीक्षण समूहों के लिए पैरामीटर और उसके मान निर्दिष्ट करना, लक्षित दर्शक (विशेषताओं द्वारा) परिभाषित करना और माप के लिए मीट्रिक चुनना। सेटअप पूरा करने के बाद, प्रयोग प्रकाशित होता है और डेटा एकत्र करना शुरू करता है।

प्रयोग प्रकार चुनना: Remote Config प्रयोग — किसी भी एप्लिकेशन पैरामीटर (UI, सामग्री, तर्क) को बदलने के लिए; Notification प्रयोग — विभिन्न पुश नोटिफिकेशन की प्रभावशीलता की तुलना करने के लिए। Remote Config प्रयोगों के लिए Remote Config में पहले से बनाए गए पैरामीटर की आवश्यकता होती है। Notification प्रयोग स्वतंत्र रूप से बनाए जाते हैं — Firebase स्वचालित रूप से क्लाइंट-साइड कोड लिखे बिना प्रत्येक समूह के लिए पुश नोटिफिकेशन तैयार और भेजेगा।

दर्शक परिभाषित करना एक अत्यंत महत्वपूर्ण कदम है। डिफ़ॉल्ट रूप से, प्रयोग सभी एप्लिकेशन उपयोगकर्ताओं पर चलता है। दर्शकों को संकीर्ण करने के लिए, फ़िल्टर का उपयोग करें: एप्लिकेशन संस्करण, देश, भाषा, OS संस्करण, Analytics उपयोगकर्ता गुण। उदाहरण के लिए, ऑनबोर्डिंग बदलना केवल नए उपयोगकर्ताओं (7 दिनों के भीतर first_open) पर परीक्षण करना समझ में आता है। अप्रासंगिक दर्शकों पर परीक्षण “धुंधला” परिणाम देता है, जो परिवर्तन के वास्तविक प्रभाव को छिपाता है।

प्रयोग की अवधि और नमूना आकार

Firebase A/B Testing में प्रयोग की न्यूनतम अवधि 3 दिन है (पूर्ण सप्ताहांत सहित, क्योंकि कार्यदिवसों और सप्ताहांतों पर उपयोगकर्ता व्यवहार भिन्न होता है)। Firebase ट्रैफ़िक और निर्दिष्ट न्यूनतम पहचान योग्य प्रभाव (MDE) के आधार पर अनुशंसित अवधि की स्वचालित रूप से गणना करता है। डिफ़ॉल्ट MDE मीट्रिक में 5% सापेक्ष परिवर्तन है। यदि वर्तमान ट्रैफ़िक 4 सप्ताह के भीतर 5% प्रभाव का पता लगाने के लिए अपर्याप्त है, तो Firebase इसके बारे में चेतावनी देगा।

नमूना आकार की गणना इसके आधार पर की जाती है: आधार रेखा मीट्रिक (वर्तमान मान), MDE, महत्व स्तर (alpha = 0.05) और सांख्यिकीय शक्ति (power = 0.8)। 50,000 MAU और 10% की आधार रेखा रूपांतरण दर वाले एक सामान्य एप्लिकेशन के लिए, 5% सापेक्ष परिवर्तन का पता लगाने के लिए प्रत्येक समूह में लगभग 30,000 उपयोगकर्ताओं (कुल 60,000) की आवश्यकता होगी। यदि नमूना आकार अपर्याप्त है, तो परिणाम सांख्यिकीय महत्व तक नहीं पहुँच सकता है, भले ही परिवर्तन प्रभावी था (टाइप II त्रुटि)।

एकाधिक वेरिएंट के साथ कार्य करना (A/B/n)

बहु-वेरिएंट प्रयोग (A/B/n) एक पैरामीटर के 3 या अधिक संस्करणों की तुलना करने की अनुमति देते हैं। Firebase एक प्रयोग में 10 वेरिएंट तक का समर्थन करता है। जितने अधिक वेरिएंट होंगे, सांख्यिकीय महत्व प्राप्त करने के लिए उतने ही अधिक उपयोगकर्ताओं की आवश्यकता होगी। नियम: प्रत्येक अतिरिक्त वेरिएंट के लिए, नमूना आकार दो-वेरिएंट परीक्षण के सापेक्ष 20–30% बढ़ जाता है। यदि ट्रैफ़िक सीमित है, तो एकल बहु-वेरिएंट परीक्षण की तुलना में क्रमिक दो-वेरिएंट परीक्षण बेहतर होते हैं।

Bonferroni सुधार — जब कई वेरिएंट या मीट्रिक हों तो Firebase स्वचालित रूप से कई तुलनाओं के लिए सुधार लागू करता है। सार: यदि आप alpha = 0.05 के साथ 5 परिकल्पनाओं का परीक्षण करते हैं, तो कम से कम एक गलत सकारात्मक परिणाम की संभावना 1 — (0.95)^5 ≈ 22.6% है। Bonferroni सुधार alpha को तुलनाओं की संख्या से विभाजित करता है: 5 परिकल्पनाओं के लिए, alpha = 0.01। यह प्रभाव का पता लगाने को अधिक रूढ़िवादी बनाता है लेकिन गलत सकारात्मक के जोखिम को कम करता है।

मीट्रिक, परिणाम विश्लेषण और निर्णय लेना

मीट्रिक चुनना सबसे महत्वपूर्ण चरण है जो प्रयोग की गुणवत्ता निर्धारित करता है। Firebase A/B Testing मीट्रिक की कई श्रेणियाँ प्रदान करता है: सहभागिता (दैनिक सक्रिय उपयोगकर्ता, सत्र अवधि, प्रति सत्र स्क्रीन), मुद्रीकरण (राजस्व, खरीदारी, सब्सक्रिप्शन), रिटेंशन (दिन 1, दिन 7, दिन 28), रूपांतरण (चयनित ईवेंट के लिए रूपांतरण दर)। किसी भी Firebase Analytics ईवेंट पर आधारित कस्टम मीट्रिक भी उपलब्ध हैं।

प्राथमिक मीट्रिक — एकमात्र मीट्रिक जिसके आधार पर प्रयोग की सफलता का आकलन किया जाता है। प्राथमिक मीट्रिक का चुनाव परिकल्पना के आधार पर प्रयोग शुरू होने से पहले किया जाना चाहिए। यदि परिकल्पना है “नया ऑनबोर्डिंग पंजीकरण के लिए रूपांतरण दर बढ़ाएगा”, तो प्राथमिक मीट्रिक sign_up_completed ईवेंट की रूपांतरण दर है। द्वितीयक मीट्रिक — दुष्प्रभावों के विश्लेषण के लिए अतिरिक्त संकेतक: क्या रिटेंशन कम हुआ, क्या राजस्व गिरा।

परिणामों की व्याख्या: Firebase प्रत्येक समूह के लिए मीट्रिक मान, नियंत्रण समूह से प्रतिशत अंतर, p-value और 95% विश्वास अंतराल के साथ एक तालिका प्रदर्शित करता है। यदि p-value < 0.05 और विश्वास अंतराल में 0 शामिल नहीं है — अंतर सांख्यिकीय रूप से महत्वपूर्ण है। यदि p-value > 0.05 — परिणाम अनिर्णायक है, और प्रयोग को बढ़ाया जाना चाहिए या अनिश्चित के रूप में रोका जाना चाहिए।

परिणामों के आधार पर निर्णय लेना

Firebase A/B Testing प्रयोग समाप्त होने के बाद तीन विकल्प प्रदान करता है: सभी उपयोगकर्ताओं के लिए विजेता वेरिएंट लागू करें, प्रयोग जारी रखें (यदि डेटा अपर्याप्त है) या बिना लागू किए प्रयोग रोकें (यदि सभी वेरिएंट नियंत्रण से बदतर हैं या परिणाम अनिर्णायक है)। विजेता लागू करना स्वचालित रूप से Remote Config टेम्पलेट को विजेता वेरिएंट के उत्पादन मान के साथ अपडेट करता है।

सावधानी: कभी-कभी सांख्यिकीय रूप से महत्वपूर्ण परिणाम का कोई व्यावहारिक अर्थ नहीं होता। उदाहरण के लिए, परीक्षण ने रूपांतरण दर में 0.5% की वृद्धि दिखाई (p = 0.03), लेकिन नए UI संस्करण के लिए 2 सप्ताह के डेवलपमेंट की आवश्यकता है। लागत-लाभ अनुपात अव्यवहारिक हो सकता है। केवल सांख्यिकीय महत्व के आधार पर नहीं, बल्कि व्यावसायिक प्रभाव के आधार पर निर्णय लें। Firebase न केवल p-value बल्कि मीट्रिक में पूर्ण परिवर्तन भी दिखाता है, जो व्यावहारिक महत्व का आकलन करने में मदद करता है।

उन्नत मीट्रिक: रिटेंशन और LTV

रिटेंशन मोबाइल एप्लिकेशन के लिए सबसे महत्वपूर्ण मीट्रिक में से एक है क्योंकि यह सीधे दीर्घकालिक उपयोगकर्ता मूल्य (LTV) से संबंधित है। Firebase A/B Testing स्वचालित रूप से प्रत्येक समूह के लिए दिन 1, दिन 7 और दिन 28 रिटेंशन की गणना करता है। हालाँकि, विश्वसनीय रिटेंशन माप में समय लगता है: दिन 7 रिटेंशन का आकलन प्रयोग शुरू होने के 7 दिन बाद किया जा सकता है, दिन 28 रिटेंशन — 28 दिनों के बाद। रिटेंशन डेटा एकत्र करने के लिए आवश्यक समय को ध्यान में रखते हुए प्रयोग की अवधि की योजना बनाएं।

LTV (Lifetime Value) एक अधिक जटिल मीट्रिक है जिसके लिए Firebase को Google Analytics for Firebase और, यदि आवश्यक हो, एक एट्रिब्यूशन प्लेटफ़ॉर्म (Adjust, AppsFlyer) के साथ एकीकरण की आवश्यकता होती है। Firebase A/B Testing LTV को मीट्रिक के रूप में उपयोग करने की अनुमति देता है, लेकिन इसकी गणना करने के लिए, आपको खरीद और उपयोगकर्ता अधिग्रहण लागत के लिए डेटा आयात सेट करना होगा। एट्रिब्यूशन के बिना, LTV गलत हो सकता है क्योंकि Firebase विज्ञापन स्रोतों से इंस्टॉल की लागत नहीं देखता है।

Remote Config के माध्यम से A/B परीक्षण सेट अप करना

A/B परीक्षण करने के लिए Firebase A/B Testing के माध्यम से, क्लाइंट-साइड पर किसी विशेष कोड की आवश्यकता नहीं है — पूरा प्रयोग Firebase कंसोल में कॉन्फ़िगर किया गया है। हालाँकि, क्लाइंट कोड को Remote Config पैरामीटर का सही ढंग से उपयोग करना चाहिए ताकि प्रयोग द्वारा निर्दिष्ट मान ठीक से लागू हों। एक उदाहरण पर विचार करें: एक नई सब्सक्रिप्शन कीमत का A/B परीक्षण, जहाँ नियंत्रण समूह पुरानी कीमत ($9.99) देखता है और प्रायोगिक समूह नई कीमत ($7.99) देखता है।

Firebase कंसोल में, हम “9.99” के डिफ़ॉल्ट मान के साथ एक Remote Config पैरामीटर subscription_price बनाते हैं। फिर हम एक A/B परीक्षण बनाते हैं जहाँ हम 50% उपयोगकर्ताओं के लिए विजेता वेरिएंट के रूप में मान “7.99” निर्दिष्ट करते हैं। Firebase स्वचालित रूप से प्रत्येक उपयोगकर्ता को एक समूह प्रदान करता है और Remote Config के माध्यम से संबंधित मान वितरित करता है। क्लाइंट कोड कीमत प्राप्त करने के लिए मानक getString का उपयोग करता है।

A/B परीक्षण लागू करने के लिए क्लाइंट कोड

क्लाइंट कोड प्रयोग के बारे में नहीं जानता — यह केवल Remote Config से पैरामीटर मान प्राप्त करता है। Firebase SDK सर्वर साइड पर ग्रुपिंग को संभालता है। यह Firebase A/B Testing का मुख्य लाभ है: डेवलपर को सशर्त वितरण तर्क लिखने की आवश्यकता नहीं है। एकमात्र आवश्यकता यह है कि एप्लिकेशन को वर्तमान मान प्राप्त करने के लिए नियमित रूप से fetchAndActivate को कॉल करना चाहिए।

class SubscriptionFragment : Fragment() {

    private fun loadPrice() {
        val remoteConfig = Firebase.remoteConfig
        val priceStr = remoteConfig
            .getString("subscription_price")
        val price = priceStr.toDoubleOrNull() ?: 9.99
        priceView.text = "$$price/month"
    }

    override fun onViewCreated(...) {
        super.onViewCreated(...)
        loadPrice()
    }
}

उदाहरण में, loadPrice Remote Config के माध्यम से subscription_price पैरामीटर का मान प्राप्त करता है। Firebase SDK स्वचालित रूप से सक्रिय A/B परीक्षण के भीतर उपयोगकर्ता के समूह के अनुरूप मान लौटाता है। यदि प्रयोग सक्रिय नहीं है या उपयोगकर्ता किसी समूह में नहीं है — डिफ़ॉल्ट मान लौटाया जाता है। यह कोड को प्रयोगों की उपस्थिति या अनुपस्थिति से पूरी तरह स्वतंत्र बनाता है।

मीट्रिक के लिए एनालिटिक्स ईवेंट लॉग करना

Firebase A/B Testing के सही ढंग से काम करने के लिए, एप्लिकेशन को प्रयोग मीट्रिक के रूप में चयनित ईवेंट को लॉग करना होगा। Firebase Analytics SDK स्वचालित रूप से मानक ईवेंट (first_open, session_start, in_app_purchase, आदि) एकत्र करता है, लेकिन कस्टम मीट्रिक के लिए लॉगिंग जोड़ने की आवश्यकता होती है। नीचे दिए गए उदाहरण में, जब उपयोगकर्ता सब्सक्राइब करने का प्रयास करता है तो subscription_started ईवेंट लॉग होता है।

private fun onSubscribeClick() {
    // A/B परीक्षण के लिए इवेंट लॉग करते हैं
    val bundle = Bundle().apply {
        putString(
            FirebaseAnalytics.Param.PRICE,
            remoteConfig.getString("subscription_price")
        )
    }
    FirebaseAnalytics.getInstance(requireContext())
        .logEvent("subscription_started", bundle)

    // भुगतान flow शुरू करना
    startBillingFlow()
}

महत्वपूर्ण: subscription_started ईवेंट को Firebase Analytics में एक कस्टम ईवेंट के रूप में (रिपोर्ट के लिए) पंजीकृत होना चाहिए या Firebase A/B Testing द्वारा उपयोग किया जाने वाला एक मानक ईवेंट होना चाहिए। Firebase स्वचालिक रूप से Analytics App Instance ID के माध्यम से ईवेंट को प्रयोग समूह से जोड़ता है। किसी अतिरिक्त टैगिंग की आवश्यकता नहीं है — सारा जादू Firebase सर्वर साइड पर होता है।

A/B परीक्षण करते समय सामान्य गलतियाँ

पीक प्रभाव त्रुटि — नियोजित अवधि पर विचार किए बिना सांख्यिकीय महत्व की पहली उपस्थिति पर प्रयोग रोकना। यदि आप प्रतिदिन p-value की जाँच करते हैं और jैसे ही p < 0.05 होता है रुक जाते हैं, तो गलत सकारात्मक परिणाम की संभावना 5% से बढ़कर 30–40% हो जाती है। Firebase A/B Testing एक निश्चित प्रयोग अवधि की अनुशंसा करता है। अनुमानित अवधि समाप्त होने से पहले परिणाम न देखें।

अनदेखे बाहरी कारक — मौसमी, विज्ञापन अभियान, OS अपडेट, प्रतिस्पर्धी रिलीज़। यदि A/B परीक्षण के दौरान आपने एक विज्ञापन अभियान शुरू किया जिसने ट्रैफ़िक संरचना बदल दी, तो परीक्षण का परिणाम विकृत हो सकता है। बड़ी मार्केटिंग गतिविधियों के साथ एक साथ A/B परीक्षण न करने की अनुशंसा की जाती है। यदि अपरिहार्य है — सुनिश्चित करें कि विज्ञापन से ट्रैफ़िक समूहों के बीच समान रूप से वितरित हो।

सेगमेंटल प्रभाव (सिम्पसन का विरोधाभास) — एक स्थिति जहाँ समग्र परिणाम कोई प्रभाव नहीं दिखाता, लेकिन व्यक्तिगत सेगमेंट के भीतर प्रभाव मौजूद है और विपरीत है। उदाहरण के लिए, एक परीक्षण ने दिखाया कि नए चेकआउट डिज़ाइन ने समग्र रूपांतरण नहीं बदला, लेकिन iOS और Android में विभाजित करने पर पता चला: iOS पर रूपांतरण 20% बढ़ा, जबकि Android पर 15% गिर गया। हमेशा प्रमुख सेगमेंट (प्लेटफ़ॉर्म, देश, एप्लिकेशन संस्करण) द्वारा परिणाम जाँचें।

एकाधिक मीट्रिक समस्या

एकाधिक तुलना समस्या तब उत्पन्न होती है जब प्रयोग में कई मीट्रिक का उपयोग किया जाता है। यदि आप alpha = 0.05 के साथ 20 मीट्रिक की जाँच करते हैं, तो कम से कम एक गलत रूप से महत्वपूर्ण अंतर (गलत सकारात्मक) खोजने की संभावना 1 — (0.95)^20 ≈ 64% है। Firebase कई प्राथमिक मीट्रिक के लिए Bonferroni सुधार का उपयोग करता है लेकिन द्वितीयक के लिए नहीं। निष्कर्ष: प्रयोग शुरू करने से पहले एक प्राथमिक मीट्रिक चुनें और निर्णय लेते समय द्वितीयक मीट्रिक के p-value पर ध्यान न दें।

नवीनता प्रभाव — उपयोगकर्ता किसी नए परिवर्तन पर अलग प्रतिक्रिया दे सकते हैं सिर्फ इसलिए कि यह नया है, इसलिए नहीं कि यह बेहतर है। प्रयोग के पहले दिन गलत वृद्धि दिखा सकते हैं (उपयोगकर्ता जिज्ञासा से नए बटन पर क्लिक करते हैं), जो समय के साथ कम हो जाती है। 3 दिनों की न्यूनतम प्रयोग अवधि इस समस्या को आंशिक रूप से हल करती है, लेकिन UI परिवर्तनों के लिए, नवीनता प्रभाव को स्थिर होने देने के लिए 7–14 दिनों की अवधि की अनुशंसा की जाती है।

प्रयोगों के बीच हस्तक्षेप

नेटवर्क प्रभाव — एक समस्या जहाँ एक समूह में उपयोगकर्ताओं का व्यवहार दूसरे समूह में उपयोगकर्ताओं को प्रभावित करता है। उदाहरण के लिए, न्यूज़ फ़ीड एल्गोरिदम परिवर्तन का A/B परीक्षण: यदि प्रायोगिक समूह बेहतर अनुशंसाएँ प्राप्त करता है, तो वे अधिक सामग्री बनाते हैं जो नियंत्रण समूह के उपयोगकर्ता भी देखते हैं, जिससे परिणाम विकृत होते हैं। ऐसे मामलों में, सोशल ग्राफ़ आइसोलेशन का उपयोग करें या देश/क्षेत्र स्तर पर परीक्षण करें।

एक ही Remote Config पैरामीटर पर एक साथ प्रयोग हस्तक्षेप का एक और स्रोत हैं। Firebase A/B Testing पहले से व्याप्त पैरामीटर पर दूसरा प्रयोग शुरू करने की अनुमति नहीं देता, लेकिन यदि प्रयोग विभिन्न पैरामीटर को प्रभावित करते हैं फिर भी एक ही मीट्रिक को प्रभावित करते हैं, तो क्रॉस-प्रभाव संभव है। एक बार में 2–3 से अधिक सक्रिय A/B परीक्षण न चलाने और यह सुनिश्चित करने की अनुशंसा की जाती है कि वे समान उपयोगकर्ता परिदृश्यों को प्रभावित न करें।