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

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

Protected Audience का ऑक्शन फ़्लो.

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

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

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

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

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

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

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

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

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

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

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

GetAdSelectionDataRequest

कॉल करने वाले (कॉलर) को अनुरोध में seller फ़ील्ड सेट करना होगा, क्योंकि इसका इस्तेमाल अनुरोध भेजने से पहले रजिस्ट्रेशन की जांच करने के लिए किया जाता है.

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

अनुरोध की पुष्टि होने के बाद, डिवाइस पर मौजूद खरीदार के डेटा को 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` इसकी वजह PostalArgument4 की वजह से दिखाता है.
2. दूसरी सभी गड़बड़ियों के लिए AdServicesException मिलता है, जिसकी वजह IllegalStateException होती है.

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

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

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

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

सेलर की सेवा देने वाली किसी ऐसी सेवा से जवाब पाना जिस पर भरोसा न किया जा सके

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

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

सुरक्षित ऑडियंस की नीलामी पूरी होने पर, SellerFrontEnd सेवा, नीलामी के नतीजे को एन्क्रिप्ट (सुरक्षित) करती है और गैर-भरोसेमंद सेलर सेवा के जवाब के तौर पर दिखाती है.

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

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

PersistAdSelectionresults एपीआई

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

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

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

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

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

   सुरक्षित ऑडियंस का डेटा पहले से जनरेट करना, इन बातों पर आधारित होगा

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

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

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

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

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

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

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

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

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

गड़बड़ी को कम करना

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

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

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

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

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

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