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

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

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

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

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

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

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

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

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

टाइमलाइन

Protected App Signals को मैनेज करना

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

Protected App Signals API

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

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

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

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

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

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

• सिग्नल जोड़ने, अपडेट करने या हटाने के लिए Java और JavaScript API.
• एक JavaScript API, जो स्टोर किए गए सिग्नल को प्रोसेस करता है, ताकि उन्हें Trusted Execution Environment (TEE) में चल रही Protected Auction के दौरान, रीयल टाइम में फ़ीचर इंजीनियरिंग के लिए तैयार किया जा सके.

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

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

सिग्नल जोड़ने के लिए, खरीदार की विज्ञापन टेक्नोलॉजी से जुड़ी उन कंपनियों को विज्ञापन टेक्नोलॉजी से जुड़ी उन कंपनियों के साथ मिलकर काम करना होगा जिनके पास ऐप्लिकेशन में एसडीके मौजूद नहीं है. जैसे, मोबाइल मेज़रमेंट पार्टनर (एमएमपी) और सप्लाई-साइड प्लैटफ़ॉर्म (एसएसपी). Protected App Signals API का मकसद, विज्ञापन टेक्नोलॉजी की मदद करना है. इसके लिए, यह Protected App Signal को मैनेज करने के लिए फ़्लेक्सिबल समाधान उपलब्ध कराता है. साथ ही, डिवाइस पर कॉल करने वालों को खरीदारों की ओर से Protected App Signal बनाने की सुविधा देता है. इस प्रोसेस को डेलिगेशन कहा जाता है. यह fetchSignalUpdates() API का इस्तेमाल करती है. fetchSignalUpdates() एक यूआरआई लेता है और सिग्नल अपडेट की सूची वापस लाता है. उदाहरण के लिए, fetchSignalUpdates() दिए गए यूआरआई को एक GET अनुरोध भेजता है, ताकि स्थानीय सिग्नल स्टोरेज पर लागू किए जाने वाले अपडेट की सूची को वापस पाया जा सके. खरीदार के मालिकाना हक वाला यूआरएल एंडपॉइंट, निर्देशों की 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 में शामिल विज्ञापन टेक्नोलॉजी की ओर से सेव किए जाते हैं. "साइट"/"ऑरिजिन" का यूआरआई, Privacy Sandbox में शामिल विज्ञापन टेक्नोलॉजी के डेटा से मेल खाना चाहिए. अगर अनुरोध करने वाली विज्ञापन टेक्नोलॉजी, Privacy Sandbox में शामिल नहीं है, तो अनुरोध अस्वीकार कर दिया जाता है.

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

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

डेटा ट्रांसमिशन के लिए, डिवाइस पर एन्कोडिंग की सुविधा

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

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

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

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

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

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

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

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

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

विज्ञापन चुनने की प्रोसेस शुरू करें

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

विज्ञापन चुनने की प्रोसेस शुरू करने के लिए, सेलर, बिडिंग में हिस्सा लेने वाले खरीदारों की सूची और डिवाइस पर मौजूद Protected App Signals का एन्क्रिप्ट किया गया पेलोड पास करता है. इस जानकारी की मदद से, सेलिंग साइड का विज्ञापन सर्वर, भरोसेमंद SellerFrontEnd सेवा के लिए SelectAdRequest तैयार करता है.

सेलर ये चीज़ें सेट करता है:

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

• कॉन्टेक्स्ट के हिसाब से सिग्नल का इस्तेमाल करके:

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

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

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

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

विज्ञापन खरीदार के लिए, विज्ञापन चुनने के लॉजिक को लागू करना

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

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

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

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

इस डायग्राम के कुछ हिस्सों के बारे में ज़्यादा जानकारी देने से पहले, टीईई के आर्किटेक्चर के बारे में कुछ ज़रूरी बातें जान लें.

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

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

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

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

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

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

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

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

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

prepareDataForAdRetrieval() यूडीएफ़

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

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

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

prepareDataForAdRetrieval() से दो काम होते हैं:

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

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

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

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

getCandidateAds() यूडीएफ़

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

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

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

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

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

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

• नीलामी के हिसाब से सिग्नल इनपुट का इस्तेमाल करके पास की गई कॉन्टेक्स्टुअल एम्बेडिंग.
• अतिरिक्त सिग्नल इनपुट का इस्तेमाल करके पास किए गए निजी एम्बेड.
• विज्ञापन टेक्नोलॉजी से जुड़ी ऐसी कोई भी कंपनी जो निजी नहीं है, वह अपने सर्वर से Ad Retrieval Service की Key-Value Service में विज्ञापन दिखा सकती है.

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

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

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

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

generateBid() यूडीएफ़

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

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

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

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

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

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

• उम्मीदवार का विज्ञापन.
• यह बिड की कैलकुलेट की गई रकम है.

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

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

फ़ीचर बनाना

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

अनुमान

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

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

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

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

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

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

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

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

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

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

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

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

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

रिपोर्टिंग

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

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

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

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

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

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

ईग्रेस पेलोड का स्कीमा तय करना

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

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

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

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

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

generateBid() में इग्रेस पेलोड बनाना

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

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

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

डेटा की सुरक्षा के लिए अपनाए गए तरीके

हम बाहर भेजे गए डेटा पर कई तरह की सुरक्षा सुविधाएं लागू करेंगे. जैसे:

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

अनुमतियां

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

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

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

इस प्रस्ताव का मकसद, ऐप्लिकेशन को अपने Protected App Signals को कंट्रोल करने की अनुमति देना है:

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

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

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

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