सर्वर-साइड टैगिंग के आगे कुकी बैनर: क्या बदलता है, और क्या नहीं

फ़र्स्ट-पार्टी होस्टनेम किसी रिक्वेस्ट की एक तकनीकी खूबी है। यह अनुमति नहीं है। अगर कल आपको analytics कुकी सेट करने के लिए सहमति चाहिए थी, तो आज भी चाहिए — और यह बात कि कुकी अब google-analytics.com की जगह metrics.yoursite.com से सेट होती है, इसमें कोई मायने नहीं रखती। रेगुलेटर का सवाल यह है कि आप क्या जुटाते हैं और क्यों, यह नहीं कि पैकेट रास्ते में किस सर्वर से होकर गया।

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

GA4 आपके स्टोर से कम कन्वर्ज़न क्यों दिखाता है, इसकी चार वजहों में से पहली वजह भी सहमति ही है: GA4 कम क्यों गिनता है, और कौन-से हिस्से वापस पाए जा सकते हैं।

Google के टैग सहमति की एक स्थिति पढ़ते हैं, जिसमें कुछ नामित अनुमतियाँ होती हैं — analytics_storage, ad_storage, ad_user_data, ad_personalization — और उसी के हिसाब से तय करते हैं कि क्या भेजना है। विज़िटर के फ़ैसला करने से पहले, कंसेंट मैनेजर denied का डिफ़ॉल्ट push करता है; जब वे चुनाव करते हैं, तो वह एक अपडेट push करता है। denied स्थिति में भी Google टैग फ़ायर होता है, लेकिन वह एक कुकी-रहित पिंग भेजता है: न क्लाइंट ID, न कुकी — बस यह संकेत कि एक पेज देखा गया, इससे ज़्यादा कुछ नहीं। analytics_storage granted होते ही वह पूरा हिट भेजता है। सर्वर कंटेनर को वही मिलता है जो भेजा गया, और सहमति के संकेत हिट के साथ ही चलते हैं, इसलिए सर्वर-साइड GA4 टैग भी वैसा ही बर्ताव करता है।

कंसेंट मैनेजर को Google टैग से पहले लोड होना चाहिए, ताकि जब टैग पहली बार जाँच करे, तब तक उसका डिफ़ॉल्ट लागू हो चुका हो। ज़्यादातर कंसेंट मैनेजर ठीक इसी के लिए wait_for_update वैल्यू देते हैं — कुछ सौ मिलीसेकंड, जितनी देर टैग denied मान लेने से पहले सहमति की स्थिति का इंतज़ार करता है।

SignalHost आपके वेब कंटेनर में जो एंटिटी बनाता है, उन पर कोई सहमति शर्त नहीं होती। यह जानबूझकर किया गया है। Google के अपने टैग Consent Mode का पालन करते हैं; Google टैग पर हाथ से जोड़ी गई सहमति जाँच, जबकि उसके नीचे के GA4 इवेंट टैग पर कोई जाँच न हो — यही नीचे बताई गई दो गलतियों में से पहली है।

Google टैग ही मेज़रमेंट को सर्वर कंटेनर के रास्ते भेजता है। GA4 इवेंट टैग — मान लीजिए purchase टैग — अपने-आप भी डेटा भेज सकता है। अगर Google टैग सहमति का इंतज़ार करता है और इवेंट टैग नहीं करते, तो इवेंट टैग सहमति से पहले फ़ायर होकर सीधे Google को डेटा भेज देते हैं, और वह भी ऐसे पेज से जिसका बैनर अभी खुला है। कंटेनर पेज पर कोई गड़बड़ी नहीं दिखती, क्योंकि ये हिट कंटेनर से होकर गुज़रे ही नहीं।

या तो हाथ से किसी भी टैग पर रोक न लगाएँ और यह काम Consent Mode को करने दें, या फिर हर उस टैग पर रोक लगाएँ जो डेटा भेज सकता है। इनके बीच का कोई सुसंगत रास्ता नहीं है।

कुछ कंसेंट मैनेजर सहमति मिलने तक स्क्रिप्ट को ब्लॉक करके काम करते हैं — वे URL देखकर script टैग को बीच में पकड़ लेते हैं और रोके रखते हैं। उनकी लिस्ट googletagmanager.com को जानती है। वे exxz2gdaz1jz.yoursite.com को नहीं जानतीं, क्योंकि किसी की भी लिस्ट इसे नहीं जान सकती: लोडर का होस्टनेम और फ़ाइलनेम आपके कंटेनर के लिए यूनिक होते हैं। इसलिए ब्लॉकिंग मोड में लोडर को बिना किसी शर्त के आगे जाने दिया जा सकता है, और अगर आप Consent Mode के बजाय ब्लॉकिंग पर निर्भर हैं, तो इसका मतलब है सहमति से पहले एक टैग का फ़ायर होना।

इससे निपटने के दो रास्ते हैं। लोडर का URL हाथ से कंसेंट मैनेजर के ब्लॉक नियमों में जोड़ें, उसी कैटेगरी में जिसमें आपका analytics आता है। या — जो बेहतर है, क्योंकि यह कुकी-रहित पिंग को भी सही तरीके से संभालता है — Google के टैग के लिए Consent Mode पर भरोसा करें और ब्लॉकिंग का इस्तेमाल सिर्फ़ उन स्क्रिप्ट के लिए करें जो इसे सपोर्ट नहीं करतीं। हमारी अपनी साइट पर एक कंसेंट मैनेजर ऑटो-ब्लॉकिंग मोड में चलता है और साथ में Consent Mode भी; Google टैग कंसेंट मैनेजर की स्क्रिप्ट के बाद रखा गया है, और अगर कोई इनका क्रम बदल दे, तो रिपॉज़िटरी का एक टेस्ट फ़ेल हो जाता है।

सहमति की स्थिति हर हिट के अंदर सर्वर कंटेनर तक पहुँचती है, और सर्वर-साइड GA4 टैग उसे ठीक वैसे ही पढ़ता है जैसे ब्राउज़र-साइड टैग पढ़ता। हमारी तरफ़ की कोई भी चीज़ न सहमति देती है, न उसे बढ़ाती है; कुकी-रहित पिंग कुकी-रहित पिंग ही रहता है।

अगर आप कोई विज्ञापन प्लेटफ़ॉर्म जोड़ते हैं — Meta, TikTok, Reddit, Pinterest, Snapchat या LinkedIn — तो उसे भी यही हिट मिलते हैं, लेकिन सिर्फ़ उन विज़िटर से जिन्होंने ad_storage की अनुमति दी है। सर्वर हर हिट के साथ आई सहमति की स्थिति पढ़ता है, और जिसने भी विज्ञापन से इनकार किया है या अभी तक जवाब नहीं दिया है, उसके लिए इन प्लेटफ़ॉर्म को कुछ नहीं जाता: न इवेंट, न कुकी। Google Ads कन्वर्ज़न Consent Mode का पालन वैसे ही करते हैं जैसे Google के अपने टैग — एक कुकी-रहित सिग्नल के रूप में, जो कभी किसी क्लिक से नहीं जोड़ा जाता — और रीमार्केटिंग सहमति का इंतज़ार करती है। यह सब इस पर निर्भर है कि बैनर Consent Mode सेट करे: जिस पेज पर यह नहीं होता, वह कोई सहमति स्थिति नहीं भेजता, और हर हिट granted माना जाता है। इसे वैसे ही जाँचें जैसे आप यहाँ बाकी सब कुछ जाँचते: बैनर का जवाब दिए बिना साइट खोलें, नेटवर्क टैब देखें, और देखें कि क्या बाहर जाता है।

“ज़्यादा कन्वर्ज़न मैच करें” चालू करने पर Google टैग वह ईमेल पता उठा लेता है जो विज़िटर किसी फ़ॉर्म में टाइप करता है, ताकि विज्ञापन प्लेटफ़ॉर्म किसी कन्वर्ज़न को उस व्यक्ति से मैच कर सकें। विज़िटर ने चाहे जो चुना हो, ब्राउज़र इसे भेजता है। SignalHost हर उस हिट से, जिसकी विज्ञापन सहमति अस्वीकार की गई थी, इसे एज पर ही हटा देता है — हिट के आगे जाने से पहले — और प्लेटफ़ॉर्म को यह हमेशा सिर्फ़ हैश किए हुए रूप में मिलता है।

• पेज में कंसेंट मैनेजर की स्क्रिप्ट Google टैग से ऊपर है।
• टैग लोड होने से पहले denied की डिफ़ॉल्ट सहमति स्थिति push की जाती है, wait_for_update के साथ।
• कंटेनर के किसी भी टैग पर हाथ से जोड़ी गई सहमति शर्त नहीं है — या फिर डेटा भेज सकने वाले हर टैग पर है।
• बैनर का जवाब दिए बिना, नेटवर्क टैब में एक कुकी-रहित पिंग (रिक्वेस्ट में gcs=G100) दिखता है और कोई पूरा हिट नहीं।
• स्वीकार करने के बाद, उसी पेज पर पूरा हिट दिखता है और कंटेनर पेज उसे गिनता है।
• अगर कंसेंट मैनेजर URL के आधार पर ब्लॉक करता है, तो लोडर का URL उसके नियमों में है।