यह लेख Universal Analytics के बारे में है, जो बंद होने वाला है. Universal Analytics प्रॉपर्टी सेटिंग को Google Analytics 4 पर माइग्रेट करना अहम है. ऐसा नहीं करने पर, आपको 1 जुलाई, 2023 से डेटा मिलना बंद हो जाएगा. वहीं 1 जुलाई, 2024 से, Analytics 360 प्रॉपर्टी का डेटा मिलना भी बंद हो जाएगा. सेटिंग को माइग्रेट करने का तरीका जानें.

कस्टम डाइमेंशन और मेट्रिक

अपनी रिपोर्ट में गैर-मानक डेटा शामिल करना.

कस्टम डाइमेंशन और मेट्रिक, आपके Analytics खाते के डिफ़ॉल्ट डाइमेंशन और मेट्रिक जैसी ही होती हैं, फ़र्क़ सिर्फ़ इतना होता है कि इन्हें खुद बनाया जाता है. इनका इस्तेमाल करके, उस डेटा को इकट्ठा किया जा सकता है और उसका विश्लेषण किया जा सकता है जिसे Analytics अपने-आप ट्रैक नहीं करता.

इस लेख में इनके बारे में बताया गया है:

खास जानकारी

कस्टम डाइमेंशन और मेट्रिक की मदद से आप Analytics डेटा को, ग्राहक प्रबंधन (सीआरएम) जैसे गैर- Analytics स्रोत से मिलने वाले डेटा के साथ मिला सकते हैं. उदाहरण के लिए:

  • अगर आपने सीआरएम सिस्टम में, साइन-इन किए हुए उपयोगकर्ताओं के लिंग की जानकारी को स्टोर किया है, तो इस जानकारी को Analytics डेटा के साथ मिलाया जा सकता है. इससे आपको पेज व्यू लिंग के हिसाब से दिखेंगे.
  • अगर आप एक गेम डेवलपर हैं तो "लेवल पूरा करना" या "सबसे ज़्यादा स्कोर" जैसे मेट्रिक, स्क्रीन व्यू जैसे पहले से तय मेट्रिक की तुलना में ज़्यादा काम के हो सकते हैं. इस डेटा को कस्टम मेट्रिक की मदद से ट्रैक करने पर, आपको अपनी खास मेट्रिक की प्रोग्रेस को ट्रैक करने में सहूलियत मिलती है. यह ट्रैकिंग, इस्तेमाल करने और पढ़ने में आसान कस्टम रिपोर्ट में की जाती है.

कस्टम रिपोर्ट में कस्टम डाइमेंशन प्राइमरी डाइमेंशन के तौर पर दिख सकते हैं. स्टैंडर्ड रिपोर्ट में उनका इस्तेमाल सेगमेंट और दूसरे डाइमेंशन के तौर पर भी किया जा सकता है.

ज़रूरी शर्तें

कस्टम डाइमेंशन और मेट्रिक सिर्फ़ उन प्रॉपर्टी के लिए उपलब्ध हैं जो यूनिवर्सल Analytics के लिए चालू की गई हैं या जिनमें कम से कम एक ऐप्लिकेशन रिपोर्टिंग व्यू शामिल है. कस्टम डाइमेंशन और मेट्रिक, Android और iOS v2.x या इसके बाद वाले वर्शन के लिए बने Google Analytics SDK टूल पर काम करते हैं. इसके अलावा, ये analytics.js और मेज़रमेंट प्रोटोकॉल के साथ भी काम करते हैं.

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

सीमाएं और सावधानियां

हर प्रॉपर्टी में अलग-अलग कस्टम डाइमेंशन के लिए 20 इंडेक्स और कस्टम मेट्रिक के लिए 20 इंडेक्स उपलब्ध हैं. Analytics 360 खातों में कस्टम डाइमेंशन के लिए 200 इंडेक्स और कस्टम मेट्रिक के लिए 200 इंडेक्स उपलब्ध हैं.

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

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

कस्टम डाइमेंशन और मेट्रिक की लाइफ़साइकल

किसी कस्टम डाइमेंशन या मेट्रिक की लाइफ़साइकल में चार चरण होते हैं:

  • कॉन्फ़िगरेशन – आप अपने कस्टम डाइमेंशन और मेट्रिक को इंडेक्स, नाम, और दायरे जैसी दूसरी प्रॉपर्टी से तय करते हैं.
  • संग्रह - लागू करने के बाद Analytics को, कस्टम डाइमेंशन और मेट्रिक वैल्यू भेजी जाती है.
  • प्रोसेसिंग – आपका डेटा आपके कस्टम डाइमेंशन और मेट्रिक में शामिल जानकारी और सभी रिपोर्टिंग व्यू फ़िल्टर का इस्तेमाल करके प्रोसेस किया जाता है.
  • रिपोर्टिंग - Analytics यूज़र इंटरफ़ेस में, आपके कस्टम डाइमेंशन और मेट्रिक का इस्तेमाल करके नई रिपोर्ट बनाई जाती हैं.

कॉन्फ़िगरेशन

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

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

  • नाम – कस्टम डाइमेंशन का नाम, जो आपकी रिपोर्ट में दिखेगा.
  • दायरा – यह बताता है कि किस डेटा पर कस्टम डाइमेंशन या मेट्रिक लागू होगी. दायरे के बारे में ज़्यादा जानें.
  • चालू – कस्टम डाइमेंशन या मेट्रिक की वैल्यू को प्रोसेस किया जाएगा या नहीं. हो सकता है कि जो कस्टम डाइमेंशन चालू न हों वे अब भी रिपोर्टिंग में दिखें. हालांकि, उनकी वैल्यू प्रोसेस नहीं होंगी.

कस्टम मेट्रिक में ये कॉन्फ़िगरेशन वैल्यू होती हैं:

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

कस्टम डाइमेंशन और मेट्रिक, Analytics यूज़र इंटरफ़ेस में तय किए जा सकते हैं.

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

इकट्ठा करना

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

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

उदाहरण के लिए, कोई कस्टम डाइमेंशन वैल्यू सेट करने के लिए आपका कोड कुछ ऐसा दिख सकता है:

ga('create', 'UA-XXXX-Y', 'auto');

// इंडेक्स 1 पर कस्टम डाइमेंशन का वैल्यू सेट करना.
ga('set', 'cd1', 'Level 1');

// पेज व्यू हिट के साथ कस्टम डाइमेंशन वैल्यू भेजना.
ga('send', 'pageview');

कस्टम मेट्रिक के प्रकार

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

प्रोसेसिंग

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

दायरा और प्राथमिकताएं

दायरे से यह तय होता है कि कोई खास कस्टम डाइमेंशन वैल्यू से कौन से हिट जोड़ी जाएगी. दायरे के चार लेवल हैं: प्रॉडक्ट, हिट, सेशन, और उपयोगकर्ता:

  • प्रॉडक्ट – वैल्यू सिर्फ़ उस प्रॉडक्ट पर लागू होती है जिसके लिए उसे सेट किया जाता है (सिर्फ़ बेहतर ई-कॉमर्स के लिए).
  • हिट – वैल्यू को उस हिट पर लागू किया जाता है जिसके लिए उसे सेट किया गया है.
  • सेशन – वैल्यू को किसी एक सत्र के सभी हिट पर लागू किया जाता है.
  • उपयोगकर्ता – वैल्यू को मौजूदा और आने वाले सेशन के सभी हिट पर वैल्यू बदलने या कस्टम डाइमेंशन को बंद किए जाने तक लागू किया जाता है.
प्रॉडक्ट-लेवल का दायरा

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

हिट-लेवल का दायरा

जब किसी कस्टम डाइमेंशन में हिट-लेवल का दायरा होता है, तो वैल्यू सिर्फ़ उस हिट पर लागू की जाती है जिससे वैल्यू सेट की गई थी. इसे नीचे चित्र A, चित्र B और चित्र C में दिखाया गया है:

चित्र A: उपयोगकर्ता दो हिट (H1, H2) भेजता है. H2 की CD1 वैल्यू A है. वह वैल्यू सिर्फ़ H2 पर लागू होती है.
 
चित्र B: उपयोगकर्ता तीसरा हिट (H3) भेजता है. H3 की कोई CD वैल्यू नहीं है.
 
चित्र C: उपयोगकर्ता चौथा हिट (H4) भेजता है. H4 की CD1 वैल्यू B है. यह वैल्यू सिर्फ़ H4 पर लागू होती है.


सेशन-लेवल का दायरा

जब सत्र दायरे वाले दो मान किसी सत्र में एक ही इंडेक्स में सेट होते हैं, तो सेट किए गए आखिरी मान को प्राथमिकता दी जाती है. वह मान उस सत्र के सभी हिट पर लागू होता है. नीचे दिए गए चित्र D में सेट किया गया सबसे नया मान उस इंडेक्स के सभी पिछले मानों को बदल देता है:

चित्र A: उपयोगकर्ता बिना किसी CD मान वाला हिट (H1) भेजता है.
 
चित्र B: उसी सत्र में, उपयोगकर्ता दूसरा हिट (H2) भेजता है, जिसका CD1 मान A पर सेट है. सत्र के दायरे की वजह से मान A को H1 पर भी लागू किया जाता है.
 
चित्र C: उपयोगकर्ता तीसरा हिट (H3) भेजता है. हालांकि H3 के साथ कोई CD1 मान नहीं भेजा जाता है, लेकिन सत्र दायरे की वजह से मान A अपने-आप H3 पर लागू हो जाता है.
 
चित्र D: उपयोगकर्ता एक नए CD1 मान B के साथ एक चौथा हिट (H4) भेजता है. सत्र-दायरा, पिछले हिट में मान A को बदलकर सत्र में सभी हिट के लिए मान B को लागू करता है.


उपयोगकर्ता-स्तर का दायरा

आखिर में, अगर दो उपयोगकर्ता-दायरे वाले कस्टम आयाम मान एक ही सत्र में सेट हैं, तो मौजूदा सत्र के लिए आखिरी मान को प्राथमिकता दी जाती है. साथ ही, वह मान उस उपयोगकर्ता के आने वाले समय के सत्रों पर लागू होता है.

नीचे दिए गए चित्र B में, CD मान A सत्र-स्तर CD की तरह सत्र 2 के सभी हिट पर लागू होता है. हालांकि चित्र Cमें, सत्र-स्तर के दायरे के उलट, CD1 का दायरा उपयोगकर्ता-स्तर का होने की वजह से CD मान A तीसरे सत्र के हिट पर लागू होता रहता है:

चित्र A: उपयोगकर्ता के पास तीन हिट वाला सत्र है (H1, H2, H3). कोई CD मान सेट नहीं है.
 
चित्र B: वही उपयोगकर्ता वापस लौटता है और तीन हिट वाला एक दूसरा सत्र शुरू करता है. H3 पर CD1 मान A पर सेट है. इसके बाद, CD1 मान सत्र के सभी हिट पर लागू होता है.
 
चित्र C: उपयोगकर्ता तीन और हिट के साथ तीसरे सत्र के लिए लौटता है. CD1 के उपयोगकर्ता-लेवल के दायरे की वजह से, वैल्यू A को सेशन 3 के सभी हिट पर लागू किया जाता है.

फ़िल्टर

व्यू फ़िल्टर कई तरीकों से कस्टम आयामों और मेट्रिक के साथ इंटरैक्ट कर सकते हैं.

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

  1. हिट का दायरा: अगर किसी हिट को फ़िल्टर कर दिया जाता है, तो उससे जुड़े हिट-दायरे वाले कस्टम डाइमेंशन और कस्टम मेट्रिक, दोनों फ़िल्टर कर दिए जाएंगे.
  2. सत्र या उपयोगकर्ता-दायरा: उपयोगकर्ता या सत्र-दायरे वाले कस्टम आयाम जिस हिट से संबंधित थे, उसे फ़िल्टर कर दिए जाने पर भी उन कस्टम आयामों को फ़िल्टर नहीं किया जाएगा. उनकी वैल्यू, अब भी मौजूदा सेशन के सभी हिट पर लागू होंगी. साथ ही, उपयोगकर्ता के दायरे वाले डाइमेंशन होने पर, ये आने वाले समय के सेशन पर भी लागू होंगी.

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

रिपोर्टिंग

इकट्ठा करने, कॉन्फ़िगरेशन, और प्रक्रिया के दूसरे चरण पूरे होने के बाद, कस्टम आयाम और मेट्रिक उपयोगकर्ता रिपोर्टिंग इंटरफ़ेस के ज़रिए उपलब्ध हो जाते हैं.

कस्टम आयाम और मेट्रिक कस्टम रिपोर्टों में उपलब्ध होते हैं और इनका इस्तेमाल बेहतर सेगमेंट के साथ किया जा सकता है. कस्टम आयाम का इस्तेमाल दूसरी रिपोर्टों में अन्य आयामों के रूप में भी किया जा सकता है.

उदाहरण

नीचे दिए गए उदाहरण यह दिखाते हैं कि कस्टम आयामों और मेट्रिक का इस्तेमाल करके किस तरह से कोई गेम डेवलपर प्लेयर के व्यवहार के बारे में जान सकता है.

एक गेम डेवलपर ने हाल ही में एक नया गेम रिलीज़ किया है.

लागू की गई मौजूदा Analytics प्रोसेस हर बार उपयोगकर्ता की ओर से कोई लेवल खेलने पर एक स्क्रीन व्यू को ट्रैक करती है. डेवलपर पहले से ही यह जानता है कि कोई लेवल कितनी बार खेला गया है. अब वह इन ज़्यादा खास सवालों के जवाब देना चाहता है:

  1. मध्यम या कठिन लेवल की तुलना में, आसान लेवल कितनी बार खेले जाते हैं?
  2. मुफ़्त ट्रायल के दौरान 3-दिन में रोज़ कितने लेवल खेले जाते हैं?
  3. पैसे देकर खेलने वाले उपयोगकर्ताओं की तुलना में, मुफ़्त में आज़माने वाले उपयोगकर्ताओं ने कितने लेवल खेले?

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

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

हिट-स्तर का दायरा

आइए इसका एक उदाहरण देखते हैं कि गेम डेवलपर किस तरह हिट-स्तर के कस्टम आयामों का इस्तेमाल करके यह पता लगा सकता है कि हर मुश्किल -- आसान, मध्यम या बेहद कठिन -- के कितने लेवल खेले गए.

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

रिपोर्ट इस तरह से दिखेगी:

मुश्किल स्क्रीन व्यू
आसान  
मध्यम  
कठिन  

कस्टम डाइमेंशन का इस्तेमाल करने से पहले, डेवलपर, लेवल के हिसाब से कुल स्क्रीन व्यू देख सकता था. हालांकि, वह उन स्क्रीन व्यू को मुश्किल लेवल के हिसाब से ग्रुप नहीं कर पा रहा था.

हिट-स्तर के कस्टम आयाम का इस्तेमाल करके, कठिनाई के लेवल को हर स्क्रीन bd/t के साथ जोड़ा जा सकता है. इससे सबसे ज़्यादा बार खेले जाने वाले मुश्किल लेवल को रिपोर्ट में शामिल किया जा सकता है.

हिट-स्तर का दायरा क्यों?

उपयोगकर्ता एक सत्र के दौरान कई लेवल खेल सकता है. हि़ट-स्तर के दायरे का इस्तेमाल करने का मतलब कि कठिनाई के किसी लेवल का मान सिर्फ़ उसी स्क्रीन व्यू के साथ जोड़ा जाएगा जिसके साथ वह भेजा गया था. इससे यह पक्का होता है कि हर लेवल का स्क्रीन व्यू कठिनाई के किसी एक खास लेवल के साथ जोड़ा जा सकता है.

कॉन्फ़िगरेशन

कस्टम आयाम लागू करने का पहला चरण है, इसे Analytics के एडमिन सेक्शन की प्रॉपर्टी सेटिंग में तय करना. इस उदाहरण के लिए, कस्टम डाइमेंशन की परिभाषा इस तरह दिखती है:

इंडेक्स 1
नाम Difficulty
दायरा Hit
चालू है true

कलेक्शन

डेवलपर, गेम में स्क्रीन व्यू के साथ हर लेवल को पहले से ही ट्रैक कर रहा है. हर लेवल के साथ कठिनाई को जोड़ने के लिए, कस्टम आयाम मान स्क्रीन व्यू को ट्रैक करने के लिए कॉल के ठीक पहले सेट होना चाहिए.

लागू होने पर ऐसा दिख सकता है:

ga('create', 'UA-XXXX-Y', 'auto');

// इंडेक्स 1 पर कस्टम आयाम का मान सेट करना.
ga('set', 'cd1', 'easy');

// पेज व्यू हिट के साथ कस्टम आयाम मान भेजना.
ga('send', 'pageview', '/level_1/');

इस उदाहरण में, कस्टम आयाम, लेवल स्क्रीन व्यू को ट्रैक किए जाने से ठीक पहले सेट होता है. यह कठिनाई के लेवल को स्क्रीन व्यू से जोड़ता है और इसकी वजह से स्क्रीन व्यू हिट कठिनाई के लेवल के अनुसार रिपोर्ट में ग्रुप किए जा सकेंगे.

प्रोसेसिंग

हिट इकट्ठा करने और Analytics को भेजने के बाद, डेटा प्रोसेस किया जाता है. हिट पर कस्टम आयाम मान उनके दायरे के मुताबिक लागू किए जाते हैं.

उदाहरण के लिए, सिर्फ़ एक सत्र में हिस्सा लेने और 6 लेवल खेलने वाले किसी खिलाड़ी का इकट्ठा किया गया डेटा ऐसा दिखेगा:

userId = 5555
सत्र 1:
H1: screen_name=/level_1/ cd1_value=easy
H2: screen_name=/level_2/ cd1_value=medium
H3: screen_name=/level_3/ cd1_value=hard
H4: screen_name=/level_4/ cd1_value=easy
H5: screen_name=/level_5/ cd1_value=medium
H6: screen_name=/level_6/ cd1_value=medium

ध्यान दें कि हिट-स्तर के दायरे का इस्तेमाल करने से यह पक्का होता है कि कठिनाई के हर लेवल का मान सिर्फ़ उस स्क्रीन व्यू के साथ जुड़ता है जिसके साथ वह भेजा गया था.

रिपोर्टिंग

हर स्क्रीन व्यू मुश्किल लेवल वाली वैल्यू से जुड़ा होता है. इसलिए, प्रोसेस होने के बाद डेवलपर ऐसी रिपोर्ट बना सकता है जिसमें स्क्रीन का नाम और मुश्किल लेवल, दोनों ही डाइमेंशन के तौर पर इस्तेमाल हों. साथ ही, स्क्रीन व्यू का इस्तेमाल मेट्रिक के तौर पर किया गया हो:

स्क्रीन का नाम मुश्किल स्क्रीन व्यू
/level_1/ आसान 1
/level_2/ मध्यम 1
/level_3/ कठिन 1
/level_4/ आसान 1
/level_5/ मध्यम 1
/level_6/ मध्यम 1

एक ऐसी कस्टम रिपोर्ट बनाई जा सकती है जिसमें स्क्रीन व्यू को ग्रुप करने के लिए, मुश्किल लेवल का इस्तेमाल किया जा सके. साथ ही, इसकी मदद से यह भी पता लगाया जा सके कि हर मुश्किल लेवल को कितनी बार खेला गया था:

मुश्किल स्क्रीन व्यू
आसान 2
मध्यम 3
कठिन 1

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

सत्र-स्तर का दायरा

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

डेवलपर हर लेवल के लिए एक स्क्रीन व्यू ट्रैक करके पहले से ही यह जानता है कि हर लेवल कितनी बार खेला जाता है. अब उन्हें यह जानना है कि हर रोज़ कितने लेवल खेले गए.

डेवलपर जो रिपोर्ट बनाना चाहता है, वह कुछ इस तरह दिखेगी:

ट्रायल का दिन स्क्रीन व्यू
पहला दिन  
दूसरा दिन  
तीसरा दिन  

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

सत्र-स्तर का दायरा क्यों?

आप सत्र-स्तर के दायरे का इस्तेमाल करके, ट्रायल के एक दिन के मान में सभी सत्रों और उनके सभी कॉम्पोनेंट के हिट का ग्रुप बना सकते हैं.

हालांकि यह काम करने के लिए हिट-स्तर के दायरे का भी इस्तेमाल जा सकता है. इसके साथ ही, सत्र-स्तर के दायरे का इस्तेमाल करके आप आसानी से 'ट्रायल का दिन' वाला मान सेट कर सकते हैं. इसके लिए, आपको कोड का इस्तेमाल करना होगा.

कॉन्फ़िगरेशन

ट्रायल का दिन वाले कस्टम डाइमेंशन को Analytics यूज़र इंटरफ़ेस के प्रॉपर्टी सेटिंग सेक्शन में, इन वैल्यू की मदद से तय किया जाता है:

इंडेक्स 2
नाम Day of Trial
दायरा Session
चालू है true

कलेक्शन

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

जब उपयोगकर्ता पहली बार गेम शुरू करेगा, तो डेवलपर कस्टम आयाम को सेट करेगा:

ga('create', 'UA-XXXX-Y', 'auto');

// इंडेक्स 2 पर कस्टम आयाम के लिए मान सेट करना.
var day = getDayOfTrial();
ga('set', 'dimension2', day );

// पेज व्यू हिट के साथ कस्टम आयाम मान भेजना.
ga('send', 'pageview', '/level_1/');

ध्यान दें कि सत्र-स्तर का कस्टम आयाम, सत्र के दौरान किसी भी समय सेट किया जा सकता है. हालांकि, इस उदाहरण में डेवलपर के लिए ट्रायल का दिन जानना और सत्र के शुरू में उसके मुताबिक मान सेट करना आसान है.

प्रोसेसिंग

हिट इकट्ठा करने और Analytics को भेजने के बाद, डेटा प्रोसेस किया जाता है. हिट पर कस्टम आयाम मान उनके दायरे के मुताबिक लागू किए जाते हैं.

उदाहरण के लिए, एक ऐसा प्लेयर जिसने पहले दिन दो बार, दूसरे दिन एक बार, और तीसरे दिन एक बार गेम खेला. अब उसका डेटा कुछ ऐसा दिखाई देगा:

userId = 5555
सत्र 1:
H1: screen_name=/level_1/  cd2_value=1
H2: screen_name=/level_2/
H3: screen_name=/level_2/

सत्र 2:
H4: screen_name=/level_3/  cd2_value=1
H5: screen_name=/level_4/
H6: screen_name=/level_4/

सत्र 3:
H1: screen_name=/level_1/  cd2_value=2
H2: screen_name=/level_2/
H3: screen_name=/level_3/

सत्र 4:
H1: screen_name=/level_3/  cd2_value=3

ध्यान दें कि कस्टम आयाम मान हर सत्र में सिर्फ़ एक स्क्रीन व्यू के साथ भेजे गए हैं.

सत्र-स्तर के दायरे से यह पक्का होता है कि ट्रायल के दिन का मान उस सत्र के सभी हिट से जुड़ेगा. वह उस हिट के साथ नहीं जुड़ेगा जिसके साथ वह भेजा गया था.

रिपोर्टिंग

प्रोसेसिंग के बाद, सत्र-स्तर के कस्टम आयाम मानों को एक ही सत्र में मिले सभी स्क्रीन व्यू के साथ जोड़ा जाएगा. डेवलपर, अब मेट्रिक के तौर पर स्क्रीन व्यू और डाइमेंशन के तौर पर स्क्रीन के नाम और ट्रायल के दिन की जानकारी का इस्तेमाल करके, एक रिपोर्ट बना सकता है:

ट्रायल का दिन स्क्रीन का नाम स्क्रीन व्यू
1 /level_1/ 1
1 /level_2/ 2
1 /level_3/ 1
1 /level_4/ 2
2 /level_1/ 1
2 /level_2/ 1
2 /level_3/ 1
3 /level_3/ 1

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

ट्रायल का दिन स्क्रीन व्यू
1 6
2 3
3 1

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

उपयोगकर्ता-स्तर का दायरा

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

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

डेवलपर जो रिपोर्ट देखना चाहता है, वह कुछ इस तरह दिखती है:

प्लेयर टाइप स्क्रीन व्यू
मुफ़्त  
पैसे देने होंगे  

उपयोगकर्ता-लेवल कस्टम डाइमेंशन का इस्तेमाल करके, डेवलपर यह डेटा हासिल कर सकता है. इसके लिए, किसी खास उपयोगकर्ता के सभी स्क्रीन व्यू को, उसके मौजूदा और आने वाले समय के सेशन में प्लेयर टाइप की वैल्यू के साथ जोड़ा जाता है.

उपयोगकर्ता-स्तर का दायरा क्यों?

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

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

कॉन्फ़िगरेशन

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

इंडेक्स 3
नाम Player Type
दायरा User
चालू है true

कलेक्शन

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

जब उपयोगकर्ता पहली बार गेम शुरू करेगा, तो डेवलपर कस्टम आयाम को सेट करेगा:

ga('create', 'UA-XXXX-Y', 'auto');

// इंडेक्स 3 पर कस्टम आयाम के लिए मान सेट करना.
ga('set', 'dimension3', 'Free' );

// पेज व्यू हिट के साथ कस्टम आयाम मान भेजना.
ga('send', 'pageview', '/level_1/');

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

ga('create', 'UA-XXXX-Y', 'auto');

// इंडेक्स 3 पर कस्टम आयाम के लिए मान सेट करना.
ga('set', 'dimension3', 'Paid' );

// पेज व्यू हिट के साथ कस्टम आयाम मान भेजना.
ga('send', 'pageview', '/level_1/');

प्रोसेसिंग

जैसा कि पिछले उदाहरणों में बताया गया है, डेटा इकट्ठा करने के बाद उसे प्रोसेस किया जाता है और कस्टम आयाम मानों को उनके दायरे के मुताबिक हिट पर लागू किया जाता है.

उदाहरण के लिए, मुफ़्त उपयोगकर्ता के तौर पर दो बार और पैसे देकर एक बार गेम खेलने वाले किसी उपयोगकर्ता का इकट्ठा किया गया डेटा ऐसा दिखेगा:

userId = 5555
सत्र 1:
H2: screen_name=/level_1/ cd3_value=free
H3: screen_name=/level_2/

सत्र 2:
H1: screen_name=/level_2/
H2: screen_name=/level_3/
H3: screen_name=/level_3/

सत्र 3:
H1: screen_name=/level_3/ cd3_value=paid
H2: screen_name=/level_4/

ध्यान दें कि सत्र 1 में सेट किया गया मुफ़्त मान उस सत्र के साथ ही सत्र 2 के सभी हिट पर तब तक लागू होता है, जब तक सत्र 3 में नया मानभुगतान सेट नहीं हो जाता.

रिपोर्टिंग

प्रोसेस होने के बाद, प्लेयर के प्रकार वाले कस्टम आयाम मान उन सत्रों के साथ जोड़े जाएंगे जिनमें वे सेट किए गए थे. साथ ही, उन्हें भविष्य के सभी सत्रों और हिट से भी जोड़ा जाएगा.

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

प्लेयर टाइप स्क्रीन का नाम स्क्रीन व्यू
मुफ़्त /level_1/ 1
मुफ़्त /level_2/ 2
मुफ़्त /level_3/ 2
पैसे देने होंगे /level_3/ 1
पैसे देने होंगे /level_4/ 1

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

प्लेयर टाइप स्क्रीन व्यू
मुफ़्त 5
पैसे देने होंगे 2

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

उत्पाद-स्तर का दायरा

आइए इस बात का एक उदाहरण देखते हैं कि गेम डेवलपर किस तरह से उत्पाद-स्तर के कस्टम आयामों का इस्तेमाल करके यह जान सकते हैं कि कौनसी पावरअप शक्ति -- कमज़ोर, मध्यम या मज़बूत -- खरीदी गई.

डेवलपर बेहतर ई-कॉमर्स का इस्तेमाल करके पहले से ही यह ट्रैक कर रहा है कि पावरअप कितनी बार खरीदे गए. अब वे यह जानना चाहते हैं कि कौन सा पावरअप सबसे ज़्यादा खरीदा जा रहा है.

रिपोर्ट कुछ इस तरह दिखेगी:

पावरअप स्ट्रेंथ प्रॉडक्ट से हुई आय
कमज़ोर  
मध्यम  
मज़बूत  

कस्टम डाइमेंशन का इस्तेमाल करने से पहले, डेवलपर पावरअप से हुई प्रॉडक्ट की कुल आय को देख सकता था, लेकिन वह उस आय को पावरअप स्ट्रेंथ के हिसाब से ग्रुप नहीं कर पा रहा था.

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

उत्पाद-स्तर का दायरा क्यों?

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

कॉन्फ़िगरेशन

पावरअप स्ट्रेंथ वाले कस्टम डाइमेंशन को Analytics एडमिन के प्रॉपर्टी सेटिंग सेक्शन में, इन वैल्यू की मदद से तय किया जाता है:

इंडेक्स 4
नाम Powerup Strength
दायरा Product
चालू है true

कलेक्शन

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

उत्पाद के साथ इस आयाम को जोड़ने से कुछ ऐसा दिख सकता है:

ga('ec:addProduct', {               // productFieldObject में उत्पाद की जानकारी डालना.
  'id': 'P12345',                   // उत्पाद आईडी (string).
  'name': 'Powerup',                // उत्पाद का नाम (string).
  'category': 'Extras',             // उत्पाद की श्रेणी (string).
  'variant': 'red',                 // उत्पाद का वेरिएंट variant (string).
  'price': '10.00',                 // उत्पाद की कीमत (currency).
  'quantity': 2,                    // उत्पाद की संख्या (number).
  'dimension4': 'strong'            // उत्पाद के दायरे का कस्टम आयाम (string).
});
ga('ec:setAction', 'purchase', {
  'id': 'T12345',
  'revenue': '20.00'
});

ga('send', 'pageview');     // शुरुआती पेज व्यू के साथ लेन-देन का डेटा भेजना.

इस उदाहरण में, कस्टम आयाम को उत्पाद जानकारी के साथ सेट किया गया है. यह शक्ति को पावरअप के साथ जोड़ता है.

प्रोसेसिंग

जैसा कि पिछले उदाहरणों में बताया गया है, हिट इकट्ठा किए जाने और उन्हें Analytics को भेजे जाने के बाद, डेटा प्रोसेस होता है और कस्टम आयाम मान उन उत्पादों पर लागू किए जाते हैं जिनके साथ वे सेट किए गए थे.

उदाहरण के लिए, एक सत्र वाले और 3 पावरअप खरीदने वाले किसी खिलाड़ी का डेटा कुछ ऐसा दिखता है:

userId = 5555
सत्र 1:
H1: product_name=powerup cd4_value=weak
    product_name=powerup cd4_value=strong
H2: product_name=powerup cd4_value=weak

ध्यान दें कि उत्पाद-स्तर के दायरे का इस्तेमाल करने से यह पक्का होता है कि हर पावरअप मान सिर्फ़ उस उत्पाद से जोड़ा जाए जिसके साथ वह सेट किया गया था.

रिपोर्टिंग

हर प्रॉडक्ट अपनी स्ट्रेंथ वैल्यू से जुड़ा होता है, इसलिए उसके प्रोसेस होने के बाद, डेवलपर ऐसी कस्टम रिपोर्ट बना सकता है जो पावरअप स्ट्रेंथ के हिसाब से आय दिखाती है:

पावरअप स्ट्रेंथ प्रॉडक्ट से हुई आय
कमज़ोर 20.00
मज़बूत 10.00

इस रिपोर्ट के हिसाब से, कमज़ोर पावरअप से सबसे ज़्यादा आय हुई है.

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

दायरा

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

हिट-दायरे वाली कस्टम मेट्रिक का उदाहरण

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

हालांकि, डेवलपर हर लेवल के पूरा होने की दर से के बारे में भी जानकारी चाहता है.

पूरा होने की दर तय करने के लिए, डेवलपर पूरे किए गए लेवल नामक नई कस्टम मेट्रिक का इस्तेमाल करेगा और उसकी तुलना हर लेवल के स्क्रीन व्यू से करेगा.

डेवलपर जो रिपोर्ट चाहता है, वह कुछ इस तरह दिखती है:

स्क्रीन का नाम स्क्रीन व्यू पूरे हो चुके लेवल
/level_1/    
/level_2/    
/level_3/    

कस्टम मेट्रिक का इस्तेमाल करने के क्या फ़ायदे हैं?

बहुत से मामलों में, आपके पास सबसे ज़्यादा अहम मेट्रिक को ट्रैक करने के लिए इवेंट, स्क्रीन व्यू, और/या एक कस्टम मेट्रिक का इस्तेमाल करने का विकल्प होता है. हालांकि, कस्टम मेट्रिक से ज़्यादा सुविधाजनक और ज़्यादा आसानी से पढ़ने लायक कस्टम रिपोर्ट मिल सकती हैं. साथ ही, यह सबसे अहम मेट्रिक को ट्रैक करने का एक आसान तरीका है.

इस उदाहरण में, पूरे हो चुके हर लेवल के स्क्रीन व्यू को दोबारा नहीं गिने गए स्क्रीन व्यू के रूप में ट्रैक नहीं किया जा सका, इसलिए आप दूसरा तरीका ढूंढना चाहेंगे.

हालांकि, इवेंट के क्रम की वजह से उसका अकेले ही इस्तेमाल किया जा सकता है, लेकिन एक आयाम के तहत स्क्रीन व्यू और पूरे किए गए लेवल को मिलाकर ऊपर दी गई रिपोर्ट तैयार करना मुश्किल होगा.

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

कॉन्फ़िगरेशन

पूरे हो चुके लेवल वाली कस्टम मेट्रिक को यूज़र इंटरफ़ेस के मैनेजमेंट सेक्शन में, इन वैल्यू की मदद से तय किया जाता है:

इंडेक्स 1
नाम Level Completions
दायरा Hit
फ़ॉर्मैट टाइप Integer
चालू है true

कलेक्शन

डेवलपर पहले से ही स्क्रीन व्यू का इस्तेमाल करके हर लेवल की शुरुआत को ट्रैक कर रहा है. अब वह नए कस्टम मेट्रिक का इस्तेमाल करके पूरे किए गए लेवल को ट्रैक करना चाहता है.

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

लागू होने पर यह ऐसा दिखाई दे सकता है:

ga('create', 'UA-XXXX-Y', 'auto');

// लेवल पूरा करने वाली मेट्रिक में 1 जोड़ना.
ga('set', 'metric1', 1 );

// इवेंट हिट के साथ एक कस्टम मेट्रिक मान भेजना.
ga('send', 'event', 'Level', 'completion');

प्रोसेसिंग

प्रोसेस करने से पहले, किसी एक सत्र में गेम के तीन लेवल खेलने वाले किसी खिलाड़ी का डेटा ऐसा दिखेगा:

userId = 5555
सत्र 1
H1: type=screen_view screen_name=/level_1/
H2: type=event screen_name=/level_1/ cm1_value=1
H3: type=screen_view screen_name=/level_2/
H4: type=screen_view screen_name=/level_2/
H5: type=screen_view screen_name=/level_2/
H6: type=event screen_name=/level_2/ cm1_value=1
H7: type=screen_view screen_name=/level_3/
H8: type=event screen_name=/level_3/ cm1_value=1

रिपोर्टिंग

प्रोसेस होने के बाद, डेवलपर एक ऐसी रिपोर्ट बना सकता है जिसमें डाइमेंशन के तौर पर स्क्रीन के नाम और मेट्रिक के तौर पर स्क्रीन व्यू, कुल इवेंट, और पूरे हो चुके लेवल का इस्तेमाल किया जाता है:

स्क्रीन का नाम स्क्रीन व्यू कुल इवेंट पूरे हो चुके लेवल
/level_1/ 1 1 1
/level_2/ 3 1 1
/level_3/ 1 1 1

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

इसके बजाय, डेवलपर पूरे हो चुके लेवल वाली कस्टम मेट्रिक का इस्तेमाल करके, आसानी से इस कस्टम रिपोर्ट को बना सकता है:

स्क्रीन का नाम स्क्रीन व्यू पूरे हो चुके लेवल
/level_1/ 1 1
/level_2/ 3 1
/level_3/ 1 1

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

उत्पाद-दायरे वाले कस्टम मेट्रिक का उदाहरण

ऊपर दिए गए उदाहरण में, गेम डेवलपर पावरअप की हर खरीदारी को ट्रैक करता रहा है. ऐसे कई मेट्रिक हैं, जिन्हें हर खरीदारी के साथ जोड़ा जा सकता है, जैसे मात्रा और उत्पाद से होने वाली आय.

हालांकि, गेम डेवलपर ने हाल ही में एक प्रोमोशन ऑफ़र चलाया था जिसके तहत सभी उपयोगकर्ताओं को ₹5000 का क्रेडिट दिया गया था. गेम डेवलपर यह आकलन करना चाहता है कि लोग अपने क्रेडिट से कौनसे पावरअप खरीद रहे हैं.

हर उत्पाद की खरीदारी में इस्तेमाल होने वाले क्रेडिट का पता लगाने के लिए, डेवलपर 'इस्तेमाल किया गया क्रेडिट' नाम का एक नया कस्टम मेट्रिक इस्तेमाल करेगा.

डेवलपर जो रिपोर्ट चाहता है, वह कुछ इस तरह दिखती है:

पावरअप स्ट्रेंथ उत्पाद की आय इस्तेमाल किए गए क्रेडिट
मज़बूत    
मध्यम    
कमज़ोर    

कॉन्फ़िगरेशन

इस्तेमाल किए गए क्रेडिट वाली कस्टम मेट्रिक को एडमिन सेक्शन में, इन वैल्यू की मदद से तय किया जाता है:

इंडेक्स 2
नाम Credits Used
दायरा Product
फ़ॉर्मैट टाइप Integer
चालू है true

कलेक्शन

उत्पाद-स्तर के कस्टम आयामों की तरह ही, उत्पाद-स्तर की कस्टम मेट्रिक, Analytics को उत्पाद डेटा से जुड़े पैरामीटर के रूप में भेजी जाती हैं.

लागू होने पर यह ऐसा दिखाई दे सकता है:

ga('ec:addProduct', {               // productFieldObject में उत्पाद की जानकारी डालना.
  'id': 'P12345',                   // उत्पाद आईडी (string).
  'name': 'Powerup',                // उत्पाद का नाम (string).
  'category': 'Extras',             // उत्पाद की श्रेणी (string).
  'variant': 'red',                 // उत्पाद का वेरिएंट variant (string).
  'price': '10.00',                 // उत्पाद की कीमत (currency).
  'quantity': 2,                    // उत्पाद की संख्या (number).
  'dimension4': 'strong',           // उत्पाद के दायरे वाला कस्टम आयाम (string).
  'metric2': 5                      // उत्पाद के दायरे वाली कस्टम मेट्रिक (integer).
});
ga('ec:setAction', 'purchase', {
  'id': 'T12345',
  'revenue': '20.00'
});

ga('send', 'pageview');     // शुरुआती पेज व्यू के साथ लेन-देन का डेटा भेजना.


प्रोसेसिंग

प्रोसेस होने से पहले, कुछ पावरअप खरीदने वाले किसी एक खिलाड़ी का डेटा कुछ ऐसा दिख सकता है:

userId = 5555
Session 1
H1: type=screen_view screen_name=/level_1/
H2: type=screen_view screen_name=/level_2/
    product_name=powerup cd4_value=weak cm2_value=5
    product_name=powerup cd4_value=strong cm2_value=5
H4: type=screen_view screen_name=/level_2/
    product_name=powerup cd4_value=medium cm2_value=1
    product_name=powerup cd4_value=weak cm2_value=10

रिपोर्टिंग

प्रोसेस होने के बाद, डेवलपर डाइमेंशन के तौर पर पावरअप स्ट्रेंथ और मेट्रिक के तौर पर प्रॉडक्ट से हुई आय और इस्तेमाल किए गए क्रेडिट वाली रिपोर्ट बना सकता है:

पावरअप स्ट्रेंथ उत्पाद की आय इस्तेमाल किए गए क्रेडिट
कमज़ोर 20 15
मज़बूत 10 5
मध्यम 10 1

डेटा से पता चलता है कि प्लेयर अपने क्रेडिट का इस्तेमाल कमज़ोर पावरअप के लिए कर रहे हैं. डेवलपर को सबसे ज़्यादा फ़ायदा मध्यम पावरअप से हुआ है.

लागू किए जाने के दौरान ध्यान देने वाली बातें

कस्टम आयामों या मेट्रिक को लागू करते समय, इन बातों को ध्यान में रखें:

किसी मौजूदा आयाम या मेट्रिक में बदलाव करना

किसी मौजूदा कस्टम डाइमेंशन या मेट्रिक के नाम या दायरे में बदलाव करने पर, आपके डेटा पर कई तरह से असर पड़ सकता है. इसकी जानकारी नीचे दी गई है:

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

दायरा सेट करने के लिए पहले से प्लान करना

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

क्या यह उपयोगी था?
हम उसे किस तरह बेहतर बना सकते हैं?

और मदद चाहिए?

मदद के दूसरे तरीकों के लिए साइन इन करें ताकि आपकी समस्या झटपट सुलझ सके

खोजें
खोज साफ़ करें
खोज बंद करें
Google ऐप
मुख्य मेन्यू
खोज मदद केंद्र
true
true
true
true
true
69256