A/B टेस्टिंग की मदद से इन-ऐप्लिकेशन मैसेज के प्रयोग बनाना

जब आपको अपने उपयोगकर्ताओं से संपर्क करना हो या कोई नया मार्केटिंग कैंपेन शुरू करना हो, तो आपको यह पक्का करना होगा कि आपने सही तरीके से काम किया हो. A/B टेस्टिंग की मदद से, शब्दों और प्रज़ेंटेशन को बेहतर बनाया जा सकता है. इसके लिए, उपयोगकर्ताओं के चुने गए हिस्से पर मैसेज के अलग-अलग वर्शन की टेस्टिंग की जाती है. आपका लक्ष्य बेहतर यूज़र ऐक्टिविटी या किसी ऑफ़र पर कन्वर्ज़न बढ़ाना हो, A/B टेस्टिंग से आंकड़ों का विश्लेषण किया जा सकता है. इससे यह पता लगाया जा सकता है कि मैसेज का कोई वर्शन, चुने गए लक्ष्य के लिए बेसलाइन से बेहतर परफ़ॉर्म कर रहा है या नहीं.

बेसलाइन के साथ सुविधा के वैरिएंट का A/B टेस्ट करने के लिए, यह तरीका अपनाएं:

  1. अपना एक्सपेरिमेंट बनाएं.
  2. टेस्ट डिवाइस पर अपने एक्सपेरिमेंट की पुष्टि करें.
  3. अपने एक्सपेरिमेंट मैनेज करें.

एक प्रयोग बनाएं

Firebase In-App Messaging का इस्तेमाल करने वाले एक्सपेरिमेंट की मदद से, ऐप्लिकेशन में दिखने वाले किसी एक मैसेज के कई वैरिएंट का आकलन किया जा सकता है.

  1. पुष्टि करें कि आपके प्रोजेक्ट में Google Analytics चालू हो, ताकि एक्सपेरिमेंट के पास Analytics डेटा का ऐक्सेस हो.

    अगर आपने प्रोजेक्ट बनाते समय Google Analytics चालू नहीं किया था, तो इसे Firebase कंसोल में जाकर चालू किया जा सकता है. इसके लिए, सेटिंग > इंटिग्रेशन टैब पर जाएं.

  2. Firebase कंसोल में, इनमें से किसी एक विकल्प का इस्तेमाल करके Firebase In-App Messaging एक्सपेरिमेंट शुरू करें:

    • A/B Testing से:

      1. DevOps और यूज़र ऐक्टिविटी > A/B टेस्टिंग पर जाएं.

      2. एक्सपेरिमेंट बनाएं पर क्लिक करें. इसके बाद, जिस सेवा के लिए आपको एक्सपेरिमेंट करना है उसके लिए प्रॉम्प्ट मिलने पर, इन-ऐप्लिकेशन मैसेजिंग चुनें.

    • In-App Messaging से:

      1. DevOps और यूज़र ऐक्टिविटी > मैसेजिंग पर जाएं.

      2. In-App Messaging पर क्लिक करें. इसके बाद, नया एक्सपेरिमेंट पर क्लिक करें.

  3. अपने एक्सपेरिमेंट के लिए नाम और जानकारी (ज़रूरी नहीं) डालें. इसके बाद, आगे बढ़ें पर क्लिक करें.

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

    • वर्शन: आपके ऐप्लिकेशन का एक या उससे ज़्यादा वर्शन
    • उपयोगकर्ता ऑडियंस: Analytics ऑडियंस का इस्तेमाल उन उपयोगकर्ताओं को टारगेट करने के लिए किया जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
    • उपयोगकर्ता प्रॉपर्टी: एक या उससे ज़्यादा Analytics उपयोगकर्ता प्रॉपर्टी. इनका इस्तेमाल उन उपयोगकर्ताओं को चुनने के लिए किया जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
    • देश/इलाका: एक या एक से ज़्यादा देश या इलाके, जहां रहने वाले उपयोगकर्ताओं को एक्सपेरिमेंट में शामिल किया जा सकता है
    • डिवाइस की भाषा: एक या उससे ज़्यादा भाषाएं और स्थानीय भाषाएं, जिनका इस्तेमाल उन उपयोगकर्ताओं को चुनने के लिए किया जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
    • पहला इस्तेमाल: उन उपयोगकर्ताओं को टारगेट करें जिन्होंने पहली बार आपका ऐप्लिकेशन खोला है
    • ऐप्लिकेशन से आखिरी बार जुड़ाव: उन उपयोगकर्ताओं को टारगेट करें जो आखिरी बार आपके ऐप्लिकेशन से जुड़े थे
  5. टारगेट किए गए उपयोगकर्ताओं का प्रतिशत सेट करें:अपने ऐप्लिकेशन के उपयोगकर्ता आधार का वह प्रतिशत चुनें जो टारगेट किए गए उपयोगकर्ताओं के लिए सेट की गई शर्तों को पूरा करता हो. आपको इस प्रतिशत को अपने एक्सपेरिमेंट के बेसलाइन और एक या उससे ज़्यादा वैरिएंट के बीच बराबर बांटना होगा. यह प्रतिशत 0.01% से 100% के बीच हो सकता है. डुप्लीकेट किए गए एक्सपेरिमेंट के साथ-साथ हर एक्सपेरिमेंट के लिए, उपयोगकर्ताओं को प्रतिशत रैंडम तरीके से फिर से असाइन किए जाते हैं.

  6. वैरिएंट सेक्शन में, एक बेसलाइन इन-ऐप्लिकेशन मैसेज कॉन्फ़िगर करें. इसे बेसलाइन ग्रुप को भेजना है. इसके लिए, मैसेज डिज़ाइन इंटरफ़ेस का इस्तेमाल करें. यह वही इंटरफ़ेस है जिसका इस्तेमाल सामान्य इन-ऐप्लिकेशन मैसेजिंग कैंपेन के लिए किया जाता है.

  7. अपने एक्सपेरिमेंट में कोई वैरिएंट जोड़ने के लिए, वैरिएंट जोड़ें पर क्लिक करें. डिफ़ॉल्ट रूप से, एक्सपेरिमेंट में एक बेसलाइन और एक वैरिएंट होता है.

  8. (ज़रूरी नहीं) हर वैरिएंट के लिए ज़्यादा जानकारी देने वाला नाम डालें.

  9. (ज़रूरी नहीं) वैरिएंट सेक्शन में सबसे ऊपर, वैरिएंट की तुलना करें बटन पर क्लिक करें. इससे, एक और मैसेज वैरिएंट की तुलना, बेसलाइन मैसेज के साथ की जा सकती है.

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

  11. एक्सपेरिमेंट के लिए शेड्यूल करने की सुविधा कॉन्फ़िगर करें:

    • एक्सपेरिमेंट के लिए, शुरू और खत्म होने की तारीख सेट करें.
    • सेट करें कि सभी वैरिएंट में, इन-ऐप्लिकेशन मैसेज कैसे ट्रिगर किए जाएं.
  12. अपने एक्सपेरिमेंट को सेव करने के लिए, समीक्षा करें पर क्लिक करें.

हर प्रोजेक्ट में ज़्यादा से ज़्यादा 300 एक्सपेरिमेंट किए जा सकते हैं. इनमें से ज़्यादा से ज़्यादा 24 एक्सपेरिमेंट चालू हो सकते हैं. बाकी एक्सपेरिमेंट ड्राफ़्ट के तौर पर सेव किए जा सकते हैं या पूरे किए जा सकते हैं.

टेस्ट के लिए डिवाइस पर अपने एक्सपेरिमेंट की पुष्टि करना

हर Firebase इंस्टॉलेशन के लिए, उससे जुड़ा इंस्टॉलेशन ऑथराइज़ेशन टोकन वापस पाया जा सकता है. इस टोकन का इस्तेमाल, अपने ऐप्लिकेशन के साथ इंस्टॉल किए गए टेस्ट डिवाइस पर, एक्सपेरिमेंट के कुछ खास वैरिएंट की जांच करने के लिए किया जा सकता है. टेस्ट डिवाइस पर अपने एक्सपेरिमेंट की पुष्टि करने के लिए, यह तरीका अपनाएं:

  1. इंस्टॉल करने के लिए पुष्टि करने वाला टोकन इस तरह पाएं:

    Swift

    do {
      let result = try await Installations.installations()
        .authTokenForcingRefresh(true)
      print("Installation auth token: \(result.authToken)")
    } catch {
      print("Error fetching token: \(error)")
    }

    Objective-C

    [[FIRInstallations installations] authTokenForcingRefresh:true
                                                   completion:^(FIRInstallationsAuthTokenResult *result, NSError *error) {
      if (error != nil) {
        NSLog(@"Error fetching Installation token %@", error);
        return;
      }
      NSLog(@"Installation auth token: %@", [result authToken]);
    }];

    Java

    FirebaseInstallations.getInstance().getToken(/* forceRefresh */true)
            .addOnCompleteListener(new OnCompleteListener<InstallationTokenResult>() {
        @Override
        public void onComplete(@NonNull Task<InstallationTokenResult> task) {
            if (task.isSuccessful() && task.getResult() != null) {
                Log.d("Installations", "Installation auth token: " + task.getResult().getToken());
            } else {
                Log.e("Installations", "Unable to get Installation auth token");
            }
        }
    });

    Kotlin

    val forceRefresh = true
    FirebaseInstallations.getInstance().getToken(forceRefresh)
        .addOnCompleteListener { task ->
            if (task.isSuccessful) {
                Log.d("Installations", "Installation auth token: " + task.result?.token)
            } else {
                Log.e("Installations", "Unable to get Installation auth token")
            }
        }

    वेब

          import { getInstallations, getToken } from "firebase/installations";
    
          const installations = getInstallations(app);
          const installationAuthToken = getToken(installations);
      
  2. Firebase कंसोल में, DevOps और यूज़र ऐक्टिविटी > A/B टेस्टिंग पर जाएं.
  3. ड्राफ़्ट पर क्लिक करें. रिमोट कॉन्फ़िगरेशन एक्सपेरिमेंट के लिए, चल रहा है पर क्लिक करें. इसके बाद, अपने एक्सपेरिमेंट पर कर्सर घुमाएं और कॉन्टेक्स्ट मेन्यू () पर क्लिक करें. इसके बाद, टेस्ट डिवाइस मैनेज करें पर क्लिक करें.
  4. टेस्ट डिवाइस के लिए, इंस्टॉलेशन का पुष्टि करने वाला टोकन डालें. इसके बाद, उस टेस्ट डिवाइस पर भेजने के लिए एक्सपेरिमेंट का वैरिएंट चुनें.
  5. ऐप्लिकेशन चलाएं और पुष्टि करें कि चुने गए वैरिएंट को टेस्ट डिवाइस पर दिखाया जा रहा है.

Firebase इंस्टॉलेशन के बारे में ज़्यादा जानने के लिए, Firebase इंस्टॉलेशन मैनेज करें लेख पढ़ें.

एक्सपेरिमेंट मैनेज करना

Remote Config, सूचना कंपोज़र या Firebase In-App Messaging की मदद से एक्सपेरिमेंट बनाया जा सकता है. इसके बाद, एक्सपेरिमेंट की पुष्टि करके उसे शुरू किया जा सकता है. साथ ही, एक्सपेरिमेंट के चालू रहने के दौरान उसे मॉनिटर किया जा सकता है. इसके अलावा, चालू एक्सपेरिमेंट में शामिल उपयोगकर्ताओं की संख्या बढ़ाई जा सकती है.

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

एक प्रयोग शुरू करें

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

एक्सपेरिमेंट को मॉनिटर करना

जब कोई एक्सपेरिमेंट कुछ समय तक चल जाता है, तो उसकी प्रोग्रेस देखी जा सकती है. साथ ही, यह भी देखा जा सकता है कि एक्सपेरिमेंट में अब तक हिस्सा लेने वाले लोगों के लिए, नतीजे कैसे दिख रहे हैं.

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

    • बेसलाइन से% अंतर: यह किसी मेट्रिक में हुए सुधार का मेज़रमेंट है. यह मेज़रमेंट, किसी वैरिएंट की तुलना में बेसलाइन के लिए किया जाता है. इसकी गणना, वैरिएंट की वैल्यू रेंज की तुलना बेसलाइन की वैल्यू रेंज से करके की जाती है.
    • बुनियादी रेखा को पीछे छोड़ने की संभावना: यह अनुमानित संभावना है कि कोई वैरिएंट, चुनी गई मेट्रिक के लिए बुनियादी रेखा को पीछे छोड़ देगा.
    • observed_metric हर उपयोगकर्ता के आधार पर: एक्सपेरिमेंट के नतीजों के आधार पर, यह अनुमानित रेंज है. इसमें समय के साथ मेट्रिक की वैल्यू शामिल होगी.
    • कुल observed_metric: यह बेसलाइन या वैरिएंट के लिए, मेज़र की गई कुल वैल्यू होती है. इस वैल्यू का इस्तेमाल यह मेज़र करने के लिए किया जाता है कि एक्सपेरिमेंट का हर वैरिएंट कैसा परफ़ॉर्म कर रहा है. साथ ही, इसका इस्तेमाल बढ़ोतरी, वैल्यू रेंज, बुनियादी रेखा को पीछे छोड़ने की संभावना, और सबसे अच्छा वैरिएंट होने की संभावना का हिसाब लगाने के लिए किया जाता है. मेज़र की जा रही मेट्रिक के आधार पर, इस कॉलम को "हर उपयोगकर्ता के हिसाब से अवधि," "हर उपयोगकर्ता के हिसाब से रेवेन्यू," "उपयोगकर्ताओं के बने रहने की दर" या "कन्वर्ज़न रेट" के तौर पर लेबल किया जा सकता है.
  3. एक्सपेरिमेंट के कुछ समय तक चलने के बाद (FCM और In-App Messaging के लिए कम से कम सात दिन या Remote Config के लिए 14 दिन), इस पेज पर मौजूद डेटा से पता चलता है कि कौनसे वैरिएंट ने सबसे अच्छा परफ़ॉर्म किया है. कुछ मेज़रमेंट के साथ एक बार चार्ट भी होता है, जो डेटा को विज़ुअल फ़ॉर्मैट में दिखाता है.

सभी उपयोगकर्ताओं के लिए एक्सपेरिमेंट लॉन्च करना

जब कोई एक्सपेरिमेंट इतने समय तक चल चुका हो कि आपके पास अपने लक्ष्य मेट्रिक के लिए कोई "लीडर" या जीतने वाला वैरिएंट हो, तब आप एक्सपेरिमेंट को 100% उपयोगकर्ताओं के लिए रिलीज़ कर सकते हैं. इससे आप आगे बढ़ने वाले सभी उपयोगकर्ताओं के लिए पब्लिश करने के लिए कोई वैरिएंट चुन सकते हैं. भले ही आपके एक्सपेरिमेंट से कोई साफ़ तौर पर जीतने वाला वैरिएंट न बना हो, फिर भी आप अपने सभी उपयोगकर्ताओं के लिए कोई वैरिएंट रिलीज़ करना चुन सकते हैं.

  1. Firebase कंसोल में, DevOps और यूज़र ऐक्टिविटी > A/B टेस्टिंग पर जाएं.
  2. पूरा हो गया या चल रहा है पर क्लिक करें. इसके बाद, उस एक्सपेरिमेंट पर क्लिक करें जिसे आपको सभी उपयोगकर्ताओं के लिए रिलीज़ करना है. इसके बाद, कॉन्टेक्स्ट मेन्यू () वेरिएंट रोल आउट करें पर क्लिक करें.
  3. इनमें से कोई एक तरीका अपनाकर, अपने एक्सपेरिमेंट को सभी उपयोगकर्ताओं के लिए रोल आउट करें:

    • सूचना कंपोज़र का इस्तेमाल करने वाले एक्सपेरिमेंट के लिए, रोल आउट मैसेज डायलॉग का इस्तेमाल करके, उन उपयोगकर्ताओं को मैसेज भेजें जिन्हें टारगेट किया गया था, लेकिन वे एक्सपेरिमेंट का हिस्सा नहीं थे.
    • Remote Config एक्सपेरिमेंट के लिए, कोई वैरिएंट चुनें, ताकि यह तय किया जा सके कि Remote Config पैरामीटर की किन वैल्यू को अपडेट करना है. एक्सपेरिमेंट बनाते समय तय की गई टारगेटिंग की शर्तों को नई शर्त के तौर पर आपके टेंप्लेट में जोड़ दिया जाएगा, ताकि यह पक्का किया जा सके कि रोल आउट, सिर्फ़ एक्सपेरिमेंट के लिए चुने गए उपयोगकर्ताओं को दिखे. बदलावों को देखने के लिए, रिमोट कॉन्फ़िगरेशन में देखें पर क्लिक करें. इसके बाद, बदलावों को पब्लिश करें पर क्लिक करके, रोल आउट को पूरा करें.
    • In-App Messaging एक्सपेरिमेंट के लिए, डायलॉग बॉक्स का इस्तेमाल करके यह तय करें कि किस वैरिएंट को स्टैंडअलोन In-App Messaging कैंपेन के तौर पर रोल आउट करना है. चुनने के बाद, आपको FIAM कंपोज़ स्क्रीन पर रीडायरेक्ट कर दिया जाता है. यहां पब्लिश करने से पहले, ज़रूरी बदलाव किए जा सकते हैं.

एक्सपेरिमेंट को बड़ा करना

अगर आपको लगता है कि किसी एक्सपेरिमेंट में, A/B Testing के लिए ज़रूरी संख्या में उपयोगकर्ता शामिल नहीं हैं, तो एक्सपेरिमेंट को ज़्यादा उपयोगकर्ताओं तक पहुंचाया जा सकता है. इससे, ऐप्लिकेशन इस्तेमाल करने वाले ज़्यादा लोगों को एक्सपेरिमेंट दिखाया जा सकेगा.

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

किसी एक्सपेरिमेंट को डुप्लीकेट करना या उसे रोकना

  1. Firebase कंसोल में, DevOps और यूज़र ऐक्टिविटी > A/B टेस्टिंग पर जाएं.
  2. पूरा हो गया या चल रहा है पर क्लिक करें. इसके बाद, अपने एक्सपेरिमेंट पर पॉइंटर घुमाएं, कॉन्टेक्स्ट मेन्यू () पर क्लिक करें, और फिर एक्सपेरिमेंट डुप्लीकेट करें या एक्सपेरिमेंट रोकें पर क्लिक करें.

उपयोगकर्ता को टारगेट करना

उपयोगकर्ता टारगेटिंग से जुड़ी इन शर्तों का इस्तेमाल करके, उन उपयोगकर्ताओं को टारगेट किया जा सकता है जिन्हें आपको अपने एक्सपेरिमेंट में शामिल करना है.

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

शामिल है, शामिल नहीं है या पूरी तरह से मेल खाता है ऑपरेटर में से किसी का भी इस्तेमाल करते समय, कॉमा लगाकर अलग की गई वैल्यू की सूची दी जा सकती है.

रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के पूरे या कुछ हिस्से से मेल खा सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरे हिस्से से मेल खाने के लिए, ^ और $ ऐंकर का भी इस्तेमाल किया जा सकता है.

उपयोगकर्ता ऑडियंस
इनमें से सभी शामिल हैं,
इनमें से कम से कम एक शामिल है,
इनमें से सभी शामिल नहीं हैं,
इनमें से कम से कम एक शामिल नहीं है
उन उपयोगकर्ताओं को टारगेट करने के लिए एक या उससे ज़्यादा Analytics ऑडियंस चुनें जिन्हें आपके एक्सपेरिमेंट में शामिल किया जा सकता है. Google Analytics ऑडियंस को टारगेट करने वाले कुछ एक्सपेरिमेंट के लिए, डेटा इकट्ठा करने में कुछ दिन लग सकते हैं. ऐसा इसलिए, क्योंकि इन पर Analytics डेटा प्रोसेसिंग में लगने वाला समय लागू होता है. आपको यह देरी नए उपयोगकर्ताओं के साथ देखने को मिल सकती है. आम तौर पर, इन उपयोगकर्ताओं को ऑडियंस की ज़रूरी शर्तें पूरी करने वाली ऑडियंस में शामिल होने के 24 से 48 घंटे बाद शामिल किया जाता है. इसके अलावा, यह देरी हाल ही में बनाई गई ऑडियंस के साथ भी देखने को मिल सकती है.
उपयोगकर्ता प्रॉपर्टी टेक्स्ट के लिए:
शामिल है,
शामिल नहीं है,
पूरी तरह से मेल खाता है,
रेगुलर एक्सप्रेशन शामिल है

संख्याओं के लिए:
<, ≤, =, ≥, >
Analytics उपयोगकर्ता प्रॉपर्टी का इस्तेमाल, उन उपयोगकर्ताओं को चुनने के लिए किया जाता है जिन्हें किसी एक्सपेरिमेंट में शामिल किया जा सकता है. साथ ही, उपयोगकर्ता प्रॉपर्टी की वैल्यू चुनने के लिए कई विकल्प उपलब्ध होते हैं.

क्लाइंट पर, उपयोगकर्ता प्रॉपर्टी के लिए सिर्फ़ स्ट्रिंग वैल्यू सेट की जा सकती हैं. जिन शर्तों में संख्या वाले ऑपरेटर इस्तेमाल किए जाते हैं उनके लिए, Remote Config सेवा, उपयोगकर्ता प्रॉपर्टी की वैल्यू को पूर्णांक/फ़्लोट में बदल देती है.
रेगुलर एक्सप्रेशन शामिल है ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के पूरे या कुछ हिस्से से मेल खा सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरे हिस्से से मेल खाने के लिए, ^ और $ ऐंकर का भी इस्तेमाल किया जा सकता है.
देश/क्षेत्र लागू नहीं एक या उससे ज़्यादा ऐसे देश या इलाके जहां के उपयोगकर्ताओं को एक्सपेरिमेंट में शामिल किया जा सकता है.  
भाषाएं लागू नहीं एक या उससे ज़्यादा भाषाओं और स्थान-भाषाओं का इस्तेमाल करके, उन उपयोगकर्ताओं को चुना जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है.  
फ़र्स्ट ओपन रिपोर्ट इससे ज़्यादा
इससे कम
इसके बीच
उन उपयोगकर्ताओं को टारगेट करें जिन्होंने पहली बार आपका ऐप्लिकेशन खोला है. इसके लिए, दिनों की संख्या तय करें.
पिछली बार ऐप्लिकेशन इस्तेमाल करने वाले उपयोगकर्ता इससे ज़्यादा
इससे कम
इसके बीच
उन उपयोगकर्ताओं को टारगेट करें जिन्होंने आखिरी बार आपके ऐप्लिकेशन का इस्तेमाल कब किया था. यह जानकारी दिनों में दी जाती है.

A/B Testing मेट्रिक

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

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

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

यहां दी गई टेबल में, लक्ष्य की मेट्रिक और अन्य मेट्रिक के कैलकुलेट होने के तरीके के बारे में जानकारी दी गई है.

लक्ष्य मेट्रिक

मेट्रिक ब्यौरा
वे उपयोगकर्ता जिनके ऐप बंद नहीं हुए उन उपयोगकर्ताओं का प्रतिशत जिन्हें आपके ऐप्लिकेशन में ऐसी गड़बड़ियों का सामना नहीं करना पड़ा जिन्हें एक्सपेरिमेंट के दौरान Firebase Crashlytics SDK ने पता लगाया था.

ध्यान दें: Firebase Crashlytics का इस्तेमाल वेब ऐप्लिकेशन के लिए नहीं किया जा सकता.

विज्ञापन से मिलने वाला अनुमानित रेवेन्यू विज्ञापन से होने वाली अनुमानित कमाई.
अनुमानित कुल रेवेन्यू खरीदारी और विज्ञापन से मिले अनुमानित रेवेन्यू की कुल वैल्यू.
खरीदारी से हुई आय सभी purchase और in_app_purchase इवेंट की कुल वैल्यू.
रिटेंशन (एक दिन) ऐसे उपयोगकर्ताओं की संख्या जो हर दिन आपके ऐप्लिकेशन पर वापस आते हैं.
रिटेंशन (दो से तीन दिन) ऐसे लोगों की संख्या जो दो से तीन दिनों के अंदर आपके ऐप्लिकेशन पर वापस आते हैं.
रिटेंशन (चार से सात दिन) ऐसे लोगों की संख्या जो चार से सात दिनों के अंदर आपके ऐप्लिकेशन पर वापस आते हैं.
रिटेंशन (8 से 14 दिन) ऐसे लोगों की संख्या जिन्होंने 8 से 14 दिनों के अंदर आपका ऐप्लिकेशन फिर से खोला.
रिटेंशन (15 दिन से ज़्यादा) ऐसे उपयोगकर्ताओं की संख्या जिन्होंने आपका ऐप्लिकेशन आखिरी बार इस्तेमाल करने के 15 या उससे ज़्यादा दिनों बाद फिर से इस्तेमाल किया.
first_open यह एक Analytics इवेंट है. यह तब ट्रिगर होता है, जब कोई उपयोगकर्ता किसी ऐप्लिकेशन को इंस्टॉल या फिर से इंस्टॉल करने के बाद पहली बार खोलता है. इसका इस्तेमाल कन्वर्ज़न फ़नल के हिस्से के तौर पर किया जाता है.

दूसरे मेट्रिक

मेट्रिक ब्यौरा
notification_dismiss यह Analytics इवेंट, Notifications composer से भेजी गई सूचना को खारिज करने पर ट्रिगर होता है. यह सिर्फ़ Android के लिए है.
notification_receive यह एक Analytics इवेंट है. यह तब ट्रिगर होता है, जब ऐप्लिकेशन के बैकग्राउंड में चालू होने पर, सूचना कंपोज़र से भेजी गई सूचना मिलती है. यह सिर्फ़ Android के लिए है.
os_update यह एक Analytics इवेंट है. इससे यह पता चलता है कि डिवाइस का ऑपरेटिंग सिस्टम कब नए वर्शन पर अपडेट किया गया. ज़्यादा जानने के लिए, अपने-आप इकट्ठा होने वाले इवेंट देखें.

यह मेट्रिक, वेब ऐप्लिकेशन के लिए मौजूद नहीं है.

screen_view यह एक Analytics इवेंट है. इससे आपके ऐप्लिकेशन में देखी गई स्क्रीन को ट्रैक किया जाता है. ज़्यादा जानने के लिए, स्क्रीन व्यू ट्रैक करना लेख पढ़ें.
session_start यह Analytics इवेंट, आपके ऐप्लिकेशन में उपयोगकर्ता के सेशन की गिनती करता है. ज़्यादा जानने के लिए, अपने-आप इकट्ठा होने वाले इवेंट देखें.