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

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

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

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

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

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

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

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

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

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

	उपयोगकर्ता के डिवाइस पर नीलामी		सर्वर नीलामी
	डेवलपर के लिए झलक	बीटा वर्शन	डेवलपर के लिए झलक	बीटा वर्शन
इवेंट-लेवल पर जीत की रिपोर्ट	साल 2023 की पहली तिमाही	साल 2023 की तीसरी तिमाही	लागू नहीं	साल 2023 की चौथी तिमाही
वॉटरफ़ॉल मीडिएशन	साल 2023 की पहली तिमाही	साल 2023 की चौथी तिमाही	लागू नहीं	24वीं तिमाही की पहली तिमाही
फ़्रीक्वेंसी कैप फ़िल्टर करना	साल 2023 की दूसरी तिमाही	साल 2023 की तीसरी तिमाही	लागू नहीं	साल 2023 की चौथी तिमाही
फ़िल्टर करने के लिए, काम के विज्ञापनों को विज्ञापन चुनने के वर्कफ़्लो पर पास करना	साल 2023 की दूसरी तिमाही	साल 2024 की पहली तिमाही	लागू नहीं	लागू नहीं
इंटरैक्शन रिपोर्टिंग	साल 2023 की दूसरी तिमाही	साल 2023 की तीसरी तिमाही	लागू नहीं	साल 2023 की चौथी तिमाही
कस्टम ऑडियंस डेलिगेशन में शामिल होना	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही	लागू नहीं	साल 2023 की चौथी तिमाही
बिना सीपीएम बिलिंग	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही
डीबग रिपोर्टिंग	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही
ओपन बिडिंग मीडिएशन	लागू नहीं	लागू नहीं	लागू नहीं	साल 2024 की पहली तिमाही
ऐप्लिकेशन इंस्टॉल विज्ञापन फ़िल्टर करना	साल 2023 की दूसरी तिमाही	साल 2024 की पहली तिमाही	लागू नहीं	साल 2024 की पहली तिमाही
करंसी मैनेजमेंट	लागू नहीं	लागू नहीं	लागू नहीं	साल 2024 की पहली तिमाही
K-anon इंटिग्रेशन	लागू नहीं	साल 2024 की पहली तिमाही	लागू नहीं	साल 2024 की पहली तिमाही
निजी एग्रीगेशन इंटिग्रेशन	लागू नहीं	लागू नहीं	लागू नहीं	साल 2024 की तीसरी तिमाही

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

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

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

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

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

गड़बड़ियां, अपवाद, और गड़बड़ी को मैनेज करना

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

1. अगर getAdSelectionData की शुरुआत अमान्य आर्ग्युमेंट के साथ की जाती है, तो AdServicesException` की वजह से एक legalArgument चेहरे से जुड़ी जानकारी मिलती है.
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 API को कॉल करके, Protected Audience से जुड़े नतीजे को डिक्रिप्ट करने का विकल्प चुन सकता है.

PersistAdSelectionresults 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: एन्क्रिप्ट (सुरक्षित) की गई नीलामी का नतीजा, बिडिंग और नीलामी सर्वर से जनरेट हुआ है, जिसे कॉलर डिक्रिप्ट करना चाहता है.

AdSelectionresults जवाब

अगर कोई 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-बिट लीक की चर्चा में बताया गया है. यहां, 1-बिट लीक पर लगने वाले कई खतरों को भी कम किया जा सकता है.

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

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

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

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

adSelectionData का साइज़ कम करने के लिए, हम आने वाली रिलीज़ में इन ऑप्टिमाइज़ेशन को एक्सप्लोर करने के साथ-साथ, इन्हें शामिल करने की योजना बना रहे हैं:

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

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

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

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

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

   1. अनुमति वाले सेलर की सूची: खरीदार की कस्टम ऑडियंस को पेलोड में सिर्फ़ तब जोड़ा जाएगा, जब अनुमति वाली सूची में शामिल कोई सेलर 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 API और persistAdSelectionResult API में हर कॉल के लिए इंतज़ार का समय कम हो. हमारा लक्ष्य 2023 में एपीआई के लिए नई सुविधाएं उपलब्ध कराना है. इसके बाद, हम एपीआई के लिए एपीआई को ऑप्टिमाइज़ करने और इंतज़ार के समय के मानदंड पर फ़ोकस करेंगे.

इंतज़ार के समय को स्वीकार की जाने वाली सीमाओं के अंदर रखने के लिए, हम ये रणनीतियां बना रहे हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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

समस्या को कम करने की प्रोसेस

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

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

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

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

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

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