एट्रिब्यूशन रिपोर्टिंग प्रस्ताव में सामुदायिक फ़ीडबैक का समाधान करने के लिए कई बदलाव किए गए हैं. इनमें एपीआई सिस्टम में बदलाव से लेकर नए फ़ंक्शन तक शामिल हैं.
बदलावों का लॉग
- 7 फ़रवरी, 2022: हेडर ट्रिगर रीडायरेक्ट पर सेक्शन जोड़ा गया.
- 27 जनवरी, 2022: पहली बार लेख पब्लिश किया गया.
यह पोस्ट किसके लिए है?
यह पोस्ट आपके लिए है:
- अगर आपको एपीआई के बारे में पहले से जानकारी है. उदाहरण के लिए, डब्ल्यूआईसीजी के डेटा स्टोर करने की जगह पर हुई चर्चा में हिस्सा लिया गया हो या उसमें हिस्सा लिया हो और आपको जनवरी 2022 में, प्रस्ताव में किए गए बदलावों के बैच को समझना हो.
- अगर किसी डेमो या प्रोडक्शन में चल रहे एक्सपेरिमेंट में, Attribution Reporting API का इस्तेमाल किया जा रहा है.
अगर आपने अभी-अभी इस एपीआई का इस्तेमाल शुरू किया है और/या आपने अभी तक इसे इस्तेमाल नहीं किया है, तो सीधे एपीआई के बारे में जानकारी पर जाएं.
माइग्रेट करने की सुविधा शुरू होने वाली है
Chrome में ये बदलाव लागू होने के बाद: डेमो में या प्रोडक्शन (ऑरिजिन ट्रायल) के किसी प्रयोग में, Attribution Reporting API से मिलने वाली इवेंट-लेवल की रिपोर्ट का इस्तेमाल करने पर, आपको अपने कोड में बदलाव करना होगा, ताकि एपीआई लगातार काम करता रहे. आप नई सुविधाएं इस्तेमाल करने के बारे में भी सोच सकते हैं.
इस लेख में, इकट्ठा की जा सकने वाली रिपोर्ट में होने वाले बदलावों के बारे में भी बताया गया है. हालांकि, इन बदलावों को लागू करने पर किसी भी तरह की कार्रवाई या माइग्रेशन की ज़रूरत नहीं होगी, क्योंकि अभी तक इस फ़ॉर्म को लिखने के समय इकट्ठा करने लायक रिपोर्ट के लिए कोई ब्राउज़र लागू नहीं किया गया है.
नाम में बदलाव
खास जानकारी वाली रिपोर्ट और इकट्ठा की जा सकने वाली रिपोर्ट
पहले एग्रीगेट रिपोर्ट के तौर पर जो जानकारी दिखती थी उसे अब खास जानकारी वाली रिपोर्ट कहा जाएगा.
खास जानकारी वाली रिपोर्ट, कई एग्रीगेट की जा सकने वाली रिपोर्ट के एग्रीगेट का फ़ाइनल आउटपुट होती हैं. इन्हें पहले योगदान या हिस्टोग्राम में योगदान कहा जाता था.
एपीआई करने के तरीके में बदलाव
हेडर पर आधारित सोर्स का रजिस्ट्रेशन (इवेंट-लेवल की रिपोर्ट)
क्या बदल रहा है और क्यों?
जब उपयोगकर्ता किसी विज्ञापन को देखता है या उस पर क्लिक करता है, तो ब्राउज़र (खास तौर पर उपयोगकर्ता के डिवाइस पर) इस इवेंट को, एट्रिब्यूशन रिपोर्टिंग के लिए खास तौर पर बने पैरामीटर (जैसे कि attributionsourceeventid, attributiondestination, attributionexpiry, और दूसरे पैरामीटर) के साथ रिकॉर्ड करता है. इन पैरामीटर की
वैल्यू adtech सेट करती है.
इन पैरामीटर को सेट करने का तरीका बदल रहा है.
पिछले प्रस्ताव में, पैरामीटर को क्लाइंट-साइड में शामिल किया जाना था: या तो एचटीएमएल एट्रिब्यूट के तौर पर ऐंकर टैग या JS-आधारित कॉल के आर्ग्युमेंट के तौर पर. पैरामीटर के बारे में जानकारी, क्लिक या व्यू के समय होनी चाहिए.
नए प्रस्ताव में, इन पैरामीटर की वैल्यू को adtech सर्वर पर तय किया गया है.
इसके कई फ़ायदे हैं, खास तौर पर सुरक्षा के मामले में: हेडर सिस्टम की मदद से रिपोर्टिंग ऑरिजिन, आम तौर पर, विज्ञापन टेक्नोलॉजी से मिलता-जुलता है. इससे यह कंट्रोल किया जा सकता है कि कोई एट्रिब्यूशन सोर्स उसके दायरे में रजिस्टर है या नहीं. इससे धोखाधड़ी की समस्याओं को कुछ हद तक कम किया जाता है, क्योंकि इस बदलाव के बाद असली ब्राउज़र कभी भी रिपोर्टिंग ऑरिजिन के ऑप्ट-इन के बिना सोर्स को रजिस्टर नहीं करेगा.
सोर्स रजिस्ट्रेशन कैसे काम करता है?
- किसी दिए गए विज्ञापन के लिए, AdTech को अब एक खास क्लाइंट-साइड एट्रिब्यूट
attributionsrcको तय करना होगा. इस एट्रिब्यूट की वैल्यू एक ऐसा यूआरएल है जिस पर ब्राउज़र अनुरोध भेजेगा. इस अनुरोध में एक नया एचटीटीपी हेडरAttribution-Reporting-Source-Infoशामिल होगा, जिसकी वैल्यूnavigationयाevent,बताती है कि सोर्स, क्लिक था या व्यू. - यह अनुरोध मिलने पर, क्लिक/व्यू ट्रैकिंग सर्वर को ऐसे एचटीटीपी हेडर,
Attribution-Reporting-Register-Sourceके साथ रिस्पॉन्स देना चाहिए जिसमें मनचाहे एट्रिब्यूशन पैरामीटर शामिल होते हैं. इस हेडर को दिखाने वाला ऑरिजिन अब रिपोर्टिंग ऑरिजिन (पहले इसे
attributionreporttoके नाम से जाना जाता था) है.एचटीटीपी रिस्पॉन्स हेडर
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
एट्रिब्यूशन सोर्स रजिस्टर करना
सार्वजनिक चर्चा में हिस्सा लें
हेडर-आधारित एट्रिब्यूशन ट्रिगर (इवेंट-लेवल की रिपोर्ट)
क्या बदल रहा है और क्यों?
क्लिक या व्यू रजिस्ट्रेशन की तरह ही, नया प्रस्ताव एट्रिब्यूशन ट्रिगर को बदल देता है—जब कोई विज्ञापन टेक्नोलॉजी, ब्राउज़र को कन्वर्ज़न रिकॉर्ड करने का निर्देश देती है, तो यह हेडर-आधारित तरीका बन जाता है.
यह तरीका, हेडर पर आधारित सोर्स रजिस्ट्रेशन के मुताबिक है. साथ ही, यह पहले इस्तेमाल किए गए रीडायरेक्ट करने के तरीके की तुलना में ज़्यादा पारंपरिक है.
इसके अलावा, नए प्रस्ताव में, कन्वर्ज़न पेज पर attributionsrc एट्रिब्यूट होना ज़रूरी है.
वजह, अनुमतियों के मामले में है: पिछले प्रस्ताव में, ट्रिगर-साइड साइट—आम तौर पर, विज्ञापन देने वाली किसी साइट—का Permissions-Policy हेडर के ज़रिए सुविधा पर सामान्य कंट्रोल होता है, लेकिन एलिमेंट के स्तर पर इस बात का पूरा कंट्रोल नहीं होता कि कोई एलिमेंट किसी पक्ष को अनुरोध भेज सकता है या नहीं. इससे, आखिर में एट्रिब्यूशन ट्रिगर होता है. attributionsrc इसमें बदलाव करता है: इस ज़रूरी मार्कर की मदद से, विज्ञापन देने वाले व्यक्ति या कंपनी को निगरानी करने की सुविधा मिलती है. साथ ही, इससे यह कंट्रोल किया जा सकता है कि कौनसे एलिमेंट एट्रिब्यूशन को ट्रिगर कर सकते हैं.
ध्यान दें कि सोर्स साइड पर—आम तौर पर पब्लिशर साइट—Permissions-Policy के ज़रिए पेज-वाइड कंट्रोल और attributionsrc के ज़रिए पूरे एलिमेंट पर कंट्रोल मौजूद होते हैं.
एट्रिब्यूशन ट्रिगर कैसे काम करता है?
पिक्सल का अनुरोध मिलने और इसे कन्वर्ज़न के तौर पर कैटगरी में डालने का फ़ैसला लेने पर, AdTech को नए एचटीटीपी
हेडर Attribution-Reporting-Register-Event-Trigger के साथ जवाब देना चाहिए.
इस हेडर की वैल्यू से पता चलता है कि ट्रिगर इवेंट को JSON ऑब्जेक्ट के तौर पर कैसे दिखाया जाए. यह वही जानकारी है जिसे पिछले प्रस्ताव में क्वेरी पैरामीटर के रूप में परिभाषित किया गया था.
एचटीटीपी रिस्पॉन्स हेडर Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
रीडायरेक्ट करना (ज़रूरी नहीं)
इसके अलावा, एडटेक सर्वर Attribution-Reporting-Register-Event-Trigger को एक रीडायरेक्ट रिस्पॉन्स के तौर पर रिस्पॉन्स दे सकता है.
इससे तीसरे पक्ष को कन्वर्ज़न इवेंट की निगरानी करने में मदद मिलती है और वे ब्राउज़र को कन्वर्ज़न इवेंट का क्रेडिट देने का निर्देश दे पाते हैं.
रीडायरेक्ट करना ज़रूरी नहीं है. विज्ञापन टेक्नोलॉजी और तीसरे पक्ष, दोनों के पेज पर पिक्सल होने पर इसकी ज़रूरत नहीं पड़ती है.
ज़्यादा जानकारी के लिए, तीसरे पक्ष की रिपोर्टिंग पर जाएं.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
सार्वजनिक चर्चा में हिस्सा लें
कोई वर्कलेट नहीं (एग्रीगेट करने लायक रिपोर्ट)
क्या बदल रहा है और क्यों?
इकट्ठा की जा सकने वाली रिपोर्ट के पिछले प्रस्ताव में, JavaScript पर आधारित एक वर्कलेट को शुरू करने के लिए JavaScript ऐक्सेस की ज़रूरत थी—जो इन रिपोर्ट को जनरेट करेगा.
नए प्रस्ताव में, वर्कलेट की ज़रूरत नहीं है. इसके बजाय, विज्ञापन टेक्नोलॉजी, एचटीटीपी हेडर की मदद से डिक्लेरेटिव टोन वाले नियमों को तय करेगी. इन नियमों का इस्तेमाल करके, ब्राउज़र को एग्रीगेट की जा सकने वाली रिपोर्ट जनरेट करनी चाहिए.
नए प्रस्ताव के कई फ़ायदे हैं:
- ब्राउज़र को लागू करना: वर्कलेट डिज़ाइन के उलट, नया डिज़ाइन काफ़ी आसान है, क्योंकि इसके लिए ब्राउज़र से एक्ज़ीक्यूशन की ज़रूरत नहीं पड़ती.
- डेवलपर अनुभव: नया डिज़ाइन, हेडर पर निर्भर करता है. डेवलपर इन हेडर का इस्तेमाल आम तौर पर करते हैं और इनके बारे में डेवलपर को सबसे ज़्यादा जानकारी होती है. यह वर्कलेट से अलग होता है. यह सोर्स रजिस्ट्रेशन के लिए, एपीआई के प्लैटफ़ॉर्म के साथ भी काम करता है. इससे एपीआई को सीखना और इस्तेमाल करना आसान हो जाता है.
- इस्तेमाल करना: नए डिज़ाइन में, ज़्यादा मौजूदा मेज़रमेंट सिस्टम को एग्रीगेट की जा सकने वाली रिपोर्ट इस्तेमाल करने की सुविधा मिलती है. मेज़रमेंट के कई तरीके सिर्फ़ एचटीटीपी होते हैं: वे इमेज के अनुरोधों—पिक्सल के अनुरोधों—पर भरोसा करते हैं, जिन्हें JavaScript ऐक्सेस की ज़रूरत नहीं होती. हालांकि, वर्कलेट वाले तरीके के लिए JavaScript का ऐक्सेस ज़रूरी था. इसलिए, हो सकता है कि कुछ मौजूदा मेज़रमेंट सिस्टम से माइग्रेट करना मुश्किल हो.
- मज़बूत: नया डिज़ाइन, डेटा का नुकसान कम करने में मदद करता है, क्योंकि
keepaliveसिमैंटिक के साथ इंटिग्रेट करना आसान हो गया है. उदाहरण के लिए, जब उपयोगकर्ता किसी पेज को छोड़कर जा रहा हो और उस समय कोई क्लिक या व्यू रजिस्टर हो.
वर्कलेट-फ़्री तकनीक कैसे काम करती है?
यह एलान करने का तरीका, एचटीटीपी हेडर पर आधारित होता है. ठीक उसी तरह, जैसे इवेंट-लेवल पर सोर्स रजिस्ट्रेशन और एट्रिब्यूशन ट्रिगर हेडर होता है. इस बारे में ज़्यादा जानकारी अगले सेक्शन में दी गई है.
सार्वजनिक चर्चा में हिस्सा लें
हेडर-आधारित सोर्स रजिस्ट्रेशन (एग्रीगेट की जा सकने वाली रिपोर्ट)
एग्रीगेट की जा सकने वाली रिपोर्ट के लिए, सोर्स को रजिस्टर करने का एक नया तरीका सुझाया गया है. यह तरीका इवेंट लेवल पर सोर्स रजिस्ट्रेशन की तरह ही है.
सिर्फ़ हेडर का नाम अलग है: Attribution-Reporting-Register-Aggregatable-Source.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
एट्रिब्यूशन सोर्स का रजिस्ट्रेशन
हेडर-आधारित एट्रिब्यूशन ट्रिगर (एग्रीगेट करने लायक रिपोर्ट)
एग्रीगेट की जा सकने वाली रिपोर्ट के लिए, सोर्स को रजिस्टर करने का एक नया तरीका सुझाया गया है. यह तरीका इवेंट-लेवल एट्रिब्यूशन ट्रिगर की तरह ही है.
सिर्फ़ हेडर का नाम अलग है: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
एट्रिब्यूशन ट्रिगर रजिस्ट्रेशन
नई सुविधाएं
तीसरे पक्ष की रिपोर्टिंग (इवेंट लेवल की रिपोर्ट और इकट्ठा की जा सकने वाली रिपोर्ट)
क्या बदल रहा है और क्यों?
नए प्रस्ताव के दो पहलू, तीसरे पक्ष की रिपोर्टिंग के इस्तेमाल के उदाहरणों को बेहतर तरीके से समझने में मदद कर सकते हैं:
- इसके अलावा, विज्ञापन टेक्नोलॉजी से जुड़े नेटवर्क अनुरोधों को दूसरे ऐडटेक सर्वर पर रीडायरेक्ट किया जा सकता है. इससे दूसरी एडटेक कंपनियों को अपना सोर्स दिखाने और रजिस्ट्रेशन ट्रिगर करने की अनुमति मिलती है. आज तीसरे पक्षों को कॉन्फ़िगर करने का यह एक सामान्य तरीका है. इससे तीसरे पक्ष के मौजूदा रिपोर्टिंग सिस्टम के साथ-साथ, एपीआई को इस्तेमाल करना आसान हो जाता है.
- रिपोर्टिंग के ऑरिजिन, आम तौर पर, विज्ञापन टेक्नोलॉजी से जुड़े होते हैं. इन डिवाइसों पर निजता से जुड़ी ज़्यादातर सीमाएं लागू नहीं होती हैं. यह उन मामलों में काम करता है जहां एक से ज़्यादा विज्ञापन टेक्नोलॉजी एक ही पब्लिशर या विज्ञापन देने वाले के साथ काम करती हैं.
तीसरे पक्ष की रिपोर्टिंग कैसे काम करती है?
नए प्रस्ताव में, रिस्पॉन्स पर आधारित सोर्स रजिस्ट्रेशन और ट्रिगर, एचटीटीपी हेडर पर निर्भर करता है. इस तरह के अनुरोधों के लिए, विज्ञापन टेक्नोलॉजी, एचटीटीपी रीडायरेक्ट का फ़ायदा उठा सकती है.
अगर किसी पब्लिशर साइट (सोर्स रजिस्ट्रेशन) पर किए गए क्लिक/व्यू अनुरोध को बाद में एक से ज़्यादा पक्षों को रीडायरेक्ट किया जाता है, तो इनमें से हर पक्ष इस व्यू या क्लिक (सोर्स इवेंट) को रजिस्टर कर सकता है.
इसी तरह, कोई AdTech किसी ऐडवर्टाइज़र साइट से किए गए एट्रिब्यूशन के खास अनुरोध को रीडायरेक्ट कर सकता है. इससे कई दूसरे पक्ष कन्वर्ज़न (एट्रिब्यूशन ट्रिगर) को रजिस्टर कर सकते हैं.
हर पक्ष अपनी अलग-अलग रिपोर्ट ऐक्सेस कर सकता है और उन्हें अलग-अलग डेटा के साथ कॉन्फ़िगर कर सकता है.
रीडायरेक्ट के बिना कई ट्रिगर रजिस्टर करें
रीडायरेक्ट का इस्तेमाल किए बिना, कन्वर्ज़न साइड पर कई पिक्सल एलिमेंट (हर ट्रिगर के लिए एक) जोड़कर, कई एट्रिब्यूशन ट्रिगर को रजिस्टर किया जा सकता है.
सार्वजनिक चर्चा में हिस्सा लें
व्यू-थ्रू मेज़रमेंट (इवेंट-लेवल रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट)
क्या बदल रहा है और क्यों?
नए प्रस्ताव में, व्यू-थ्रू मेज़रमेंट और क्लिक-थ्रू मेज़रमेंट एक साथ काम करता है:
registerattributionsrc, व्यू के लिए दिया गया वह एट्रिब्यूट जिसका इस्तेमाल करके ब्राउज़र को क्लिक के साथ व्यू रिकॉर्ड करने के निर्देश दिए जाते हैं. अब यह एट्रिब्यूट भी इस प्रस्ताव का हिस्सा नहीं है.- निजता नीति अब सभी क्लिक और व्यू पर एक साथ मिल गई है. इस बारे में, शोर और पारदर्शिता में दी गई जानकारी देखें.
इस बदलाव को हेडर पर आधारित रजिस्ट्रेशन के नए तरीके के मुताबिक बनाने का सुझाव दिया जाता है. जब क्लिक और व्यू-थ्रू मेज़रमेंट, दोनों को सपोर्ट करना हो, तब डेवलपर को बेहतर अनुभव भी मिल सकता है.
व्यू-थ्रू मेज़रमेंट कैसे काम करता है?
व्यू-थ्रू मेज़रमेंट और क्लिक-थ्रू मेज़रमेंट, दोनों हेडर पर आधारित रजिस्ट्रेशन पर निर्भर करते हैं.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
इवेंट-लेवल की रिपोर्ट (क्लिक और व्यू, दोनों के लिए)
सार्वजनिक चर्चा में हिस्सा लें
डीबग करना / परफ़ॉर्मेंस का विश्लेषण (इवेंट लेवल की रिपोर्ट और इकट्ठा की जा सकने वाली रिपोर्ट)
क्या बदल रहा है और क्यों?
प्रस्ताव में डीबग करने का एक तरीका जोड़ा गया है. इससे डेवलपर को गड़बड़ियों का पता लगाने में मदद मिलेगी. साथ ही, एट्रिब्यूशन रिपोर्टिंग की परफ़ॉर्मेंस की तुलना कुकी पर आधारित मौजूदा मेज़रमेंट समाधानों से की जा सकेगी.
डीबग करने की सुविधा कैसे काम करती है?
सोर्स और ट्रिगर रजिस्ट्रेशन, दोनों में नए पैरामीटर debug_key को स्वीकार किया जाएगा. यह 64-बिट वाला, बिना हस्ताक्षर वाला एक पूर्णांक (यह एक बड़ी संख्या है).
अगर कोई रिपोर्ट, सोर्स और ट्रिगर डीबग कुंजियों की मदद से बनाई गई है और रिपोर्टिंग ऑरिजिन के कुकी जार में सोर्स और ट्रिगर रजिस्ट्रेशन के समय पर Samesite=None ar_debug=1 कुकी मौजूद है, तो .well-known/attribution-reporting/debug एंडपॉइंट पर डीबग रिपोर्ट (JSON) भेजी जाएगी:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
इवेंट-लेवल और इकट्ठा की जा सकने वाली रिपोर्ट में ये दो नए पैरामीटर भी शामिल होंगे, ताकि उन्हें सही डीबग रिपोर्ट से जोड़ा जा सके.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
ज़रूरी नहीं: एक्सटेंडेड डीबग की रिपोर्ट
सार्वजनिक चर्चा में हिस्सा लें
फ़िल्टर करने की सुविधाएं (इवेंट लेवल की रिपोर्ट और इकट्ठा की जा सकने वाली रिपोर्ट)
क्या बदल रहा है और क्यों?
ये मौजूदा विज्ञापन नेटवर्क में इस्तेमाल के ज़रूरी उदाहरण देते हैं. इसलिए, अब इवेंट-लेवल और इकट्ठा करने लायक, दोनों रिपोर्ट में इस्तेमाल के कई उदाहरण काम करेंगे:
- कन्वर्ज़न फ़िल्टर करना: सोर्स साइड की जानकारी के आधार पर कन्वर्ज़न को फ़िल्टर करें. उदाहरण में, विज्ञापन पर क्लिक और व्यू के लिए अलग-अलग ट्रिगर डेटा (कन्वर्ज़न डेटा) चुनें.
- एट्रिब्यूशन का मेल न खाना: ऐसे कन्वर्ज़न फ़िल्टर करें जिन्हें गलत एट्रिब्यूट किया गया है. यह खास तरह की कन्वर्ज़न फ़िल्टर करने की सुविधा है. उदाहरण के लिए, ऐसे कन्वर्ज़न फ़िल्टर करें जो एपीआई में etld+1 डेस्टिनेशन के दायरे की वजह से गलत विज्ञापन क्लिक/व्यू से मैच होते हैं.
फ़िल्टर करने की सुविधाएं कैसे काम करती हैं? (इवेंट-लेवल की रिपोर्ट के लिए)
सोर्स-साइड JSON ऑब्जेक्ट में मौजूद source_data फ़ील्ड का इस्तेमाल करना ज़रूरी नहीं है. इससे ऐसे आइटम तय किए जा सकते हैं जिन्हें ब्राउज़र, कन्वर्ज़न के समय इस्तेमाल करेगा, ताकि फ़िल्टर करने का लॉजिक लागू किया जा सके.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
ट्रिगर रजिस्ट्रेशन अब एक वैकल्पिक हेडर Attribution-Reporting-Filters को स्वीकार करेगा.
एचटीटीपी रिस्पॉन्स हेडर Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
इसके अलावा, Attribution-Reporting-Register-Event-Trigger हेडर को filters फ़ील्ड के साथ बढ़ाया जा सकता है, ताकि trigger_data को source_data के आधार पर सेट किया जा सके.
अगर source_data में, JSON मैच कुंजियों के फ़िल्टर में मौजूद बटन, इंटरसेक्शन खाली है, तो ट्रिगर को
पूरी तरह से अनदेखा कर दिया जाता है.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
सार्वजनिक चर्चा में हिस्सा लें
निजता सुरक्षा से जुड़े बदलाव
शोर और पारदर्शिता (इवेंट-लेवल की रिपोर्ट और इकट्ठा की जा सकने वाली रिपोर्ट)
क्या बदल रहा है और क्यों?
इस नए प्रस्ताव में, रिपोर्ट के लिए निजता की सुरक्षा करने के तरीकों में से एक को बेहतर किया गया है: रिपोर्ट बिना किसी क्रम के जवाब दी जाती हैं.
इसका मतलब है कि कुछ असल कन्वर्ज़न सही तरीके से रिपोर्ट किए जाएंगे. साथ ही, कुछ प्रतिशत मामलों में, कुछ असल कन्वर्ज़न छिपा दिए जाएंगे या कुछ नकली कन्वर्ज़न जोड़ दिए जाएंगे.
इस नई तकनीक के कुछ फ़ायदे हैं:
- यह क्लिक और व्यू से जुड़ी निजता तकनीक को एक साथ करती है.
- ट्रिगर डेटा (कन्वर्ज़न डेटा) और ट्रिगर-सोर्स लिंक के शोर को अलग करने के तरीके के बजाय, इसे समझना आसान है.
- यह एक निजता फ़्रेमवर्क सेट अप करता है, जो सही नॉइज़ सेटिंग की मदद से यह पक्का कर सकता है कि कोई भी पक्ष इस एपीआई पर भरोसा करके यह पक्का नहीं कर सकता कि किसी उपयोगकर्ता ने किसी खास विज्ञापन के लिए कन्वर्ज़न किया है या नहीं.
यह नया तरीका, उस पिछले तरीके को बदल देता है जिसमें 5% बार, ट्रिगर डेटा (कन्वर्ज़न डेटा) को रैंडम वैल्यू से बदला गया था.
इसके अलावा, किसी भी क्रम में जवाब मिलने की संभावना की वैल्यू को रिपोर्ट के मुख्य हिस्से (randomized_trigger_rate फ़ील्ड) में जोड़ा गया है. यह फ़ील्ड इस बात की संभावना (0 से 1) बताता है कि कोई सोर्स, किसी भी क्रम में जवाब दे सकता है या नहीं.
इसके दो मुख्य फ़ायदे हैं:
- इससे, ब्राउज़र के काम करने के तरीके को उन पक्षों के लिए transparent कर दिया जाता है जिन्हें रिपोर्ट मिलेंगी. आम तौर पर, विज्ञापन टेक्नोलॉजी से जुड़ी सेवाएं.
- यह आने वाले समय के लिए तब फ़ायदेमंद होता है, जब एपीआई को सभी ब्राउज़र पर काम किया जाएगा: अलग-अलग ब्राउज़र अपने निजता से जुड़े लक्ष्यों के आधार पर गै़र-ज़रूरी डेटा के अलग-अलग लेवल लागू करने का फ़ैसला ले सकते हैं. साथ ही, जो पक्ष रिपोर्ट मैनेज करेंगे, उन्हें इसकी जानकारी की ज़रूरत होगी.
शोर कैसे काम करता है?
नए प्रस्ताव में, किसी स्रोत के रजिस्टर होने पर (यानी किसी विज्ञापन पर क्लिक या व्यू रिकॉर्ड किया जाता है), ब्राउज़र रैंडम तरीके से यह तय करता है कि क्या वह सही तरीके से कन्वर्ज़न का क्रेडिट देगा और इस विज्ञापन क्लिक/व्यू के लिए रिपोर्ट भेजेगा या फिर वह स्रोत के बजाय नकली आउटपुट जनरेट करेगा.
नकली आउटपुट ये हो सकता है:
- कोई भी रिपोर्ट नहीं—इससे कोई फ़र्क़ नहीं पड़ता कि उपयोगकर्ता ग्राहक में बदला है या नहीं;
- एक या कई फ़र्ज़ी रिपोर्ट—इससे कोई फ़र्क़ नहीं पड़ता कि उपयोगकर्ता, ग्राहक में बदला है या नहीं.
नकली रिपोर्ट में, ट्रिगर डेटा (कन्वर्ज़न डेटा) बिना किसी क्रम के होता है: क्लिक के लिए कोई भी 3-बिट वैल्यू (0 से 7 के बीच की कोई भी संख्या) और व्यू के लिए रैंडम 1-बिट वैल्यू (0 या 1) होती है.
असली रिपोर्ट की तरह, उपयोगकर्ता के ग्राहक में बदलने के तुरंत बाद नकली रिपोर्ट नहीं भेजी जाती. इन्हें किसी भी रिपोर्टिंग विंडो के आखिर में भेजा जाता है.
क्लिक (क्लिक के 2 दिन, 7 दिन या क्लिक के 30 दिन बाद) के लिए तीन रिपोर्टिंग विंडो होती हैं. हर नकली रिपोर्ट, किसी एक रिपोर्टिंग विंडो को रैंडम तरीके से असाइन की जाती है.
इसके अलावा, जैसा कि पिछले प्रस्ताव में पहले ही बताया गया है, किसी विंडो के अंदर रिपोर्ट का क्रम बिना किसी खास क्रम के होता है.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
ग़ैर-ज़रूरी नकली कन्वर्ज़न के उदाहरण
सार्वजनिक चर्चा में हिस्सा लें
रिपोर्टिंग की सीमाएं (इवेंट लेवल की रिपोर्ट और इकट्ठा की जा सकने वाली रिपोर्ट)
क्या बदल रहा है और क्यों?
नए प्रस्ताव में साफ़ तौर पर यह तय किया गया है कि कितने पक्ष, दो साइटों के बीच इवेंट को मेज़र कर सकते हैं.
- रिपोर्टिंग के यूनीक ऑरिजिन (आम तौर पर, adtech) की ज़्यादा से ज़्यादा संख्या 100 हर 30 दिन तय की जा सकती है. यह संख्या, हर {publisher,Advertiser}, सोर्स के हिसाब से रजिस्टर हो सकती है. हर विज्ञापन क्लिक या व्यू (सोर्स इवेंट) के लिए, इस काउंटर को बढ़ा दिया जाएगा. भले ही, इन्हें एट्रिब्यूट नहीं किया गया हो.
- हर {publisher, Advertiser} के लिए रिपोर्ट भेजने वाले यूनीक रिपोर्टिंग ऑरिजिन (आम तौर पर, adtech) की ज़्यादा से ज़्यादा संख्या को 10 दिन पर सेट करने का प्रस्ताव है. हर एट्रिब्यूट किए गए कन्वर्ज़न के लिए, यह काउंटर बढ़ाया जाएगा.
ये सीमाएं इतनी ज़्यादा होनी चाहिए कि इनसे किसी भी कलाकार के कन्वर्ज़न मेज़र करने की क्षमता सीमित न हो. हालांकि, ये इतनी कम हैं कि एपीआई के गलत इस्तेमाल को कम करने में मदद मिल सकती है.
रिपोर्टिंग की कूलडाउन / दर की सीमाएं
क्या बदल रहा है और क्यों?
कूलडाउन रिपोर्ट करना एक ऐसा निजता सिस्टम है जो किसी तय समयावधि में, इस एपीआई से भेजी जाने वाली कुल जानकारी को कम करता है.
नए प्रस्ताव में, हर {source site, destination, Reporting origin} के लिए 100 रिपोर्ट (आम तौर पर, {publisher, advertiser, adtech}) को 30 दिनों के लिए शेड्यूल किया जा सकता है.
इस सीमा के बाद, ब्राउज़र इस {source site,destination, reporting origin} (आम तौर पर {publisher, Advertiser, adtech}) से मैच करने वाली रिपोर्ट शेड्यूल करना बंद कर देगा. ऐसा तब तक होगा, जब तक उस {source site, destination, reporting origin} के लिए 30-दिनों की रिपोर्ट की संख्या 100 से कम नहीं हो जाती.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
कूलडाउन / दर की सीमाओं की रिपोर्ट करना
डेस्टिनेशन कैपिंग (सिर्फ़ इवेंट-लेवल की रिपोर्ट)
क्या बदल रहा है और क्यों?
रिपोर्टिंग के ऑरिजिन (आम तौर पर, एक adtech) को दायरे में शामिल करने के लिए, डेस्टिनेशन कैपिंग में बदलाव किया गया है: हर {publisher, adtech} के लिए 100 ऐसी चुनिंदा डेस्टिनेशन (आम तौर पर, विज्ञापन देने वाली कंपनियों की साइटें या साइटें, जहां कन्वर्ज़न होने की उम्मीद होती है) को अनुमति दी जाती है.
ब्राउज़िंग इतिहास को फिर से बनाने की प्रक्रिया को सीमित करने के लिए, यह निजता सुरक्षा है.
ज़्यादा जानकारी के लिए, तकनीकी जानकारी वाला लेख पढ़ें
मंज़ूरी बाकी वाले सोर्स से कवर किए गए यूनीक डेस्टिनेशन की संख्या को सीमित करना
सभी संसाधन
- एट्रिब्यूशन रिपोर्टिंग देखें.
- आपको एपीआई के बारे में क्या पता होना चाहिए लेख पढ़ें.
हेडर इमेज Unsplash पर डायना पोलेखीना ने ली है.