हर रिपोर्ट डाइमेंशन, जैसे कि पेज, ब्राउज़र, स्क्रीन रिज़ॉल्यूशन वगैरह में कई वैल्यू होती हैं, जिन्हें डाइमेंशन के लिए असाइन किया जा सकता है. किसी डाइमेंशन के लिए यूनीक वैल्यू की कुल संख्या को, उसके एलिमेंट की संख्या के तौर पर जाना जाता है. उदाहरण के लिए, मोबाइल या ga:isMobile डाइमेंशन की दो संभावित वैल्यू (हां या नहीं) हैं. इसलिए, उस डाइमेंशन के लिए एलिमेंट की संख्या दो है. अन्य डाइमेंशन में असाइन की गई वैल्यू की संख्या कितनी भी हो सकती है. उदाहरण के लिए, पेज डाइमेंशन में हर यूआरएल के लिए अलग वैल्यू होती है, जो आपकी साइट पर दिखती है.
जिन डाइमेंशन में संभावित वैल्यू की संख्या ज़्यादा होती हैं उन्हें ज़्यादा एलिमेंट वाले डाइमेंशन कहा जाता है. जिन रिपोर्ट में ज़्यादा एलिमेंट वाले डाइमेंशन होते हैं उन पर Analytics सिस्टम की सीमाओं का असर पड़ सकता है. इस वजह से, रिपोर्ट में एक (अन्य) एंट्री जुड़ जाती है, ताकि तय सीमाओं से ज़्यादा डेटा को शामिल किया जा सके.
इस लेख में, इन विषयों के बारे में बताया गया है:समाधान
पेज डाइमेंशन में संभावित वैल्यू की संख्या को कम करें. इसके लिए, क्वेरी पैरामीटर की सेटिंग में किसी भी डाइनैमिक सेशन या ग्राहक आईडी वैरिएबल को फ़िल्टर करें. अगर आपको क्वेरी पैरामीटर को रिपोर्ट में शामिल नहीं करना है, तो उन्हें यूआरएल से अलग करें. क्वेरी पैरामीटर को अलग करने के लिए, अपनी व्यू सेटिंग में बदलाव करें. साइट खोज सेटिंग में, क्वेरी पैरामीटर के विकल्पों में बदलाव करें.
क्वेरी पैरामीटर को एक्सट्रैक्ट करने के लिए, इस स्प्रेडशीट का इस्तेमाल करें. यह स्प्रेडशीट, पिछले सात दिनों के पेजों की सूची को क्वेरी करने के लिए, Google Sheets के Analytics API ऐड-ऑन का इस्तेमाल करती है. साथ ही, सभी यूनीक क्वेरी पैरामीटर को एक्सट्रैक्ट करके, पढ़ने में आसान सूची में शामिल करती है. आपके पास सूची देखने, जिन पैरामीटर को बाहर रखना है उन्हें मार्क करने, और फिर कॉमा लगाकर अलग की जाने वाली ऐसी स्ट्रिंग जनरेट करने का विकल्प है जिसे व्यू सेटिंग में, यूआरएल क्वेरी पैरामीटर को बाहर रखें विकल्प में चिपकाया जा सकता है. स्प्रेडशीट में निर्देश शामिल हैं.
ज़्यादा जानकारी
प्रोसेस की गई टेबल की मदद से रिपोर्टिंग में तेज़ी लाना
Analytics, आपकी प्रॉपर्टी के हर सेशन के बारे में रॉ डेटा स्टोर करने के लिए, विज़िट टेबल का इस्तेमाल करता है. इसके अलावा, यह सामान्य रिपोर्ट के पहले से इकट्ठा किए गए डेटा को प्रोसेस की गई टेबल में स्टोर करता है. इन टेबल को एग्रीगेट टेबल कहा जाता है. प्रोसेस की गई इन टेबल की मदद से, आम तौर पर अनुरोध की गई रिपोर्ट जल्दी और बिना सैंपलिंग के लोड हो जाती हैं.1
हर दिन प्रोसेस की जाने वाली टेबल के लिए डेटा की सीमाएं
हर दिन प्रोसेस की जाने वाली टेबल, स्टैंडर्ड Analytics के लिए ज़्यादा से ज़्यादा 50,000 लाइनें और Google Analytics 360 के लिए 10,00,000 लाइनें स्टोर कर सकती हैं. इसका यह मतलब है कि प्रोसेस की जाने वाली हर टेबल में, हर दिन डाइमेंशन वैल्यू के कई यूनीक कॉम्बिनेशन2 स्टोर किए जाते हैं. जब डाइमेंशन वैल्यू के कॉम्बिनेशन, किसी टेबल के लिए तय की गई संख्या से ज़्यादा होते हैं, तो Analytics टॉप N वैल्यू 3 को स्टोर करता है और बाकी के कॉम्बिनेशन के लिए, एक (अन्य) लाइन बनाता है.
कस्टम टेबल का इस्तेमाल करने वाले 360 क्लाइंट के लिए, इन टेबल की हर दिन की सीमा 10 लाख लाइनें हैं. कस्टम टेबल और उनकी सीमाओं के बारे में ज़्यादा जानकारी के लिए, कस्टम टेबल के बारे में जानकारी लेख पढ़ें.
कई दिनों में प्रोसेस की जाने वाली टेबल के लिए डेटा की सीमाएं
लंबी तारीख की सीमाओं वाली रिपोर्ट को तेज़ी से तैयार करने के लिए, Analytics कई दिनों में प्रोसेस की जाने वाली टेबल का इस्तेमाल करता है. इनमें से हर एक में चार दिनों का डेटा शामिल होता है. कई दिनों का डेटा दिखाने वाली टेबल बनाने के लिए, हर दिन प्रोसेस की जाने वाली टेबल का इस्तेमाल किया जाता है. ये टेबल, स्टैंडर्ड Analytics के लिए 1 लाख लाइनें और 360 के लिए 1.5 लाख लाइनें स्टोर करती हैं. हर दिन प्रोसेस की जाने वाली टेबल की तरह, जब डाइमेंशन वैल्यू के यूनीक कॉम्बिनेशन, कई दिनों का डेटा दिखाने वाली किसी टेबल के लिए तय की गई संख्या से ज़्यादा होते हैं, तो Analytics टॉप N वैल्यू को स्टोर करता है और बाकी के कॉम्बिनेशन के लिए, एक (अन्य) लाइन बनाता है.
यूनीक यूआरएल या कैंपेन से जुड़े कीवर्ड जैसी डाइमेंशन वैल्यू, अक्सर सभी तय किए गए दिनों में दोहराई जाती हैं. इसलिए, कई दिनों के आंकड़े दिखाने वाली टेबल की सीमाएं, आम तौर पर उन साइटों पर असर डालती हैं जिनमें ज़्यादा यूनीक कॉन्टेंट और/या कीवर्ड होते हैं.
रिपोर्ट क्वेरी की सीमा
यह, सिस्टम की एक और सीमा है. इसकी वजह से, एग्रीगेट (अन्य) एंट्री बन सकती है. किसी भी तारीख की सीमा के लिए Analytics, रिपोर्ट में ज़्यादा से ज़्यादा 10 लाख लाइनें दिखाता है. इसलिए, 10 लाख से ज़्यादा लाइनें होने पर, उन्हें (अन्य) लाइन में जोड़ दिया जाता है.
ज़्यादा एलिमेंट वाले डाइमेंशन इंपोर्ट करना
उपयोगकर्ता, प्रॉडक्ट या कॉन्टेंट डेटा पर क्वेरी-टाइम डेटा इंपोर्ट का इस्तेमाल करने से, आपके डेटा को आपकी रिपोर्ट में (अन्य) लाइन में जोड़ा जा सकता है. इसकी जानकारी नीचे दी गई है.
मेरी रिपोर्ट पर इसका क्या असर होगा?
ज़्यादा एलिमेंट वाले डाइमेंशन की ऐसी रिपोर्ट देखने पर जिसमें ऊपर बताई गई सीमाओं से ज़्यादा लाइनें हों, आपको उस डाइमेंशन की सभी वैल्यू नहीं दिखेंगी. इसकी वजह यह है कि उसकी कुछ वैल्यू (अन्य) एंट्री में जोड़ दी जाती हैं. कृपया ध्यान दें, Analytics अब भी सामान्य तौर पर डेटा ट्रैक कर रहा है. हालांकि, यह पूरे डेटा को आपकी रिपोर्ट में नहीं दिखा सकता.
इस बात पर भी ध्यान देना ज़रूरी है कि (अन्य) में जोड़ी गई वैल्यू बदल सकती हैं. उदाहरण के लिए, मान लें कि 1 मार्च को, "/categories/hats" पेज आपका 49,999वां सबसे ज़्यादा देखा गया यूआरएल था, जिसे 3 पेज व्यू मिले, लेकिन 2 मार्च को यह आपका 50,001वां सबसे ज़्यादा देखा गया यूआरएल था, जिसे 1 पेज व्यू मिला. अब अगर Analytics में उन दो दिनों को कवर करने के लिए रिपोर्ट मांगी जाती है, तो आपको "/categories/hats" यूआरएल के लिए 3 पेज व्यू दिखेंगे. ऐसा इसलिए, क्योंकि 2 मार्च के पेज व्यू को (अन्य) में जोड़ दिया जाएगा.
1 कुछ मामलों में, प्रोसेस की गई मौजूदा टेबल से उपयोगकर्ता क्वेरी का जवाब नहीं मिल पाता है. ऐसे में, मांगी गई जानकारी इकट्ठा करने के लिए, Analytics, रॉ विज़िट डेटा का इस्तेमाल करता है. उस स्थिति में, आपकी रिपोर्ट में उस क्वेरी के सैंपल सेट में 10 लाख यूनीक डाइमेंशन वैल्यू कॉम्बिनेशन शामिल होंगे.↑
2प्रोसेस की गई कुछ टेबल में एक से ज़्यादा डाइमेंशन होते हैं. यह सीमा, उन सभी डाइमेंशन के अलग-अलग वैल्यू कॉम्बिनेशन पर लागू होती है जिन्हें टेबल में जोड़ा जाता है.↑
3टेबल को काम की मेट्रिक के हिसाब से क्रम में लगाकर, यह पता लगाया जा सकता है कि सबसे ज़्यादा वैल्यू वाले कॉम्बिनेशन कौनसे हैं. उदाहरण के लिए, सेशन, पेज व्यू, ट्रांज़ैक्शन वगैरह. इसके बाद, कम वॉल्यूम वाले डाइमेंशन वैल्यू कॉम्बिनेशन को (अन्य) एंट्री में एग्रीगेट किया जाता है.↑
