[GA4] असाइन नहीं किया गया, (not set), और डायरेक्ट ट्रैफ़िक वाली समस्याओं से बचने के लिए, टैग करने से जुड़े सबसे सही तरीके

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

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

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

टैग कोड को क्रम से लगाने के सबसे सही तरीके

टैग कोड को क्रम से लगाने के लिए, ये सबसे सही तरीके अपनाएं:

टैग प्रकार	निर्देश	सबसे सही तरीके
Google टैग	Google प्रॉडक्ट कॉन्फ़िगर करना और इवेंट डेटा भेजना	ऑडियंस से ट्रिगर होने वाले इवेंट के साथ-साथ, किसी इवेंट के तरीके को कॉल करने से पहले Google टैग को शुरू करें.
Google Tag Manager	Google Tag Manager को सेट अप करें वेब पेजों के लिए Google Tag Manager Google टैग प्रबंधक का परिचय	GTM सेट अप करने के चार चरणों को पूरा करें
सर्वर साइड टैगिंग	सर्वर साइड - Tag Manager	इन टैग सेटिंग को स्किप न करें. आपको किसी GA4 प्रॉपर्टी के लिए, एक ही पेज पर सर्वर-साइड और स्टैंडअलोन क्लाइंट-साइड, दोनों को लागू नहीं करना चाहिए. अगर sGTM का इस्तेमाल किया जा रहा है, तो पक्का करें कि आपके सभी चालू टैग को सर्वर-साइड कंटेनर के ज़रिए इवेंट भेजने के लिए सेट अप किया गया हो.

अगर इवेंट के लिए, क्रम से लगाने के सुझाए गए तरीके का पालन नहीं किया जा सकता, तो भी आपको यहां दिए गए दो सुझावों का पालन करना चाहिए. ऐसा न करने पर, आपको रिपोर्टिंग में समस्याएं आ सकती हैं.

• पेज पर जितनी जल्दी हो सके और किसी इवेंट से पहले, config कमांड (Google टैग के लिए) या Google टैग की सेटिंग (Google Tag Manager के लिए) के हिस्से के तौर पर, पेज के लिए सभी ज़रूरी कॉन्फ़िगरेशन दें.
• कस्टम इवेंट, config कमांड से पहले ट्रिगर नहीं होने चाहिए. अगर ऐसा होता है, तो उन इवेंट को session_start इवेंट के साथ बैच करके भेजा जाएगा. config कमांड, पेज के बाकी हिस्से के लिए उपयोगकर्ता और सेशन की पहचान पर असर डाल सकता है. इसका मतलब है कि पेज व्यू और बाद के में होने वाले इवेंट, पहले शुरू होने वाले सेशन और कस्टम इवेंट से नहीं जोड़े जा सकते.

अगर मेरे इवेंट सही क्रम में नहीं हैं, तो क्या होगा?

जब GA4 टैग अनचाहे समय पर सेट किए जाते हैं, तो इसका असर यूज़र आईडी, सेशन आईडी या दोनों पर पड़ सकता है. उदाहरण के लिए, जब पेज पर दूसरे इवेंट के बाद config कमांड या Google टैग ट्रिगर होता है. इसकी वजह से ऐसा हो सकता है:

• Analytics में (not set) के तौर पर दिखने वाला डेटा
• उपयोगकर्ता और सेशन की गलत संख्या
• उपयोगकर्ता और सेशन लेवल की मेट्रिक का गलत हिसाब लगाया जा रहा है
• उपयोगकर्ता और सेशन का गलत मेज़रमेंट

इवेंट के क्रम में गड़बड़ी कैसे हो सकती है?

अनचाहे समय पर टैग ट्रिगर होने की कुछ सामान्य वजहें ये हैं:

सुविधा	वजह	नतीजा	सबसे सही तरीके
सर्वर साइड टैगिंग सर्वर से मैनेज की जाने वाली सेटिंग (सर्वर से मैनेज किया जाने वाला क्लाइंट आईडी) क्लाइंट की ओर से मैनेज की जाने वाली सेटिंग (transport_url, first_party_collection, server_container_url)	"सर्वर की ओर से मैनेज की गई सेटिंग" के लिए, सर्वर-साइड टैगिंग बॉक्स को चुनना. यह डिफ़ॉल्ट रूप से चालू होता है. जब GA4 इवेंट को सर्वर टैग के ज़रिए प्रोसेस किया जाता है, तो उपयोगकर्ताओं के पास वेब टैग के क्लाइंट आईडी के बजाय, किसी दूसरी उपयोगकर्ता पहचान का इस्तेमाल करने के कई विकल्प होते हैं.	सबसे ऊपर मौजूद ड्रॉप-डाउन में "कुकी को सर्वर से मैनेज करने वाली सेटिंग" सेट करने का मतलब है कि सर्वर साइड टैगिंग, एक अलग क्लाइंट आईडी मैनेज करेगी और उसे प्रोसेस किए जाने वाले मेज़रमेंट के लिए इस्तेमाल करेगी. यह कुकी लिखने के कई विकल्प भी चालू करता है. साथ ही, उन ग्राहकों के लिए समय के साथ माइग्रेशन का विकल्प भी उपलब्ध कराता है जिनके पास मौजूदा GA डायरेक्ट ट्रैफ़िक है और वे एक ही समय पर अपने सभी विज़िटर के आईडी बदलकर, ऑडियंस और रिपोर्ट में अचानक रुकावट नहीं चाहते.	इस विकल्प का इस्तेमाल करने पर, आपको यह पक्का करना होगा कि आपकी स्ट्रीम के सभी मेज़रमेंट, आपके सर्वर टैग से फ़्लो हों और कोई भी मेज़रमेंट सीधे Google के सर्वर पर न भेजा जाए. ऐसा करने का सबसे आसान तरीका यह पक्का करना है कि आपके सर्वर कंटेनर में डेटा भेजने वाले वेब टैग के लिए, Google Tag Manager या config कमांड (Google टैग) हमेशा उस कंटेनर के लिए पहला टैग या कमांड हो.
कुकी के नाम को पसंद के मुताबिक बनाना (cookie_prefix)	इससे क्लाइंट आईडी और सेशन स्टेटस, दोनों के लिए इस्तेमाल की जाने वाली पहले पक्ष की कुकी का नाम बदल जाता है.	उपयोगकर्ताओं को अलग-अलग सेशन में नहीं जोड़ा जा सकता. साथ ही, सेशन में इवेंट शामिल नहीं किए जा सकते. सेशन या उपयोगकर्ता डाइमेंशन के साथ विश्लेषण करने पर, इवेंट मेट्रिक (not set) के तौर पर दिखती हैं.	अपनी अलग-अलग साइट पर एक कुकी प्रीफ़िक्स का इस्तेमाल करें. Analytics में कुकी प्रीफ़िक्स का इस्तेमाल, कुकी का नाम पसंद के मुताबिक बनाने के लिए किया जाता है, न कि कुकी के कई साइलो बनाने के लिए. अलग-अलग प्रीफ़िक्स का इस्तेमाल करने पर ऐसा होता है.
अलग-अलग डोमेन को अपने-आप लिंक करने वाला टूल (linker)1	यह सेटिंग, टैग को पिछले पेज के क्लाइंट और सेशन के डेटा को प्रोसेस करने और इस्तेमाल करने के लिए कहती है. हालांकि, ऐसा तब होता है, जब वह डेटा उपलब्ध हो. लिंक किए गए डेटा को अपनाते समय, टैग यह मान लेता है कि सेशन पहले पेज पर ही शुरू हो चुका था.	अगर लिंक करने वाला टूल को देर से शुरू किया जाता है और बाद में चलने वाली config कमांड की मदद से, अलग-अलग डोमेन के जोड़े गए उपयोगकर्ता के बारे में पता चलता है, तो उस समय उपयोगकर्ता की पहचान अचानक बदल जाएगी. बाद में चलने वाले config कमांड की वजह से, कम से कम छोटे सेशन बनते हैं. इन्हें लिंकर पैरामीटर की वैल्यू लागू होने पर, खारिज कर दिया जाता है. उस समय भेजे गए किसी भी सेशन या उपयोगकर्ता एट्रिब्यूट को अब असली सेशन या उपयोगकर्ता से नहीं जोड़ा जा सकता.	क्लाइंट या सेशन आईडी को पसंद के मुताबिक न बनाएं. ऐसा करने से, टैग और प्रोसेसिंग, दोनों में सेशन को स्ट्रक्चर करने के तरीके के बारे में गलत अनुमान लगाए जाते हैं. साथ ही, इससे समस्याएं भी हो सकती हैं.
मैन्युअल क्रॉस-डोमेन लिंकर (client_id, session_id)	ग्राहकों को क्रॉस-डोमेन मेज़रमेंट को मैन्युअल तरीके से लागू करने की अनुमति देने के लिए, GA4 टैग में क्लाइंट और सेशन आईडी, दोनों को पाने और सेट करने के लिए एपीआई हैं. client_id और session_id की अपने-आप जनरेट हुई वैल्यू में गलती से बदलाव करने पर, GA4 इवेंट को उपयोगकर्ताओं और सेशन से जोड़ने के तरीके पर असर पड़ता है.	जिन इवेंट को उनके ओरिजनल क्लाइंट और सेशन आईडी से अलग किया गया है उनमें ज़रूरी जानकारी मौजूद नहीं हो सकती. साथ ही, इनसे एट्रिब्यूशन से जुड़ी अनचाही समस्याएं भी हो सकती हैं.	उपयोगकर्ता की कस्टम आइडेंटिटी देने के लिए, user_id का इस्तेमाल करें. कस्टम क्लाइंट या सेशन आईडी में बदलाव करने या उन्हें उपलब्ध कराने के लिए, इन एपीआई का इस्तेमाल न करें. इन आईडी को मैन्युअल तरीके से सिर्फ़ तब सेट किया जाना चाहिए, जब क्रॉस-डोमेन मैन्युअल सेटअप ज़रूरी हो.

 

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