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

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

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

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

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

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

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

टाइमलाइन

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

खास जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

कस्टम ऑडियंस

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ScheduleCustomAudienceUpdateRequest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

registerAdBeacon(beacons)

इनपुट:

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

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

आउटपुट:

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

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

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

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

reportEvent(request)

इनपुट:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

खरीदार और विक्रेता ये ऐसे प्लैटफ़ॉर्म हैं जो Android और वेब पर प्राइवसी सैंडबॉक्स के साथ काम करते हैं.