(अन्य) लाइन क्या है
(अन्य) लाइन, रिपोर्ट, एक्सप्लोरेशन या Data API से मिले रिस्पॉन्स में तब दिखती है, जब टेबल में लाइनों की संख्या, टेबल की तय सीमा से ज़्यादा हो जाती है. ऐसा होने पर, Analytics सिर्फ़ सबसे ज़्यादा इस्तेमाल होने वाली डाइमेंशन वैल्यू को दिखाता है. कम इस्तेमाल होने वाली वैल्यू को (अन्य) लाइन में छोटा किए गए डेटा के तौर पर दिखाया जाता है.
उदाहरण के लिए, अगर पेज और स्क्रीन रिपोर्ट से जुड़ा डेटा दिखाने वाली टेबल के लिए लाइनों की सीमा 1 लाख है, लेकिन प्रॉपर्टी में यूनीक पेजों की संख्या 1 लाख 50 हज़ार है, तो Analytics लाइनों को इस क्रम से लगाएगा कि सबसे ज़्यादा इस्तेमाल होने वाली लाइनें ऊपर हों और सबसे कम इस्तेमाल होने वाली लाइनें सबसे नीचे. इसके बाद, आखिरी 50 हज़ार लाइनों का एक ग्रुप बनाकर उसे (अन्य) लाइन के तहत रखेगा.
आपको (अन्य) लाइन क्यों दिखती है
Analytics में मौजूद हर डाइमेंशन में, असाइन की गई कई वैल्यू हो सकती हैं. किसी डाइमेंशन को असाइन की गई वैल्यू की संख्या, उसके एलिमेंट की संख्या होती है. उदाहरण के लिए, आईएस मुख्य इवेंट वाले डाइमेंशन में असाइन की गई दो वैल्यू हो सकती हैं ('सही' या 'गलत'). वहीं, पेज का पाथ वाले डाइमेंशन में, आपकी वेबसाइट के हर यूआरएल पाथ के लिए, अलग वैल्यू हो सकती है.
कई टेबल में एक से ज़्यादा डाइमेंशन होते हैं. इन टेबल में लाइनों की संख्या, हर डाइमेंशन के लिए तय वैल्यू को आपस में गुणा करके मिलने वाली संख्या के बराबर होगी. उदाहरण के लिए, अगर किसी रिपोर्ट में डिवाइस वाला डाइमेंशन (तीन वैल्यू: डेस्कटॉप, टैबलेट, और मोबाइल) और उम्र वाला डाइमेंशन (उम्र का छह ग्रुप) शामिल हैं, तो टेबल में 18 लाइनें हो सकती हैं. यह इस बात पर निर्भर करता है कि आपने डाइमेंशन वैल्यू के हर कॉम्बिनेशन के लिए डेटा इकट्ठा किया है या नहीं.
अगर किसी डाइमेंशन में 500 से ज़्यादा वैल्यू हैं, तो उसे ज़्यादा एलिमेंट वाला डाइमेंशन माना जाना चाहिए. इसकी वजह यह है कि उस डाइमेंशन को स्टोर करने वाली सभी टेबल के लिए, एलिमेंट की संख्या काफ़ी बढ़ जाएगी. साथ ही, इस बात की संभावना भी बढ़ जाएगी कि उन टेबल में कुछ डेटा (अन्य) लाइन में, छोटे किए गए डेटा के तौर पर दिखाए जा सकते हैं. हर डाइमेंशन के लिए 500 वैल्यू कोई सीमा नहीं है, बल्कि एक दिशा-निर्देश है. किसी डाइमेंशन के लिए बहुत ज़्यादा वैल्यू इकट्ठा करने पर, (अन्य) लाइन में डेटा शामिल किए जाने का जोखिम भी बढ़ जाता है.
एलिमेंट की संख्या की सीमाएं
टेबल में लाइनों की संख्या की सीमा इन स्थितियों के आधार पर अलग-अलग होती है:
- प्रॉपर्टी टाइप: स्टैंडर्ड प्रॉपर्टी की सीमाओं की तुलना में, Analytics 360 प्रॉपर्टी की सीमाएं ज़्यादा होती हैं.
- अलग-अलग रिपोर्ट या एक्सप्लोरेशन: कुछ रिपोर्ट में ज़्यादा एलिमेंट वाले डाइमेंशन होते हैं. इसलिए, उनकी सीमाएं भी ज़्यादा होती हैं. उदाहरण के लिए, पेज और स्क्रीन रिपोर्ट.
- क्वेरी की जटिलता: एक डाइमेंशन वाली स्टैंडर्ड रिपोर्ट में शायद ही (अन्य) लाइन मौजूद हो. हालांकि, सेकंडरी डाइमेंशन, फ़िल्टर या तुलना वाली रिपोर्ट में, (अन्य) लाइन के शामिल होने की संभावना ज़्यादा होती है. इसकी वजह यह है कि उनमें कई डाइमेंशन वाली डेटाबेस टेबल शामिल होती हैं. आम तौर पर, ज़्यादा और मुश्किल डेटा वाली प्रॉपर्टी में, तय सीमा से ज़्यादा एलिमेंट हो सकते हैं.
(अन्य) लाइन में डेटा इकट्ठा होने से रोकने के सबसे सही तरीके
(अन्य) लाइन के दिखने की संभावना कम करने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं:
- कस्टम डाइमेंशन बनाने से पहले, पहले से तय किए गए डाइमेंशन इस्तेमाल करें. उदाहरण के लिए, किसी डेटा के लिए कस्टम डाइमेंशन तय करने के बजाय, पहले से तय किए गए गेमिंग डाइमेंशन इस्तेमाल करें. जैसे, किरदार, वर्चुअल मुद्रा का टाइप.
- ज़्यादा एलिमेंट वाले डाइमेंशन का इस्तेमाल सिर्फ़ ज़रूरत पड़ने पर करें. ये डाइमेंशन आपको प्रॉपर्टी में लाइनों की सीमा के करीब पहुंचा देते हैं या यह सीमा पार कर देते हैं.
- कस्टम डाइमेंशन का इस्तेमाल करके, हर उपयोगकर्ता के लिए अलग आइडेंटिफ़ायर बनाने से बचें. इसके बजाय, User-ID सुविधा का इस्तेमाल करें.
- जहां भी मुमकिन हो, वहां स्टैंडर्ड रिपोर्ट इस्तेमाल करें, क्योंकि इनमें एग्रीगेट टेबल होती हैं. इससे (अन्य) लाइन में, डेटा के शामिल होने की संभावना कम हो जाती है.
अगर आपको ज़्यादा एलिमेंट वाला डेटा मेज़र करना है, तो इवेंट पैरामीटर और उपयोगकर्ता प्रॉपर्टी की मदद से डेटा भेजें. ऐसा कस्टम डाइमेंशन में डेटा को रजिस्टर किए बिना करें. कस्टम डाइमेंशन को रजिस्टर न करके भी, प्रॉपर्टी की सीमाओं पर असर डाले बिना, BigQuery, ऑडियंस, सेगमेंट, और अन्य सुविधाओं में डेटा का इस्तेमाल किया जा सकता है.