सुरक्षित ऐप्लिकेशन सिग्नल, जो ऐप्लिकेशन इंस्टॉल करने का बढ़ावा देने वाले विज्ञापनों के साथ काम करते हैं

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

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

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

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

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

1. Protected App Signals API: यह एपीआई, विज्ञापन टेक्नोलॉजी की मदद से बनाई गई उन सुविधाओं को सेव और बनाए रखने के लिए है जो उपयोगकर्ता की संभावित दिलचस्पियों के बारे में बताती हैं. विज्ञापन टेक्नोलॉजी, हर ऐप्लिकेशन के लिए अपने-आप तय होने वाले इवेंट सिग्नल सेव करती हैं. जैसे, ऐप्लिकेशन इंस्टॉल, पहली बार खोलना, उपयोगकर्ता की कार्रवाइयां (गेम में लेवल, उपलब्धियां), खरीदारी गतिविधियां या ऐप्लिकेशन में बिताया गया समय. डेटा लीक होने से बचाने के लिए, सिग्नल को डिवाइस पर लिखा और सेव किया जाता है. साथ ही, इन्हें सिर्फ़ उस विज्ञापन टेक्नोलॉजी लॉजिक के लिए उपलब्ध कराया जाता है जिसने सुरक्षित माहौल में चल रही सुरक्षित नीलामी के दौरान, दिए गए सिग्नल को सेव किया था.
2. विज्ञापन चुनने वाला एपीआई: यह भरोसेमंद एक्सीक्यूशन एनवायरमेंट (टीईई) में चल रही सुरक्षित नीलामी को कॉन्फ़िगर और लागू करने के लिए एपीआई उपलब्ध कराता है. यहां विज्ञापन टेक्नोलॉजी, विज्ञापन के संभावित विकल्पों को वापस लाती है, अनुमान लगाती है, बिड का हिसाब लगाती है, और "विजेता" विज्ञापन चुनने के लिए स्कोरिंग करती है. इसके लिए, यह सुरक्षित ऐप्लिकेशन सिग्नल और पब्लिशर की दी गई रीयल-टाइम कॉन्टेक्स्ट की जानकारी, दोनों का इस्तेमाल करती है.

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

• सिग्नल क्यूरेटर: जब उपयोगकर्ता मोबाइल ऐप्लिकेशन का इस्तेमाल करते हैं, तो विज्ञापन टेक्नोलॉजी, विज्ञापन टेक्नोलॉजी के तय किए गए ऐप्लिकेशन इवेंट को सेव करके सिग्नल को क्यूरेट करती है. ऐसा, उपयोगकर्ताओं को काम के विज्ञापन दिखाने के लिए, Protected App Signals API का इस्तेमाल करके किया जाता है. ये इवेंट, कस्टम ऑडियंस की तरह ही, डिवाइस पर सुरक्षित स्टोरेज में सेव किए जाते हैं. साथ ही, इन्हें डिवाइस से भेजे जाने से पहले एन्क्रिप्ट (सुरक्षित) किया जाता है. ऐसा इसलिए किया जाता है, ताकि सिर्फ़ ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट में चल रही बिडिंग और नीलामी की सेवाएं, इन्हें डिक्रिप्ट (सुरक्षित) कर सकें. साथ ही, इनका इस्तेमाल करके विज्ञापनों के लिए बिडिंग और स्कोरिंग की जा सके.
• सिग्नल को कोड में बदलना: सिग्नल, शेड्यूल किए गए समय पर तैयार किए जाते हैं. Android बैकग्राउंड जॉब, इस लॉजिक को डिवाइस पर एन्क्रिप्ट (सुरक्षित) करने के लिए लागू करता है. इससे, सुरक्षित ऐप्लिकेशन सिग्नल का पेलोड जनरेट होता है. इसका इस्तेमाल, सुरक्षित नीलामी के दौरान विज्ञापन चुनने के लिए, रीयल-टाइम में किया जा सकता है. नीलामी के लिए भेजे जाने तक, पेलोड को डिवाइस पर सुरक्षित तरीके से सेव किया जाता है.
• विज्ञापन चुनना: उपयोगकर्ता के लिए काम के विज्ञापन चुनने के लिए, सेलर SDK टूल, Protected App सिग्नल का एन्क्रिप्ट किया गया पेलोड भेजता है और Protected ऑक्शन को कॉन्फ़िगर करता है. नीलामी में, खरीदार का कस्टम लॉजिक, पब्लिशर से मिले कॉन्टेक्स्ट के हिसाब से डेटा (आम तौर पर, ओपन-आरटीबी विज्ञापन अनुरोध में शेयर किया जाने वाला डेटा) के साथ-साथ Protected ऐप्लिकेशन सिग्नल तैयार करता है. ऐसा, विज्ञापन चुनने के लिए बनाई गई सुविधाओं (विज्ञापन वापस पाना, अनुमान लगाना, और बिड जनरेट करना) को इंजीनियर करने के लिए किया जाता है. Protected Audience की तरह ही, खरीदार Protected Auction में फ़ाइनल स्कोरिंग के लिए, विज्ञापनों को सेलर को सबमिट करते हैं.
  • विज्ञापन वापस पाना: उपयोगकर्ता की दिलचस्पी के हिसाब से सुविधाओं को बेहतर बनाने के लिए, खरीदार, Protected App सिग्नल और पब्लिशर से मिले कॉन्टेक्स्ट के हिसाब से डेटा का इस्तेमाल करते हैं. इन सुविधाओं का इस्तेमाल, टारगेटिंग की ज़रूरी शर्तें पूरी करने वाले विज्ञापनों से मैच करने के लिए किया जाता है. बजट में न आने वाले विज्ञापनों को फ़िल्टर कर दिया जाता है. इसके बाद, बिडिंग के लिए सबसे ज़्यादा k विज्ञापन चुने जाते हैं.
  • बिडिंग: खरीदारों का कस्टम बिडिंग लॉजिक, पब्लिशर से मिले कॉन्टेक्स्ट के हिसाब से डेटा और Protected App सिग्नल को तैयार करता है. इससे, ऐसी सुविधाएं तैयार की जाती हैं जिनका इस्तेमाल, खरीदार के मशीन लर्निंग मॉडल के इनपुट के तौर पर किया जाता है. इन सुविधाओं की मदद से, निजता बनाए रखने की भरोसेमंद सीमाओं के अंदर, अनुमान लगाने और संभावित विज्ञापनों पर बिडिंग करने में मदद मिलती है. इसके बाद, खरीदार अपना चुना गया विज्ञापन, सेलर को लौटा देगा.
  • सेलर को मिलने वाले पॉइंट: सेलर के कस्टम स्कोरिंग लॉजिक से, हिस्सा लेने वाले खरीदारों के सबमिट किए गए विज्ञापनों को स्कोर मिलता है. साथ ही, रेंडर करने के लिए ऐप्लिकेशन में वापस भेजे जाने वाले विज्ञापन को चुना जाता है.
• रिपोर्टिंग: नीलामी में हिस्सा लेने वाले लोगों को, जीतने और हारने से जुड़ी रिपोर्ट मिलती हैं. हम मॉडल ट्रेनिंग के लिए, जीत की रिपोर्ट में डेटा शामिल करने के लिए, निजता बनाए रखने के तरीकों को एक्सप्लोर कर रहे हैं.

टाइमलाइन

Protected App Signals को क्यूरेट करना

सिग्नल, किसी ऐप्लिकेशन में उपयोगकर्ता के अलग-अलग इंटरैक्शन का प्रतिनिधित्व करता है. विज्ञापन टेक्नोलॉजी से यह तय किया जाता है कि ये इंटरैक्शन, काम के विज्ञापन दिखाने के लिए कितने फ़ायदेमंद हैं. ऐप्लिकेशन या इंटिग्रेट किया गया SDK टूल, उपयोगकर्ता की गतिविधि के आधार पर विज्ञापन टेक्नोलॉजी से तय किए गए सुरक्षित ऐप्लिकेशन सिग्नल को सेव या मिटा सकता है. जैसे, ऐप्लिकेशन खोलने, उपलब्धियों, खरीदारी गतिविधि या ऐप्लिकेशन में बिताए गए समय के आधार पर. सुरक्षित ऐप्लिकेशन सिग्नल, डिवाइस पर सुरक्षित तरीके से सेव किए जाते हैं. साथ ही, डिवाइस से भेजे जाने से पहले उन्हें एन्क्रिप्ट (सुरक्षित) कर दिया जाता है. ऐसा इसलिए किया जाता है, ताकि बिडिंग और नीलामी की सेवाएं, विज्ञापनों के लिए बिडिंग और स्कोरिंग करने के लिए, उन्हें डिक्रिप्ट (सुरक्षित से सामान्य में बदलना) कर सकें. इसके लिए, यह ज़रूरी है कि ये सेवाएं भरोसेमंद एक्सीक्यूशन एनवायरमेंट में चल रही हों और इनमें सुरक्षा और निजता से जुड़ी ज़रूरी सेटिंग मौजूद हों. Custom Audience API की तरह ही, किसी डिवाइस पर सेव किए गए सिग्नल को ऐप्लिकेशन या SDK टूल पढ़ या जांच नहीं सकते. सिग्नल की वैल्यू पढ़ने के लिए कोई एपीआई नहीं है. साथ ही, एपीआई को इस तरह से डिज़ाइन किया गया है कि सिग्नल की मौजूदगी का पता न चल पाए. विज्ञापन टेक्नोलॉजी के कस्टम लॉजिक के पास, चुने गए सिग्नल का सुरक्षित ऐक्सेस होता है. इससे, ऐसी सुविधाएं तैयार की जा सकती हैं जो सुरक्षित नीलामी में विज्ञापन चुनने के आधार के तौर पर काम करती हैं.

Protected App Signals API

Protected App Signals API, कस्टम ऑडियंस के लिए इस्तेमाल किए जाने वाले तरीके की तरह ही, किसी दूसरे को अनुमति देने के तरीके का इस्तेमाल करके सिग्नल मैनेज करता है. Protected App Signals API, सिग्नल को एक स्केलर वैल्यू या टाइम सीरीज़ के तौर पर स्टोर करने की सुविधा देता है. टाइम-सीरीज़ सिग्नल का इस्तेमाल, उपयोगकर्ता के सेशन की अवधि जैसी चीज़ों को सेव करने के लिए किया जा सकता है. टाइम सीरीज़ सिग्नल, 'पहले आओ, पहले पाओ' नियम का इस्तेमाल करके, किसी तय अवधि को लागू करने की सुविधा देते हैं. स्केलर सिग्नल या टाइम सीरीज़ सिग्नल के हर एलिमेंट का डेटा टाइप, बाइट कलेक्शन होता है. हर वैल्यू को, सिग्नल को स्टोर करने वाले ऐप्लिकेशन के पैकेज के नाम और स्टोर सिग्नल एपीआई कॉल के बनाए जाने के टाइमस्टैंप के साथ बेहतर बनाया जाता है. यह अतिरिक्त जानकारी, सिग्नल कोड करने वाले JavaScript में उपलब्ध है. इस उदाहरण में, किसी विज्ञापन टेक्नोलॉजी के मालिकाना हक वाले सिग्नल का स्ट्रक्चर दिखाया गया है:

इस उदाहरण में, adtech1.com से जुड़े स्केलर सिग्नल और टाइम सीरीज़ सिग्नल को दिखाया गया है:

• Base64 वैल्यू की "A1c" और वैल्यू "c12Z" वाली स्केलर सिग्नल. सिग्नल स्टोर को 1 जून 2023 को com.google.android.game_app ने ट्रिगर किया है.
• "dDE" कुंजी वाले सिग्नल की सूची, जिसे दो अलग-अलग ऐप्लिकेशन ने बनाया है.

विज्ञापन टेक्नोलॉजी विशेषज्ञों को डिवाइस पर सिग्नल सेव करने के लिए, कुछ जगह दी जाती है. सिग्नल का एक ज़्यादा से ज़्यादा टीटीएल होगा, जिसे तय करना होगा.

अगर सिग्नल जनरेट करने वाले ऐप्लिकेशन को अनइंस्टॉल कर दिया जाता है, Protected App Signals API का इस्तेमाल करने से ब्लॉक कर दिया जाता है या उपयोगकर्ता ने ऐप्लिकेशन का डेटा मिटा दिया है, तो Protected App Signals को स्टोरेज से हटा दिया जाता है.

Protected App Signals API में ये चीज़ें शामिल होती हैं:

• सिग्नल जोड़ने, अपडेट करने या हटाने के लिए, Java और JavaScript API.
• सेव किए गए सिग्नल को प्रोसेस करने के लिए JavaScript API, ताकि उन्हें रीयल टाइम में ज़्यादा सुविधाएं देने के लिए तैयार किया जा सके. ऐसा, ट्रस्टेड एक्सीक्यूशन एनवायरमेंट (टीईई) में चल रही सुरक्षित नीलामी के दौरान किया जाता है.

सिग्नल जोड़ना, अपडेट करना या हटाना

विज्ञापन टेक्नोलॉजी विशेषज्ञ, fetchSignalUpdates() API की मदद से सिग्नल जोड़ सकते हैं, उन्हें अपडेट कर सकते हैं या हटा सकते हैं. यह एपीआई, Protected Audience कस्टम ऑडियंस के ऐक्सेस को किसी दूसरे को देने की सुविधा की तरह ही काम करता है.

सिग्नल जोड़ने के लिए, उन खरीदार विज्ञापन टेक्नोलॉजी कंपनियों को, डिवाइस पर मौजूद विज्ञापन टेक्नोलॉजी कंपनियों के साथ मिलकर काम करना होगा जिनके ऐप्लिकेशन में SDK टूल मौजूद नहीं है. जैसे, मोबाइल मेज़रमेंट पार्टनर (एमएमपी) और सप्लाई-साइड प्लैटफ़ॉर्म (एसएसपी). Protected App Signals API का मकसद, विज्ञापन टेक्नोलॉजी से जुड़ी इन कंपनियों की मदद करना है. इसके लिए, यह एपीआई Protected App Signal को मैनेज करने के लिए आसान समाधान उपलब्ध कराता है. साथ ही, यह डिवाइस पर कॉल करने वालों को, खरीदारों की ओर से Protected App Signal बनाने की सुविधा देता है. इस प्रोसेस को fetchSignalUpdates() एपीआई का इस्तेमाल करके, अनुमति देना कहा जाता है. fetchSignalUpdates() यूआरआई लेता है और सिग्नल अपडेट की सूची दिखाता है. उदाहरण के लिए, fetchSignalUpdates(), दिए गए यूआरआई पर एक जीईटी अनुरोध जारी करता है, ताकि वह अपडेट की सूची हासिल कर सके और उसे लोकल सिग्नल स्टोरेज पर लागू कर सके. खरीदार के मालिकाना हक वाला यूआरएल एंडपॉइंट, निर्देशों की JSON सूची के साथ जवाब देता है.

ये JSON कमांड इस्तेमाल किए जा सकते हैं:

• put: यह किसी दी गई कुंजी के लिए स्केलर वैल्यू डालता है या उसे बदल देता है.
• put_if_not_present: अगर पहले से कोई वैल्यू सेव नहीं है, तो दी गई कुंजी के लिए स्केलर वैल्यू डालता है. उदाहरण के लिए, यह विकल्प किसी उपयोगकर्ता के लिए एक्सपेरिमेंट आईडी सेट करने और किसी दूसरे ऐप्लिकेशन से पहले से सेट किए गए आईडी को बदलने से बचने के लिए मददगार हो सकता है.
• append: यह दिए गए कीवर्ड से जुड़ी टाइम सीरीज़ में एक एलिमेंट जोड़ता है. maxSignals पैरामीटर, टाइम सीरीज़ में सिग्नल की ज़्यादा से ज़्यादा संख्या बताता है. अगर साइज़ तय सीमा से ज़्यादा हो जाता है, तो पहले के एलिमेंट हटा दिए जाते हैं. अगर कुंजी में स्केलर वैल्यू है, तो उसे अपने-आप टाइम सीरीज़ में बदल दिया जाता है.
• remove: यह दिए गए पासकोड से जुड़ा कॉन्टेंट हटाता है.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

सभी कुंजियों और वैल्यू को Base64 में दिखाया जाता है.

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

सेव किए गए सिग्नल, फ़ेच करने का अनुरोध करने वाले ऐप्लिकेशन और अनुरोध का जवाब देने वाले ऐप्लिकेशन (रजिस्टर किए गए विज्ञापन टेक्नोलॉजी की "साइट" या "ऑरिजिन") के साथ अपने-आप जुड़ जाते हैं. साथ ही, अनुरोध बनाने का समय भी जुड़ जाता है. सभी सिग्नल, Privacy Sandbox में रजिस्टर की गई विज्ञापन टेक्नोलॉजी की ओर से सेव किए जा सकते हैं. इसके लिए, यूआरआई "site"/"origin" को रजिस्टर की गई विज्ञापन टेक्नोलॉजी के डेटा से मैच करना होगा. अगर अनुरोध करने वाली विज्ञापन टेक्नोलॉजी रजिस्टर नहीं है, तो अनुरोध अस्वीकार कर दिया जाता है.

स्टोरेज कोटा और डेटा हटाना

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

डेटा ट्रांसमिशन के लिए, डिवाइस पर डेटा को एन्कोड (सुरक्षित) करना

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

विज्ञापन टेक्नोलॉजी कंपनियां, अपने कस्टम लॉजिक के हिसाब से सिग्नल प्रोसेसिंग के लेवल तय करती हैं. उदाहरण के लिए, अपने समाधान को पहले के सिग्नल को खारिज करने के लिए इंस्ट्रूमेंट किया जा सकता है. साथ ही, अलग-अलग ऐप्लिकेशन से मिलते-जुलते या पुष्टि करने वाले सिग्नल को नए सिग्नल में इकट्ठा किया जा सकता है, जो कम जगह का इस्तेमाल करते हैं.

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

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

विज्ञापन चुनने का वर्कफ़्लो

इस प्रस्ताव के तहत, विज्ञापन टेक्नोलॉजी का कस्टम कोड, सिर्फ़ टीईई में चल रही Protected Auction (Ad Selection API) में मौजूद Protected App सिग्नल को ऐक्सेस कर सकता है. ऐप्लिकेशन इंस्टॉल करने के उदाहरण की ज़रूरतों को और बेहतर तरीके से पूरा करने के लिए, संभावित विज्ञापनों को रीयल-टाइम में सुरक्षित नीलामी के दौरान फ़ेच किया जाता है. यह रीमार्केटिंग के इस्तेमाल के उदाहरण से अलग है, जहां नीलामी से पहले ही संभावित विज्ञापनों के बारे में पता होता है.

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

विज्ञापन चुनने का वर्कफ़्लो इस तरह है:

1. सेलर का SDK टूल, डिवाइस पर मौजूद, सुरक्षित ऐप्लिकेशन सिग्नल का एन्क्रिप्ट (सुरक्षित) किया गया पेलोड भेजता है.
2. सेलर का सर्वर, नीलामी का कॉन्फ़िगरेशन बनाता है और उसे एन्क्रिप्ट किए गए पेलोड के साथ, सेलर की भरोसेमंद बिडिंग और नीलामी सेवा पर भेजता है. ऐसा इसलिए किया जाता है, ताकि विज्ञापन चुनने का वर्कफ़्लो शुरू किया जा सके.
3. सेलर की बिडिंग और नीलामी की सेवा, पेलोड को उन भरोसेमंद खरीदारों के फ़्रंटएंड सर्वर पर भेजती है जो इसमें हिस्सा ले रहे हैं.
4. खरीदार की बिडिंग सेवा, बाय-साइड विज्ञापन चुनने का लॉजिक लागू करती है
   1. बाय-साइड विज्ञापन को वापस पाने के लॉजिक को लागू करना.
   2. खरीदारी वाले पक्ष की बिडिंग लॉजिक को लागू करना.
5. सेल-साइड स्कोरिंग लॉजिक लागू किया जाता है.
6. विज्ञापन रेंडर हो जाता है और रिपोर्टिंग शुरू हो जाती है.

विज्ञापन चुनने का वर्कफ़्लो शुरू करना

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

विज्ञापन चुनने की प्रोसेस शुरू करने के लिए, सेलर, हिस्सा लेने वाले खरीदारों की सूची और डिवाइस पर मौजूद, सुरक्षित ऐप्लिकेशन सिग्नल के एन्क्रिप्ट किए गए पेलोड को पास करता है. इस जानकारी के आधार पर, विज्ञापन देने वाले की तरफ़ से काम करने वाला विज्ञापन सर्वर, अपनी भरोसेमंद SellerFrontEnd सेवा के लिए SelectAdRequest तैयार करता है.

सेलर ये सेट करता है:

• getAdSelectionData से मिला पेलोड, जिसमें सुरक्षित ऐप्लिकेशन सिग्नल शामिल होते हैं.

• काम के सिग्नल, इनका इस्तेमाल करके:

  • auction_config.auction_signals (नीलामी के बारे में जानकारी के लिए)

  • auction_config.seller_signals (सेलर के सिग्नल के लिए

  • auction_config.per_buyer_config["buyer"].buyer_signals (खरीदारों के सिग्नल के लिए)

• buyer_list फ़ील्ड का इस्तेमाल करके नीलामियों में शामिल खरीदारों की सूची.

बाय-साइड विज्ञापन चुनने के लॉजिक को लागू करना

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

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

1. BuyerFrontEnd सेवा को विज्ञापन अनुरोध मिलता है.
2. BuyerFrontEnd सेवा, खरीदार की बिडिंग सेवा को एक अनुरोध भेजती है. खरीदार की बिडिंग सेवा, prepareDataForAdRetrieval() नाम का एक यूडीएफ़ चलाती है. यह विज्ञापन वापस पाने की सेवा से, सबसे ज़्यादा k उम्मीदवारों को पाने के लिए अनुरोध बनाता है. बिडिंग सेवा, इस अनुरोध को कॉन्फ़िगर किए गए रीट्रिवल सर्वर एंडपॉइंट पर भेजती है.
3. विज्ञापन वापस पाने की सेवा, getCandidateAds() यूडीएफ़ चलाती है. यह सबसे ज़्यादा संभावित विज्ञापनों के सेट तक फ़िल्टर करती है. इन विज्ञापनों को खरीदार की बिडिंग सेवा को भेजा जाता है.
4. बिडिंग की खरीदार की सेवा, generateBid() यूडीएफ़ को चलाती है. यह सबसे अच्छा उम्मीदवार चुनती है, बिड का हिसाब लगाती है, और फिर उसे BuyerFrontEnd सेवा को दिखाती है.
5. BuyerFrontEnd सेवा, सेलर को विज्ञापन और बिड दिखाती है.

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

इस डायग्राम में TEEs के बारे में कुछ अहम जानकारी दी गई है. इस जानकारी को ध्यान में रखते हुए, इस डायग्राम के अलग-अलग हिस्सों के बारे में ज़्यादा जानकारी दी गई है.

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

विज्ञापन वापस पाने की सेवा में, कुंजी-वैल्यू सेवा शामिल होती है. विज्ञापन टेक्नोलॉजी, अपने सर्वर से इस सेवा में कीवर्ड-वैल्यू पेयर को मैटीरियलाइज़ कर सकती हैं. ऐसा, निजता की सीमा के बाहर किया जा सकता है. हम विज्ञापन टेक्नोलॉजी के लिए एक JavaScript API उपलब्ध कराएंगे, ताकि वे विज्ञापन वापस पाने की सेवा पर चल रहे UDF में, इस की-वैल्यू सेवा को पढ़ सकें. बिडिंग की खरीदार की सेवा के उलट, विज्ञापन वापस पाने की सेवा में अनुमान लगाने वाली सेवा नहीं होती.

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

मॉडल का फ़ैक्टराइज़ेशन

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

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

इससे यह डिज़ाइन बनाया जा सकता है:

1. मॉडल को निजी हिस्से (उपयोगकर्ता का डेटा) और एक या उससे ज़्यादा गैर-निजी हिस्सों (विज्ञापन और संदर्भ के हिसाब से डेटा) में बांटें.
2. इसके अलावा, कुछ या सभी गैर-निजी हिस्सों को, अनुमान लगाने वाले UDF के लिए आर्ग्युमेंट के तौर पर पास किया जा सकता है. उदाहरण के लिए, per_buyer_signals में यूडीफ़ को कॉन्टेक्स्ट के हिसाब से एम्बेड किया जाता है.
3. इसके अलावा, विज्ञापन टेक्नोलॉजी कंपनियां, निजी नहीं होने वाले कॉन्टेंट के लिए मॉडल बना सकती हैं. इसके बाद, उन मॉडल से एम्बेड किए गए कॉन्टेंट को विज्ञापन वापस पाने की सेवा के पास मौजूद, की-वैल्यू स्टोर में डाल सकती हैं. विज्ञापन वापस पाने की सेवा पर मौजूद यूडीफ़, रनटाइम के दौरान इन एम्बेड को फ़ेच कर सकते हैं.
4. यूडीएफ़ के दौरान अनुमान लगाने के लिए, अनुमान लगाने वाली सेवा के निजी एम्बेड को, यूडीएफ़ फ़ंक्शन के आर्ग्युमेंट या की-वैल्यू स्टोर के ऐसे ऑपरेशन के साथ जोड़ें जिसमें डॉट प्रॉडक्ट जैसा ऑपरेशन शामिल हो. यह आखिरी अनुमान है.

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

prepareDataForAdRetrieval() यूडीएफ़

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

prepareDataForAdRetrieval(), यह जानकारी लेता है:

• getAdSelectionData से मिला, हर खरीदार का पेलोड. इस पेलोड में, Protected App Signals शामिल होते हैं.
• काम के सिग्नल के auction_signals (नीलामी के बारे में जानकारी के लिए) और buyer_signals (खरीदारों के सिग्नल फ़ील्ड के लिए).

prepareDataForAdRetrieval() दो काम करता है:

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

prepareDataForAdRetrieval() का शुल्क देकर, प्रॉडक्ट को लौटाया जा सकता है:

• Protected App Signals: विज्ञापन टेक्नोलॉजी से चुने गए सिग्नल का पेलोड.
• नीलामी से जुड़े सिग्नल: प्लैटफ़ॉर्म के हिसाब से सेल-साइड सिग्नल और SelectAdRequest से मिली auction_signals और per_buyer_signals जैसी संदर्भ जानकारी (इसमें संदर्भ के हिसाब से एम्बेड की गई जानकारी भी शामिल है). यह सुरक्षित ऑडियंस जैसी ही है.
• अतिरिक्त सिग्नल: अनुमान लगाने वाली सेवा से हासिल की गई निजी जानकारी जैसी अतिरिक्त जानकारी.

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

getCandidateAds() यूडीएफ़

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

getCandidateAds(), यह जानकारी लेता है:

• Protected App Signals: विज्ञापन टेक्नोलॉजी से चुने गए सिग्नल का पेलोड.
• नीलामी से जुड़े सिग्नल: प्लैटफ़ॉर्म के हिसाब से सेल-साइड सिग्नल और SelectAdRequest से मिली auction_signals और per_buyer_signals जैसी संदर्भ जानकारी (इसमें संदर्भ के हिसाब से एम्बेड की गई जानकारी भी शामिल है). यह सुरक्षित ऑडियंस जैसी ही है.
• अतिरिक्त सिग्नल: अनुमान लगाने वाली सेवा से हासिल की गई निजी जानकारी जैसी अतिरिक्त जानकारी.

getCandidateAds() ये काम करता है:

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

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

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

ध्यान दें कि बिडिंग की सेवा पर चलने वाला generateBid() यूडीएफ़, बिडिंग के अनुमान लगाने के लिए, अपनी तरह का मॉडल फ़ैक्टर भी लागू कर सकता है. अगर ऐसा करने के लिए, कुंजी-वैल्यू सेवा से किसी एम्बेड की ज़रूरत है, तो उन्हें अभी फ़ेच करना होगा.

getCandidateAds() का शुल्क देकर, प्रॉडक्ट को लौटाया जा सकता है:

• विज्ञापन के विकल्प: generateBid() को दिखाए जाने के लिए, सबसे ऊपर के k विज्ञापन. हर विज्ञापन में ये शामिल होते हैं:
  • रेंडर यूआरएल: विज्ञापन क्रिएटिव को रेंडर करने के लिए एंडपॉइंट.
  • मेटाडेटा: विज्ञापन टेक्नोलॉजी के हिसाब से, विज्ञापनों का मेटाडेटा. उदाहरण के लिए, इसमें विज्ञापन कैंपेन के बारे में जानकारी और टारगेटिंग की शर्तें शामिल हो सकती हैं. जैसे, जगह और भाषा. मेटाडेटा में वैकल्पिक एम्बेड शामिल हो सकते हैं. इनका इस्तेमाल तब किया जाता है, जब बिडिंग के दौरान अनुमान लगाने के लिए मॉडल फ़ैक्टराइज़ेशन की ज़रूरत होती है.
• अतिरिक्त सिग्नल: विज्ञापन वापस पाने की सेवा में, generateBid() में इस्तेमाल किए जाने वाले अतिरिक्त एम्बेड या स्पैम सिग्नल जैसी अतिरिक्त जानकारी शामिल की जा सकती है. हालांकि, ऐसा करना ज़रूरी नहीं है.

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

generateBid() यूडीएफ़

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

generateBid(), यह जानकारी लेता है:

• विज्ञापन के संभावित विकल्प: विज्ञापन वापस पाने की सेवा से मिले, सबसे ज़्यादा k विज्ञापन.
• नीलामी से जुड़े सिग्नल: प्लैटफ़ॉर्म के हिसाब से सेल-साइड सिग्नल और SelectAdRequest से मिली auction_signals और per_buyer_signals जैसी संदर्भ जानकारी (इसमें संदर्भ के हिसाब से एम्बेड की गई जानकारी भी शामिल है).
• अतिरिक्त सिग्नल: बिडिंग के समय इस्तेमाल की जाने वाली अतिरिक्त जानकारी.

खरीदार के generateBid() लागू करने से तीन काम होते हैं:

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

generateBid() का शुल्क देकर, प्रॉडक्ट को लौटाया जा सकता है:

• उम्मीदवार का विज्ञापन.
• बिड की गिनती की गई रकम.

ध्यान दें कि ऐप्लिकेशन इंस्टॉल करने के बढ़ावा देने वाले विज्ञापनों के लिए इस्तेमाल किया जाने वाला generateBid() और रीमार्केटिंग विज्ञापनों के लिए इस्तेमाल किया जाने वाला generateBid() अलग-अलग होता है.

नीचे दिए गए सेक्शन में, फ़ीचराइज़ेशन, अनुमान लगाने की सुविधा, और बिडिंग के बारे में ज़्यादा जानकारी दी गई है.

फ़ीचर

ऑक्शन सिग्नल को generateBid() की सुविधाओं में तैयार किया जा सकता है. इन सुविधाओं का इस्तेमाल, अनुमान लगाने के दौरान किया जा सकता है. इससे क्लिक मिलने की दर और कन्वर्ज़न रेट जैसे आंकड़े का अनुमान लगाया जा सकता है. हम निजता बनाए रखने के तरीकों को भी एक्सप्लोर कर रहे हैं, ताकि मॉडल को ट्रेनिंग देने के लिए, जीतने वाले कुछ डेटा को रिपोर्ट में भेजा जा सके.

अनुमान

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

क्लाइंट, generateBid() लागू करने के साथ-साथ कई मशीन लर्निंग मॉडल भी उपलब्ध करा सकते हैं. हम generateBid() में एक JavaScript एपीआई भी उपलब्ध कराएंगे, ताकि क्लाइंट रनटाइम के दौरान अनुमान लगा सकें.

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

आने वाले समय में, अनुमान लगाने की सुविधाओं के बारे में ज़्यादा जानकारी दी जाएगी. जैसे, इस्तेमाल किए जा सकने वाले मॉडल फ़ॉर्मैट और सबसे बड़े साइज़.

मॉडल फ़ैक्टरिज़ेशन लागू करना

हमने पहले मॉडल फ़ैक्टरिज़ेशन के बारे में बताया था. बिडिंग के समय, यह तरीका अपनाया जाता है:

1. एक मॉडल को निजी हिस्से (उपयोगकर्ता का डेटा) और एक या एक से ज़्यादा गैर-निजी हिस्सों (कॉन्टेक्स्ट और विज्ञापन डेटा) में बांटें.
2. generateBid() को नॉन-प्राइवेट पीस पास करें. ये per_buyer_signals से या ऐसे एम्बेड से मिल सकते हैं जिनका हिसाब विज्ञापन टेक्नोलॉजी बाहर से लगाती है. ये एम्बेड, डेटा वापस पाने की सेवा के की-वैल्यू स्टोर में दिखते हैं. साथ ही, डेटा वापस पाने के समय फ़ेच किए जाते हैं और अतिरिक्त सिग्नल के तौर पर दिखते हैं. इसमें निजी एम्बेड शामिल नहीं हैं, क्योंकि उन्हें निजता के दायरे से बाहर के सोर्स से नहीं लिया जा सकता.
3. generateBid() में:
   1. उपयोगकर्ता के निजी एम्बेडमेंट पाने के लिए, मॉडल के आधार पर अनुमान लगाएं.
   2. उपयोगकर्ता के निजी एम्बेड को, per_buyer_signals या गैर-निजी विज्ञापन से मिले कॉन्टेक्स्ट के हिसाब से एम्बेड किए गए शब्दों के साथ जोड़ें. साथ ही, जानकारी वापस पाने वाली सेवा से मिले कॉन्टेक्स्ट के हिसाब से एम्बेड किए गए शब्दों को भी जोड़ें. इसके लिए, डॉट प्रॉडक्ट जैसे ऑपरेशन का इस्तेमाल करें. यह आखिरी अनुमान है. इसका इस्तेमाल बिड का हिसाब लगाने के लिए किया जा सकता है.

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

सेल-साइड स्कोरिंग लॉजिक

इस चरण में, हिस्सा लेने वाले सभी खरीदारों से मिली बिड वाले विज्ञापनों को स्कोर दिया जाता है. generateBid() का आउटपुट, scoreAd() को चलाने के लिए सेलर की नीलामी सेवा को भेजा जाता है. साथ ही, scoreAd() एक बार में सिर्फ़ एक विज्ञापन को ध्यान में रखता है. स्कोर के आधार पर, सेलर एक विज्ञापन चुनता है, ताकि उसे डिवाइस पर रेंडर किया जा सके.

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

विज्ञापन चुनने वाले कोड का रनटाइम

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

रिपोर्टिंग

इस प्रपोज़ल में उन ही रिपोर्टिंग एपीआई का इस्तेमाल किया जाता है जिनका इस्तेमाल Protected Audience की रिपोर्टिंग के लिए बने प्रपोज़ल में किया जाता है. उदाहरण के लिए, reportImpression(), जो सेलर और खरीदार की रिपोर्ट भेजने के लिए प्लैटफ़ॉर्म को ट्रिगर करता है.

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

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

कुछ समय के लिए, हम generateBid() से ग़ैर-ज़रूरी डेटा को हटाने का एक तरीका उपलब्ध कराएंगे. इसके लिए, हमारा शुरुआती प्रस्ताव यहां दिया गया है. हम इंडस्ट्री के सुझावों के आधार पर, इसमें बदलाव करेंगे. इनमें ऐसे बदलाव भी शामिल हो सकते हैं जो पुराने वर्शन के साथ काम न करें.

तकनीकी तौर पर, यह इस तरह काम करता है:

1. विज्ञापन टेक्नोलॉजी विशेषज्ञ, उस डेटा के लिए स्कीमा तय करते हैं जिसे उन्हें ट्रांसमिट करना है.
2. generateBid() में, वे अपना चुना गया एग्ज़िट पेलोड बनाते हैं.
3. प्लैटफ़ॉर्म, स्कीमा के हिसाब से एग्ज़िट पेलोड की पुष्टि करता है और साइज़ की सीमाएं लागू करता है.
4. प्लैटफ़ॉर्म, एग्ज़िट पेलोड में नॉइज़ जोड़ता है.
5. आउटगोइंग पेलोड को वायर फ़ॉर्मैट में, जीत की रिपोर्ट में शामिल किया जाता है. इसे विज्ञापन टेक्नोलॉजी सर्वर पर भेजा जाता है, डिकोड किया जाता है, और मॉडल ट्रेनिंग के लिए इस्तेमाल किया जाता है.

एग्ज़िट पेलोड का स्कीमा तय करना

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

हम आपको एक CDDL फ़ाइल देंगे, जिसमें उस JSON के स्ट्रक्चर के बारे में बताया गया होगा. CDDL फ़ाइल में, काम करने वाली सुविधाओं के टाइप का एक सेट शामिल होगा. उदाहरण के लिए, बूलियन, इंटेजर, बकेट वगैरह. CDDL फ़ाइल और दिए गए स्कीमा, दोनों के वर्शन बनाए जाएंगे.

उदाहरण के लिए, एक बूलियन फ़ीचर और उसके बाद दो साइज़ वाली बकेट फ़ीचर वाला एग्ज़िट पेलोड कुछ ऐसा दिखेगा:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

इस्तेमाल की जा सकने वाली सुविधाओं के टाइप के बारे में जानकारी, GitHub पर उपलब्ध है.

generateBid() में, बाहर भेजे जाने वाले पेलोड बनाना

किसी खरीदार के लिए, सुरक्षित ऐप्लिकेशन सिग्नल के सभी डेटा, उसके generateBid() यूडीफ़ के लिए उपलब्ध होते हैं. इन सुविधाओं को शामिल करने के बाद, विज्ञापन टेक्नोलॉजी टीम अपना पेलोड, JSON फ़ॉर्मैट में बनाती है. इस एग्ज़िट पेलोड को विज्ञापन टेक्नोलॉजी सर्वर पर भेजने के लिए, खरीदार की जीत की रिपोर्ट में शामिल किया जाएगा.

इस डिज़ाइन के बजाय, एग्ज़िट वेक्टर का हिसाब generateBid() के बजाय reportWin() में लगाया जा सकता है. हर तरीके के कुछ फ़ायदे और कुछ नुकसान होते हैं. हम इंडस्ट्री के सुझावों और राय के आधार पर, इस फ़ैसले को फ़ाइनल करेंगे.

आउटगोइंग पेलोड की पुष्टि करना

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

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

हम विज्ञापन टेक्नोलॉजी के लिए एक JavaScript API उपलब्ध कराएंगे. इससे यह पक्का किया जा सकेगा कि generateBid() में बनाया गया एग्ज़िट पेलोड, प्लैटफ़ॉर्म की पुष्टि कर पाएगा:

validate(payload, schema)

यह JavaScript API, कॉल करने वालों के लिए पूरी तरह से है. इससे यह तय किया जा सकता है कि कोई खास पेलोड, प्लैटफ़ॉर्म की पुष्टि करेगा या नहीं. नुकसान पहुंचाने वाले generateBid() यूडीफ़ से बचने के लिए, प्लैटफ़ॉर्म पर ही पुष्टि की जानी चाहिए.

आउटगोइंग पेलोड में गड़बड़ी करना

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

गड़बड़ी का पता लगाने का तरीका:

1. प्लैटफ़ॉर्म, एग्ज़िट पेलोड के लिए स्कीमा की परिभाषा लोड करता है.
2. गड़बड़ी का पता लगाने के लिए, बाहर भेजे जाने वाले 1% पेलोड चुने जाएंगे.
3. अगर कोई एग्ज़िट पेलोड नहीं चुना जाता है, तो पूरी मूल वैल्यू बरकरार रहती है.
4. अगर कोई एग्ज़िट पेलोड चुना जाता है, तो हर सुविधा की वैल्यू को उस सुविधा के टाइप के लिए, किसी भी मान्य वैल्यू से बदल दिया जाएगा. उदाहरण के लिए, बूलियन सुविधा के लिए 0 या 1.

मॉडल ट्रेनिंग के लिए, आउटगोइंग पेलोड को ट्रांसमिट, रिसीव, और डिकोड करना

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

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

एग्ज़िट पेलोड का साइज़ तय करना

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

साइज़ तय करने का तरीका:

1. शुरुआत में, हम generateBid() में दो एक्सग्रेस पेलोड के साथ काम करेंगे:
   1. egressPayload: साइज़ की सीमा वाला वह एग्ज़िट पेलोड जिसे हमने इस दस्तावेज़ में अब तक बताया है. शुरुआत में, इस एग्ज़िट पेलोड का साइज़ 0 बिट होगा. इसका मतलब है कि पुष्टि के दौरान इसे हमेशा हटा दिया जाएगा.
   2. temporaryUnlimitedEgressPayload: साइज़ से जुड़े एक्सपेरिमेंट के लिए, कुछ समय के लिए साइज़ के हिसाब से अनलिमिटेड एक्सग्रेस पेलोड. इस एग्ज़िट पेलोड को फ़ॉर्मैट करने, बनाने, और प्रोसेस करने के लिए, egressPayload के जैसे ही तरीके इस्तेमाल किए जाते हैं.
2. इनमें से हर एग्ज़िट पेलोड के लिए, एक स्कीमा JSON फ़ाइल होगी: egress_payload_schema.json और temporary_egress_payload_schema.json.
3. हम एक्सपेरिमेंट प्रोटोकॉल और मेट्रिक का एक सेट उपलब्ध कराते हैं. इससे, अलग-अलग एग्ज़िट पेलोड साइज़ (उदाहरण के लिए, 5, 10, ... बिट) के लिए मॉडल की उपयोगिता का पता लगाया जा सकता है.
4. एक्सपेरिमेंट के नतीजों के आधार पर, हम सही उपयोगिता और निजता के समझौते के साथ, एग्ज़िट पेलोड का साइज़ तय करते हैं.
5. हमने egressPayload का साइज़ 0 बिट से नए साइज़ पर सेट किया है.
6. माइग्रेशन की तय अवधि के बाद, हम temporaryUnlimitedEgressPayload को हटा देते हैं और सिर्फ़ egressPayload को उसके नए साइज़ के साथ छोड़ देते हैं.

हम इस बदलाव को मैनेज करने के लिए, अन्य तकनीकी गार्डरेल की जांच कर रहे हैं. उदाहरण के लिए, egressPayload का साइज़ 0 बिट से बढ़ाने पर उसे एन्क्रिप्ट करना. एक्सपेरिमेंट के खत्म होने का समय और temporaryUnlimitedEgressPayload को हटाने के साथ-साथ, इन जानकारी को अगले अपडेट में शामिल किया जाएगा.

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

मान लें कि हम pInstall मॉडल को ट्रेनिंग दे रहे हैं. साथ ही, ट्रेनिंग डेटा के सोर्स हमारे लॉग और नीलामी जीतने पर मिलने वाले temporaryUnlimitedegressPayload के कॉन्टेंट हैं. विज्ञापन टेक्नोलॉजी के प्रोटोकॉल में सबसे पहले ऑफ़लाइन प्रयोग शामिल होते हैं:

1. यह तय करना कि वे Protected App Signals के साथ किन मॉडल का इस्तेमाल करेंगे. उदाहरण के लिए, उन्हें यह तय करना होगा कि उन्हें मॉडल फ़ैक्टरिज़ेशन का इस्तेमाल करना है या नहीं.
2. मॉडल की क्वालिटी मेज़र करने के लिए कोई मेट्रिक तय करें. सुझाई गई मीट्रिक में AUC में कमी और लॉग लॉस शामिल हैं.
3. मॉडल को ट्रेन करने के दौरान इस्तेमाल की जाने वाली सुविधाओं का सेट तय करें.
4. मॉडल के आर्किटेक्चर, क्वालिटी मेट्रिक, और ट्रेनिंग की सुविधाओं के सेट का इस्तेमाल करके, एब्लेशन स्टडी की जाती हैं. इससे यह पता चलता है कि PAS में इस्तेमाल किए जाने वाले हर मॉडल के लिए, हर बिट की उपयोगिता क्या है. ऐब्लेशन स्टडी के लिए सुझाया गया प्रोटोकॉल यह है:
   1. सभी सुविधाओं के साथ मॉडल को ट्रेन करें और उपयोगिता को मेज़र करें; यह तुलना के लिए बेसलाइन है.
   2. बेसलाइन बनाने के लिए इस्तेमाल की गई हर सुविधा के लिए, मॉडल को उस सुविधा के बगैर सभी सुविधाओं के साथ ट्रेन करें.
   3. इससे मिलने वाली सुविधा को मेज़र करें. डेल्टा को बिट में सुविधा के साइज़ से divide करें; यह उस सुविधा के लिए हर बिट की अनुमानित उपयोगिता है.
5. एक्सपेरिमेंट के लिए, ट्रेनिंग पेलोड के साइज़ तय करें. हमारा सुझाव है कि आप [5, 10, 15, ..., size_of_all_training_features_for_baseline] बिट का इस्तेमाल करें. इनमें से हर एक, egressPayload के लिए एक संभावित साइज़ दिखाता है, जिसका आकलन एक्सपेरिमेंट में किया जाएगा.
6. हर संभावित साइज़ के लिए, उन सुविधाओं का एक सेट चुनें जो उस साइज़ से कम या उसके बराबर हों. इससे, हर बिट की उपयोगिता को बढ़ाया जा सकता है. इसके लिए, एब्लेशन स्टडी के नतीजों का इस्तेमाल करें.
7. हर संभावित साइज़ के लिए मॉडल को ट्रेन करें और सभी सुविधाओं पर ट्रेन किए गए बेसलाइन मॉडल की उपयोगिता के प्रतिशत के तौर पर, उसकी उपयोगिता का आकलन करें.
8. नतीजों को एक ग्राफ़ पर प्लॉट करें. इसमें x-ऐक्सिस पर, बिट में ट्रेनिंग पेलोड का साइज़ और y-ऐक्सिस पर, बेसलाइन की तुलना में उस मॉडल से जनरेट होने वाले रेवेन्यू का प्रतिशत होगा.

इसके बाद, विज्ञापन टेक्नोलॉजी कंपनियां, temporaryUnlimitedEgressPayload के ज़रिए भेजे गए सुविधा के डेटा का इस्तेमाल करके, लाइव ट्रैफ़िक एक्सपेरिमेंट में पांचवें से आठवें चरण को दोहरा सकती हैं. विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियां, egressPayload के साइज़ के बारे में फ़ैसला लेने के लिए, अपने ऑफ़लाइन और लाइव ट्रैफ़िक एक्सपेरिमेंट के नतीजे, Privacy Sandbox के साथ शेयर कर सकती हैं.

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

डेटा की सुरक्षा के लिए उठाए गए कदम

हम बाहर भेजे गए डेटा को सुरक्षित रखने के लिए कई उपाय अपनाएंगे. इनमें ये शामिल हैं:

1. egressPayload और temporaryUnlimitedEgressPayload, दोनों में गड़बड़ी होगी.
2. डेटा को कम करने और उसकी सुरक्षा के लिए, temporaryUnlimitedEgressPayload सिर्फ़ साइज़ से जुड़े प्रयोगों के दौरान उपलब्ध होगा. इस दौरान, हम egressPayload के लिए सही साइज़ तय करेंगे.

अनुमतियां

उपयोगकर्ता के कंट्रोल की जानकारी

• इस प्रस्ताव का मकसद, उपयोगकर्ताओं को उन ऐप्लिकेशन की सूची दिखाना है जिनमें कम से कम एक सुरक्षित ऐप्लिकेशन सिग्नल या कस्टम ऑडियंस सेव की गई है.
• उपयोगकर्ता इस सूची से ऐप्लिकेशन को ब्लॉक और हटा सकते हैं. ब्लॉक करने और हटाने पर ये काम होते हैं:
  • ऐप्लिकेशन से जुड़े सभी सुरक्षित ऐप्लिकेशन सिग्नल और कस्टम ऑडियंस मिटाता है.
  • इससे ऐप्लिकेशन, नए सुरक्षित ऐप्लिकेशन सिग्नल और कस्टम ऑडियंस को सेव नहीं कर पाते
• उपयोगकर्ता, Protected App Signals और Protected Audience API को पूरी तरह से रीसेट कर सकते हैं. ऐसा होने पर, डिवाइस पर मौजूद Protected App सिग्नल और कस्टम ऑडियंस मिट जाती हैं.
• उपयोगकर्ता, Android पर Privacy Sandbox से पूरी तरह ऑप्ट आउट कर सकते हैं. इसमें Protected App Signals API और Protected Audience API शामिल हैं. ऐसा होने पर, Protected Audience और Protected App Signals API, स्टैंडर्ड अपवाद मैसेज दिखाते हैं: SECURITY_EXCEPTION.

ऐप्लिकेशन की अनुमतियां और कंट्रोल

इस प्रस्ताव का मकसद, ऐप्लिकेशन को 'सुरक्षित ऐप्लिकेशन सिग्नल' पर कंट्रोल देना है:

• कोई ऐप्लिकेशन, Protected App Signals के साथ अपने असोसिएशन मैनेज कर सकता है.
• कोई ऐप्लिकेशन, तीसरे पक्ष के विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म को अनुमतियां दे सकता है, ताकि वे ऐप्लिकेशन के सुरक्षित सिग्नल को मैनेज कर सकें.

विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म का कंट्रोल

इस प्रस्ताव में, विज्ञापन टेक्नोलॉजी कंपनियों के लिए, सुरक्षित ऐप्लिकेशन सिग्नल को कंट्रोल करने के तरीके बताए गए हैं:

• विज्ञापन टेक्नोलॉजी से जुड़ी सभी कंपनियों को Privacy Sandbox में रजिस्टर करना होगा. साथ ही, "साइट" या "ऑरिजिन" डोमेन देना होगा, जो Protected App Signals के सभी यूआरएल से मेल खाता हो.
• विज्ञापन टेक्नोलॉजी कंपनियां, पुष्टि करने वाले टोकन उपलब्ध कराने के लिए ऐप्लिकेशन या SDK टूल के साथ साझेदारी कर सकती हैं. इन टोकन का इस्तेमाल, सुरक्षित ऐप्लिकेशन सिग्नल बनाने की पुष्टि करने के लिए किया जाता है. जब इस प्रोसेस को किसी पार्टनर को सौंपा जाता है, तो सुरक्षित ऐप्लिकेशन सिग्नल बनाने की प्रोसेस को कॉन्फ़िगर किया जा सकता है, ताकि विज्ञापन टेक्नोलॉजी की सेवा देने वाली कंपनी को इसकी पुष्टि करनी पड़े.