इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

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

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

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

अगर आपने प्रोजेक्ट बनाते समय Google Analytics चालू नहीं किया था, तो इसे इंटिग्रेशन टैब पर जाकर चालू किया जा सकता है. इस टैब को ऐक्सेस करने के लिए, Firebase कंसोल में जाकर > प्रोजेक्ट सेटिंग पर जाएं.
Firebase कंसोल के नेविगेशन मेन्यू में मौजूद, उपयोगकर्ता गतिविधि सेक्शन में जाकर, A/B Testing पर क्लिक करें.
एक्सपेरिमेंट बनाएं पर क्लिक करें. इसके बाद, जिस सेवा के लिए आपको एक्सपेरिमेंट करना है उसके लिए प्रॉम्प्ट मिलने पर, इन-ऐप्लिकेशन मैसेजिंग चुनें.
इसके अलावा, Firebase कंसोल के नेविगेशन मेन्यू में जाकर, Engage को बड़ा करें. इसके बाद, In-App Messaging पर क्लिक करें. इसके बाद, नया एक्सपेरिमेंट पर क्लिक करें.
अपने एक्सपेरिमेंट के लिए नाम और जानकारी (ज़रूरी नहीं) डालें. इसके बाद, आगे बढ़ें पर क्लिक करें.
टारगेटिंग फ़ील्ड में जानकारी भरें. इसके लिए, सबसे पहले वह ऐप्लिकेशन चुनें जो आपके एक्सपेरिमेंट का इस्तेमाल करता है. अपने एक्सपेरिमेंट में हिस्सा लेने के लिए, उपयोगकर्ताओं के सबसेट को भी टारगेट किया जा सकता है. इसके लिए, आपको ऐसे विकल्प चुनने होंगे जिनमें ये शामिल हैं:
- वर्शन: आपके ऐप्लिकेशन का एक या उससे ज़्यादा वर्शन
- उपयोगकर्ता ऑडियंस: Analytics ऑडियंस का इस्तेमाल उन उपयोगकर्ताओं को टारगेट करने के लिए किया जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
- उपयोगकर्ता प्रॉपर्टी: एक या उससे ज़्यादा Analytics उपयोगकर्ता प्रॉपर्टी. इनका इस्तेमाल उन उपयोगकर्ताओं को चुनने के लिए किया जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
- देश/इलाका: एक या एक से ज़्यादा देश या इलाके, जहां रहने वाले उपयोगकर्ताओं को एक्सपेरिमेंट में शामिल किया जा सकता है
- डिवाइस की भाषा: एक या उससे ज़्यादा भाषाएं और स्थानीय भाषाएं, जिनका इस्तेमाल उन उपयोगकर्ताओं को चुनने के लिए किया जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है
- पहली बार ऐप्लिकेशन खोलना: उन उपयोगकर्ताओं को टारगेट करें जिन्होंने पहली बार आपका ऐप्लिकेशन खोला है
- ऐप्लिकेशन से आखिरी बार जुड़ाव: उन उपयोगकर्ताओं को टारगेट करें जो आखिरी बार आपके ऐप्लिकेशन से जुड़े थे
ध्यान दें: Analytics उपयोगकर्ता ऑडियंस को टारगेट करने वाले एक्सपेरिमेंट में, डेटा इकट्ठा होने में 24 से 48 घंटे लग सकते हैं. इस और टारगेटिंग के अन्य विकल्पों के बारे में ज़्यादा जानने के लिए, उपयोगकर्ता टारगेटिंग लेख पढ़ें.
टारगेट किए गए उपयोगकर्ताओं का प्रतिशत सेट करें:अपने ऐप्लिकेशन के उपयोगकर्ता आधार का वह प्रतिशत चुनें जो टारगेट किए गए उपयोगकर्ता में सेट की गई शर्तों को पूरा करता हो. इस प्रतिशत को आपको अपने एक्सपेरिमेंट में, बेसलाइन और एक या उससे ज़्यादा वैरिएंट के बीच बराबर बांटना है. यह 0.01% से 100% के बीच कोई भी प्रतिशत हो सकता है. हर एक्सपेरिमेंट के लिए, उपयोगकर्ताओं को प्रतिशत रैंडम तरीके से फिर से असाइन किए जाते हैं. इसमें डुप्लीकेट किए गए एक्सपेरिमेंट भी शामिल हैं.
वैरिएंट सेक्शन में, एक बेसलाइन इन-ऐप्लिकेशन मैसेज कॉन्फ़िगर करें. इसे बेसलाइन ग्रुप को भेजना है. इसके लिए, मैसेज डिज़ाइन इंटरफ़ेस का इस्तेमाल करें. यह वही इंटरफ़ेस है जिसका इस्तेमाल सामान्य इन-ऐप्लिकेशन मैसेजिंग कैंपेन के लिए किया जाता है.
अपने एक्सपेरिमेंट में कोई वैरिएंट जोड़ने के लिए, वैरिएंट जोड़ें पर क्लिक करें. डिफ़ॉल्ट रूप से, एक्सपेरिमेंट में एक बेसलाइन और एक वैरिएंट होता है.
(ज़रूरी नहीं) हर वैरिएंट के लिए ज़्यादा जानकारी देने वाला नाम डालें.
(ज़रूरी नहीं) वैरिएंट सेक्शन में सबसे ऊपर, वैरिएंट की तुलना करें बटन पर क्लिक करें. इससे, एक और मैसेज वैरिएंट की तुलना, बेसलाइन मैसेज के साथ की जा सकती है.
अपने एक्सपेरिमेंट के लिए कोई लक्ष्य मेट्रिक तय करें. इसका इस्तेमाल, एक्सपेरिमेंट के वैरिएंट का आकलन करते समय किया जाएगा. साथ ही, सूची में से कोई भी अतिरिक्त मेट्रिक इस्तेमाल की जा सकती है. इन मेट्रिक में, पहले से मौजूद मकसद (उपयोगकर्ताओं की दिलचस्पी, खरीदारी, रेवेन्यू, उपयोगकर्ताओं को बनाए रखना वगैरह) शामिल होते हैं. Analytics कन्वर्ज़न इवेंट और अन्य Analytics इवेंट.
एक्सपेरिमेंट के लिए शेड्यूल करने की सुविधा कॉन्फ़िगर करें:
- एक्सपेरिमेंट के लिए, शुरू और खत्म होने की तारीख सेट करें.
- सेट करें कि सभी वैरिएंट में, इन-ऐप्लिकेशन मैसेज कैसे ट्रिगर किए जाएं.
अपने एक्सपेरिमेंट को सेव करने के लिए, समीक्षा करें पर क्लिक करें.

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

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

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

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

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");
        }
    }
});MainActivity.java

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")
        }
    }MainActivity.kt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Firebase कंसोल के नेविगेशन मेन्यू में मौजूद, उपयोगकर्ता गतिविधि सेक्शन में जाकर, A/B Testing पर क्लिक करें.
पूरे हो चुके या चल रहे हैं पर क्लिक करें. इसके बाद, अपने एक्सपेरिमेंट पर पॉइंटर घुमाएं, कॉन्टेक्स्ट मेन्यू () पर क्लिक करें, और फिर एक्सपेरिमेंट डुप्लीकेट करें या एक्सपेरिमेंट रोकें पर क्लिक करें.

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

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

टारगेटिंग का मानदंड	ऑपरेटर	वैल्यू	ध्यान दें
वर्शन	शामिल है, शामिल नहीं है, पूरी तरह से मैच करता है, रेगुलर एक्सप्रेशन शामिल है	ऐप्लिकेशन के एक या उससे ज़्यादा वर्शन के लिए वैल्यू डालें. इन वर्शन को आपको एक्सपेरिमेंट में शामिल करना है.	शामिल है, शामिल नहीं है या पूरी तरह से मेल खाता है ऑपरेटर में से किसी का भी इस्तेमाल करते समय, कॉमा लगाकर अलग की गई वैल्यू की सूची दी जा सकती है. contains regex ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के सभी या कुछ हिस्से से मैच कर सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरे हिस्से से मेल खाने के लिए, ^ और $ ऐंकर का इस्तेमाल भी किया जा सकता है.
उपयोगकर्ता ऑडियंस	इनमें से सभी शामिल हैं, इनमें से कम से कम एक शामिल है, इनमें से सभी शामिल नहीं हैं, इनमें से कम से कम एक शामिल नहीं है	उन उपयोगकर्ताओं को टारगेट करने के लिए एक या उससे ज़्यादा Analytics ऑडियंस चुनें जिन्हें आपके एक्सपेरिमेंट में शामिल किया जा सकता है.	Google Analytics ऑडियंस को टारगेट करने वाले कुछ एक्सपेरिमेंट के लिए, डेटा इकट्ठा होने में कुछ दिन लग सकते हैं. ऐसा इसलिए, क्योंकि इन पर Analytics डेटा प्रोसेसिंग में लगने वाला समय लागू होता है. आपको यह देरी नए उपयोगकर्ताओं के साथ देखने को मिल सकती है. आम तौर पर, इन उपयोगकर्ताओं को ऑडियंस की ज़रूरी शर्तें पूरी करने वाली ऑडियंस में शामिल होने के 24 से 48 घंटे बाद शामिल किया जाता है. इसके अलावा, यह देरी हाल ही में बनाई गई ऑडियंस के साथ भी देखने को मिल सकती है.
उपयोगकर्ता प्रॉपर्टी	टेक्स्ट के लिए: शामिल है, शामिल नहीं है, पूरी तरह से मेल खाता है, रेगुलर एक्सप्रेशन शामिल है संख्याओं के लिए: <, ≤, =, ≥, >	Analytics उपयोगकर्ता प्रॉपर्टी का इस्तेमाल, उन उपयोगकर्ताओं को चुनने के लिए किया जाता है जिन्हें किसी एक्सपेरिमेंट में शामिल किया जा सकता है. इसमें उपयोगकर्ता प्रॉपर्टी की वैल्यू चुनने के लिए कई विकल्प होते हैं. क्लाइंट पर, उपयोगकर्ता प्रॉपर्टी के लिए सिर्फ़ स्ट्रिंग वैल्यू सेट की जा सकती हैं. जिन शर्तों में संख्या वाले ऑपरेटर इस्तेमाल किए जाते हैं उनके लिए, Remote Config सेवा, उपयोगकर्ता प्रॉपर्टी की वैल्यू को पूर्णांक/फ़्लोट में बदल देती है.	contains regex ऑपरेटर का इस्तेमाल करते समय, RE2 फ़ॉर्मैट में रेगुलर एक्सप्रेशन बनाए जा सकते हैं. आपका रेगुलर एक्सप्रेशन, टारगेट वर्शन स्ट्रिंग के सभी या कुछ हिस्से से मैच कर सकता है. टारगेट स्ट्रिंग की शुरुआत, आखिर या पूरे हिस्से से मेल खाने के लिए, ^ और $ ऐंकर का इस्तेमाल भी किया जा सकता है.
देश/क्षेत्र	लागू नहीं	एक या उससे ज़्यादा देशों या इलाकों का इस्तेमाल करके, उन उपयोगकर्ताओं को चुना जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है.
भाषाएं	लागू नहीं	एक या उससे ज़्यादा भाषाओं और स्थान-भाषाओं का इस्तेमाल करके, उन उपयोगकर्ताओं को चुना जाता है जिन्हें एक्सपेरिमेंट में शामिल किया जा सकता है.
फ़र्स्ट ओपन रिपोर्ट	से ज़्यादा से कम के बीच	उन उपयोगकर्ताओं को टारगेट करें जिन्होंने पहली बार आपका ऐप्लिकेशन खोला है. इसके लिए, दिनों की संख्या तय करें.
पिछली बार ऐप्लिकेशन इस्तेमाल करने वाले उपयोगकर्ता	से ज़्यादा से कम के बीच	उन उपयोगकर्ताओं को टारगेट करें जिन्होंने आखिरी बार आपके ऐप्लिकेशन का इस्तेमाल कब किया था. यह जानकारी दिनों में दी जाती है.

A/B Testing मेट्रिक

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

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

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

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

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

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

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

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

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