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

सुझाव/राय देना या शिकायत करना

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

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

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

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

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

टाइमलाइन

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

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

खास जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

कस्टम ऑडियंस

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

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

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

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

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

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

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

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

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

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

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

  • पुष्टि करने वाले टोकन का इस्तेमाल, Protected Audience API में किसी भी काम के लिए नहीं किया जाता. साथ ही, यह ज़रूरी नहीं है.

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

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

'पसंद के मुताबिक दर्शक' का मालिक leaveCustomAudience() को कॉल करके बाहर निकलने का विकल्प चुन सकता है, जैसा कि नीचे दिए गए कोड स्निपेट में दिखाया गया है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

विज्ञापन चुनने के वर्कफ़्लो की शुरुआत दिखाने वाला फ़्लो चार्ट.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

खरीदारी की ओर से फ़िल्टर करने का तरीका

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. बिक्री के पक्ष की रिपोर्ट.
  2. खरीदारी के पक्ष की रिपोर्ट.

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

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

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

registerAdBeacon(beacons)

इनपुट:

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

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

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

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

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

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

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

इनपुट:

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

आउटपुट:

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

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

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

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

reportEvent(request)

इनपुट:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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