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

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

Protected Audience API से जुड़ी नीलामी का फ़्लो.

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

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

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

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

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

1. सर्वर नीलामी में हिस्सा लेने वाले सेलर के लिए डेटा इकट्ठा करना और उसे एन्क्रिप्ट करना: एन्क्रिप्ट किए गए पेलोड को पाने के लिए, विज्ञापन टेक्नोलॉजी को getAdSelectionData API को कॉल करना चाहिए.
2. भरोसेमंद नहीं मानी जाने वाली सेलर सेवा को अनुरोध भेजें: HTTP POST या PUT का अनुरोध, जिसमें getAdSelectionData एपीआई से जनरेट किया गया एन्क्रिप्ट किया गया पेलोड शामिल होता है. यह अनुरोध, भरोसेमंद नहीं मानी जाने वाली सेलर सेवा को भेजा जाता है. साथ ही, इसमें वह डेटा भी शामिल होता है जो संदर्भ के हिसाब से नतीजे जनरेट करने के लिए, भरोसेमंद नहीं मानी जाने वाली सेलर सेवा को ज़रूरी होता है.
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 की पहली तिमाही
Private Aggregation इंटिग्रेशन	लागू नहीं	लागू नहीं	लागू नहीं	साल 2024 की तीसरी तिमाही

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 का नतीजा पाने से ज़्यादा फ़ायदा होगा, तो वह 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

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

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

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

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

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

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

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

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

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

   इसके बाद, सुरक्षित ऑडियंस का डेटा पहले से जनरेट करने के लिए,

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

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

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

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

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

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

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

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

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

जोखिम कम करना

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

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

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

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

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

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