Chrome Privacy Sandbox और Topics API: सहमति, टारगेटिंग और माप के लिए 2026 का प्रकाशक गाइड

पिछले दशक के अधिकांश समय तक, डिजिटल विज्ञापन एक सरल धारणा पर चलता था: थर्ड-पार्टी कुकीज़ हमेशा वहाँ रहेंगी, वेब पर चुपचाप उपयोगकर्ता पहचानकर्ता ले जाती रहेंगी। वह धारणा अब टूट गई है। Chrome का deprecation पथ कई बार बदला है, लेकिन यात्रा की दिशा नहीं बदली: थर्ड-पार्टी कुकी के माध्यम से क्रॉस-साइट ट्रैकिंग समाप्त हो रही है, और Google का Privacy Sandbox वह प्रतिस्थापन है जिसे Chrome चाहता है कि प्रकाशक और विज्ञापनदाता अपनाएं। Sandbox एक एकल उत्पाद नहीं है। यह ब्राउज़र API का एक समूह है — Topics, Protected Audience, Attribution Reporting, Fenced Frames, Shared Storage, और अधिक — प्रत्येक उस विशिष्ट उपयोग के मामले को प्रतिस्थापित करते हुए जिसे कुकीज़ पहले कवर करती थीं। एक प्रकाशक के लिए, कठिन हिस्सा API को अलग-अलग समझना नहीं है। यह एक सहमति परत और मौद्रीकरण पथ बनाना है जो Privacy Sandbox प्रवाह, GDPR अनुपालन और राज्य की गोपनीयता कानून को एक साथ संरेखित रखे। यह गाइड 2026 में चलने वाले टुकड़ों और आपकी सहमति स्टैक को कैसा दिखना चाहिए, इसके बारे में बात करता है।

Privacy Sandbox वास्तव में क्या बदलता है

थर्ड-पार्टी कुकीज़ चार अलग-अलग विज्ञापन कार्य करती थीं: रुचि-आधारित लक्ष्यीकरण, रीटार्गेटिंग, रूपांतरण माप और आवृत्ति कैपिंग। Privacy Sandbox इन्हें अलग API में विभाजित करता है, प्रत्येक का अपना सहमति प्रोफ़ाइल है।

Topics API — रुचि-आधारित लक्ष्यीकरण

Topics API प्रत्येक ब्राउज़र को मोटे-दाने वाले रुचि विषयों का एक छोटा समूह असाइन करता है — प्रति सप्ताह लगभग पाँच विषय, कुछ सौ श्रेणियों की एक क्यूरेटेड टैक्सोनॉमी से। जब एक प्रकाशक document.browsingTopics() कॉल करता है, तो ब्राउज़र तीन तक विषय लौटाता है जिनका उपयोग ad tech ecosystem किसी भी क्रॉस-साइट पहचानकर्ता के बिना प्रासंगिक वैयक्तिकरण के लिए कर सकता है। विषयों की गणना स्थानीय रूप से की जाती है, डिवाइस पर संग्रहीत किए जाते हैं, साप्ताहिक रूप से बदलते हैं, और chrome://settings/adPrivacy में उपयोगकर्ता नियंत्रण के अधीन हैं।

Protected Audience API — रीटार्गेटिंग और रीमार्केटिंग

Protected Audience, पूर्व FLEDGE, साझा क्रॉस-साइट पहचानकर्ता के बिना रीटार्गेटिंग को जीवित रखता है। विज्ञापनदाता अपनी साइट पर एक उपयोगकर्ता को एक रुचि समूह में शामिल करते हैं; जब उपयोगकर्ता किसी भाग लेने वाले प्रकाशक पर जाता है, तो एक ऑन-डिवाइस नीलामी एक Fenced Frame में चलती है और एक क्रिएटिव चुनती है। जीतने वाला विज्ञापन प्रकाशक को यह जाने बिना प्रस्तुत किया जाता है कि कौन सा रुचि समूह मिलान हुआ।

Attribution Reporting API — रूपांतरण माप

Attribution Reporting माप उपयोग के मामलों के एक उपसमूह के लिए रूपांतरण पिक्सेल को बदलता है। यह इवेंट-स्तरीय रिपोर्ट (शोरगुल वाली, हानिपूर्ण, प्रति-रूपांतरण) और एग्रीगेट सारांश रिपोर्ट (सांख्यिकीय रूप से पूर्वाग्रह-मुक्त रोलअप) का समर्थन करता है। विरासत पिक्सेल के विपरीत, यह व्यक्तिगत उपयोगकर्ता-से-रूपांतरण लिंक को उजागर नहीं करता।

Shared Storage और Fenced Frames

Shared Storage एक राइट-एनीव्हेयर, रीड-इन-सैंडबॉक्स कुंजी-मूल्य स्टोर है जो आवृत्ति कैपिंग और A/B प्रयोग संगति जैसे क्रॉस-साइट उपयोग के मामलों के लिए है। Fenced Frames अलग-थलग iframes हैं जो आसपास के पृष्ठ को प्रस्तुत विज्ञापन या उसके इंटरैक्शन डेटा को पढ़ने से रोकते हैं।

क्या Privacy Sandbox को सहमति की आवश्यकता है?

यह 2026 के ad tech परिदृश्य में सबसे गलत समझा जाने वाला प्रश्न है, और उत्तर क्षेत्राधिकार-विशिष्ट है।

GDPR और ePrivacy के अंतर्गत

यूरोपीय डेटा संरक्षण बोर्ड ने कोई व्यापक स्थिति जारी नहीं की है, लेकिन राष्ट्रीय प्राधिकरण अधिक स्पष्ट रहे हैं। UK ICO, इतालवी Garante, और फ्रांस के CNIL सभी ने यह दृष्टिकोण लिया है कि Topics और Protected Audience को पूर्व opt-in सहमति की आवश्यकता है जहाँ वे व्यक्तिगत डेटा संसाधित करते हैं, जिसमें कोई भी प्रसंस्करण शामिल है जो उपयोगकर्ता के डिवाइस पर स्थिति लिखता या पढ़ता है। तर्क: ब्राउज़र अभी भी स्थानीय रूप से रुचि विषयों और रुचि समूहों को संग्रहीत करता है, और document.browsingTopics() कॉल किसी तीसरे पक्ष को अनुमानित व्यक्तिगत डेटा प्रसारित करता है। यह ePrivacy निर्देश के अनुच्छेद 5(3) के अंतर्गत विनियमित है, जो अनुरोधित सेवा के लिए जो सख्त आवश्यक है उससे परे उपयोगकर्ता के टर्मिनल उपकरण तक किसी भी पहुँच या उस पर संग्रहण के लिए सहमति की आवश्यकता करता है।

Google की स्थिति अधिक अनुमोदक है — वे तर्क देते हैं कि API डिज़ाइन द्वारा गोपनीयता-संरक्षण करने वाले हैं और सहमति की आवश्यकताएं सभी संदर्भों में लागू नहीं हो सकती हैं। यह एक नियामक की स्थिति नहीं है। यूरोप में Privacy Sandbox को सहमति-मुक्त के रूप में मानना एक उच्च-जोखिम की मुद्रा है।

CCPA, CPRA और अमेरिकी राज्य कानूनों के अंतर्गत

संयुक्त राज्य अमेरिका में, Privacy Sandbox प्रवाहों को आम तौर पर CPRA के तहत क्रॉस-संदर्भ व्यवहार संबंधी विज्ञापन के लिए व्यक्तिगत जानकारी के साझाकरण के रूप में माना जाता है। इसका मतलब है कि वे opt-out अधिकार को ट्रिगर करते हैं और Global Privacy Control संकेतों और अन्य सार्वभौमिक opt-out तंत्रों के माध्यम से सम्मानित किए जाने चाहिए। यह तथ्य कि Topics डेटा ब्राउज़र से प्राप्त होता है न कि थर्ड-पार्टी ब्रोकर से बेचा जाता है, इसे छूट नहीं देता।

Chrome के अपने नियंत्रण

Chrome Topics, Protected Audience और Attribution Reporting के लिए chrome://settings/adPrivacy में उपयोगकर्ता-मुखी टॉगल प्रदान करता है। ये उपयोगकर्ता विकल्प — के बजाय नहीं — आपके CMP की सहमति स्थिति के साथ-साथ हैं। एक उपयोगकर्ता जिसने आपके बैनर में विज्ञापन कुकीज़ के लिए नहीं कहा लेकिन Chrome की वैश्विक सेटिंग में Topics के लिए हाँ कहा, उसने फिर भी बैनर के माध्यम से आपको नहीं कहा। आपके स्टैक को दोनों में से सख्त संकेत का सम्मान करना होगा।

वह सहमति परत जिसकी आपको वास्तव में आवश्यकता है

एक प्रोडक्शन-ग्रेड 2026 सहमति स्टैक Privacy Sandbox API को अलग प्रसंस्करण गतिविधियों के रूप में मानती है, प्रत्येक IAB TCF उद्देश्यों या समकक्ष राज्य-कानून श्रेणियों के माध्यम से गेट किया गया।

Sandbox API को TCF उद्देश्यों से मैपिंग

Google Consent Mode v2 से मैपिंग

Google के Consent Mode v2 संकेत Privacy Sandbox व्यवहार से मैप होते हैं:

अमेरिकी राज्य संकेत हैंडलिंग

अमेरिकी ट्रैफ़िक के लिए, आपकी सहमति परत Global Privacy Control और लागू राज्य opt-out संकेतों की जाँच करनी चाहिए। जब एक अमेरिकी उपयोगकर्ता ने साझाकरण से opt-out किया हो, document.browsingTopics() को दबाएं, joinAdInterestGroup को कॉल न करें, और Attribution Reporting पंजीकरण हेडर को हटाएं।

व्यावहारिक कार्यान्वयन पैटर्न

जो प्रकाशक पहले से Privacy Sandbox रोल आउट कर चुके हैं वे आम तौर पर दो में से एक आर्किटेक्चर पैटर्न का पालन करते हैं।

पैटर्न 1: सर्वर-साइड ऑर्केस्ट्रेशन

आपके ऑरिजिन पर एक फर्स्ट-पार्टी टैग मैनेजर सहमति स्थिति, उपयोगकर्ता क्षेत्राधिकार और किसी भी संकेत ओवरराइड को एकत्र करता है, फिर सशर्त रूप से Privacy Sandbox हुक को पृष्ठ में प्रस्तुत करता है। विज्ञापन सर्वर और SSP को बिड अनुरोध के माध्यम से सहमति ध्वज प्राप्त होते हैं, और वे तय करते हैं कि Topics, Protected Audience या किसी को भी कॉल करना है या नहीं। यह पैटर्न तर्क को केंद्रीकृत करता है और सहमति स्थिति को आधिकारिक रखता है।

पैटर्न 2: Header Bidding Wrapper एकीकरण

Prebid.js और अन्य header bidding wrappers अब Privacy Sandbox मॉड्यूल का समर्थन करते हैं। wrapper सहमति संकेत पढ़ता है, Topics कॉल व्यवहार कॉन्फ़िगर करता है, और जब अनुमत हो तो Protected Audience के माध्यम से नीलामी परिणाम अग्रेषित करता है। यह दृष्टिकोण तैनात करने में हल्का है लेकिन क्लाइंट में अधिक तर्क धकेलता है और wrapper रिलीज़ कैडेंस पर आपकी निर्भरता को कसता है।

क्या ऑडिट करें

Privacy Sandbox क्या नहीं करता

बजट से पहले कई सामान्य गलतफहमियों को मरना होगा।

यह सहमति का वर्कअराउंड नहीं है

API विज्ञापनदाताओं को उजागर किए गए व्यक्तिगत डेटा को कम करते हैं, लेकिन वे यूरोपीय कानून के तहत अंतर्निहित प्रसंस्करण को सहमति-मुक्त नहीं बनाते। अनुपालन सिद्धांत कि Sandbox अपनाने से आप CMP को छोड़ सकते हैं, हर EU/EEA क्षेत्राधिकार में गलत है।

यह आज कुकीज़ का पूर्ण प्रतिस्थापन नहीं है

Topics मोटे, हानिपूर्ण लक्ष्यीकरण संकेत प्रदान करता है जो आम तौर पर कुकी-आधारित ऑडियंस से कमज़ोर होता है। Protected Audience रीटार्गेटिंग स्केल अभी भी परिपक्व हो रहे हैं। Attribution Reporting में माप शोर फर्श हैं जो छोटे रूपांतरण उठान को छिपा सकते हैं। एक प्रकाशक जो आज सभी मौद्रीकरण को Sandbox में स्थानांतरित करता है, उसे विशिष्ट इन्वेंट्री पर कुकी-आधारित स्टैक के सापेक्ष RPM में 10-30 प्रतिशत की गिरावट की उम्मीद करनी चाहिए।

यह अपने वर्तमान आकार में स्थायी नहीं है

Privacy Sandbox विनिर्देश अभी भी विकसित हो रहा है। Topics टैक्सोनॉमी का विस्तार हो रहा है, Protected Audience रुचि-समूह सीमाएं संशोधन के अधीन हैं, और नियामक प्रतिक्रिया जारी है। अपनी सहमति परत को कॉन्फ़िगरेशन-संचालित बनाने के लिए डिज़ाइन करें, न कि वर्तमान विनिर्देश के लिए हार्डकोड किया गया।

2026 के लिए सही स्थिति

Privacy Sandbox को सबसे अच्छी तरह से व्यापक कुकीलेस रणनीति की एक परत के रूप में समझा जाता है, फर्स्ट-पार्टी डेटा, विक्रेता-परिभाषित ऑडियंस, प्रासंगिक लक्ष्यीकरण और सर्वर-साइड header bidding के साथ। 2026 में जीतने वाले प्रकाशक वे होंगे जो सहमति को मध्यस्थ के रूप में मानते हैं, बाधा नहीं — Sandbox API को केवल तभी फीड करते हैं जहाँ कानून और उपयोगकर्ता की पसंद अनुमति देती है, हर जगह साफ तरीके से प्रासंगिक पर वापस आते हैं, और ऐसे टूलिंग के साथ दोनों मार्गों पर परिणामों को मापते हैं जो पहचान मान नहीं लेते।

सबसे बुरी स्थिति प्रतीक्षा-और-देखने वाली है। नियामक पहले से ही अगली नियमों की लहर लिख रहे हैं — UK Competition and Markets Authority की Sandbox प्रतिबद्धताएं, चल रहे CNIL मार्गदर्शन, और EU AI Act के प्रोफाइलिंग प्रावधान सभी इस जमीन को छूते हैं। जो प्रकाशक 2026 में ठीक से गेट की गई सहमति स्टैक में Privacy Sandbox बनाएंगे वे उन नियमों के लिए तैयार होंगे। जो इसे अंतिम समय के कुकी प्रतिस्थापन के रूप में बोल्ट करेंगे वे खुद को दबाव में फिर से लिखते पाएंगे।

← ब्लaderegistrdelays delays सभी पढ़ें →