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

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

Protected Audience API की नीलामी का फ़्लो.

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

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

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

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

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

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

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

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

GetAdSelectionDataresults

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

1. adSelectionId: इसकी पहचान करने के लिए एक ओपेक पूर्णांक getAdSelectionData को शुरू करना. AdTech क्लाइंट को इसे जारी रखना चाहिए 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` वजह के तौर पर legalArgument चेहरे से जुड़ी जानकारी देता है.
2. अन्य सभी त्रुटियों को AdServicesException वजह के तौर पर IllegalStateException.

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

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

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

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

किसी गैर-भरोसेमंद विक्रेता सेवा से जवाब पाना

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

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

Protected Audience से जुड़ी नीलामी की प्रोसेस पूरी होने पर, SellerFrontEnd सेवा नीलामी के नतीजे को एन्क्रिप्ट करता है और गैर-भरोसेमंद सेलर को जवाब के तौर पर वापस करता है सेवा.

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

जवाब मिलने के बाद, डिवाइस पर मौजूद सेलर का विज्ञापन टेक्नोलॉजी कोड संदर्भ के हिसाब से विज्ञापन का इस्तेमाल सिर्फ़ तब करें, जब आपको लगता है कि Protected Audience से जुड़ा नतीजा पाने में, इंक्रीमेंटल वैल्यू मिलती है, तो यह PersistAdSelectionResult पर कॉल करके, 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) {}

PersistAdSelectionresultsRequest

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

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-बिट लीक पर लागू होने वाली पाबंदियां भी यहां लागू होती हैं.

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

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

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

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

हम Google Search में, इन ऑप्टिमाइज़ेशन के बारे में बताएंगे. साथ ही, adSelectionData का साइज़ कम करने के लिए, आने वाली रिलीज़:

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

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

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

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

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

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

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

   खरीदार कॉन्फ़िगरेशन की तरह, हर विक्रेता कॉन्फ़िगरेशन की मदद से विक्रेता यह तय करें कि वे नीलामी में खरीदारों का कौनसा समूह देखना चाहते हैं और का इस्तेमाल करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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