बिडिंग और नीलामी सेवाओं का इंटिग्रेशन और ऑप्टिमाइज़ेशन

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

पहले बताए गए तरीके से नीलामी चलाने के लिए, डिवाइस पर सेलर की विज्ञापन टेक्नोलॉजी को यह तरीका अपनाना होगा:

1. सर्वर नीलामी के लिए डेटा इकट्ठा करना और उसे एन्क्रिप्ट करना
2. किसी ऐसी सेलर सेवा को अनुरोध भेजना जिस पर भरोसा नहीं किया जा सकता
3. किसी ऐसी सेलर सेवा से जवाब मिलना जिस पर भरोसा नहीं किया जा सकता
4. Protected Audience API से जुड़ी नीलामी के जवाब को डिक्रिप्ट करना और नीलामी का नतीजा पाना

सर्वर नीलामियों को चलाने के लिए, Protected Audience दो नए एपीआई पेश कर रहा है:

1. getAdSelectionData एपीआई, सर्वर नीलामी के लिए डेटा इकट्ठा करता है और नीलामी का डेटा शामिल करने वाला एन्क्रिप्ट (सुरक्षित) किया गया पेलोड जनरेट करता है. बिडिंग और नीलामी सर्वर, नीलामी चलाने, नीलामी का नतीजा जनरेट करने, और नीलामी का नतीजा दिखाने के लिए इस पेलोड का इस्तेमाल करता है.
2. डिवाइस पर मौजूद विज्ञापन टेक्नोलॉजी क्लाइंट, persistAdSelectionResult एपीआई को कॉल करके, सर्वर नीलामी से जनरेट हुए नतीजे को डिक्रिप्ट कर सकते हैं. साथ ही, विज्ञापन के लिए चुने गए यूआरएल को रेंडर कर सकते हैं.

डिवाइस पर सेलर की विज्ञापन टेक्नोलॉजी को नीलामी चलाने के लिए, इन चीज़ों को इंटिग्रेट और बनाना होगा:

1. सर्वर नीलामी में हिस्सा लेने वाले सेलर के लिए डेटा इकट्ठा करना और उसे एन्क्रिप्ट करना: एन्क्रिप्ट (सुरक्षित) किए गए पेलोड को पाने के लिए, विज्ञापन से जुड़ी टेक्नोलॉजी को getAdSelectionData एपीआई को कॉल करना चाहिए.
2. भरोसेमंद नहीं मानी जाने वाली सेलर सेवा को अनुरोध भेजें: HTTP POST या PUT का अनुरोध, जिसमें getAdSelectionData एपीआई से जनरेट किया गया एन्क्रिप्ट किया गया पेलोड शामिल होता है. यह अनुरोध, भरोसेमंद नहीं मानी जाने वाली सेलर सेवा को भेजा जाता है. साथ ही, इसमें वह डेटा भी शामिल होता है जो संदर्भ के हिसाब से नतीजे जनरेट करने के लिए, भरोसेमंद नहीं मानी जाने वाली सेलर सेवा को ज़रूरी होता है.
3. भरोसेमंद नहीं सेलर सेवा से जवाब पाना: भरोसेमंद नहीं सेलर सेवा से मिले जवाब में, एन्क्रिप्ट (सुरक्षित) की गई ऑडियंस नीलामी का नतीजा और कॉन्टेक्स्ट के हिसाब से नीलामी का नतीजा शामिल होगा.
4. Protected Audience नीलामी के रिस्पॉन्स को डिक्रिप्ट करना और नीलामी का नतीजा पाना: Protected Audience नीलामी के नतीजे को डिक्रिप्ट करने के लिए, सेलर की विज्ञापन टेक्नोलॉजी को persistAdSelectionResult एपीआई को कॉल करना चाहिए. persistAdSelectionResult से जनरेट हुए नतीजे से, विज्ञापन टेक्नोलॉजी को यह तय करने में मदद मिलेगी कि नीलामी में कॉन्टेक्स्ट विज्ञापन या सुरक्षित ऑडियंस वाले विज्ञापन में से किसने जीत हासिल की. साथ ही, अगर लागू हो, तो जीतने वाले सुरक्षित ऑडियंस वाले विज्ञापन का यूआरआई भी मिलेगा.

सर्वर नीलामी के लिए काम करने वाली सुविधाएं

हमारा मकसद, डिवाइस पर होने वाली नीलामी के लिए उपलब्ध सभी सुविधाओं को इस्तेमाल करना है. सर्वर नीलामी में इन सुविधाओं के साथ काम करने की समयावधि इस तरह है:

Protected Audience API का इस्तेमाल करके सर्वर नीलामियां चलाना

डेवलपर के लिए झलक वाले ट्रैक में, AdSelectionManager दो नए एपीआई दिखाता है: getAdSelectionData और persistAdSelectionResult. इन एपीआई की मदद से, विज्ञापन टेक्नोलॉजी के SDK, बिडिंग और नीलामी सर्वर के साथ इंटिग्रेट हो सकते हैं.

सर्वर नीलामी के लिए डेटा इकट्ठा और एन्क्रिप्ट (सुरक्षित) करना

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

एपीआई को ऐक्सेस करने के लिए, Protected Audience API का ऐक्सेस चालू होना चाहिए. साथ ही, कॉलर के मेनिफ़ेस्ट में ACCESS_ADSERVICES_CUSTOM_AUDIENCE की अनुमति दी जानी चाहिए.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. कॉल करने वाले को अनुरोध में seller फ़ील्ड सेट करना होगा, क्योंकि अनुरोध को प्रोसेस करने से पहले, रजिस्ट्रेशन की जांच करने के लिए इसका इस्तेमाल किया जाता है.
2. coordinatorOriginUri फ़ील्ड भरना ज़रूरी नहीं है.
   1. अगर यह सेट है, तो यह कोऑर्डिनेटर यूआरएल के स्कीम, होस्टनेम, और पोर्ट से मेल खाना चाहिए. इस यूआरएल को सेलर के बीएंडए सर्वर को डिप्लॉय करते समय कॉन्फ़िगर किया गया था.
   2. कोऑर्डिनेटर, अनुमति पा चुके कोऑर्डिनेटर की सूची में शामिल होना चाहिए:

      सेवा देने वाली कंपनी	यूआरआई	यूआरआई का ऑरिजिन	डिफ़ॉल्ट
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	हां
      Amazon वेब सेवाएं	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	नहीं

   3. अगर कोई कोऑर्डिनेटर ऑरिजिन नहीं दिया गया है, तो डिफ़ॉल्ट कोऑर्डिनेटर का इस्तेमाल किया जाता है.
   4. हालांकि, कोऑर्डिनेटर यूआरएल के बदलने की संभावना बहुत कम है, लेकिन हमारा सुझाव है कि इस यूआरएल को डाइनैमिक तौर पर मैनेज करने के लिए कोई तरीका लागू करें. इससे यह पक्का होता है कि आने वाले समय में यूआरएल में किए जाने वाले किसी भी बदलाव को, SDK टूल की नई रिलीज़ के बिना लागू किया जा सकता है.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

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

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome, getAdSelectionData एपीआई के नतीजे के तौर पर जनरेट होता है. इसमें ये चीज़ें शामिल हैं:

1. adSelectionId: getAdSelectionData के इस कॉल को पहचानने के लिए, ओपेक इंटरजर. विज्ञापन टेक्नोलॉजी क्लाइंट को इस adSelectionId वैल्यू को बनाए रखना चाहिए, क्योंकि यह getAdSelectionData कॉल के पॉइंटर के तौर पर काम करती है. बिडिंग और नीलामी सर्वर से नीलामी के नतीजे को डिक्रिप्ट करने के लिए, persistAdSelectionResult एपीआई को इस आइडेंटिफ़ायर की ज़रूरत होती है. साथ ही, reportImpression और reportEvent एपीआई को भी इसकी ज़रूरत होती है.
2. adSelectionData: यह एन्क्रिप्ट (सुरक्षित) किया गया नीलामी डेटा है. नीलामियां चलाने के लिए, बिडिंग और नीलामी सर्वर को इसकी ज़रूरत होगी. इस तरीके में ये शामिल हैं:
   1. फ़्रीक्वेंसी कैपिंग, ऐप्लिकेशन इंस्टॉल के फ़िल्टर, और कस्टम ऑडियंस के लिए सर्वर नीलामी की ज़रूरी शर्तों के आधार पर फ़िल्टर किया गया कस्टम ऑडियंस डेटा.
   2. आने वाले वर्शन में, इसमें ऐप्लिकेशन इंस्टॉल करने का डेटा शामिल होगा.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

गड़बड़ियां, अपवाद, और गड़बड़ी ठीक करना

अगर अमान्य आर्ग्युमेंट, टाइम आउट या ज़्यादा संसाधन खर्च होने जैसी वजहों से, विज्ञापन चुनने के लिए डेटा जनरेशन की प्रोसेस पूरी नहीं हो पाती है, तो OutcomeReceiver.onError() कॉलबैक, AdServicesException को इन कामों के साथ उपलब्ध कराता है:

1. अगर getAdSelectionData को अमान्य आर्ग्युमेंट के साथ शुरू किया जाता है, तो AdServicesException` से पता चलता है कि इसकी वजह IllegalArgumentException है.
2. अन्य सभी गड़बड़ियों के लिए, AdServicesException को IllegalStateException के तौर पर वजह के साथ दिखाया जाता है.

किसी ऐसी सेलर सेवा को अनुरोध भेजना जिस पर भरोसा नहीं किया जा सकता

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

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

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

किसी भरोसेमंद सेलर की सेवा से जवाब मिलना

बिडिंग और नीलामी सर्वर के बारे में जानकारी में बताया गया है कि जब किसी भरोसेमंद सेलर की सेवा को अनुरोध मिलता है, तो वह संदर्भ के हिसाब से विज्ञापन दिखाने के लिए, पार्टनर खरीदारों को कॉल करती है.

भरोसेमंद नहीं है, इसलिए सेलर की सेवा, एन्क्रिप्ट (सुरक्षित) किए गए adSelectionData और AuctionConfig को बिडिंग और नीलामी सर्वर की SellerFrontEnd सेवा पर भेजती है. यह सेवा, टीईई में चलती है.

Protected Audience नीलामी पूरी होने के बाद, SellerFrontEnd सेवा, नीलामी के नतीजे को एन्क्रिप्ट कर देती है. साथ ही, इसे अविश्वसनीय सेलर सेवा को जवाब के तौर पर दिखाती है.

भरोसेमंद नहीं की गई सेलर सेवा, डिवाइस पर एक रिस्पॉन्स भेजती है. इसमें, कॉन्टेक्स्ट के हिसाब से विज्ञापन और / या एन्क्रिप्ट (सुरक्षित) की गई Protected Audience नीलामी का नतीजा शामिल होता है.

रिस्पॉन्स मिलने पर, डिवाइस पर सेलर का विज्ञापन टेक्नोलॉजी कोड, रिस्पॉन्स में सिर्फ़ कॉन्टेक्स्ट के हिसाब से विज्ञापन का इस्तेमाल कर सकता है. अगर उसे लगता है कि Protected Audience का नतीजा पाने से ज़्यादा फ़ायदा होगा, तो वह PersistAdSelectionResult एपीआई को कॉल करके, Protected Audience के नतीजे को डिक्रिप्ट कर सकता है.

PersistAdSelectionResult API

Protected Audience के नतीजे को डिक्रिप्ट करने के लिए, सेलर की विज्ञापन टेक्नोलॉजी, दूसरे Protected Audience API persistAdSelectionResult को कॉल कर सकती है. एपीआई, नतीजे को डिक्रिप्ट करता है और AdSelectionOutcome दिखाता है. यह वही ऑब्जेक्ट है जो आज डिवाइस पर होने वाली नीलामी से दिखाया जाता है.

एपीआई को ऐक्सेस करने के लिए, कॉलर को Protected Audience API का ऐक्सेस चालू करना होगा और अपने मेनिफ़ेस्ट में ACCESS_ADSERVICES_CUSTOM_AUDIENCE की अनुमति तय करनी होगी.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

कॉल करने वाले को अनुरोध में यह जानकारी सेट करनी होगी:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: getAdSelectionData कॉल से जनरेट किया गया ऐसा आइडेंटिफ़ायर जिसका नतीजा, कॉलर को डिक्रिप्ट करना है.
2. seller: अनुरोध को पूरा करने से पहले, रजिस्ट्रेशन की जांच करने के लिए, सेलर के विज्ञापन टेक्नोलॉजी आइडेंटिफ़ायर को अनुरोध में सेट करना ज़रूरी है.
3. adSelectionResult: बिडिंग और नीलामी सर्वर से जनरेट किया गया, एन्क्रिप्ट (सुरक्षित) किया गया नीलामी का नतीजा, जिसे कॉल करने वाले को डिक्रिप्ट करना है.

AdSelectionOutcome response

अगर Protected Audience की मदद से विज्ञापन दिखाने की सुविधा का इस्तेमाल करके विज्ञापन दिखाने वाला कोई विजेता है, तो AdSelectionOutcome, विजेता विज्ञापन के रेंडर यूआरआई को दिखाता है.adSelectionResult को डिक्रिप्ट करने के बाद, रिपोर्टिंग डेटा को अंदरूनी तौर पर सेव किया जाता है. OutcomeReceiver.onResult() कॉलबैक, एक AdSelectionOutcome दिखाता है जिसमें ये चीज़ें शामिल होती हैं:

• URI: अगर Protected Audience के तहत विज्ञापन दिखाने की सुविधा का इस्तेमाल करके कोई विज्ञापन दिखाया जाता है, तो विज्ञापन दिखाने की सुविधा का इस्तेमाल करके दिखाए गए विज्ञापन का रेंडर यूआरएल दिखाया जाता है. अगर सुरक्षित ऑडियंस में कोई विजेता नहीं है, तो `Uri.EMPTY दिखाया जाता है.
• adSelectionId: इस सर्वर नीलामी से जुड़ा adSelectionId.

गड़बड़ियां, अपवाद, और गड़बड़ी ठीक करना

अगर अमान्य आर्ग्युमेंट, टाइम आउट या ज़्यादा संसाधन खर्च होने जैसी वजहों से, विज्ञापन चुनने के लिए डेटा जनरेशन की प्रोसेस पूरी नहीं हो पाती है, तो OutcomeReceiver.onError() कॉलबैक, AdServicesException को इन कामों के साथ उपलब्ध कराता है:

1. अगर getAdSelectionData को अमान्य आर्ग्युमेंट के साथ शुरू किया जाता है, तो AdServicesException, IllegalArgumentException को वजह के तौर पर दिखाता है.
2. अन्य सभी गड़बड़ियों के लिए, AdServicesException को IllegalStateException के तौर पर वजह के साथ दिखाया जाता है.

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

adSelectionData को एन्क्रिप्ट (सुरक्षित) किया जाता है, ताकि यह पक्का किया जा सके कि ट्रांज़िट में डेटा को सिर्फ़ PPAPI और भरोसेमंद सर्वर ऐक्सेस कर सकें.

डेटा को एन्क्रिप्ट करने के बावजूद, adSelectionData के साइज़ की वजह से डेटा लीक हो सकता है. adSelectionData के साइज़ में इन वजहों से अंतर हो सकता है:

1. डिवाइस पर मौजूद CustomAudience डेटा में बदलाव.
2. CustomAudience फ़िल्टर करने के लॉजिक में बदलाव.
3. getAdSelectionData कॉल के इनपुट में बदलाव.

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

इन लीक को मैनेज करने के लिए, हम getAdSelectionData एपीआई के सभी कॉल के लिए एक ही adSelectionData जनरेट करने वाले हैं. शुरुआती रिलीज़ में, डिवाइस पर मौजूद सभी CustomAudiences का इस्तेमाल adSelectionData बनाने के लिए किया जाता है. साथ ही, एन्क्रिप्ट किए गए पेलोड को साइज़ में होने वाले बदलावों को छिपाने के लिए पैड किया जाएगा. हम जनरेट किए गए adSelectionData पर, GetAdSelectionData इनपुट पैरामीटर के असर पर भी पाबंदी लगाएंगे.

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

साइज़ ऑप्टिमाइज़ेशन

विज्ञापन टेक्नोलॉजी क्लाइंट एसडीके को, adSelectionData के एन्क्रिप्ट किए गए बाइट को HTTP PUT/POST के संदर्भ कॉल में पैकेज करना चाहिए. यह कॉल, विज्ञापन टेक्नोलॉजी सर्वर को किया जाता है. adSelectionData के साइज़ को जितना हो सके उतना कम करना ज़रूरी है, ताकि अनुरोध और जवाब मिलने में लगने वाला समय और लागत कम हो. हालांकि, ऐसा करने से adSelectionData की उपयोगिता पर असर नहीं पड़ना चाहिए.

हम adSelectionData के साइज़ को कम करने के लिए, आने वाले वर्शन में इन ऑप्टिमाइज़ेशन को एक्सप्लोर और लागू करने की कोशिश करेंगे:

1. पेडिंग के साथ बकेट साइज़ के तय किए गए सेट में जनरेट किया गया पेलोड: हमारा सुझाव है कि जनरेट किए गए पेलोड के लिए, तय साइज़ की बकेट का इस्तेमाल करें. इससे, साइज़ में होने वाले बदलावों से होने वाले लीकेज को कम किया जा सकता है और कम साइज़ के पेलोड का इस्तेमाल किया जा सकता है. बकेट की संख्या कम रखने पर, उदाहरण के लिए, 7 से getAdSelectionData को हर कॉल पर 3 बिट से कम एन्ट्रॉपी लीक होगी.

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

2. खरीदार का कॉन्फ़िगरेशन: हम यह आकलन कर रहे हैं कि खरीदारों को हर खरीदार के लिए पेलोड कॉन्फ़िगरेशन सेट अप करने की सुविधा दी जा सकती है या नहीं. यह कॉन्फ़िगरेशन, यह पता लगाने में मददगार होगा कि खरीदार किन नीलामियों में शामिल होना चाहता है. अगर संभव हो, तो रजिस्टर करने के दौरान, खरीदार का विज्ञापन टेक्नोलॉजी पार्टनर एक एंडपॉइंट रजिस्टर कर सकता है. इससे, सुरक्षित ऑडियंस हर दिन नियमित अंतराल पर, पेलोड कॉन्फ़िगरेशन फ़ेच करेगी. इसके अलावा, निजता बनाए रखने वाले एपीआई, एक एपीआई को एक्सपोज़ करेंगे, ताकि खरीदार की विज्ञापन टेक्नोलॉजी इस एंडपॉइंट को रजिस्टर कर सकें.

   इसके बाद, इस कॉन्फ़िगरेशन का इस्तेमाल, हर getAdSelectionData अनुरोध के लिए जनरेट किए गए adSelectionData में खरीदार के योगदान का आकलन करने के लिए किया जाएगा.

   खरीदार के पेलोड कॉन्फ़िगरेशन की मदद से, खरीदार ये बता सकते हैं:

   1. सभी सेलर की सूची: Buyer CustomAudiences को पेलोड में सिर्फ़ तब जोड़ा जाएगा, जब अनुमति वाली सूची में शामिल सेलर ने getAdSelectionData कॉल शुरू किया हो. हम हर दिन, अनुमति वाली सूची को अप-टू-डेट रखने के लिए, पेलोड कॉन्फ़िगरेशन को फ़ेच करेंगे.
   2. हर सेलर के लिए साइज़ की सीमा: जब कोई सेलर नीलामी शुरू करता है, तो खरीदार यह तय कर सकता है कि पेलोड में कितना डेटा भेजा जाए. इसके लिए, वह हर सेलर के लिए साइज़ की सीमा तय कर सकता है. यह तब फ़ायदेमंद होगा, जब कोई खरीदार कुछ सेलर के ऑक्शन डेटा को प्रोसेस करने के लिए ज़्यादा संसाधनों का इस्तेमाल करना चाहता हो. SellerFrontendService, हर BuyerFrontendService को सिर्फ़ खरीदार से जुड़ा डेटा फ़ॉरवर्ड करता है. इसलिए, हर सेलर के लिए साइज़ की सीमा तय करके, खरीदार यह कंट्रोल कर सकता है कि सेलर की ओर से चलाई जाने वाली नीलामियों के लिए, बिडिंग और नीलामी सर्वर की BuyerFrontendService से कितना डेटा डाला और प्रोसेस किया जाए.

3. सेलर कॉन्फ़िगरेशन: हम हर सेलर के लिए नीलामी कॉन्फ़िगरेशन की संभावना का आकलन कर रहे हैं. इससे सेलर, नीलामी के पैरामीटर तय कर पाएंगे, ताकि वे पेलोड का साइज़ और नीलामी में हिस्सा लेने वाले लोगों को कंट्रोल कर सकें. अगर संभव हो, तो रजिस्टर करने के दौरान, सेलर की विज्ञापन टेक्नोलॉजी कंपनी उस एंडपॉइंट की जानकारी दे सकती है जहां से Protected Audience, हर सेलर के लिए ऑक्शन कॉन्फ़िगरेशन को नियमित अंतराल पर फ़ेच कर सके. इसके बाद, इस कॉन्फ़िगरेशन का इस्तेमाल, हर getAdSelectionData अनुरोध के लिए जनरेट किए गए adSelectionData के कॉम्पोनेंट और सीमाओं को तय करने के लिए किया जाएगा.

   खरीदार कॉन्फ़िगरेशन की तरह ही, हर सेलर कॉन्फ़िगरेशन की मदद से, सेलर यह तय कर सकते हैं कि नीलामी में उन्हें खरीदारों का कौनसा सेट दिखे. साथ ही, वे पेलोड के साइज़ में हर खरीदार के योगदान की सीमाएं तय कर सकते हैं.

   सेलर नीलामी कॉन्फ़िगरेशन की मदद से, सेलर ये बता सकते हैं:

   1. अनुमति वाले खरीदारों की सूची: किसी सेलर की ओर से शुरू की गई नीलामियों के लिए, सिर्फ़ अनुमति वाली सूची में शामिल खरीदार ही नीलामी के लिए कस्टम ऑडियंस का योगदान दे पाएंगे. सर्वर साइड पर मौजूद खरीदार की अनुमति वाली सूची के साथ, अनुमति वाली सूची को अप-टू-डेट रखने के लिए, नीलामी कॉन्फ़िगरेशन को हर दिन अपडेट करना होगा.
   2. हर खरीदार के लिए साइज़ की सीमा: सेलर, हर खरीदार के लिए साइज़ की सीमा तय कर सकते हैं, ताकि SellerFrontendService को भेजे जा रहे पेलोड में, हर खरीदार के अपलोड किए गए डेटा के साइज़ को कंट्रोल किया जा सके. अगर खरीदार, हर खरीदार के लिए तय किए गए साइज़ की सीमा से ज़्यादा डेटा मांगता है, तो उम्मीद के मुताबिक सीमा में डेटा पाने के लिए, खरीदार के पेलोड कॉन्फ़िगरेशन में सेट की गई कस्टम ऑडियंस की प्राथमिकता का इस्तेमाल किया जाएगा.
   3. हर खरीदार के लिए प्राथमिकता: इससे सेलर, हर खरीदार के लिए प्राथमिकता सेट कर सकते हैं. अगर पेलोड का साइज़, पेलोड के साइज़ की तय सीमा से ज़्यादा हो जाता है, तो खरीदार की प्राथमिकता का इस्तेमाल करके यह तय किया जाएगा कि पेलोड में किस खरीदार का डेटा रखना है.
   4. पेलोड के लिए साइज़ की ज़्यादा से ज़्यादा सीमा: अलग-अलग सेलर के पास, संसाधन का अलग-अलग बंटवारा हो सकता है. साथ ही, वे हर अनुरोध के लिए नीलामी के पेलोड के साइज़ की ज़्यादा से ज़्यादा सीमा सेट कर सकते हैं. फ़ाइल के साइज़ की तय सीमा, Protected Audience API के तय किए गए फ़िक्स साइज़ की बकेट के हिसाब से होगी.

4. कस्टम ऑडियंस में हुए बदलाव

   1. कस्टम ऑडियंस की प्राथमिकता तय करना: खरीदारों को कस्टम ऑडियंस में प्राथमिकता वाली वैल्यू तय करने की अनुमति दें. priority फ़ील्ड का इस्तेमाल, उन कस्टम ऑडियंस की पहचान करने के लिए किया जाएगा जिन्हें नीलामी में शामिल किया जाना चाहिए. ऐसा तब किया जाएगा, जब खरीदार की कस्टम ऑडियंस का सेट, हर सेलर या हर खरीदार के साइज़ की सीमाओं से ज़्यादा हो. कस्टम ऑडियंस में प्राथमिकता की कोई वैल्यू न होने पर, डिफ़ॉल्ट रूप से वैल्यू 0.0 पर सेट हो जाएगी.

5. पेलोड डेटा में बदलाव

   1. पेलोड में भेजे गए डेटा को कम करना: बिडिंग और नीलामी सेवाओं के लिए, पेलोड को ऑप्टिमाइज़ करना में बताया गया है कि ज़्यादा पेलोड, कस्टम ऑडियंस ads डेटा, उपयोगकर्ता बिडिंग सिग्नल, और Android सिग्नल से जनरेट होता है. ज़्यादा पेलोड को कम करने के लिए:
      1. क्लाइंट को पेलोड में विज्ञापन ऑब्जेक्ट के बजाय, विज्ञापन रेंडर आईडी भेजने के लिए कहना.
      2. क्लाइंट, पेलोड में कोई विज्ञापन डेटा न भेजे.
      3. क्लाइंट पेलोड में उपयोगकर्ता बिडिंग सिग्नल नहीं भेजना.

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

इंतज़ार के समय को ऑप्टिमाइज़ करना

सर्वर नीलामियों की सुविधा को बेहतर बनाने के लिए, हमें यह पक्का करना होगा कि getAdSelectionData एपीआई और persistAdSelectionResult एपीआई के लिए हर कॉल में इंतज़ार का समय कम हो. हमारा मकसद 2023 में एपीआई के लिए सुविधाएं उपलब्ध कराना है. हालांकि, हमारी अगली रिलीज़ में एपीआई के लिए, इंतज़ार का समय और ऑप्टिमाइज़ेशन पर फ़ोकस किया जाएगा.

हम इंतज़ार का समय तय सीमा में रखने के लिए, इन रणनीतियों पर काम कर रहे हैं:

1. हर सेलर के लिए, Protected Audience का डेटा पहले से जनरेट करना: सेलर की नीलामी का कॉन्फ़िगरेशन और खरीदार के पेलोड का कॉन्फ़िगरेशन, काफ़ी समय (रोज़) तक स्थिर रहेगा. इसलिए, प्लैटफ़ॉर्म ज़रूरी शर्तें पूरी करने वाले Protected Audience का डेटा पहले से कैलकुलेट और सेव कर सकता है.

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

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

   इसके बाद, Protected Audience का डेटा पहले से जनरेट करने के लिए,

   1. सेलर, Protected Audience का डेटा पहले से जनरेट करने के लिए ऑप्ट-इन करता है.
   2. ऐसे खरीदार जो किसी खास सेलर की शुरू की गई नीलामी में हिस्सा ले सकते हैं.
   3. हर खरीदार के लिए कस्टम ऑडियंस की पहचान करना. ये ऑडियंस, इनके आधार पर पैकेट का हिस्सा होंगी:
      1. सेलर कॉन्फ़िगरेशन में तय की गई, हर खरीदार के लिए साइज़ की सीमाएं, हर खरीदार के लिए प्राथमिकता, और साइज़ की ज़्यादा से ज़्यादा सीमाएं,
      2. हर सेलर के लिए साइज़ की सीमा, खरीदार के कॉन्फ़िगरेशन में तय की गई कस्टम ऑडियंस की प्राथमिकता.

2. नेगेटिव फ़िल्टरिंग को पहले से लागू करना: अगर सेलर चाहे, तो प्लैटफ़ॉर्म, adSelectionData को पहले से कैलकुलेट कर सकता है. इसके लिए, वह सुरक्षित ऑडियंस का डेटा पहले से जनरेट करेगा और ज़रूरी getAdSelectionData कॉल पर नेगेटिव फ़िल्टरिंग लागू करेगा. इससे, सेलर को नेगेटिव फ़िल्टरिंग में पुराने प्रॉडक्ट को स्वीकार करते हुए, रिस्पॉन्स में लगने वाले समय को कम करने में मदद मिलेगी.

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

3. एक से ज़्यादा नीलामियों के लिए पेलोड का हिसाब लगाना: कुछ मामलों में, डेटा के पुराने होने की कीमत पर, इंतज़ार का समय कम करने वाला एपीआई इस्तेमाल करना बेहतर हो सकता है. इसे उपलब्ध कराने के लिए, प्लैटफ़ॉर्म में एक ऐसा एपीआई शुरू किया जा सकता है जो पूरे पेलोड का हिसाब लगा सके. साथ ही, कॉल करने वाले को हिसाब लगाए गए पेलोड का रेफ़रंस दे सके.

   getAdSelectionData पर बाद के कॉल के लिए, कॉल करने वाला व्यक्ति पहले से कैलकुलेट किए गए पेलोड का रेफ़रंस दे सकता है, ताकि उसका इस्तेमाल adSelectionData जनरेट करने के लिए किया जा सके.

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

बुरे बर्ताव को कम करना और उसकी पहचान करना

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

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

जोखिम कम करना

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

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

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

नुकसान पहुंचाने वाली इकाइयों की पहचान करना

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

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