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

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

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

Protected Audience API, बीटा वर्शन में है और डेवलपमेंट के लिए उपलब्ध है.

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

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

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

टाइमलाइन

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

खास जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

कस्टम ऑडियंस

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

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

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

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

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

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

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

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

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

joinCustomAudience()

कोई ऐप्लिकेशन या एसडीके, कस्टम ऑडियंस में शामिल होने का अनुरोध कर सकता है. इसके लिए, उसे 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()

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

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

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

के-एनॉन चेक न होने की वजह से, खरीदार की पुष्टि करने के लिए fetchUri का इस्तेमाल किया जा सकता है. साथ ही, खरीदार और एसडीके के बीच जानकारी शेयर करने की सुविधा चालू की जा सकती है. कस्टम ऑडियंस की पुष्टि करने के लिए, खरीदार पुष्टि करने वाला टोकन दे सकता है. ऑन-डिवाइस एसडीके को इस टोकन को 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 चुपचाप काम करना बंद कर देता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस फ़ंक्शन के लिए, इन पैरामीटर की ज़रूरत होती है:

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

विज्ञापन पर खर्च

बिड के अलावा, बाय-साइड प्लैटफ़ॉर्म के पास 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 को यह रजिस्टर करना होगा कि उसे किस इवेंट की रिपोर्ट मिलनी चाहिए. साथ ही, सेलिंग-साइड, इवेंट-लेवल की जानकारी रिपोर्ट करने के लिए ज़िम्मेदार है.

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

registerAdBeacon(beacons)

इनपुट:

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

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

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

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

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 का मतलब है कि कार्रवाई पूरी हो गई है. कार्रवाई पूरी न होने पर, कोई दूसरी वैल्यू दिखेगी.
• रिपोर्टिंग यूआरएल: प्लैटफ़ॉर्म, फ़ंक्शन से मिले इस यूआरएल को चालू करता है.
• खरीदार के लिए सिग्नल: यह एक JSON ऑब्जेक्ट है, जिसे खरीदार के reportWin फ़ंक्शन को पास किया जाना है.

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

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

खरीदारी करने वाले पक्ष की रिपोर्टिंग

यह प्लैटफ़ॉर्म, मांग पक्ष की ओर से दिए गए कोड में 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, सेलर-साइड रिपोर्टResult का आउटपुट है. इससे सेल-साइड प्लैटफ़ॉर्म को, रिपोर्टिंग के मकसद से बाय-साइड प्लैटफ़ॉर्म के साथ डेटा शेयर करने का मौका मिलता है.
• contextual_signals में ऐप्लिकेशन का नाम जैसी जानकारी होती है और custom_audience_signals में कस्टम ऑडियंस की जानकारी होती है. आने वाले समय में, अन्य जानकारी भी जोड़ी जा सकती है.

आउटपुट:

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

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

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

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

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

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

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

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

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

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

सोर्स रजिस्ट्रेशन चालू करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 के साथ काम करने वाले प्लैटफ़ॉर्म के लिए, भरोसेमंद और सामान्य की-वैल्यू-टाइप सर्वर का इस्तेमाल कर सकते हैं.