यूरोपीय कानूनों के बारे में खास जानकारी और दिशा-निर्देश

Google के 'अन्य सहमति वाले मोड' के बारे में जानकारी

अगला: IAB ईयू के टीसीएफ़ वर्शन 2.2 को लागू करने में होने वाली समस्याओं को हल करना

ऐसे पब्लिशर जो विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली नॉन-टीसीएफ़ कंपनियों (एटीपी) के साथ काम नहीं करना चाहते उन्हें सीधे अपने सीएमपी के साथ काम करना चाहिए.

इस दस्तावेज़ में एक सुविधा के बारे में जानकारी दी गई है, जिसे "अन्य सहमति" कहा जाता है. इसे सिर्फ़ IAB यूरोप के पारदर्शिता और सहमति फ़्रेमवर्क (टीसीएफ़) के वर्शन 2 के साथ इस्तेमाल किया जाएगा. इसका मकसद उन वेंडर को पारदर्शिता और/या सहमति के सिग्नल भेजना है जो अब तक IAB यूरोप की ग्लोबल वेंडर लिस्ट (जीवीएल) में रजिस्टर नहीं हुए हैं. यह मोड, टीसीएफ़ को लागू करने के साथ-साथ पब्लिशर, सहमति मैनेजमेंट प्लैटफ़ॉर्म (सीएमपी), और पार्टनर को उन कंपनियों के लिए अन्य सहमति पाने और उन्हें बढ़ावा देने में मदद करता है जो Google की विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों (एटीपी) की सूची में तो शामिल हैं, लेकिन अब तक IAB यूरोप की ग्लोबल वेंडर लिस्ट में रजिस्टर नहीं हुई हैं.

अन्य सहमति वाले मोड के वर्शन 2 में हुए बदलाव

Google, दिसंबर 2023 से ही अन्य सहमति वाले मोड के वर्शन 2 का इस्तेमाल कर रहा है. इसमें ये मुख्य बदलाव हुए हैं:

सीएमपी में बताए गए वेंडर को सपोर्ट करने के लिए, अन्य सहमति (एसी) वाली स्ट्रिंग में अपडेट.
टीसीएफ़ और विज्ञापन देने वाले व्यक्ति या कंपनी के लिए सहमति मोड, दोनों के साथ काम करने वाले सीएमपी के इंटरऑपरेबिलिटी के लिए, सीएमपी एपीआई में अपडेट.

अन्य सहमति वाले मोड के वर्शन 1 के हिसाब से जनरेट की गई अन्य सहमति वाली स्ट्रिंग काम करती रहेंगी.

अन्य सहमति वाले मोड के कॉम्पोनेंट

"अन्य सहमति वाले मोड" में, हम ये दोनों सुविधाएं देते हैं:

पारदर्शिता और सहमति वाली स्ट्रिंग यानी टीसी स्ट्रिंग, जिसके बारे में IAB टीसीएफ़ के 2.2 वर्शन की खास जानकारी में बताया गया है. इस स्ट्रिंग में, IAB की ग्लोबल वेंडर लिस्ट (जीवीएल) में वेंडर के लिए तय की गई पारदर्शिता और सहमति शामिल है. और,
एक छोटी addtl_consent स्ट्रिंग यानी अन्य सहमति वाली स्ट्रिंग, जिसमें सहमति वाली और/या ज़ाहिर की गई, Google की विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली ऐसी कंपनियों (एटीपी) की सूची है जो IAB के साथ रजिस्टर नहीं हैं.

इस खास जानकारी में इनके बारे में बताया गया है:

अन्य सहमति वाली स्ट्रिंग का फ़ॉर्मैट.
टीसीएफ़ और विज्ञापन देने वाले व्यक्ति या कंपनी का सहमति मोड, दोनों मौजूद होने पर अन्य सहमति वाली स्ट्रिंग को सपोर्ट और कंट्रोल के लिए, TCF v2.2 CMP API का एक्सटेंशन.
अन्य सहमति वाली स्ट्रिंग को सेव करने का तरीका.
डिजिटल विज्ञापन की चेन में अन्य सहमति वाली स्ट्रिंग पास करने का तरीका.

"अन्य सहमति" वाली स्ट्रिंग का फ़ॉर्मैट

अन्य सहमति वाली स्ट्रिंग में कौनसी जानकारी सेव की जाती है?

अन्य सहमति वाली स्ट्रिंग में ये कॉम्पोनेंट होते हैं:

पहला: खास जानकारी का वर्शन नंबर, जैसे कि "2"
दूसरा: सेपरेटर का निशान "~"
तीसरा: विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली ऐसी कंपनियों (ATP) के आईडी की लिस्ट जिन्हें उपयोगकर्ताओं से अनुमति मिली है. इस लिस्ट में अलग-अलग आईडी, बिंदु से अलग किए जाते हैं. जैसे: "1.35.41.101"
चौथा: सेपरेटर का निशान "~"
पांचवां: "dv." के बाद, Google की विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों (एटीपी) की दी गई सूची, जिसमें कंपनियों के आईडी को बिंदु से अलग किया गया हो. उदाहरण: "dv.9.21.81"

स्ट्रिंग की लंबाई कम करने के लिए, तीसरे कॉम्पोनेंट में शामिल वेंडर को पांचवें कॉम्पोनेंट में शामिल नहीं किया जाना चाहिए.

अन्य सहमति वाली स्ट्रिंग का उदाहरण

अन्य सहमति वाली स्ट्रिंग में 2~1.35.41.101~dv.9.21.81 का मतलब है कि उपयोगकर्ता ने 1, 35, 41, और 101 आईडी वाले एटीपी को सहमति दी है. वहीं, 9, 21, और 81 आईडी वाले एटीपी की जानकारी उपयोगकर्ता के सामने ज़ाहिर की है. साथ ही, स्ट्रिंग बनाने के लिए, वर्शन 2 में बताए गए फ़ॉर्मैट का इस्तेमाल किया है.

अन्य सहमति वाली स्ट्रिंग किसे बनानी चाहिए?

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

Google ATP की लिस्ट कहां पब्लिश की जाएगी?

विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली ऐसी कंपनियां जो IAB में रजिस्टर नहीं हैं, Google उनके नाम और आईडी यहां पब्लिश करेगा:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

अन्य सहमति वाली स्ट्रिंग कब बनानी चाहिए?

सभी मामलों में, अन्य सहमति वाली स्ट्रिंग सिर्फ़ तब बनाई जा सकती है, जब पब्लिशर, Google की ईयू उपयोगकर्ता की सहमति से जुड़ी नीति का पालन करे.

सहमति वाले वेंडर को सिर्फ़ तब शामिल किया जाना चाहिए, जब उपयोगकर्ता ने इनके लिए कानूनी तौर पर मान्य सहमति दी हो:

कानूनी रूप से ज़रूरी होने पर, कुकी या अन्य लोकल स्टोरेज का इस्तेमाल करने के लिए; और
किसी एटीपी की मदद से, दिलचस्पी के मुताबिक विज्ञापन दिखाने के लिए निजी डेटा को इकट्ठा, शेयर, और इस्तेमाल करने के लिए. साथ ही, Google की ईयू उपयोगकर्ता की सहमति से जुड़ी नीति की अन्य सभी शर्तों का पालन करने के लिए.

ज़ाहिर किए गए वेंडर जिनके पास इनकी सहमति नहीं है

कानूनी रूप से ज़रूरी होने पर, कुकी या अन्य लोकल स्टोरेज का इस्तेमाल करने की; और
विज्ञापनों को मनमुताबिक बनाने के लिए, निजी डेटा को इकट्ठा, शेयर, और इस्तेमाल करने की जानकारी सिर्फ़ तब शामिल करने की, जब उपयोगकर्ताओं को हर एटीपी की पहचान के बारे में पारदर्शिता के साथ जानकारी दी गई हो. इसमें, एटीपी की निजता नीति से लिंक करने की जानकारी भी शामिल है, जैसा कि Google की एटीपी सूची में बताया गया है.

अन्य सहमति वाली स्ट्रिंग, सिर्फ़ टीसी स्ट्रिंग की पूरक स्ट्रिंग के तौर पर बनाई जानी चाहिए, न कि टीसी स्ट्रिंग की जगह पर. Google, अन्य सहमति वाली स्ट्रिंग के ऐसे किसी अनुरोध को प्रोसेस नहीं करेगा जिसके लिए टीसी स्ट्रिंग उपलब्ध नहीं है. साथ ही, अनुरोध की गई, अन्य सहमति वाली स्ट्रिंग को खारिज कर देगा.

इस खास जानकारी को लागू करने वाले सीएमपी को यह पक्का करना होगा कि वे अन्य सहमति वाली जो स्ट्रिंग बनाएं उसमें सिर्फ़ ऐसे वेंडर शामिल हों जिनके आईडी, पब्लिश की गई Google ATP फ़ाइल में मौजूद हैं, लेकिन वे IAB Europe ग्लोबल वेंडर लिस्ट (जीवीएल) पर रजिस्टर नहीं हैं. जब Google को कोई टीसी स्ट्रिंग मिलती है, तो वह उस टीसी स्ट्रिंग में मौजूद जीवीएल के वर्शन की जांच करेगा. अगर किसी वेंडर का जीवीएल के उस वर्शन के लिए रजिस्ट्रेशन है, तो उस वेंडर के लिए टीसी स्ट्रिंग कंट्रोल के साथ उस वेंडर से जुड़ी अन्य सहमति वाली स्ट्रिंग एंट्री को अनदेखा किया जाएगा. ऐसी स्थिति में, Google के पास यह अधिकार है कि वह अन्य सहमति वाली स्ट्रिंग से ऐसी "डुप्लीकेट" एंट्री हटा दे और बदली हुई अन्य सहमति वाली स्ट्रिंग को टीसी स्ट्रिंग के साथ पास कर दे. Google के अलावा, दूसरे वेंडर अन्य सहमति वाली स्ट्रिंग में बदलाव नहीं कर सकते.

इसी विषय से जुड़े लिंक

CMP API का एक्सटेंशन

हमारा सुझाव है कि मौजूदा TCF v2.2 CMP JavaScript API को बढ़ाया जाए, ताकि उससे अन्य सहमति वाली स्ट्रिंग को दिखाया जा सके. खास तौर पर, यह डेटा देने के लिए, हम TCData और InAppTCData नाम के JSON ऑब्जेक्ट को बढ़ाने का सुझाव देते हैं.

TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

अन्य सहमति वाली स्ट्रिंग का स्टोरेज कैसे किया जाना चाहिए?

वेब

स्टोरेज का तरीका सीएमपी की पसंद पर निर्भर करता है.

इन-ऐप्लिकेशन

iOS के लिए NSUserDefaults या Android के लिए SharedPreferences का इस्तेमाल करके, सीएमपी SDK टूल, अन्य सहमति वाली स्ट्रिंग को स्टोर करेगा. इससे आपको ये सुविधाएं मिलेंगी:

वेंडर, अन्य सहमति वाली स्ट्रिंग को आसानी से ऐक्सेस कर पाएंगे
अन्य सहमति वाली स्ट्रिंग सभी ऐप्लिकेशन सेशन में बनी रहेगी
अन्य सहमति वाली स्ट्रिंग, अलग-अलग सीएमपी के बीच ट्रांसफ़र की जा सकेगी. इससे पब्लिशर को किसी एक सीएमपी SDK टूल को दूसरे से बदलने में आसानी होती है

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

NSUserDefaults और SharedPreferences में स्टोरेज और लुकअप बटन वैल्यू

IABTCF_AddtlConsent

स्ट्रिंग: अन्य सहमति वाली स्ट्रिंग, जिसमें वर्शन की खास जानकारी और विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली ऐसी कंपनियों के आईडी हैं, जिन्हें उपयोगकर्ताओं से सहमति मिल चुकी है

डिजिटल विज्ञापन की चेन में अन्य सहमति वाली स्ट्रिंग पास करने का तरीका

बिड रिक्वेस्ट

डाउनस्ट्रीम लागू करने के लिए, हम ConsentedProvidersSettings का दोबारा इस्तेमाल उन वेंडर के लिए करेंगे जो जीवीएल में रजिस्टर नहीं हैं.

OpenRTB एक्सटेंशन प्रोटोकॉल में
लेगसी प्रोटोबफ़ वर्शन में

message ConsentedProvidersSettings { // Set of IDs corresponding to providers for whom the publisher has told // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local // storage where legally required; and 2) the collection, sharing, and use of personal data for // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy. // A mapping of provider ID to provider name is posted at providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Information about the providers for whom the publisher has told Google // that its EEA users have consented to the use of their personal data for // ads personalization in accordance with Google's EU User Consent Policy. // This field will only be populated when regs_gdpr is true. optional ConsentedProvidersSettings consented_providers_settings = 42;

यूआरएल आधारित सेवाएं

जब कोई क्रिएटिव रेंडर किया जाता है, तो उसमें <img> टैग के तहत कई पिक्सल हो सकते हैं. उदाहरण के लिए, <img src="http://vendor-a.com/key1=val1&key2=val2">, जो वेंडर के डोमेन में ब्राउज़र से HTTP GET अनुरोध भेजता है.

पिक्सल <img> टैग में है और JavaScript का इस्तेमाल नहीं कर सकता, इसलिए टीसी स्ट्रिंग पाने के लिए, CMP API का इस्तेमाल नहीं किया जा सकता. टीसी स्ट्रिंग के लिए सहायता की तरह, हम पिक्सल यूआरएल में एक स्टैंडर्ड यूआरएल पैरामीटर और मैक्रो देते हैं जहां अन्य सहमति वाली स्ट्रिंग डाली जानी चाहिए.

यूआरएल पैरामीटर	संबंधित मैक्रो	यूआरएल में कैसे दिखेगा
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

पहला उदाहरण

अन्य सहमति वाली स्ट्रिंग पाने के लिए, वेंडर A को किसी इमेज यूआरएल में, यूआरएल पैरामीटर और मैक्रो के साथ की-वैल्यू पेयर, &addtl_consent=${ADDTL_CONSENT} शामिल करना होगा. इससे मिलने वाला यूआरएल है:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

दूसरा उदाहरण

अगर किसी अनुरोध में, अन्य सहमति वाली स्ट्रिंग 1~1.35.41.101 है

क्रिएटिव का कॉलर या रेंडरर, यूआरएल में मौजूद मैक्रो को, वास्तविक अन्य सहमति वाली स्ट्रिंग से बदल देता है. इससे, बताए गए सर्वर पर कॉल करते समय, उस पिक्सल में नीचे बताए गए तरीके से बदलाव होता है जिसमें मैक्रो मौजूद है:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

क्या यह उपयोगी था?

हम उसे किस तरह बेहतर बना सकते हैं?