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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

सुरक्षित ऑडियंस की मदद से, ये काम किए जा सकते हैं:

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

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

टाइमलाइन

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

खास जानकारी

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

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

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

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

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

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

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

3. विज्ञापन दिखाने वाले ऐप्लिकेशन या विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म का SDK टूल, चुने गए विज्ञापन को रेंडर करता है.

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

Android API पर Protected Audience का ऐक्सेस पाना

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

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

कस्टम ऑडियंस

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

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

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

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

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

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

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

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

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

joinCustomAudience()

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

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

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

k-anon की जांच न होने पर, खरीदार की पुष्टि करने और खरीदार और SDK टूल के बीच जानकारी शेयर करने के लिए, fetchUri का इस्तेमाल किया जा सकता है. कस्टम ऑडियंस की पुष्टि करने के लिए, खरीदार पुष्टि करने वाला टोकन दे सकता है. डिवाइस पर मौजूद 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 पर Privacy Sandbox से पूरी तरह ऑप्ट-आउट कर सकते हैं. इसमें Protected Audience API भी शामिल है. अगर उपयोगकर्ता ने Privacy Sandbox से ऑप्ट आउट किया है, तो Protected Audience API बिना किसी सूचना के काम नहीं करता.

इस सुविधा के डिज़ाइन पर काम जारी है. इसकी जानकारी, आने वाले समय में किए जाने वाले अपडेट में शामिल की जाएगी.

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

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

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

/**
* API To schedule delayed update events for Custom Audience
*
* @param request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

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

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

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

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

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

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

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

  • इससे यह एपीआई, fetchAndJoinCustomAudience() एपीआई के साथ भी काम करता रहता है. इस एपीआई की मदद से, मिलती-जुलती जानकारी शेयर की जा सकती है.

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

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

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

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

इस सुविधा के डिज़ाइन पर काम जारी है. इसकी जानकारी, आने वाले समय में किए जाने वाले अपडेट में शामिल की जाएगी.

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

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

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

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

बाय-साइड प्लैटफ़ॉर्म से मिले संभावित विज्ञापनों और मेटाडेटा में ये फ़ील्ड शामिल होने चाहिए:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

बिड के अलावा, बाय-साइड प्लैटफ़ॉर्म के पास 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 की बिड वैल्यू लौटाई जाती है.

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

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

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

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

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

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

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

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

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

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

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

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

विज्ञापन रेंडर करने की सुविधा

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

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

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

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

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

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

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

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

registerAdBeacon(beacons)

इनपुट:

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

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

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

प्लैटफ़ॉर्म, selectAds() एपीआई के लिए, सेलर के फ़ैसला लेने के लॉजिक के यूआरएल पैरामीटर से डाउनलोड किए गए, सप्लाई साइड से दिए गए कोड में 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, सेल-साइड reportResult का आउटपुट है. इससे सेल-साइड प्लैटफ़ॉर्म को, रिपोर्टिंग के मकसद से बाय-साइड प्लैटफ़ॉर्म के साथ डेटा शेयर करने का मौका मिलता है.
• 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 ऑब्जेक्ट या व्यू इवेंट के लिए null होता है. इस पैरामीटर के बारे में ज़्यादा जानकारी के लिए, एट्रिब्यूशन रिपोर्टिंग एपीआई इंटिग्रेशन देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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