Consent Mode v2 और जून 2026 में Google Signals का अंत
15 जून 2026 को ad_storage, Google के स्टैक में विज्ञापन डेटा पर एकमात्र नियंत्रण बन जाता है। यहाँ बताया गया है कि Google Signals का अंत डेवलपर्स के लिए क्या बदलता है — और यह पूरी मशीनरी ऐसी चीज़ क्यों है जिसे cookie-रहित analytics को कभी बनाना ही नहीं पड़ा।
15 जून 2026 को Google विज्ञापन डेटा पर एक स्वतंत्र नियंत्रण के रूप में Google Signals को हटा देता है। इस तारीख के बाद, आपका Consent Management Platform (CMP) जो ad_storage सहमति संकेत भेजता है, वही एकमात्र गेट बन जाता है जो तय करता है कि visitor-स्तर का डेटा Google Ads तक पहुँचेगा या नहीं। यदि आपका CMP गलत तरीके से कॉन्फ़िगर है, तो उस गलती को पकड़ने के लिए Analytics में अब कोई server-side सेटिंग नहीं बची।
यह एक शांत किन्तु महत्वपूर्ण बदलाव है। यह सहमति की शुद्धता का पूरा बोझ एक JavaScript परत पर डाल देता है जो किसी भी डेटा के संग्रह से पहले visitor के browser में चलती है। यह ठीक-ठीक समझना सार्थक है कि यह परत क्या करती है, क्योंकि यही वह जटिलता है जो cookie-रहित डिज़ाइन कभी वहन नहीं करता।
Consent Mode v2 वास्तव में क्या है
Consent Mode v2, Google का वह framework है जो उसके tags को बताता है कि उन्हें storage का उपयोग करने की अनुमति है या नहीं। यह कोई सहमति बैनर नहीं है — यह आपके बैनर और Google के tags के बीच की वायरिंग है। आपका CMP चार संकेत सेट करता है:
gtag('consent', 'default', {
ad_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
});
ad_storageविज्ञापन cookies, device पहचानकर्ताओं, और Google Ads को भेजे जाने वाले visitor-स्तर के डेटा को नियंत्रित करता है।analytics_storageउस Analytics cookie को नियंत्रित करता है जो एक client ID निर्दिष्ट करता है।ad_user_data, Enhanced Conversions के लिए email जैसे first-party डेटा की hashing की अनुमति देता है।ad_personalizationतय करता है कि Analytics डेटा personalized विज्ञापन targeting को भरता है या नहीं।
जब visitor स्वीकार करता है, तो आपका CMP एक दूसरा कॉल फायर करता है जो संबंधित संकेतों को granted में अपडेट कर देता है। आगे की हर चीज़ इस बात पर निर्भर करती है कि वह अपडेट सही ढंग से पहुँचता है या नहीं।
basic बनाम advanced, और advanced क्यों मौजूद है
दो कार्यान्वयन mode हैं, और इनका अंतर कानूनी रूप से मायने रखता है।
basic mode में, जब तक सहमति न दी जाए तब तक Google के tags बिल्कुल लोड नहीं होते। मना कर दिया, तो कुछ भी नहीं भेजा जाता।
advanced mode में, tags तुरंत लोड हो जाते हैं, सभी संकेत डिफ़ॉल्ट रूप से denied पर, और फिर भी वे Google को cookieless pings भेजते हैं — ऐसा अनुरोध जिसमें कोई पहचानकर्ता, कोई client ID, और कोई संग्रहीत स्थिति नहीं होती। Google इन pings की मात्रा का, साथ ही उस अल्पसंख्यक के व्यवहार का जो सहमति देता है, उपयोग करके उन conversions को मॉडल करता है जिन्हें वह सीधे नहीं देख सकता।
advanced mode इसलिए मौजूद है क्योंकि सहमति की दरें कम हैं और विज्ञापनदाता अपने आँकड़े वापस चाहते हैं। लेकिन सहमति से पहले भेजा गया cookieless ping भी किसी तीसरे पक्ष को डेटा का संचरण ही है, और ePrivacy के Article 5(3) की EDPB द्वारा तकनीकी रूप से तटस्थ व्याख्या केवल इसलिए अनुरोधों को छूट नहीं देती कि वे cookie को छोड़ देते हैं। मॉडल की गई conversions को कुछ भी विश्वसनीय उत्पन्न करने के लिए सहमति-प्राप्त sessions का एक न्यूनतम पूल भी चाहिए, इसलिए छोटी साइटों को शोर मिलता है।
15 जून का अंत क्या हटाता है
अब तक Google Signals एक दूसरे गेट के रूप में काम करता था। Consent Mode चाहे जो रिपोर्ट करे, आप विज्ञापन डेटा साझाकरण को सीमित करने के लिए इसे Analytics में बंद रख सकते थे। वह सुरक्षा-कवच चला गया।
बंद होने के बाद:
- Google Ads, Analytics-side सेटिंग्स पढ़ना बंद कर देता है और विशेष रूप से उन Consent Mode संकेतों पर निर्भर करता है जो आपका CMP भेजता है।
- Google Signals केवल Analytics-उपयोग तक सीमित कर दिया जाता है — GA4 के भीतर sessions को logged-in उपयोगकर्ताओं से जोड़ना।
- IP पते एकत्र होते रहते हैं और लिंक किए गए Ads खातों को अग्रेषित करने से पहले एन्क्रिप्ट किए जाते हैं, जहाँ गंतव्य खाते की सेटिंग्स नियंत्रण ले लेती हैं।
व्यावहारिक प्रभाव: एक अकेला असफल gtag('consent', 'update', ...) कॉल — एक race condition, एक ऐसा CMP जो पहले tag के बाद लोड होता है, एक ऐसा deploy जो डिफ़ॉल्ट स्थिति गिरा देता है — अब चुपचाप वह डेटा भेज देता है जिसे आप रोकना चाहते थे। GDPR के तहत यह बिना वैध आधार की processing है, और server-side सुरक्षा-जाल का हटना इस तर्क को कठिन बना देता है कि उजागर होना सीमित था।
हालिया मार्गदर्शन के अनुसार यह भी विज्ञापन डेटा साझा करने के तरीके में एक भौतिक (material) परिवर्तन है। EU विज़िटर वाली साइटों के लिए, यह उपयोगकर्ताओं को सूचित करने का दायित्व उत्पन्न कर सकता है — एक समीक्षा जो समय-सीमा के बाद नहीं, बल्कि पहले करने योग्य है।
वह जटिलता जिसे कभी अस्तित्व में होना ही नहीं चाहिए था
एक कदम पीछे हटकर देखें कि एक अनुपालक Consent Mode v2 सेटअप क्या-क्या माँगता है: एक CMP, चार सहमति संकेत, डिफ़ॉल्ट स्थितियाँ, tag लोड के सापेक्ष सही ढंग से क्रमित update कॉल, कानूनी परिणामों वाला advanced बनाम basic का निर्णय, मॉडल की गई conversions जो केवल एक traffic सीमा के ऊपर ही काम करती हैं, और अब बिना किसी सुरक्षा-जाल के एक एकल विफलता-बिंदु।
यह सारी मशीनरी पहचानकर्ताओं — client ID, विज्ञापन cookie, hashed email — का उपयोग जारी रखने के लिए मौजूद है, साथ ही सहमति कानून के सही पक्ष पर बने रहने के लिए। पहचानकर्ता हटा दें और पूरा तंत्र शून्य में ढह जाता है।
cookie-रहित tracker के पास रोकने के लिए कोई ad_storage नहीं है क्योंकि यह कोई विज्ञापन storage सेट ही नहीं करता। इसके पास मना करने के लिए कोई client ID नहीं है क्योंकि पहचान एक एकतरफा hash SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) है जो edge पर memory में गणना किया जाता है और कभी उलटा नहीं किया जाता। कच्चे IP और User-Agent का उपयोग केवल उस hash की गणना के लिए होता है; D1 इनपुट नहीं, hash संग्रहीत करता है। ऐसा कोई सहमति संकेत नहीं है जो विफल हो सके क्योंकि Article 5(3) के तहत सहमति देने के लिए कुछ है ही नहीं — visitor के device तक पहुँच पृष्ठ देने के लिए कठोरता से आवश्यक है, और /collect को भेजने वाला 2 KB से कम का script किसी भी storage को नहीं पढ़ता।
15 जून का बंद होना "क्या मेरा Consent Mode सही ढंग से कॉन्फ़िगर है" से अधिक तीखा प्रश्न पूछने का अच्छा अवसर है। पूछिए कि आप pageviews मापने के लिए पहले स्थान पर एक सहमति state machine क्यों चला रहे हैं। Google जिन conversions को cookieless pings से मॉडल करता है, वे उस डेटा का अनुमान हैं जिसे एकत्र करने की आपको कभी अनुमति ही नहीं थी। बिना किसी पहचानकर्ता के, जो वास्तव में हुआ उसे गिनना — हमेशा से सरल प्रणाली रही है।
Comments
Loading comments…