बिडिंग और नीलामी से जुड़ी सेवाएं

bookmark_border संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

Protected Audience के शुरुआती प्रपोज़ल में, रीमार्केटिंग विज्ञापन की मांग के लिए बिडिंग और नीलामी, डिवाइस पर स्थानीय तौर पर की जाती है. इस ज़रूरी शर्त के तहत, कैलकुलेशन से जुड़ी ऐसी ज़रूरी शर्तें हो सकती हैं जिन्हें सीमित प्रोसेसिंग क्षमता वाले डिवाइसों पर लागू करना मुश्किल हो. इसके अलावा, नेटवर्क के इंतज़ार की वजह से, विज्ञापनों को चुनने और रेंडर करने में काफ़ी समय लग सकता है.

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

Google, B&A के कॉम्पोनेंट उपलब्ध कराएगा. इन्हें ओपन सोर्स के तौर पर उपलब्ध कराया जाएगा. जिन विज्ञापन टेक्नोलॉजी कंपनियों को इस सुविधा का इस्तेमाल करना है वे, काम करने वाले सार्वजनिक क्लाउड सेवा देने वाली कंपनियों के साथ मिलकर अपने इंस्टेंस होस्ट कर सकती हैं. बीएंडए के प्रस्ताव के बारे में ज़्यादा जानने के लिए, GitHub पर जाएं. ध्यान दें कि उस दस्तावेज़ में दी गई तारीखें, Chrome के लिए लागू होने की तारीखें हैं. आने वाले समय में, हम Android के साथ इंटिग्रेशन के बारे में ज़्यादा जानकारी पब्लिश करेंगे. इस दस्तावेज़ में, B&A के बारे में जानकारी दी गई है. साथ ही, B&A के साथ इंटरैक्ट करने के लिए, Android के नए एपीआई के बारे में भी बताया गया है. आने वाले समय में, हम इन नए एपीआई का इस्तेमाल करने के तरीके के बारे में ज़्यादा तकनीकी जानकारी पोस्ट करेंगे.

B&A सेवाएं कहां फ़िट होती हैं

B&A, विज्ञापन टेक्नोलॉजी के मालिकाना हक वाले भरोसेमंद सर्वर में नीलामी चलाने का एक और विकल्प देता है. ये सर्वर, Google की ओर से उपलब्ध कराए गए ओपन सोर्स बाइनरी पर काम करते हैं. उपयोगकर्ता का डेटा अब भी डिवाइस पर मौजूद होता है. Google, उस डेटा को सुरक्षित तरीके से टीईई में ले जाने के लिए एपीआई उपलब्ध कराएगा. एन्क्रिप्शन की रणनीति के बारे में ज़्यादा जानकारी यहां दी गई है.

इसका मतलब है कि नीलामी की प्रोसेस के कुछ हिस्से डिवाइस पर और कुछ हिस्से क्लाउड में होते हैं. डीएसपी के नज़रिए से, कस्टम ऑडियंस (रीमार्केटिंग कैंपेन के लिए शामिल संभावित विज्ञापन) अब भी डिवाइस पर मैनेज की जाती हैं. इसके लिए, कस्टम ऑडियंस मैनेजमेंट एपीआई का इस्तेमाल उसी तरह किया जाता है जिस तरह डिवाइस पर नीलामी की जाती है. एसएसपी के लिहाज़ से, रिक्वेस्ट अब भी डिवाइस पर ट्रिगर होते हैं. इस दस्तावेज़ में, इस्तेमाल किए जाने वाले नए एपीआई के बारे में बताया गया है. सभी पक्षों के लिए, बिडिंग और नीलामी के कॉल के खत्म होने के बाद, नीलामी के नतीजे की रिपोर्टिंग अब भी डिवाइस से शुरू होती है.

बिडिंग, स्कोरिंग, और रिपोर्टिंग यूआरएल जनरेशन लॉजिक को लागू करने की जगह के हिसाब से, इन दोनों में काफ़ी अंतर होता है. डिवाइस पर बिडिंग, नीलामी, और रिपोर्टिंग लॉजिक चलाने के बजाय, generateBid(), scoreAd(), reportResult(), और reportWin() लॉजिक को टीईई में चलाया जाता है. खरीदार की बिडिंग लॉजिक और सेलर की स्कोरिंग लॉजिक, सुरक्षित ऑडियंस की नीलामी के फ़्लो के बीच, अपने बीए (बिडिंग और ऑप्टिमाइज़ेशन) एनवायरमेंट में लागू की जाती है:

डेटा एन्क्रिप्शन

B&A की मदद से, कस्टम ऑडियंस और बिड की रकम जैसी Protected Audience की जानकारी, डिवाइस से सेलर के विज्ञापन टेक्नोलॉजी सर्वर पर भेजी जाती है. इसके बाद, यह जानकारी सेलर के विज्ञापन टेक्नोलॉजी सर्वर से खरीदार के विज्ञापन टेक्नोलॉजी सर्वर पर भेजी जाती है और फिर डिवाइस पर वापस भेजी जाती है. इस वजह से, प्लैटफ़ॉर्म, Protected Audience की सेवाओं को भेजे जाने वाले डेटा को एन्क्रिप्ट करता है. साथ ही, सिर्फ़ ऐसी सेवाएं ही इस डेटा को डिक्रिप्ट कर सकती हैं जिन्हें पुष्टि मिली हो. एन्क्रिप्शन की रणनीतियों के बारे में ज़्यादा जानने के लिए, GitHub पर जाएं.

आर्किटेक्चर और नीलामी का फ़्लो

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

डेटा के फ़्लो के बारे में हाई लेवल पर इस तरह बताया गया है:

1. डिवाइस पर, सेलर getAdSelectionData एपीआई का इस्तेमाल करके, Protected Audience से जानकारी इकट्ठा करते हैं.
2. डिवाइस पर मौजूद SDK टूल, सेलर विज्ञापन सेवा को अनुरोध भेजता है. इस अनुरोध में, कॉन्टेक्स्ट के हिसाब से बनाया गया पेलोड और एन्क्रिप्ट (सुरक्षित) किया गया ProtectedAudienceInput शामिल है.
3. सेलर विज्ञापन सेवा, टीईई के बाहर चल रही खरीदारों की रीयल टाइम बिडिंग (आरटीबी) सेवा को अनुरोध भेजती है, ताकि कॉन्टेक्स्ट के हिसाब से विज्ञापनों के लिए उम्मीदवारों को हासिल किया जा सके. इसके बाद, वह कॉन्टेक्स्ट के हिसाब से विज्ञापनों को स्कोर करती है और उनमें से सबसे अच्छा विज्ञापन चुनती है.
4. सेलर विज्ञापन सेवा, टीईई में चल रही अपनी SellerFrontEnd service को अनुरोध भेजती है.
5. SellerFrontEnd सेवा, खरीदार के डेटा के साथ अनुरोध भेजती है. ये अनुरोध, BuyerFrontEnd सेवाओं को भेजे जाते हैं.
6. खरीदार अपनी की/वैल्यू सेवा और बिडिंग सेवा का इस्तेमाल करते हैं. इससे, रीमार्केटिंग के लिए चुनी गई सभी कस्टम ऑडियंस के लिए, डिवाइस से मिले विज्ञापन के लिए बिड जनरेट होती हैं.
7. SellerFrontEnd सेवा, अपनी कीवर्ड/वैल्यू सेवा से पढ़ती है और संभावित विज्ञापनों को स्कोर देती है. नतीजे को एन्क्रिप्ट (सुरक्षित) किया जाता है और सेलर विज्ञापन सेवा को वापस भेजा जाता है.
8. सेलर विज्ञापन सेवा, डिवाइस पर मौजूद SDK को एन्क्रिप्ट किया गया नतीजा दिखाती है. साथ ही, वैकल्पिक तौर पर, संदर्भ के हिसाब से नतीजा भी दिखा सकती है.
9. डिवाइस पर, सेलर processAdSelectionResult एपीआई का इस्तेमाल करके, विज्ञापन के लिए चुना गया विज्ञापन पाते हैं. यह एपीआई, सेलर विज्ञापन सेवा से मिले रिस्पॉन्स को डिक्रिप्ट करता है.

हर चरण के बारे में पूरी जानकारी और डेटा को एन्क्रिप्ट करने के तरीके के बारे में ज़्यादा जानने के लिए, GitHub पर जाएं. इन कॉम्पोनेंट का कोड, ओपन सोर्स के ज़रिए उपलब्ध कराया जाएगा. दिया गया कोड, SellerFrontEnd सेवा से BuyerFrontEnd सेवाओं के लिए अनुरोधों के फ़ेडरेशन को मैनेज करेगा.

क्लाउड पर डिप्लॉयमेंट

विज्ञापन टेक्नोलॉजी, B&A सेवाओं को काम करने वाले सार्वजनिक क्लाउड प्लैटफ़ॉर्म पर डिप्लॉय करेगी. इन डिप्लॉयमेंट को विज्ञापन टेक्नोलॉजी विशेषज्ञ मैनेज करेंगे. ये विशेषज्ञ, उपलब्धता सेवा के लेवल के मकसद को तय करने के लिए ज़िम्मेदार होंगे.

नीलामी चलाना

बिडिंग और ऑप्टिमाइज़ेशन (बीए) नीलामी चलाने का पहला चरण, डिवाइस पर मौजूद कस्टम ऑडियंस से डेटा इकट्ठा करना है. साथ ही, उसे सर्वर साइड नीलामियों में भेजने के लिए एन्क्रिप्ट करना है. ऐसा करने के लिए, getAdSelectionData एपीआई का इस्तेमाल करें:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData तरीका, बीए कॉम्पोनेंट के लिए ज़रूरी इनपुट जनरेट करता है. जैसे, BuyerInput और ProtectedAudienceInput. साथ ही, कॉल करने वाले को नतीजा उपलब्ध कराने से पहले, डेटा को एन्क्रिप्ट करता है. सभी ऐप्लिकेशन में डेटा लीक होने से रोकने के लिए, इस डेटा में डिवाइस पर मौजूद सभी खरीदारों की जानकारी शामिल होती है. इस फ़ैसले के बारे में ज़्यादा जानने के लिए, निजता से जुड़ी बातें सेक्शन पढ़ें.

यह एपीआई, AdSelectionData ऑब्जेक्ट दिखाता है:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

इस AdSelectionData का इस्तेमाल करके, डिवाइस पर मौजूद SDK टूल, अपनी विज्ञापन सेवा के लिए अनुरोध भेज सकता है. इसके लिए, डेटा को POST या PUT अनुरोध में शामिल करना होगा:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

इस डेटा को एन्कोड करने की ज़िम्मेदारी, डिवाइस पर मौजूद SDK टूल की होती है. हमारा सुझाव है कि आप multipart/form-data के तौर पर, सेलर की विज्ञापन सेवा को अनुरोध भेजें.

अनुरोध शुरू होने के बाद, Seller Ad सेवा, अनुरोध को TEE में चल रही SellerFrontEnd सेवा को भेजती है. SellerFrontEnd सेवा को कॉन्फ़िगर करते समय, सेलर उन डोमेन पतों की सूची देंगे जो BuyerFrontEnd सेवाओं से जुड़े होते हैं. ये सेवाएं, उन खरीदारों के ज़रिए ऑपरेट की जाती हैं जिनके साथ सेलर की साझेदारी है. अनुरोधों को, सेलर की ओर से उपलब्ध कराई गई BuyerFrontEnd की अलग-अलग सेवाओं के साथ फ़ेडरेट किया जाएगा, ताकि खरीदार अपने चुने गए विज्ञापन कैंडिडेट के लिए बिड जनरेट कर सकें. किसी खास खरीदार के लिए, B&A सिर्फ़ उन कस्टम ऑडियंस की जानकारी भेजेगा जिनका मालिकाना हक खरीदार के पास है. इससे, खरीदारों के बीच डेटा का क्रॉस-लीक नहीं होगा. बिड जनरेट करने के बाद, विज्ञापनों की सूची, SellerFrontEnd सेवा पर वापस आ जाती है. यहां विज्ञापनों में से किसी एक को विजेता चुना जाता है. आखिर में, SellerFrontEnd सेवा, एन्क्रिप्ट (सुरक्षित) किए गए विज्ञापन को डिवाइस पर दिखाती है.

डिवाइस पर Seller Ad service के अनुरोध के जवाब के साथ, प्लैटफ़ॉर्म नतीजे को डिक्रिप्ट करने और AdSelectionOutcome देने के लिए दूसरा नया एपीआई उपलब्ध कराता है. यह वही ऑब्जेक्ट है जो आज डिवाइस पर होने वाली नीलामी से मिलता है.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

रिपोर्टिंग

रिपोर्टिंग यूआरएल, B&A सेवाओं में जनरेट किए जाएंगे. नीलामियों के लिए इंप्रेशन और इंटरैक्शन की रिपोर्टिंग करने के लिए, उन यूआरएल को डिवाइस पर ट्रिगर करना अब भी ज़रूरी होगा. डिवाइस पर मौजूद SDK टूल को अब भी, बिडिंग और ऑप्टिमाइज़ेशन फ़्लो के दौरान जनरेट किए गए AdSelectionId का इस्तेमाल करके, reportImpression() और reportInteraction() एपीआई को शुरू करना होगा. एन्क्रिप्ट किए गए रिस्पॉन्स में, इंटरैक्शन रिपोर्टिंग के लिए जनरेट किए गए बीकन और उनसे जुड़े यूआरएल शामिल होते हैं. इसलिए, रिस्पॉन्स को डिक्रिप्ट करने के दौरान, इवेंट और यूआरएल मैपिंग को डिवाइस पर सेव किया जाता है.

निजता से जुड़ी बातें

GitHub पर ब्राउज़र बिडिंग और नीलामी एपीआई का प्रस्ताव बताता है कि निजता से जुड़ी बातों को कैसे ध्यान में रखा गया है. इस प्रस्ताव में Chrome के नामकरण का इस्तेमाल किया गया है, लेकिन ये सिद्धांत Android पर भी लागू होते हैं.

adSelectionData को एन्क्रिप्ट (सुरक्षित) किया जाता है, ताकि यह पक्का किया जा सके कि ट्रांज़िट में डेटा को सिर्फ़ PPAPI और भरोसेमंद सर्वर ऐक्सेस कर सकें. adSelectionData के साइज़ में होने वाले बदलावों की वजह से, डेटा लीक होने के जोखिम को कम करने के लिए, हम getAdSelectionData एपीआई के सभी कॉल के लिए एक ही adSelectionData जनरेट करने जा रहे हैं. इसका मतलब है कि डिवाइस पर मौजूद सभी CustomAudience का इस्तेमाल, adSelectionData बनाने के लिए किया जाता है. हम जनरेट किए गए adSelectionData पर, GetAdSelectionData इनपुट पैरामीटर के असर को सीमित करने का भी प्लान बना रहे हैं.

डिवाइस पर मौजूद सभी नीलामी डेटा का इस्तेमाल करके, सभी विज्ञापन टेक्नोलॉजी के लिए एक ही adSelectionData जनरेट करने से, ज़्यादा पेलोड जनरेट होता है. इसे विज्ञापन टेक्नोलॉजी सर्वर को हर कॉल में ट्रांसफ़र करना पड़ता है. साथ ही, इससे नुकसान पहुंचाने वाली इकाइयों के लिए, नेटवर्क का गलत इस्तेमाल करने का मौका मिलता है. इन समस्याओं के बारे में, नीचे दिए गए साइज़ से जुड़ी बातें और गलत इस्तेमाल को रोकने के लिए ध्यान रखने वाली बातें सेक्शन में बताया गया है.

साइज़ से जुड़ी बातें

विज्ञापन टेक्नोलॉजी क्लाइंट SDK को, adSelectionData के एन्क्रिप्ट किए गए बाइट को, सेलर के सर्वर पर कॉन्टेक्स्ट के हिसाब से विज्ञापन दिखाने के लिए कॉल में पैकेज करना चाहिए. बेहतरीन परफ़ॉर्मेंस के लिए, adSelectionData के साइज़ को ऑप्टिमाइज़ करना ज़रूरी है. ऐसा करने से, फ़ंक्शन में कोई बदलाव नहीं होता. adSelectionData के साइज़ को कम करने के लिए, हम पेलोड ऑप्टिमाइज़ेशन के बारे में बताने वाले लेख में बताए गए ऑप्टिमाइज़ेशन को लागू करने जा रहे हैं. इन ऑप्टिमाइज़ेशन में ये शामिल होंगे:

1. CustomAudience में ad_render_id जोड़ना, ताकि विज्ञापन रेंडर यूआरआई और मेटाडेटा के बजाय, इसे adSelectionData का इस्तेमाल करके भेजा जा सके. विज्ञापन टेक्नोलॉजी विशेषज्ञ, adSelectionData में विज्ञापन डेटा न भेजकर, इसे और ऑप्टिमाइज़ कर सकते हैं. आने वाले समय में, CustomAudience API के रिलीज़ में यह विकल्प काम करेगा.
2. पक्का करें कि user_bidding_signals को adSelectionData में न भेजा जाए. इसके बजाय, विज्ञापन टेक्नोलॉजी के विशेषज्ञ अपने पास मौजूद कुंजी/वैल्यू सर्वर से user_bidding_signals फ़ेच कर सकते हैं.
3. खरीदारों को CustomAudience को प्राथमिकता देने की अनुमति दें.
4. खरीदार को सेलर की प्राथमिकता तय करने की अनुमति दें.
5. पेलोड के साइज़ को कम करते समय, बिट लीकेज को सीमित करने के लिए, कुछ तय बकेट में adSelectionData जनरेट करें.

साइज़ को ऑप्टिमाइज़ करते समय, निजता से जुड़ी चिंताओं को ध्यान में रखा जाएगा.

गलत इस्तेमाल को रोकने के लिए ध्यान देने वाली बातें

निजता से जुड़ी बातों में बताया गया है कि adSelectionData को डिवाइस पर खरीदार के पूरे डेटा का इस्तेमाल करके जनरेट किया जाता है.

इससे, नुकसान पहुंचाने वाली संभावित इकाइयों को नेटवर्क का ऐक्सेस मिल जाता है. ये इकाइयां, खरीदार का धोखाधड़ी वाला डेटा जोड़ सकती हैं. इससे परफ़ॉर्मेंस खराब हो सकती है. साथ ही, लागत बढ़ाने के लिए पेलोड का साइज़ भी बढ़ सकता है.

adSelectionData के गलत इस्तेमाल को रोकने के लिए, हम ये तरीके अपनाएंगे

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

इन उपायों को इस तरह से डिज़ाइन किया गया है कि विज्ञापन टेक्नोलॉजी से जुड़े लोग यह तय कर सकें कि वे किन अन्य विज्ञापन टेक्नोलॉजी के साथ मिलकर काम करेंगे. साथ ही, वे adSelectionData पेलोड की ऐसी सीमाएं तय कर सकें जिन्हें उन्हें प्रोसेस करना होगा. हमारा सुझाव है कि सेलर को खरीदार की इस सूची और प्राथमिकता के बारे में अलग से बताने की अनुमति दी जाए. यह जानकारी, कुछ समय के लिए एक जैसी रहेगी, ताकि बार-बार कॉल करने पर उपयोगकर्ता के बारे में ज़्यादा डेटा इकट्ठा न हो.

ऊपर बताए गए जो उपाय हैं उन पर फ़िलहाल चर्चा की जा रही है. साथ ही, समय के साथ इनमें बदलाव भी हो सकते हैं. जैसा कि पहले बताया गया है, गलत इस्तेमाल को रोकने और साइज़ से जुड़ी पाबंदियों के लिए, जो भी बदलाव किए गए हैं वे निजता से जुड़ी शर्तों का पालन करते हों.