इस पेज का अनुवाद Cloud Translation API से किया गया है.

Protected Audience API की मदद से, कस्टम ऑडियंस टारगेटिंग की सुविधा पाएं

हाल ही के अपडेट

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

Protected Audience बीटा वर्शन में है और सार्वजनिक डिवाइसों पर टेस्ट करने के लिए उपलब्ध है!

Protected Audience की मदद से, ये काम किए जा सकते हैं:

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

शुरू करने के लिए, Protected Audience डेवलपर गाइड पढ़ें. हम Protected Audience को लगातार बेहतर बनाने की कोशिश कर रहे हैं. इसलिए, आपके सुझाव/राय/शिकायत की सराहना करते हैं.

टाइमलाइन

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

सुविधा	'डेवलपर के लिए झलक' में उपलब्ध है	बीटा वर्शन में उपलब्ध है
इवेंट-लेवल की रिपोर्टिंग	साल 2023 की पहली तिमाही	साल 2023 की तीसरी तिमाही
वॉटरफ़ॉल मीडिएशन	साल 2023 की पहली तिमाही	साल 2023 की चौथी तिमाही
ऐप्लिकेशन इंस्टॉल विज्ञापन फ़िल्टर करना	साल 2023 की दूसरी तिमाही	साल 2023 की तीसरी तिमाही
फ़्रीक्वेंसी कैप फ़िल्टर करना	साल 2023 की दूसरी तिमाही	साल 2023 की तीसरी तिमाही
फ़िल्टर करने के लिए, काम के विज्ञापनों को विज्ञापन चुनने के वर्कफ़्लो पर पास करना	साल 2023 की दूसरी तिमाही	साल 2023 की तीसरी तिमाही
इंटरैक्शन रिपोर्टिंग	साल 2023 की दूसरी तिमाही	साल 2023 की तीसरी तिमाही
कस्टम ऑडियंस डेलिगेशन में शामिल होना	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही
गैर-सीपीएम बिलिंग	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही
बिडिंग और नीलामी की सेवाओं को इंटिग्रेट करना	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही
डीबग रिपोर्टिंग	साल 2023 की तीसरी तिमाही	साल 2023 की चौथी तिमाही
एट्रिब्यूशन रिपोर्टिंग इंटिग्रेशन	लागू नहीं	साल 2023 की चौथी तिमाही
ओपन बिडिंग मीडिएशन	साल 2023 की चौथी तिमाही	साल 2023 की चौथी तिमाही
करंसी मैनेजमेंट	साल 2024 की पहली तिमाही	साल 2024 की दूसरी तिमाही
K-anon इंटिग्रेशन	लागू नहीं	साल 2024 की दूसरी तिमाही
एग्रीगेट रिपोर्टिंग इंटिग्रेशन	साल 2024 की तीसरी तिमाही	साल 2024 की चौथी तिमाही

खास जानकारी

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

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

Android पर Protected Audience API (इसे पहले FLEDGE कहा जाता था) में, विज्ञापन टेक्नोलॉजी से जुड़े प्लैटफ़ॉर्म और विज्ञापन देने वाले लोगों या कंपनियों के लिए, नीचे दिए गए एपीआई शामिल हैं. इससे, वे एक-दूसरे के साथ इंटरैक्ट करने में मदद कर पाते हैं. इससे ऐप्लिकेशन में आइडेंटिफ़ायर और तीसरे पक्ष के साथ उपयोगकर्ता के ऐप्लिकेशन इंटरैक्शन की जानकारी, दोनों को शेयर करने की सीमा तय की जाती है:

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

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

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

हाई लेवल पर इंटिग्रेशन इस तरह काम करता है:

SportsinggoodsApp अपने उपयोगकर्ताओं को याद दिलाना चाहता है कि अगर उन्होंने दो दिनों के अंदर, कार्ट में जोड़े गए मर्चंडाइज़ आइटम को खरीदारी के लिए पूरा नहीं किया है, तो वे उन आइटम को खरीद लें. उपयोगकर्ता को "कार्ट में मौजूद प्रॉडक्ट" वाली ऑडियंस की सूची में जोड़ने के लिए, SportsinggoodsApp कस्टम ऑडियंस एपीआई का इस्तेमाल करता है. यह प्लैटफ़ॉर्म, ऑडियंस की इस सूची को डिवाइस पर मैनेज और सेव करता है. हालांकि, तीसरे पक्ष के साथ यह सूची शेयर नहीं की जा सकती. SportsinggoodsApp ने विज्ञापन टेक्नोलॉजी से जुड़े प्लैटफ़ॉर्म के साथ पार्टनरशिप की है, ताकि ऑडियंस की सूची में मौजूद उपयोगकर्ताओं को इसके विज्ञापन दिखाए जा सकें. विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म, ऑडियंस की सूचियों के लिए मेटाडेटा मैनेज करता है. साथ ही, कैंडिडेट विज्ञापन दिखाता है, जिन्हें विज्ञापन चुनने के वर्कफ़्लो के लिए उपलब्ध कराया जाता है. प्लैटफ़ॉर्म को बैकग्राउंड में समय-समय पर अपडेट किए गए ऑडियंस-आधारित विज्ञापनों को फ़ेच करने के लिए कॉन्फ़िगर किया जा सकता है. इससे ऑडियंस-आधारित कैंडिडेट विज्ञापनों की सूची को अप-टू-डेट रखने में मदद मिलती है. साथ ही, यह विज्ञापन ऑपर्च्यूनिटी (यानी कि संदर्भ के हिसाब से विज्ञापन अनुरोध) के दौरान तीसरे पक्ष के विज्ञापन सर्वर को भेजे गए अनुरोधों से भी जुड़ा नहीं रहता.
जब उपयोगकर्ता उसी डिवाइस पर FisbeeGame खेलता है, तो उसे एक विज्ञापन दिख सकता है. इस विज्ञापन में स्पोर्टिंग GoodsApp के शॉपिंग कार्ट में बचे आइटम की खरीदारी पूरी करने के लिए कहा जा सकता है. इसके लिए, FisbeeGame (एक साथ जुड़े विज्ञापन दिखाने में इस्तेमाल होने वाले SDK टूल की मदद से) Ad Select API को इस्तेमाल करके, उपयोगकर्ताओं की ऐसी किसी भी सूची के आधार पर जीतने वाले विज्ञापन को चुना जा सकता है जिसमें वे शामिल हो सकते हैं (इस उदाहरण में "कार्ट में मौजूद", स्पोर्टिंग गुड्स ऐप के ज़रिए बनाई गई कस्टम ऑडियंस). विज्ञापन चुनने के वर्कफ़्लो को इस तरह सेट अप किया जा सकता है कि कस्टम ऑडियंस से जुड़े डिवाइस पर मौजूद विज्ञापनों के साथ-साथ अन्य उपयोगकर्ता के डिवाइस से मिलने वाले विज्ञापनों के साथ-साथ, विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म के सर्वर से वापस लाए गए विज्ञापनों पर भी विचार किया जा सके. वर्कफ़्लो को पसंद के मुताबिक बनाने के लिए, विज्ञापन टेक्नोलॉजी से जुड़े प्लैटफ़ॉर्म और विज्ञापन SDK टूल का इस्तेमाल करके ज़रूरत के मुताबिक बिडिंग और स्कोरिंग लॉजिक का इस्तेमाल किया जा सकता है, ताकि विज्ञापन के सही लक्ष्यों को हासिल किया जा सके. इस तरीके से, उपयोगकर्ता की दिलचस्पी और ऐप्लिकेशन के इंटरैक्शन का डेटा चुना जा सकता है, ताकि विज्ञापन चुने जा सकें और तीसरे पक्ष के साथ डेटा शेयर न किया जाए.
विज्ञापन दिखाने वाला ऐप्लिकेशन या विज्ञापन टेक्नोलॉजी से जुड़े प्लैटफ़ॉर्म का SDK टूल, चुने गए विज्ञापन को रेंडर करता है.
यह प्लैटफ़ॉर्म, इंप्रेशन और विज्ञापन चुनने के नतीजों की रिपोर्टिंग करने की सुविधा देता है. रिपोर्टिंग की यह सुविधा, Attribution Reporting API की अन्य सुविधाएं देती है. विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाले प्लैटफ़ॉर्म को, रिपोर्टिंग से जुड़ी ज़रूरतों के हिसाब से अपनी पसंद के मुताबिक बनाया जा सकता है.

Android के एपीआई पर Protected Audience का ऐक्सेस पाना

Protected Audience API को ऐक्सेस करने के लिए, AdTech प्लैटफ़ॉर्म को रजिस्टर करना होगा. ज़्यादा जानकारी के लिए, Privacy Sandbox खाते के लिए रजिस्टर करें लेख देखें.

कस्टम ऑडियंस मैनेजमेंट

कस्टम ऑडियंस

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

विज्ञापन देने वाला कोई ऐप्लिकेशन या इंटिग्रेट किया गया SDK टूल, कस्टम ऑडियंस join हो सकता है या उसे छोड़ सकता है. उदाहरण के लिए, ऐप्लिकेशन में उपयोगकर्ता का जुड़ाव.

कस्टम ऑडियंस मेटाडेटा

हर कस्टम ऑडियंस में यह मेटाडेटा शामिल होता है:

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

पसंद के मुताबिक ऑडियंस का ऐक्सेस देना

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

कस्टम ऑडियंस में शामिल हों

पसंद के मुताबिक ऑडियंस में शामिल होने के दो तरीके हैं:

joinCustomAudience()

अनुमानित पैरामीटर के साथ CustomAudience ऑब्जेक्ट को इंस्टैंशिएट करने के बाद, कोई ऐप्लिकेशन या SDK टूल, joinCustomAudience() को कॉल करके कस्टम ऑडियंस में शामिल होने का अनुरोध कर सकता है. यहां कोड स्निपेट का एक उदाहरण दिया गया है:

CustomAudience audience = new CustomAudience(
    Buyer = "example-dsp.com",
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    DailyUpdateURL = Uri.parse("https://..."),
    UserBiddingSignals = new JSONObject("{...}"),
    TrustedBiddingURL = Uri.parse("https://..."),
    TrustedBiddingKeys = {'key1","key2", ...,"key n"},
    BiddingLogicURL =  Uri.parse("https://..."),
    Ads = [new AdData(renderUrl = Uri.parse("https://..."),
           metadata = new JSONObject("{...}"), ...];

// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);

fetchAndJoinCustomAudience()

कोई ऐप्लिकेशन या SDK टूल, उस विज्ञापन टेक्नोलॉजी की ओर से कस्टम ऑडियंस में शामिल होने का अनुरोध कर सकता है जो डिवाइस पर मौजूद नहीं है. ऐसा करने के लिए, fetchAndJoinCustomAudience() को सही पैरामीटर के साथ कॉल करें, जैसा कि इस उदाहरण में दिखाया गया है:

FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
    // Example: Optional verification token passed inside the fetch URL
    FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
    // All the following parameters are optional
    Name = "running-shoes",
    ActivationTime = now(),
    ExpirationTime = ActivationTime.plus(30 days),
    UserBiddingSignals = new JSONObject("{...}")
);

fetchAndJoinCustomAudience(fetchRequest);

खरीदार के मालिकाना हक वाला यूआरएल एंडपॉइंट, रिस्पॉन्स के मुख्य हिस्से में CustomAudience JSON ऑब्जेक्ट के साथ जवाब देता है. कस्टम ऑडियंस के खरीदार और मालिक के फ़ील्ड को अनदेखा किया जाता है. साथ ही, एपीआई इन्हें अपने-आप भरता है. एपीआई यह भी लागू करता है कि हर दिन अपडेट होने वाला यूआरएल, खरीदार के eTLD+1 से मेल खाएगा.

{
 "name": "running-shoes",
 "activation_time": 1680603133000,
 "expiration_time": 1680803133000,
 "user_bidding_signals" : {"signal1": "value"},
 "trusted_bidding_data": {
    "trusted_bidding_uri": "https://example-dsp.com/.."
    "trusted_bidding_keys": ["k1", "k2"],
 },
 "bidding_logic_uri": "https://example-dsp.com/...",
 "daily_update_uri": "https://example-dsp.com/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": 1,
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": 2,
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

fetchAndJoinCustomAudience() एपीआई, fetchUri के eTLD+1 से खरीदार की पहचान तय करता है. CustomAudience खरीदार की पहचान का इस्तेमाल, वही रजिस्ट्रेशन और ऐप्लिकेशन की अनुमति से जुड़ी जांच करने के लिए किया जाता है जो joinCustomAudience() ने की है. फ़ेच रिस्पॉन्स की मदद से, इस पहचान में बदलाव नहीं किया जा सकता. CustomAudience का मालिक, कॉल करने वाले ऐप्लिकेशन के पैकेज का नाम होता है. eTLD+1 जांच के अलावा, fetchUri के लिए कोई और पुष्टि नहीं है और खास तौर पर कोई k-anon जांच नहीं है. fetchAndJoinCustomAudience() एपीआई, fetchUri को एचटीटीपी जीईटी अनुरोध भेजता है. साथ ही, उम्मीद है कि JSON ऑब्जेक्ट, कस्टम ऑडियंस को दिखा रहा हो. कस्टम ऑडियंस ऑब्जेक्ट फ़ील्ड के लिए वही ज़रूरी, वैकल्पिक कंस्ट्रेंट, और डिफ़ॉल्ट वैल्यू रिस्पॉन्स पर लागू होती हैं. हमारी डेवलपर गाइड में, मौजूदा ज़रूरी शर्तों और सीमाओं के बारे में जानें.

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

CustomAudienceFetchRequest ऑब्जेक्ट, एपीआई कॉलर को ऊपर दिए गए उदाहरण में दिखाई गई वैकल्पिक प्रॉपर्टी का इस्तेमाल करके कस्टम ऑडियंस के लिए कुछ जानकारी देने की अनुमति देता है. अगर अनुरोध में सेट की गई वैल्यू को, प्लैटफ़ॉर्म को खरीदार के जवाब के हिसाब से बदला नहीं जा सकता, तो उन्हें बदला नहीं जा सकता. Protected Audience API, रिस्पॉन्स में दिए गए फ़ील्ड को अनदेखा कर देता है. अगर इन्हें अनुरोध में सेट नहीं किया गया है, तो इन्हें रिस्पॉन्स में सेट किया जाना चाहिए. इसकी वजह यह है कि कस्टम ऑडियंस बनाने के लिए ये फ़ील्ड ज़रूरी हैं. एपीआई कॉलर की ओर से तय किया गया CustomAudience का कॉन्टेंट, fetchUri के GET अनुरोध में एक खास हेडर X-CUSTOM-AUDIENCE-DATA में शामिल होता है. कस्टम ऑडियंस के लिए तय किए गए डेटा के सीरियल वाले फ़ॉर्म का साइज़ 8 केबी तक सीमित है. अगर साइज़ से ज़्यादा साइज़ है, तो fetchAndJoinCustomAudience एपीआई कॉल नहीं हो पाता.

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

पुष्टि वाले टोकन की परिभाषा और डिवाइस के स्टोरेज के बारे में जानकारी

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

कस्टम ऑडियंस छोड़ें

कस्टम ऑडियंस का मालिक, leaveCustomAudience() को कॉल करके पेज को छोड़ सकता है. इसका उदाहरण नीचे दिया गया है:

// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);

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

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

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

इस सुविधा के डिज़ाइन पर अभी काम चल रहा है. इसकी जानकारी बाद में होने वाले अपडेट में शामिल की जाएगी.

शेड्यूल किए गए अपडेट

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

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

/**
* API To schedule delayed update events for Custom Audience
*
* @param delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/

public void scheduleCustomAudienceUpdates(
    @NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

DelayedCustomAudienceUpdate

public final class DelayedCustomAudienceUpdate {
    // Required Field
    @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

    // Required Field
    @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

    //  Required Field
    @NonNull public List<PartialCustomAudience> getPartialCustomAudiences() {
    return mPartialCustomAudiences;
  }
}

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

UpdateUri: यूआरआई एंडपॉइंट जिसे अपडेट फ़ेच करने के लिए GET कॉल भेजा जाएगा. खरीदार की पहचान, eTLD+1 से ली जाती है. ज़रूरी नहीं है कि यह जानकारी साफ़ तौर पर दी जाए और अपडेट के बाद इसमें कोई बदलाव न किया जाए. GET अनुरोध के लिए ज़रूरी है कि ऐसा JSON ऑब्जेक्ट हो जिसमें customAudience ऑब्जेक्ट की सूची शामिल हो.
DelayTime: अपडेट शेड्यूल करने के लिए scheduleCustomAudienceUpdate() एपीआई कॉल करने के बाद से हुई देरी को दिखाता है.

PartialCustomAudience: यह एपीआई, डिवाइस पर मौजूद SDK टूल को आंशिक तौर पर बनी कस्टम ऑडियंस की सूची भेजने की भी अनुमति देता है. इससे, इन-ऐप्लिकेशन SDK टूल को डीएसपी के साथ पार्टनरशिप के आधार पर, कस्टम ऑडियंस मैनेजमेंट पर पूरा कंट्रोल मिलने से लेकर, उसके कुछ हद तक कंट्रोल करने की सुविधा मिलती है.
- इससे यह एपीआई, fetchAndJoinCustomAudience() एपीआई के साथ भी काम करता है. इससे मिलती-जुलती जानकारी शेयर करने की अनुमति मिलती है.

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

इस प्रस्ताव का मकसद, ऐप्लिकेशन को अपनी पसंद के मुताबिक ऑडियंस पर कंट्रोल देना है:

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

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

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

विज्ञापन टेक्नोलॉजी, प्राइवसी सैंडबॉक्स के साथ रजिस्टर करती हैं और एक eTLD+1 डोमेन देती है, जो कस्टम ऑडियंस के लिए सभी यूआरएल से मेल खाता है.
विज्ञापन टेक्नोलॉजी, पुष्टि करने वाले टोकन देने के लिए ऐप्लिकेशन या SDK टूल के साथ साझेदारी कर सकती हैं. इनका इस्तेमाल, पसंद के मुताबिक ऑडियंस बनाने की पुष्टि करने के लिए किया जाता है. जब यह प्रोसेस किसी पार्टनर को सौंपी जाती है, तो कस्टम ऑडियंस बनाने की सुविधा को इस तरह से कॉन्फ़िगर किया जा सकता है कि विज्ञापन टेक्नोलॉजी से जुड़ी सहमति लेना ज़रूरी हो.
कोई विज्ञापन टेक्नोलॉजी अपनी ओर से joinCustomAudience कॉल को बंद करने का विकल्प चुन सकती है. साथ ही, वह सिर्फ़ fetchAndJoinCustomAudience API को कॉल की सभी कस्टम ऑडियंस को चालू करने की अनुमति दे सकती है. प्राइवसी सैंडबॉक्स में रजिस्टर करने के दौरान, कंट्रोल को अपडेट किया जा सकता है. ध्यान रखें कि कंट्रोल में सभी विज्ञापन टेक्नोलॉजी या किसी भी टेक्नोलॉजी को इस्तेमाल करने की अनुमति नहीं होती. प्लैटफ़ॉर्म की सीमाओं की वजह से, डेलिगेशन की अनुमतियां, विज्ञापन टेक्नोलॉजी के हिसाब से अलग-अलग नहीं हो सकतीं.

उम्मीदवार के विज्ञापन और मेटाडेटा के जवाब

बाय-साइड प्लैटफ़ॉर्म से लौटाए गए उम्मीदवार के विज्ञापनों और मेटाडेटा में ये फ़ील्ड होने चाहिए:

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

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

इस प्रस्ताव का मकसद, Ad Selection API की मदद से निजता को बेहतर बनाना है. यह एपीआई, विज्ञापन टेक्नोलॉजी से जुड़े प्लैटफ़ॉर्म के लिए नीलामी की प्रोसेस को पूरा करता है.

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

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

यह तरीका, विज्ञापन चुनने के लिए उपयोगकर्ता के ऐप्लिकेशन इंटरैक्शन का डेटा चालू करता है. साथ ही, तीसरे पक्षों के साथ इस डेटा की शेयरिंग को सीमित करता है.

फ़्लो चार्ट, जिसमें विज्ञापन चुनने के वर्कफ़्लो की शुरुआत को दिखाया गया है.

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

बाय-साइड बिडिंग के लॉजिक को लागू करना
बाय-साइड विज्ञापन फ़िल्टर करना और प्रोसेस करना
सेल-साइड के फ़ैसले वाले लॉजिक को लागू करना

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

जिन विज्ञापन चयनों में कस्टम ऑडियंस शामिल नहीं हैं, उनका डिज़ाइन सक्रिय डिज़ाइन में है.

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

जब किसी ऐप्लिकेशन को कोई विज्ञापन दिखाना होता है, तो विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म का SDK टूल, selectAds() तरीके को कॉल करके विज्ञापन चुनने का वर्कफ़्लो शुरू कर सकता है. ऐसा करने के लिए, यह ज़रूरी पैरामीटर के साथ AdSelectionConfig ऑब्जेक्ट को इंस्टैंशिएट करता है:

सेलर: eTLD+1 फ़ॉर्मैट के हिसाब से, सेल-साइड विज्ञापन प्लैटफ़ॉर्म का आइडेंटिफ़ायर
डिसिज़न लॉजिक यूआरएल: विज्ञापन नीलामी शुरू होने पर प्लैटफ़ॉर्म इस यूआरएल का इस्तेमाल, सेल-साइड प्लैटफ़ॉर्म से JavaScript कोड फ़ेच करने के लिए करेगा, ताकि विजेता विज्ञापन को स्कोर दिया जा सके.
कस्टम ऑडियंस खरीदार: eTLD+1 फ़ॉर्मैट के हिसाब से इस नीलामी के लिए, कस्टम ऑडियंस की मांग वाले बाय-साइड प्लैटफ़ॉर्म की सूची.
विज्ञापन चुनने के सिग्नल: नीलामी के बारे में जानकारी (विज्ञापन का साइज़, विज्ञापन फ़ॉर्मैट वगैरह).
सेलर के सिग्नल: साइड प्लैटफ़ॉर्म से जुड़े सिग्नल उपलब्ध कराएं.
भरोसेमंद स्कोरिंग सिग्नल का यूआरएल: सेल-साइड भरोसेमंद सिग्नल का यूआरएल एंडपॉइंट, जिससे क्रिएटिव की खास रीयल टाइम जानकारी फ़ेच की जा सकती है.
हर खरीदार के सिग्नल: भाग लेने वाले मांग पक्ष, नीलामी के लिए इनपुट देने के लिए इस पैरामीटर का इस्तेमाल कर सकते हैं. उदाहरण के लिए, इस पैरामीटर में बिड तय करने के लिए, काम की ऐसी पूरी जानकारी शामिल हो सकती है जो काम के हो.

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

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
                         "buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};

// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);

बाय-साइड बिडिंग का लॉजिक

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

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

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ...};
}

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

इस फ़ंक्शन में ये पैरामीटर होने चाहिए:

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

विज्ञापन की लागत

बोली के अलावा, बाय-साइड प्लैटफ़ॉर्म के पास generateBid() के हिस्से के तौर पर, हर क्लिक की लागत (सीपीसी) दिखाने का विकल्प भी होता है. उदाहरण के लिए:

generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return {'bid': ..., 'adCost': ...,};
}

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

बाय-साइड फ़िल्टर करने का लॉजिक

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

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

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

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

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

scoreAd(ad, bid, auction_config, trusted_scoring_signals,
        contextual_signals, user_signals, custom_audience_signals) {
    // ...
    return score_for_this_ad;
}

इस फ़ंक्शन में ये पैरामीटर होने चाहिए:

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

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

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

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

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

प्रोग्रामिंग भाषा

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

विजेता विज्ञापन रेंडरिंग

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

इस प्लान का मकसद ऐसे समाधान को तैयार करना है जिससे यह पक्का हो सके कि ऐप्लिकेशन या एसडीके, उपयोगकर्ताओं की कस्टम ऑडियंस की सदस्यता या ऐप्लिकेशन में दिलचस्पी बढ़ाने वाले इतिहास की जानकारी को, जीतने वाले विज्ञापन (Chrome के फ़ेंस किए गए फ़्रेम के प्रपोज़ल की तरह) से तय न कर सके.

इंप्रेशन और इवेंट रिपोर्टिंग

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

सेल-साइड रिपोर्टिंग.
बाय-साइड रिपोर्टिंग.

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

इवेंट की रिपोर्टिंग के लिए दो चरणों की ज़रूरत है: सेल-साइड और बाय-साइड JavaScript को यह रजिस्टर करना होगा कि उसे किस इवेंट के लिए इवेंट रिपोर्ट मिलनी चाहिए. सेल-साइड, इवेंट-लेवल की जानकारी देने के लिए ज़िम्मेदार है.

Protected Audience, बीकन को रजिस्टर करके, नीलामी जीतने से जुड़े आने वाले इवेंट की सदस्यता लेने का तरीका उपलब्ध कराता है. सेलर के reportResult() JavaScript फ़ंक्शन में, सेल-साइड प्लैटफ़ॉर्म, प्लैटफ़ॉर्म के registerAdBeacon() फ़ंक्शन का इस्तेमाल करके बीकन रजिस्टर कर सकते हैं. इसी तरह, बाय-साइड प्लैटफ़ॉर्म अपने reportWin() JavaScript फ़ंक्शन से registerAdBeacon() तरीके को कॉल कर सकते हैं.

registerAdBeacon(beacons)

इनपुट:

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

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

सेल-साइड रिपोर्टिंग

यह प्लैटफ़ॉर्म, selectAds() API के लिए सेलर के डिसिज़न लॉजिक यूआरएल पैरामीटर से डाउनलोड किए गए सप्लाई साइड से मिले कोड में, reportResult() JavaScript फ़ंक्शन को शुरू करता है:

reportResult(render_url, bid, auction_config, contextual_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_url": reporting_url,
                  "signals_for_buyer": signals_for_buyer}};
}

आउटपुट: एक JSON ऑब्जेक्ट जिसमें शामिल है

स्थिति: सफलता के लिए 0, विफलता के लिए कोई अन्य मान.
रिपोर्टिंग यूआरएल: प्लैटफ़ॉर्म, फ़ंक्शन से लौटाए गए इस यूआरएल को शुरू करता है.
खरीदार के लिए सिग्नल: खरीदार के reportWin फ़ंक्शन को पास किया जाने वाला JSON ऑब्जेक्ट.

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

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

बाय-साइड रिपोर्टिंग

यह प्लैटफ़ॉर्म, नीलामी से जुड़ी कस्टम ऑडियंस के बिडिंग लॉजिक यूआरएल मेटाडेटा से डाउनलोड किए गए डिमांड साइड कोड में reportWin() JavaScript फ़ंक्शन को शुरू करता है.

reportWin(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    beacons = {"click":clickUri}
    registerAdBeacon(beacons)
    return {
      "status": 0,
      "results": {"reporting_uri": reporting_uri}};
}

इनपुट:

auction_signals और per_buyer_signals को AuctionConfig से फ़ेच किया गया है. ऐसी कोई भी जानकारी जिसे बाय-साइड प्लैटफ़ॉर्म को रिपोर्टिंग यूआरएल में भेजना ज़रूरी होता है, वह इस डाटुम से मिल सकती है.
signals_for_buyer, सेल-साइड रिपोर्ट के नतीजे का आउटपुट है. इससे, सेल-साइड प्लैटफ़ॉर्म को रिपोर्टिंग के लिए, बाय-साइड प्लैटफ़ॉर्म के साथ डेटा शेयर करने का मौका मिलता है.
contextual_signals में ऐप्लिकेशन का नाम जैसी जानकारी होती है और custom_audience_signals में पसंद के मुताबिक ऑडियंस की जानकारी होती है. आने वाले समय में, इस बारे में अन्य जानकारी जोड़ी जा सकती है.

आउटपुट:

स्थिति: सफलता के लिए 0, विफलता के लिए कोई अन्य मान.
रिपोर्टिंग यूआरएल: प्लैटफ़ॉर्म, फ़ंक्शन से लौटाए गए इस यूआरएल को शुरू करता है.

इवेंट की रिपोर्ट करना

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

ReportEventRequest request = new ReportEventRequest(
  AdSelectionId = ad_selection_id,
  event_key = "view"
  event_data = "{ "viewTimeInSeconds" :1 }",
  reporting_destinations =
    FLAG_REPORTING_DESTINATION_SELLER |
      FLAG_REPORTING_DESTINATION_BUYER,
  input_event = clickInputEvent // or null for view
  )

reportEvent(request)

इनपुट:

ad_selection_id, हाल ही में चलाई गई नीलामी का AdSelectionId होना चाहिए, जिसे AdSelectionOutcome से लिया गया है.
event_key एक सेल-साइड से तय की गई स्ट्रिंग है, जो इंटरैक्शन इवेंट की जानकारी देती है.
event_data एक स्ट्रिंग है, जो event_key से जुड़ा डेटा दिखाती है
reporting_destinations एक बिट मास्क सेट है, जो प्लैटफ़ॉर्म से मिले फ़्लैग का इस्तेमाल करता है. यह FLAG_REPORTING_DESTINATION_SELLER या FLAG_REPORTING_DESTINATION_BUYER या दोनों में से कोई एक हो सकता है.
input_event (ज़रूरी नहीं) का इस्तेमाल Attribution Reporting API के साथ इंटिग्रेशन के लिए किया जाता है. यह या तो InputEvent ऑब्जेक्ट (क्लिक इवेंट के लिए) या शून्य (व्यू इवेंट के लिए) है. इस पैरामीटर के बारे में ज़्यादा जानकारी के लिए, Attribution Reporting API का इंटिग्रेशन देखें.

सेल-साइड SDK टूल, reportEvent को शुरू करता है और reporting_destinations फ़्लैग के मुताबिक, प्लैटफ़ॉर्म, खरीदारों और विक्रेताओं के reportWin और reportResult JavaScript फ़ंक्शन में रजिस्टर की गई कुंजियों से event_key को मैच करने की कोशिश करता है. अगर कोई मैच होता है, तो प्लैटफ़ॉर्म, event_data को उससे जुड़े reporting_url में पोस्ट करता है. अनुरोध का कॉन्टेंट टाइप एक सादा टेक्स्ट होता है, जिसमें मुख्य हिस्सा event_data होता है. यह अनुरोध किया जाता है, ताकि नेटवर्क की गड़बड़ी मिलने, सर्वर की गड़बड़ी मिलने या उससे मिलती-जुलती कोई कुंजी न मिलने पर, यह अनुरोध अपने-आप फ़ेल हो जाता है.

Attribution Reporting API का इंटिग्रेशन

Protected Audience नीलामी में हिस्सा लेने वाले खरीदारों की मदद करने के लिए, हम Protected Audience और Attribution Reporting API (ARA) में क्रॉस-एपीआई की सुविधा उपलब्ध करा रहे हैं. इस सुविधा के ज़रिए, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों को अलग-अलग रीमार्केटिंग रणनीतियों में अपनी एट्रिब्यूशन परफ़ॉर्मेंस का आकलन करने में मदद मिलती है. इससे यह समझने में मदद मिलती है कि किस तरह की ऑडियंस से सबसे ज़्यादा आरओआई मिलता है.

इस क्रॉस-एपीआई इंटिग्रेशन की मदद से, AdTech ये काम कर सकते हैं:

यूआरआई का एक की-वैल्यू मैप बनाएं, जिसका इस्तेमाल 1) विज्ञापन इंटरैक्शन रिपोर्टिंग और 2) सोर्स रजिस्ट्रेशन, दोनों के लिए किया जा सके.
Protected Audience से जुड़ी नीलामी से मिलने वाले नीलामी के डेटा को, खास जानकारी की एग्रीगेट रिपोर्टिंग (Attribution Reporting API का इस्तेमाल करके) के लिए, सोर्स-साइड की मैपिंग में शामिल करें. ज़्यादा जानकारी के लिए, ARA डिज़ाइन प्रपोज़ल देखें.

जब कोई उपयोगकर्ता किसी विज्ञापन को देखता है या उस पर क्लिक करता है:

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

सोर्स रजिस्ट्रेशन की सुविधा चालू करना

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

Android पर ARA, व्यू और क्लिक इवेंट के साथ काम करता है. इसलिए, InputEvents का इस्तेमाल इन दोनों में अंतर करने के लिए किया जाता है. ARA सोर्स के रजिस्ट्रेशन की तरह ही, reportEvent() API, प्लैटफ़ॉर्म से पुष्टि किए गए InputEvent को क्लिक इवेंट मानेगा. अगर InputEvent मौजूद नहीं है, शून्य या अमान्य है, तो सोर्स रजिस्ट्रेशन को एक व्यू माना जाएगा.

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

यूज़र ऐक्टिविटी और कन्वर्ज़न रिपोर्टिंग का उदाहरण

इस उदाहरण में, हम इसे खरीदार के नज़रिए से देखेंगे. इसकी दिलचस्पी नीलामी, रेंडर किए गए विज्ञापन, और कन्वर्ज़न ऐप्लिकेशन के डेटा को एक साथ जोड़ने में है.

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

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

reportWin को लागू करने के दौरान, खरीदार विज्ञापन रेंडर समय के दौरान और खास इंटरैक्शन इवेंट (registerAdBeacon()) के लिए ट्रिगर होने वाले विज्ञापन बीकन को रजिस्टर कर सकता है. किसी विज्ञापन इवेंट के लिए नीलामी सिग्नल जोड़ने के लिए, auctionId को बीकन यूआरएल के क्वेरी पैरामीटर के रूप में सेट करें.
विज्ञापन को रेंडर करते समय, नीलामी के दौरान रजिस्टर किए गए बीकन को ट्रिगर किया जा सकता है या इवेंट-लेवल के डेटा की मदद से बेहतर बनाया जा सकता है. सेलर को reportEvent() को ट्रिगर करना होगा और इवेंट-लेवल का डेटा भेजना होगा. यह प्लैटफ़ॉर्म, खरीदार के रजिस्टर किए गए विज्ञापन बीकन के यूआरएल को पिंग करेगा, जो ट्रिगर किए गए reportEvent() से जुड़ा होगा.
खरीदार Attribution-Reporting-Register-Source हेडर वाले विज्ञापन बीकन के अनुरोधों का जवाब देकर, Attribution Reporting API के साथ विज्ञापन रजिस्टर करेगा. किसी कन्वर्ज़न इवेंट के लिए नीलामी के सिग्नल जोड़ने के लिए, रजिस्टर किए गए सोर्स यूआरएल में auctionId सेट करें.

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

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

AdTech प्लैटफ़ॉर्म से मैनेज किया जाने वाला भरोसेमंद सर्वर

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

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

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

नीचे एक सैंपल यूआरएल दिया गया है, ताकि आप कस्टम ऑडियंस से मिले भरोसेमंद बिडिंग सिग्नल मेटाडेटा के आधार पर, भरोसेमंद बिडिंग का डेटा फ़ेच कर सकें:

https://www.kv-server.example/getvalues?keys=key1,key2

सर्वर से मिलने वाला रिस्पॉन्स एक JSON ऑब्जेक्ट होना चाहिए, जिसकी कुंजियां key1, key2 वगैरह हों. साथ ही, जिनकी वैल्यू खरीदार के बिडिंग फ़ंक्शन के लिए उपलब्ध कराई जाएगी.

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

क्रिएटिव रेंडर यूआरएल के आधार पर, नीलामी में विचार किए जाने वाले क्रिएटिव के बारे में जानकारी पाने के लिए, यहां एक सैंपल यूआरएल दिया गया है:

https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2

सर्वर से मिला रिस्पॉन्स एक JSON ऑब्जेक्ट होना चाहिए, जिसकी कुंजियां, अनुरोध में भेजे गए यूआरएल होती हैं.

ये सर्वर कई सुरक्षा और निजता से जुड़े फ़ायदे देने के लिए भरोसेमंद तरीके से काम करेंगे:

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

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

खरीदार और सेलर, Android और वेब पर प्राइवसी सैंडबॉक्स के साथ काम करने वाले प्लैटफ़ॉर्म के लिए, की-वैल्यू टाइप वाले एक भरोसेमंद सर्वर का इस्तेमाल कर सकते हैं.