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

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

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

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

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

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

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

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

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

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

आर्किटेक्चर और ऑक्शन फ़्लो

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

डेटा के फ़्लो के बारे में यहां खास जानकारी दी गई है:

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

हर चरण के बारे में पूरी जानकारी और डेटा को एन्क्रिप्ट (सुरक्षित) करने के तरीके के बारे में जानने के लिए, 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.
}

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

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

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

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

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

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

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

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

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

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