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

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

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

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

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

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

डिवाइस पर मौजूद सेलर की विज्ञापन टेक्नोलॉजी को नीलामी चलाने के लिए, इन सुविधाओं को इंटिग्रेट और डेवलप करना होगा:

1. सर्वर ऑक्शन में हिस्सा लेने वाले सेलर के लिए डेटा इकट्ठा करना और उसे एन्क्रिप्ट (सुरक्षित) करना: विज्ञापन से जुड़ी टेक्नोलॉजी को एन्क्रिप्ट (सुरक्षित) किए गए पेलोड को पाने के लिए, getAdSelectionData API को कॉल करना चाहिए.
2. Send request to Untrusted Seller Service Send: HTTP POST या PUT अनुरोध में, getAdSelectionData API से जनरेट किया गया एन्क्रिप्ट (सुरक्षित) किया गया पेलोड होता है. यह अनुरोध, भरोसेमंद न मानी जाने वाली सेलर सेवा और भरोसेमंद न मानी जाने वाली सेलर सेवा को कॉन्टेक्स्ट के हिसाब से नतीजे जनरेट करने के लिए ज़रूरी डेटा को भेजा जाता है.
3. Receive response from Untrusted Seller Service: Response from untrusted seller service would contain the encrypted protected audience auction result and the contextual auction result.
4. Protected Audience की नीलामी के जवाब को डिक्रिप्ट करना और नीलामी का नतीजा पाना: Protected Audience की नीलामी के नतीजे को डिक्रिप्ट करने के लिए, सेलर की विज्ञापन टेक्नोलॉजी को persistAdSelectionResult API को कॉल करना चाहिए. persistAdSelectionResult से जनरेट हुए नतीजे से, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों को यह तय करने में मदद मिलेगी कि कॉन्टेक्स्ट के हिसाब से दिखाए जाने वाले विज्ञापन या Protected Audience विज्ञापन में से किसने नीलामी जीती. साथ ही, अगर लागू हो, तो नीलामी जीतने वाले Protected Audience विज्ञापन का यूआरआई भी पता चलेगा.

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

हमारा लक्ष्य, डिवाइस पर होने वाली नीलामी के लिए उपलब्ध सभी सुविधाओं को सपोर्ट करना है. सर्वर ऑक्शन में इन सुविधाओं को उपलब्ध कराने की समयसीमा यहां दी गई है:

Protected Audience API का इस्तेमाल करके सर्वर साइड ऑक्शन चलाना

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

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

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

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

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

GetAdSelectionDataOutcome

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

1. adSelectionId: यह getAdSelectionData के इस इनवोकेशन की पहचान करने के लिए, ओपेक पूर्णांक होता है. विज्ञापन टेक्नोलॉजी क्लाइंट को इस adSelectionId वैल्यू को सेव करके रखना चाहिए, क्योंकि यह getAdSelectionData कॉल के लिए पॉइंटर के तौर पर काम करती है. इस आइडेंटिफ़ायर की ज़रूरत persistAdSelectionResult API को होती है, ताकि वह बिडिंग और नीलामी सर्वर से मिले नीलामी के नतीजे को डिक्रिप्ट कर सके. इसकी ज़रूरत reportImpression और reportEvent API को भी होती है.
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,
...
})

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

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

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

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

Protected Audience ऑक्शन पूरा होने के बाद, SellerFrontEnd सेवा ऑक्शन के नतीजे को एन्क्रिप्ट (सुरक्षित) करती है. इसके बाद, इसे जवाब के तौर पर, भरोसेमंद न मानी जाने वाली सेलर सेवा को भेजती है.

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

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

PersistAdSelectionResult API

Protected Audience API के नतीजे को डिक्रिप्ट करने के लिए, सेलर की विज्ञापन टेक्नोलॉजी, दूसरे 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 रिस्पॉन्स

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

• URI: अगर Protected Audience का कोई विज्ञापन जीत जाता है, तो जीतने वाले विज्ञापन के लिए विज्ञापन रेंडर यूआरएल दिखाया जाता है. अगर 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 API को किए जाने वाले सभी कॉल के लिए, एक ही adSelectionData जनरेट करने का प्लान बना रहे हैं. शुरुआती रिलीज़ में, डिवाइस पर मौजूद सभी CustomAudiences का इस्तेमाल adSelectionData बनाने के लिए किया जाता है. साथ ही, एन्क्रिप्ट (सुरक्षित) किए गए पेलोड को पैड किया जाएगा, ताकि साइज़ में होने वाले बदलावों को छिपाया जा सके. हम GetAdSelectionData जनरेट करने पर, GetAdSelectionData इनपुट पैरामीटर के असर को भी सीमित करेंगे.adSelectionData

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

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

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

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

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

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

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

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

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

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

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

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

   सेलर ऑक्शन कॉन्फ़िगरेशन की मदद से, सेलर ये काम कर पाएंगे:

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

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

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

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

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

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

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

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

हम लेटेन्सी को तय सीमा के अंदर रखने के लिए, इन रणनीतियों पर काम कर रहे हैं:

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

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

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

   इसके बाद, Protected Audience का डेटा पहले से जनरेट करने की सुविधा इन पर आधारित होगी

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

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

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

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

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

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

गलत इस्तेमाल को कम करना और उसकी पहचान करना

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

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

गड़बड़ी की गंभीरता को कम करना

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

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

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

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

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

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