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

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

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

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

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

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

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

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

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

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

टाइमलाइन

	डेवलपर के लिए झलक			बीटा वर्शन
सुविधा	साल 2023 की चौथी तिमाही	साल 2024 की पहली तिमाही	साल 2024 की दूसरी तिमाही	साल 2024 की तीसरी तिमाही
सिग्नल क्यूरेशन एपीआई	डिवाइस पर स्टोरेज एपीआई	डिवाइस पर स्टोरेज कोटा लॉजिक डिवाइस पर मौजूद कस्टम लॉजिक से जुड़े हर दिन के अपडेट	लागू नहीं	1% T+ डिवाइसों के लिए उपलब्ध है
टीईई में विज्ञापन वापस पाने वाला सर्वर	एमवीपी	GCP पर उपलब्ध टॉप K यूडीएफ़ प्रोडक्शन के लिए सहायता	AWS पर उपलब्ध सहमति के साथ डीबग करने, मेट्रिक, और मॉनिटरिंग की सुविधा
टीईई में अनुमान सेवा एमएल मॉडल चलाने और टीईई में बिडिंग के लिए उनका इस्तेमाल करने के लिए सहायता	इस पर काम जारी है	GCP पर उपलब्ध TensorFlow और PyTorch का इस्तेमाल करके, स्टैटिक एमएल मॉडल को डिप्लॉय और प्रोटोटाइप करने की सुविधा	AWS पर उपलब्ध Tensorflow और PyTorch मॉडल के लिए, प्रोडक्शन मॉडल का डिप्लॉयमेंट टेलीमेट्री, सहमति से डीबग करना, और निगरानी करना
टीईई में बिडिंग और नीलामी से जुड़ी सहायता	GCP पर उपलब्ध है	PAS-B&A और TEE विज्ञापन वापस पाने का इंटिग्रेशन (gRPC और TEE<>TEE एन्क्रिप्शन के साथ) संदर्भ के पाथ के ज़रिए विज्ञापन वापस पाने में मदद करता है (इसमें TEE पर B&A<>K/V सहायता भी शामिल है)	AWS पर उपलब्ध डीबग रिपोर्टिंग सहमति के साथ डीबग करना, मेट्रिक, और मॉनिटरिंग

सुरक्षित ऐप्लिकेशन के सिग्नल चुनें

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

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" कुंजी वाले सिग्नल की सूची, जिसे दो अलग-अलग ऐप्लिकेशन ने बनाया है.

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

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

Protected App Signals API में, ये हिस्से शामिल हैं:

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

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

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

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

इस्तेमाल किए जा सकने वाले JSON निर्देश:

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

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

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

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

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

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

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

डेटा ट्रांसमिशन के लिए, डिवाइस पर कोड में बदलने का तरीका

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

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

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

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

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

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

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

Android पर प्राइवसी सैंडबॉक्स में, विज्ञापन चुनने का वर्कफ़्लो.

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

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 फ़ील्ड का इस्तेमाल करके नीलामियों में शामिल की गई खरीदारों की सूची.

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

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

Android पर प्राइवसी सैंडबॉक्स में, खरीदारी करने पर दिखने वाले विज्ञापन चुनने का लॉजिक.

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

ध्यान दें: इस फ़्लो में, फ़्रेमवर्क कोड और उपयोगकर्ता के तय किए गए फ़ंक्शन (यूडीएफ़) जैसे खरीदार के कारोबारी नियम शामिल होते हैं. ये यूडीएफ़, JavaScript या WASM में लागू किए जाते हैं. हाई लेवल पर, फ़्लो है:

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

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

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

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

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

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

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

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

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

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

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

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

prepareDataForAdRetrieval() यूडीएफ़

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

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

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

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

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

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

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

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

getCandidateAds() यूडीएफ़

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

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

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

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

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

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

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

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

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

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

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

generateBid() यूडीएफ़

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

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

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

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

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

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

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

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

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

फ़ेचराइज़ेशन

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

अनुमान

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

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

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

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

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

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

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

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

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

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

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

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

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

रिपोर्ट करना

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

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

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

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

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

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

इग्रेस डेटा ट्रैफ़िक पेलोड का स्कीमा तय करना

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

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

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

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-ऐक्सिस, साइज़-अनलिमिटेड बेसलाइन की तुलना में उस साइज़ के मॉडल से जनरेट हुई आय का प्रतिशत होगा.

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

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

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

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

डेटा की सुरक्षा के तरीके

हम इग्रेस डेटा ट्रैफ़िक को रोकने के लिए कई सुरक्षा सुविधाएं लागू करेंगे. इनमें ये शामिल हैं:

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

अनुमतियां

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

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

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

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

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

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

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

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