डेवलपर टूल · URL एनकोडर और डिकोडर
असंगत URL एन्कोडिंग एनालिटिक्स में एक पेज को कई पंक्तियों में क्यों विभाजित करती है
· यह क्यों मायने रखती है
एनालिटिक्स URL एन्कोडिंग मानकीकरण
%20 और +, %2F और /, %c3 और %C3 सभी एक ही URL का वर्णन कर सकते हैं, लेकिन रिपोर्ट उन्हें अलग-अलग पेजों के रूप में मानती हैं। यह पोस्ट बताती है कि वेरिएंट कहां से आते हैं और गिनती से पहले उन्हें कैसे सामान्य किया जाए।
रिपोर्ट में छह URL वाला लैंडिंग पेज - साथ-साथ वेरिएंट और उनके द्वारा विभाजित ट्रैफ़िक
डेटा विश्लेषकों ने देखा कि एक लैंडिंग पेज एनालिटिक्स डैशबोर्ड में छह अलग-अलग URL के रूप में दिखाई दे रहा है। समान पेज हो सकते हैं: /landing?utm_source=email, /landing?utm_source=%65mail, /landing?utm_source=email%20campaign, /landing?utm_source=email+campaign, /landing?utm_source=email%20अभियान, /landing?utm_source=email%2bअभियान। प्रत्येक वैरिएंट को अलग-अलग पेज दृश्य, खंडित ट्रैफ़िक के रूप में गिना जाता है। स्प्रेडशीट, ईमेल और फ़ॉर्म का डेटा एन्कोडिंग विविधताएं प्रस्तुत करता है।
असंगत एन्कोडिंग कई डेटा स्रोतों और परिवर्तनों से उत्पन्न होती है। हाथ से लिखे गए लिंक में खाली स्थान या कोई एन्कोडिंग का उपयोग नहीं होता है। स्प्रैडशीट निर्यात प्रतिशत-एन्कोडेड URL उत्पन्न करता है। ईमेल क्लाइंट URL में गड़बड़ी करते हैं या उन्हें दोबारा एनकोड करते हैं। पुनर्निर्देशन श्रृंखलाएं असंगत रूप से सामान्यीकृत होती हैं। API इंटीग्रेशन, JavaScript फ्रेमवर्क और एनालिटिक्स कोड अलग-अलग नियम लागू करते हैं। वही URL अवधारणा परतों से गुजरती है, अलग-अलग तरीके से एन्कोड और पुनः एन्कोड की जाती है।
भिन्नता के स्रोत - हस्तलिखित लिंक, स्प्रेडशीट निर्यात, मेल क्लाइंट और रीडायरेक्ट चेन
हेक्स अंकों में मामला पहला सामान्यीकरण मुद्दा प्रस्तुत करता है। RFC 3986 निर्दिष्ट करता है कि हेक्स अंक अपरकेस होने चाहिए: %2F, न कि %2f। अपरकेस और लोअरकेस हेक्स समान बाइट्स को एनकोड करते हैं। सख्त तुलना %2F और %2f को अलग-अलग मानती है। %65 के रूप में वर्ण "e" को अनएन्कोडेड "e" के रूप में सामान्यीकृत किया जाना चाहिए क्योंकि RFC 3986 अक्षरों को अनारक्षित के रूप में वर्गीकृत करता है। संपूर्ण URL को ओवर-एन्कोडिंग करने से अलग-अलग विश्लेषण रिकॉर्ड बनते हैं।
RFC 3986 में अनारक्षित सेट में शामिल हैं: A-Z, a-z, 0-9, हाइफ़न, अवधि, अंडरस्कोर और टिल्ड। इन्हें सामान्यीकृत URL में कभी भी प्रतिशत-एन्कोड नहीं किया जाना चाहिए। RFC सामान्यीकरण निर्दिष्ट करता है कि %41 "ए" को डिकोड करने से अनएन्कोडेड "ए" को सामान्य किया जाना चाहिए। इसे सभी URL पर लागू करने से अनावश्यक एन्कोडिंग हट जाती है। %2f%6c%61%6e%64%69%6e%67 जैसे URL डिकोडिंग के बाद /landing बन जाते हैं।
हेक्स अंकों में मामला और अनारक्षित सेट - जो RFC 3986 कहता है वह समतुल्य है और जो नहीं है
आरक्षित वर्ण विनिमेय नहीं हैं और सामान्यीकरण के दौरान अलग-अलग रहने चाहिए। RFC 3986 जेन-डिलिम्स (:, /, ?, #, [, ], @) और सब-डिलिम्स (!, $, &, ', (, ), *, +, ,, ;, =) आरक्षित करता है। इनका संरचनात्मक अर्थ है। पथों में फ़ॉरवर्ड स्लैश विभाजक के रूप में कार्य करते हैं और इन्हें एन्कोड नहीं किया जाना चाहिए। जब वही वर्ण क्वेरी मानों में डेटा के रूप में दिखाई देता है, तो इसे %2F के रूप में एन्कोड किया जाना चाहिए। आँख बंद करके डिकोडिंग करने से URL संरचना टूट जाती है।
सामान्यीकरण की बारीकियाँ प्रासंगिक समझ की आवश्यकता वाली चुनौतियाँ पैदा करती हैं। केवल अनारक्षित वर्णों को डीकोड करें, आरक्षित वर्णों को एन्कोडेड छोड़ दें। /landing?data=%2F%20%2f जैसे URL अस्पष्ट रहते हैं। क्वेरी स्ट्रिंग्स किससे प्रारंभ होती हैं? (आरक्षित, संरचनात्मक)। क्वेरी मानों के अंदर, कुछ भी दिखाई दे सकता है—प्रश्न चिह्नों के लिए %3F एन्कोडिंग की आवश्यकता होती है। %2f%6c%61%6e%64%69%6e%67%3fkey%3dvalue के रूप में एन्कोड किए गए URL /landing?key=value पर सामान्य हो जाते हैं।
आरक्षित वर्ण विनिमेय नहीं हैं - क्यों %2F और/वैध रूप से अलग-अलग अर्थ हो सकते हैं
व्यावहारिक उदाहरण: छह URL वेरिएंट को सामान्य बनाना पूर्ण सामान्यीकरण को दर्शाता है। आधार URL /page?utm_source=email&campaign=test को दर्शाता है। छह प्रकार: 1) /page?utm_source=email&campaign=test (विहित), 2) /page?utm_source=%65%6d%61%69%6c&campaign=test (लोअरकेस हेक्स), 3) /page?utm_source=email%20&campaign=test (मूल्य में स्थान), 4) /page?utm_source=email+&campaign=test (स्पेस के अलावा), 5) /page?utm_source=EMAIL&campaign=test (अलग मामला), 6) /page?utm_source=email&%63ampaign=test (हेक्स नाम में)।
वैरिएंट 2 को सामान्य करने के लिए हेक्स मामलों को ठीक करने और अनारक्षित अक्षरों को डिकोड करने की आवश्यकता होती है: %65%6d%61%69%6c ईमेल बन जाता है। प्लस चिह्न वाले वेरिएंट 4 को संदर्भ जागरूकता की आवश्यकता होती है - यदि स्रोत HTML रूप हैं, तो प्लस का अर्थ स्थान है; अन्यथा प्लस शाब्दिक है। वेरिएंट 5 में अपरकेस "EMAIL" है; लोअरकेस "ईमेल" विहित है क्योंकि ईमेल केस-असंवेदनशील होते हैं। वैरिएंट 6 में %63 है ("c" के लिए हेक्स); अनारक्षित डिकोडिंग विहित से मेल खाते "अभियान" का निर्माण करती है।
कारगर उदाहरण: एक URL के छह प्रकारों को सामान्य बनाना - सुरक्षित वर्णों को डिकोड करना, हेक्स केस को ठीक करना, और जो अलग रहता है
पाइपलाइनों में सामान्यीकरण को लागू करना - अंतर्ग्रहण पर सामान्यीकरण और कच्चे मूल्यों को बनाए रखना - एनालिटिक्स के लिए अनुशंसित वास्तुकला है। अंतर्ग्रहण बिंदुओं पर जहां URL डेटाबेस में प्रवेश करते हैं (लॉगिंग एंडपॉइंट), पेज-दृश्य कुंजियों को संग्रहीत या प्राप्त करने से पहले सामान्यीकरण लागू करें। सामान्यीकरण: 1) URL को घटकों में पार्स करें, 2) अनारक्षित अनुक्रमों को डिकोड करें (हेक्स केस ठीक करें), 3) पैरामीटर क्रम को सामान्य करें, 4) समूहीकरण के लिए विहित प्रपत्र तैयार करें, 5) सामान्यीकृत प्रपत्रों और कच्चे मानों को संग्रहीत करें। यह सभी छह वेरिएंट को एक ही समूह कुंजी में हैश करना सुनिश्चित करता है।
सामान्यीकृत URL पर आधारित हैश फ़ंक्शन यह सुनिश्चित करते हैं कि सभी वेरिएंट रिपोर्ट में समान पेजों पर मैप हों। यदि एनालिटिक्स सिस्टम में अंतर्निहित सामान्यीकरण का अभाव है, तो डेटा इंजीनियरिंग परतें (ETL पाइपलाइन) डेटाबेस लिखने से पहले सामान्य हो जाती हैं। Google Analytics जैसे टूल के लिए, कॉन्फ़िगर करने योग्य फ़िल्टर रेगेक्स ग्रुपिंग या URL से अलग शीर्षक भेजने की अनुमति देते हैं। अधिकांश मजबूत दृष्टिकोण स्रोतों पर सामान्यीकरण करते हैं: जब ट्रैकिंग कोड एनालिटिक्स को URL भेजता है, तो कैनोनिकलाइज्ड फॉर्म सुनिश्चित करें।
इसे एक पाइपलाइन में करना - अंतर्ग्रहण पर सामान्यीकृत करना और एक पैटर्न के रूप में वर्णित कच्चे मूल्य को बनाए रखना
इसमें जो शामिल नहीं है उसमें SEO के लिए ट्रैकिंग-पैरामीटर स्ट्रिपिंग और कैनोनिकल टैग शामिल हैं, जो संबंधित हैं लेकिन अलग हैं। Utm_source और utm_campaign जैसे ट्रैकिंग पैरामीटर को एनालिटिक्स से हटाकर ऑर्गेनिक सामग्री के आधार पर समूह में लाया जा सकता है। यह अलग व्यावसायिक तर्क है. HTML कैनोनिकल टैग SEO के विभिन्न प्रकारों में पेज दृश्यों को समेकित करते हैं लेकिन आंतरिक विश्लेषण को प्रभावित नहीं करते हैं। व्यापक रणनीतियाँ दोनों दृष्टिकोणों को मिलाकर कई डिडुप्लीकेशन परतों को नियोजित करती हैं।
एनालिटिक्स स्पेस सामान्यीकरण समर्थन व्यापक रूप से भिन्न होता है। Google Analytics कुछ सामान्यीकरण को स्वचालित रूप से संभालता है लेकिन इसमें विविधताएं छूट सकती हैं। अन्य टूलों के लिए मैन्युअल कॉन्फ़िगरेशन की आवश्यकता होती है। सशुल्क खोज प्लेटफ़ॉर्म अभियान URL पर भिन्न सामान्यीकरण लागू करते हैं। सर्वर रिकॉर्ड URL को सामान्यीकरण के बिना प्राप्त के रूप में लॉग करता है। व्यापक रणनीतियाँ दस्तावेज़ सामान्यीकरण प्रत्येक परत पर लागू होती हैं और ऑडिटिंग के लिए कच्चे डेटा को संरक्षित किया जाता है। URL एनकोडर और डिकोडर वेरिएंट का निरीक्षण करने में मदद करता है।
इसमें क्या शामिल नहीं है - SEO के लिए ट्रैकिंग-पैरामीटर स्ट्रिपिंग नीतियां और कैनोनिकल टैग
टेकअवे: गिनने से पहले सामान्यीकृत करें - URL एनकोडर और डिकोडर किसी भी प्रकार का निरीक्षण करने में मदद करता है जो दिखाता है कि यह क्या एन्कोड करता है और क्या यह कैनोनिकल रूपों से मेल खाता है। संदिग्ध विश्लेषणात्मक वेरिएंट के लिए, डिकोड किए गए आउटपुट की जांच करने वाले डिकोडर में पेस्ट करें। यदि दो URL समान रूपों में डिकोड होते हैं, तो वे समान पेजों का प्रतिनिधित्व करते हैं और उन्हें समेकित किया जाना चाहिए। टूल सटीक रूप से दिखाता है कि कौन से अक्षर एनकोड करते हैं, उनके हेक्स मान और परिणाम। यह निरीक्षण पहला समस्या निवारण कदम है.
एनालिटिक्स विसंगतियों का निवारण करते समय, सभी देखे गए URL वेरिएंट की सूची बनाएं और प्रत्येक को URL एनकोडर और डिकोडर के साथ डीकोड करें। डिकोड किए गए प्रपत्रों की तुलना करें. यदि प्रपत्र डेटा सामग्री में भिन्न हैं (जैसे विभिन्न utm_source मान), तो वे वैध रूप से भिन्न पेज हैं। यदि वे केवल एन्कोडिंग में भिन्न हैं (जैसे %65मेल बनाम ईमेल), तो वे डुप्लिकेट हैं जिन्हें सामान्यीकरण की आवश्यकता है। विहित प्रपत्रों का दस्तावेज़ीकरण करें और सामान्यीकरण लागू करें। URL एनकोडर और डिकोडर निदान प्रदान करता है; एनालिटिक्स पाइपलाइन समाधान प्रदान करती है।
टेकअवे: गिनने से पहले सामान्य करें - कैसे URL एनकोडर और डिकोडर आपको किसी भी प्रकार का निरीक्षण करने में मदद करता है यह देखने के लिए कि यह वास्तव में क्या एन्कोड करता है
टेकअवे: गिनने से पहले सामान्यीकृत करें - URL एनकोडर और डिकोडर किसी भी प्रकार का निरीक्षण करने में मदद करता है जो दिखाता है कि यह क्या एन्कोड करता है और क्या यह कैनोनिकल रूपों से मेल खाता है। संदिग्ध विश्लेषणात्मक वेरिएंट के लिए, डिकोड किए गए आउटपुट की जांच करने वाले डिकोडर में पेस्ट करें। यदि दो URL समान रूपों में डिकोड होते हैं, तो वे समान पेजों का प्रतिनिधित्व करते हैं और उन्हें समेकित किया जाना चाहिए। टूल सटीक रूप से दिखाता है कि कौन से अक्षर एनकोड करते हैं, उनके हेक्स मान और परिणाम।
एनालिटिक्स विसंगतियों का निवारण करते समय, सभी देखे गए URL वेरिएंट की सूची बनाएं और प्रत्येक को URL एनकोडर और डिकोडर के साथ डीकोड करें। डिकोड किए गए प्रपत्रों की तुलना करें. यदि प्रपत्र डेटा सामग्री में भिन्न हैं (जैसे विभिन्न utm_source मान), तो वे वैध रूप से भिन्न पेज हैं। यदि वे केवल एन्कोडिंग में भिन्न हैं (जैसे %65मेल बनाम ईमेल), तो वे डुप्लिकेट हैं जिन्हें सामान्यीकरण की आवश्यकता है। विहित प्रपत्रों का दस्तावेज़ीकरण करें और सामान्यीकरण लागू करें।