CookiePass और Google Consent Mode: सहमति बैनर आपके ट्रैफ़िक के साथ क्या करता है

Consent Mode आपके टैग के लिए कोई ऑन/ऑफ़ स्विच नहीं है। इसके लागू रहते Google टैग हर पेज पर फ़ायर होता रहता है; बदलता है हर हिट पर लगा एक फ़्लैग, और उस फ़्लैग की वजह से Google उस हिट के साथ जो करता है। जब analytics_storage denied होता है, तो टैग कोई कुकी सेट नहीं करता, पेजों के बीच कोई क्लाइंट ID नहीं रखता, और वह भेजता है जिसे Google कुकी-रहित पिंग कहता है — एक ऐसा हिट जिसका इस्तेमाल GA4 मॉडलिंग के लिए करता है, न कि उन रिपोर्ट के लिए जो आप पढ़ते हैं।

यह फ़्लैग gcs नाम का एक क्वेरी पैरामीटर है। इसमें दो अक्षर और दो अंक होते हैं: पहला अंक ad_storage है, दूसरा analytics_storage — granted के लिए 1 और denied के लिए 0।

gcs=G100   ad_storage denied,  analytics_storage denied
gcs=G101   ad_storage denied,  analytics_storage granted
gcs=G110   ad_storage granted, analytics_storage denied
gcs=G111   both granted
(no gcs)   no Consent Mode on the page — treated as granted

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

Consent Mode v2 को एक क्रम चाहिए, कोई एक सेटिंग नहीं। डिफ़ॉल्ट स्थिति Google टैग लोड होने से पहले घोषित करनी होती है — जिसने अभी तक चुनाव नहीं किया, उसके लिए denied — और विज़िटर के फ़ैसला करते ही एक अपडेट आना चाहिए, जिसे फिर हर अगली विज़िट पर दोबारा लागू किया जाए। क्रम गड़बड़ हुआ, तो हर सेशन का पहला पेज व्यू बैनर दिखने से पहले ही सहमति-प्राप्त के तौर पर चला जाता है।

CookiePass अपनी ही स्क्रिप्ट से यही क्रम बनाता है, इसलिए इसका कुछ भी आपके Tag Manager कंटेनर में नहीं आता:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// …the visitor accepts…
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

पूरा इंटीग्रेशन बस इतना ही है। Google के अपने टैग सहमति की स्थिति का अपने-आप पालन करते हैं, और इनमें वे टैग भी शामिल हैं जो SignalHost आपके वेब कंटेनर में पब्लिश करता है। आपके सर्वर कंटेनर में किसी भी चीज़ पर सहमति शर्त की ज़रूरत नहीं है — हाथ से शर्त जोड़ना ही वह तरीका है जिससे रोक वाले Google टैग के बगल में बिना रोक वाले इवेंट टैग रह जाते हैं, जो डेटा सीधे Google को भेजते हैं।

हर हिट अब भी उसी रास्ते से जाता है: ब्राउज़र उसे आपके अपने होस्टनेम पर पोस्ट करता है, एज उसे आपके सर्वर कंटेनर तक भेजता है, और कंटेनर उसे GA4 को आगे भेजता है। सारा फ़र्क़ पेलोड में है।

• चुनाव से पहले: हर हिट पर gcs=G100, कोई _ga कुकी नहीं, और हर पेज पर एक नया क्लाइंट ID। GA4 को एक कुकी-रहित पिंग मिलता है; आपका कंटेनर एक रिक्वेस्ट गिनता है।
• स्वीकार करने के बाद: gcs=G111, कुकी सेट होती हैं, और सेशन आपस में जुड़ जाता है। यहाँ से जो हिट आते हैं, उन्हीं से आपकी रिपोर्ट बनती हैं।
• अस्वीकार करने के बाद: जब तक वह चुनाव बना रहता है, हर पेज पर gcs=G100। Enhanced measurement इवेंट — scroll, file_download और बाकी — भी page_view वाले नियम पर ही चलते हैं।

इसीलिए बैनर लगने के बाद कंटेनर पेज हर इवेंट के लिए दो संख्याएँ दिखाता है: हरे रंग में, analytics सहमति के साथ भेजे गए हिट — जिन्हें Analytics यूज़र और सेशन के रूप में रिपोर्ट करेगा — और उसके बगल में ग्रे रंग में, प्लस के निशान के साथ, वे कुकी-रहित पिंग जिन्हें Analytics अपनी रिपोर्ट से बाहर रखता है। हर इवेंट का बार भी इसी तरह बँटा होता है। session_start और first_visit इनमें से किसी में भी कभी नहीं दिखते; Analytics इन्हें इवेंट के रूप में पाने के बजाय पहले page_view पर लगे फ़्लैग से ख़ुद निकालता है।

उम्मीद रखें कि दोनों कॉलम मेल नहीं खाएँगे, और यह भी कि उनके बीच का अंतर पेज की सबसे काम की संख्या होगी।

• आपका कंटेनर जितनी रिक्वेस्ट गिनता है, Analytics उससे कम यूज़र और सेशन रिपोर्ट करता है। यह अंतर उन विज़िटर का हिस्सा है जिन्होंने मना किया या कभी जवाब नहीं दिया — यानी आपकी सहमति दर, अंदाज़े से नहीं, नापकर।
• प्रॉपर्टी के Google के थ्रेशोल्ड पूरे करने के बाद, GA4 बिहेवियरल मॉडलिंग से इस अंतर का कुछ हिस्सा भर सकता है। मॉडल किया गया डेटा रिपोर्ट में दिखता है; वह आपके कंटेनर में कभी नहीं दिखता, क्योंकि वह कभी भेजा ही नहीं जाता।
• ad_storage denied होने पर, Google Ads कन्वर्ज़न ट्रैकिंग के पास श्रेय देने के लिए कुछ नहीं होता, और conversion linker के पास जोड़ने के लिए कुछ नहीं होता। सर्वर कंटेनर इसे नहीं बदलता, और उसे बदलना भी नहीं चाहिए: फ़र्स्ट-पार्टी का मतलब सहमति से छूट नहीं है।
• बैनर का डिज़ाइन अब मेज़रमेंट का फ़ैसला है। 60% और 85% की सहमति दर एक ही साइट की हो सकती है, बस बटन अलग हों — और दोनों कॉलम के बीच का अंतर ही वह जगह है जहाँ आप देखेंगे कि आपकी कौन-सी है।

• सहमति स्क्रिप्ट को Google टैग से पहले लोड करें। पहले हिट से पहले डिफ़ॉल्ट स्थिति मौजूद होनी चाहिए।
• बैनर का जवाब दिए बिना एक पेज खोलें और अपने ब्राउज़र के नेटवर्क पैनल में किसी /g/collect रिक्वेस्ट पर gcs पढ़ें। उसमें G100 होना चाहिए।
• स्वीकार करें, और अगले पेज पर इसे फिर से पढ़ें। उसमें G111 होना चाहिए।
• सर्वर कंटेनर में किसी भी चीज़ पर सहमति ट्रिगर न जोड़ें। वेब टैग पहले से ही यह स्थिति साथ लेकर चलता है।
• एक दिन बाद कंटेनर पेज पर लौटें और page_view की दोनों संख्याएँ पढ़ें। हरी संख्या को दोनों के जोड़ से भाग दें — यही आपकी सहमति दर है।

हमने CookiePass इसलिए चुना क्योंकि यह ठीक ऊपर वाला क्रम ही चलाता है, एक दोपहर में इस साइट पर लाइव हो गया, और बैनर को साइट के अपने रंग अपनाने देता है। पिछले सेक्शन की संख्याओं से ही हमें पता है कि यह काम करता है।