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

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

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

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

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

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

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

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

Protected Audience ऑक्शन फ़्लो

डेटा एन्क्रिप्ट (सुरक्षित) करने का तरीका

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

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

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

बिडिंग और नीलामी की सेवाओं के साथ, यूनिफ़ाइड कॉन्टेक्स्चुअल और प्रोटेक्टेड ऑडियंस ऑक्शन फ़्लो.

बड़े लेवल पर, डेटा के फ़्लो को इस तरह बताया जाता है:

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

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

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

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

नीलामी करना

B&A नीलामी शुरू करने का पहला कदम है, डिवाइस में मौजूद कस्टम ऑडियंस से डेटा इकट्ठा करना और उसे सर्वर साइड नीलामियों में भेजने के लिए एन्क्रिप्ट (सुरक्षित) करना. ऐसा करने के लिए, getAdSelectionData एपीआई का इस्तेमाल करें:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

getAdSelectionData वाला तरीका, B&A कॉम्पोनेंट, जैसे कि 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.
}

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

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

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

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

डिवाइस पर, सेलर विज्ञापन सेवा से किए गए अनुरोध का जवाब देने के बाद, प्लैटफ़ॉर्म एक दूसरा नया एपीआई उपलब्ध कराता है. इसकी मदद से, नतीजे को डिक्रिप्ट किया जा सकता है और 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 टूल को अब भी B&A फ़्लो के दौरान जनरेट किए गए AdSelectionId का इस्तेमाल करके, reportImpression() और reportInteraction() एपीआई शुरू करने होंगे. इंटरैक्शन की रिपोर्टिंग के लिए जनरेट किए गए बीकन और उनसे जुड़े यूआरएल, एन्क्रिप्ट (सुरक्षित) किए गए रिस्पॉन्स में शामिल होते हैं. इसलिए, रिस्पॉन्स को डिक्रिप्शन के दौरान, इवेंट और यूआरएल मैपिंग को डिवाइस पर सेव किया जाता है.

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

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

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

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

साइज़ का ध्यान रखना

विज्ञापन टेक्नोलॉजी क्लाइंट SDK टूल से, adSelectionData के एन्क्रिप्ट (सुरक्षित) किए गए बाइट को सेलर के सर्वर पर काम के विज्ञापन दिखाने के लिए पैकेज किया जाता है. सबसे अच्छी परफ़ॉर्मेंस के लिए, फ़ंक्शन से समझौता किए बिना, adSelectionData के साइज़ को ऑप्टिमाइज़ करना ज़रूरी है. adSelectionData का साइज़ कम करने के लिए, हम पेलोड ऑप्टिमाइज़ेशन की जानकारी वाले सेक्शन में बताए गए ऑप्टिमाइज़ेशन की सुविधा शुरू करने वाले हैं. इन ऑप्टिमाइज़ेशन में ये चीज़ें शामिल होंगी:

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

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

गलत इस्तेमाल को रोकने के लिए ज़रूरी बातें

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

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

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

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

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

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