जनवरी 2022 में एट्रिब्यूशन रिपोर्टिंग के प्रस्ताव में हुए अपडेट

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

बदलावों का लॉग

यह पोस्ट किसके लिए है?

यह पोस्ट आपके लिए है:

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

अगर आपने अभी-अभी इस एपीआई का इस्तेमाल शुरू किया है और/या आपने अब तक इसका इस्तेमाल नहीं किया है, तो सीधे एपीआई के बारे में जानकारी पर जाएं.

माइग्रेशन की प्रक्रिया आगे बढ़ रही है

Chrome में ये बदलाव लागू होने के बाद: अगर किसी डेमो या प्रोडक्शन (ऑरिजिन ट्रायल) में एक्सपेरिमेंट के लिए, एट्रिब्यूशन रिपोर्टिंग एपीआई की इवेंट-लेवल रिपोर्ट का इस्तेमाल किया जाता है, तो एपीआई के काम करते रहने के लिए आपको अपने कोड में बदलाव करना होगा. नई सुविधाओं का इस्तेमाल भी किया जा सकता है.

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

नाम में बदलाव

खास जानकारी वाली रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट

आपको एग्रीगेट रिपोर्ट के तौर पर दिखने वाली रिपोर्ट को अब खास जानकारी वाली रिपोर्ट कहा जाएगा.

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

एपीआई के काम करने के तरीके में हुए बदलाव

हेडर पर आधारित सोर्स रजिस्ट्रेशन (इवेंट-लेवल रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

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

इन पैरामीटर को सेट करने का तरीका बदल रहा है.

पिछले प्रस्ताव में, पैरामीटर को क्लाइंट-साइड में शामिल करना था: या तो एचटीएमएल एट्रिब्यूट के तौर पर ऐंकर टैग में या JS-आधारित कॉल के आर्ग्युमेंट के तौर पर. क्लिक या व्यू के समय पैरामीटर की जानकारी होनी चाहिए.

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

हेडर पर आधारित सोर्स रजिस्ट्रेशन का डायग्राम

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

सोर्स रजिस्ट्रेशन कैसे काम करता है?

  1. किसी विज्ञापन के लिए, विज्ञापन टेक्नोलॉजी को अब एक खास क्लाइंट-साइड एट्रिब्यूट तय करना होगा attributionsrc. इस एट्रिब्यूट की वैल्यू एक यूआरएल होती है, जिस पर ब्राउज़र अनुरोध भेजेगा. इस अनुरोध में एक नया एचटीटीपी हेडर Attribution-Reporting-Source-Info शामिल होगा. इस हेडर की वैल्यू navigation या event, से पता चलता है कि सोर्स, क्लिक था या व्यू.
  2. यह अनुरोध मिलने पर, क्लिक/व्यू ट्रैकिंग सर्वर को एचटीटीपी हेडर, Attribution-Reporting-Register-Source के साथ जवाब देना चाहिए. इसमें, पसंदीदा एट्रिब्यूशन पैरामीटर शामिल होने चाहिए.

  3. यह हेडर दिखाने वाला ऑरिजिन, अब रिपोर्टिंग ऑरिजिन है. इसे पहले attributionreportto के तौर पर दिखाया जाता था.

    एचटीटीपी रिस्पॉन्स हेडर Attribution-Reporting-Register-Source:

    {
  "source_event_id": "267630968326743374",
  "destination": "https://toasters.example",
  "expiry": "604800000"
}

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

एट्रिब्यूशन सोर्स रजिस्टर करना

सार्वजनिक चर्चा में शामिल होना

समस्या #261

हेडर पर आधारित एट्रिब्यूशन ट्रिगर (इवेंट-लेवल रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

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

इसके अलावा, नए प्रस्ताव में कन्वर्ज़न पेज पर attributionsrc एट्रिब्यूट की वैल्यू देना ज़रूरी है.

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

ध्यान दें कि सोर्स साइड पर, आम तौर पर पब्लिशर साइट पर, Permissions-Policy के ज़रिए पेज-वाइड कंट्रोल और attributionsrc के ज़रिए एलिमेंट-वाइड कंट्रोल मौजूद होता है.

एट्रिब्यूशन ट्रिगर कैसे काम करता है?

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

रीडायरेक्ट करना ज़रूरी नहीं है. अगर पेज पर विज्ञापन टेक्नोलॉजी और तीसरे पक्ष, दोनों के पिक्सल मौजूद हैं, तो रीडायरेक्ट करने की ज़रूरत नहीं है.

ज़्यादा जानकारी के लिए, तीसरे पक्ष की रिपोर्टिंग पर जाएं.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

ट्रिगर करने वाला एट्रिब्यूशन

सार्वजनिक चर्चा में शामिल होना

समस्या #91

कोई वर्कलेट नहीं (एग्रीगेट की जा सकने वाली रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

एग्रीगेट की जा सकने वाली रिपोर्ट के लिए, पिछले प्रस्ताव में JavaScript ऐक्सेस की ज़रूरत थी. इससे, JavaScript पर आधारित एक तंत्र, वर्कलेट को शुरू किया जा सकता था. यह तंत्र, ये रिपोर्ट जनरेट करता था.

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

नए प्रस्ताव में कई फ़ायदे दिए गए हैं:

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

बिना वर्कलेट वाले सिस्टम का काम करने का तरीका क्या है?

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

सार्वजनिक चर्चा में शामिल होना

समस्या #194

हेडर पर आधारित सोर्स रजिस्ट्रेशन (एग्रीगेट की जा सकने वाली रिपोर्ट)

एग्रीगेट की जा सकने वाली रिपोर्ट के लिए सोर्स को रजिस्टर करने के लिए, एक नया तरीका सुझाया गया है. यह तरीका, इवेंट-लेवल पर सोर्स रजिस्टर करने के तरीके जैसा ही है.

सिर्फ़ हेडर का नाम अलग है: Attribution-Reporting-Register-Aggregatable-Source.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

एट्रिब्यूशन सोर्स का रजिस्ट्रेशन

हेडर पर आधारित एट्रिब्यूशन ट्रिगर (एग्रीगेट की जा सकने वाली रिपोर्ट)

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

सिर्फ़ हेडर का नाम अलग है: Attribution-Reporting-Register-Aggregatable-Trigger-Data.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

एट्रिब्यूशन ट्रिगर रजिस्ट्रेशन

नई सुविधाएं

तीसरे पक्ष की रिपोर्टिंग (इवेंट-लेवल की रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

नए प्रस्ताव के दो पहलु, तीसरे पक्ष की रिपोर्टिंग के इस्तेमाल के उदाहरणों को बेहतर तरीके से इस्तेमाल करने में मदद करते हैं:

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

तीसरे पक्ष की शिकायत करने की सुविधा कैसे काम करती है?

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

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

हर पक्ष अपनी अलग-अलग रिपोर्ट ऐक्सेस कर सकता है और उन्हें अलग-अलग डेटा के साथ कॉन्फ़िगर कर सकता है.

रीडायरेक्ट किए बिना एक से ज़्यादा ट्रिगर रजिस्टर करना

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

सार्वजनिक चर्चा में शामिल होना

समस्या #91 समस्या #261

व्यू-थ्रू मेज़रमेंट (इवेंट-लेवल की रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

नए प्रस्ताव में, व्यू-थ्रू मेज़रमेंट और क्लिक-थ्रू मेज़रमेंट एक ही तरीके से काम करते हैं:

  • registerattributionsrc, व्यू के हिसाब से इस्तेमाल होने वाला एट्रिब्यूट है. इससे ब्राउज़र को क्लिक के साथ-साथ व्यू रिकॉर्ड करने का निर्देश मिलता है. हालांकि, यह एट्रिब्यूट अब प्रस्ताव का हिस्सा नहीं है.
  • निजता से जुड़े तरीके, अब क्लिक और व्यू के लिए एक जैसे हैं. इस बारे में ज़्यादा जानने के लिए, शोर और पारदर्शिता सेक्शन देखें.

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

व्यू-थ्रू मेज़रमेंट कैसे काम करता है?

व्यू-थ्रू मेज़रमेंट और क्लिक-थ्रू मेज़रमेंट, दोनों हेडर पर आधारित रजिस्ट्रेशन पर निर्भर करते हैं.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

इवेंट-लेवल की रिपोर्ट (क्लिक और व्यू, दोनों के लिए)

सार्वजनिक चर्चा में शामिल होना

समस्या #261

डीबगिंग / परफ़ॉर्मेंस का विश्लेषण (इवेंट-लेवल की रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

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

कुकी पर आधारित नए डीबगिंग सिस्टम का डायग्राम

डीबग करने की सुविधा कैसे काम करती है?

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

अगर कोई रिपोर्ट, सोर्स और ट्रिगर डीबग बटन की मदद से बनाई गई है और सोर्स और ट्रिगर रजिस्ट्रेशन के समय, रिपोर्टिंग ऑरिजिन के कुकी जर्स में Samesite=None ar_debug=1 कुकी मौजूद है, तो डीबग रिपोर्ट (JSON) को .well-known/attribution-reporting/debug एंडपॉइंट पर भेजा जाएगा:

{
  "source_debug_key": 1234567890987,
  "trigger_debug_key": 4567654345028
}

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

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

ज़रूरी नहीं: डीबग करने से जुड़ी ज़्यादा जानकारी वाली रिपोर्ट

सार्वजनिक चर्चा में शामिल होना

समस्या #174

फ़िल्टर करने की सुविधाएं (इवेंट-लेवल की रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

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

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

अगर फ़िल्टर JSON में मौजूद कुंजियां, source_data में मौजूद कुंजियों से मेल खाती हैं, तो इंटरसेक्शन खाली होने पर ट्रिगर को
पूरी तरह से अनदेखा कर दिया जाता है.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

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

सार्वजनिक चर्चा में शामिल होना

समस्या #194
समस्या #201

निजता सुरक्षा से जुड़े बदलाव

शोर और पारदर्शिता (इवेंट-लेवल की रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

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

इस नई तकनीक के कुछ फ़ायदे हैं:

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

यह नया तरीका, पिछले तरीके की जगह लेता है. पिछले तरीके में, 5% समय पर ट्रिगर डेटा (कन्वर्ज़न डेटा) को किसी रैंडम वैल्यू से बदल दिया जाता था.

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

इससे दो मुख्य फ़ायदे मिलते हैं:

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

शोर की सुविधा कैसे काम करती है?

नए प्रस्ताव में, किसी सोर्स के रजिस्टर होने (यानी विज्ञापन पर क्लिक या व्यू रिकॉर्ड होने) के समय, ब्राउज़र यह तय करता है कि वह इस विज्ञापन पर क्लिक/व्यू के लिए, कन्वर्ज़न को सही तरीके से एट्रिब्यूट करेगा और रिपोर्ट भेजेगा या इसके बजाय नकली आउटपुट जनरेट करेगा.

नकली आउटपुट इनमें से कोई हो सकता है:

  • कोई रिपोर्ट नहीं—इससे कोई फ़र्क़ नहीं पड़ता कि उपयोगकर्ता ग्राहक में बदलता है या नहीं;
  • एक या उससे ज़्यादा फ़र्ज़ी रिपोर्ट—इससे कोई फ़र्क़ नहीं पड़ता कि उपयोगकर्ता ग्राहक में बदला है या नहीं.

नकली रिपोर्ट में, ट्रिगर डेटा (कन्वर्ज़न डेटा) रैंडम होता है: क्लिक के लिए रैंडम 3-बिट वैल्यू (0 से 7 के बीच कोई भी संख्या) और व्यू के लिए रैंडम 1-बिट वैल्यू (0 या 1).

असल रिपोर्ट की तरह, उपयोगकर्ता के ग्राहक में बदलने के तुरंत बाद, नकली रिपोर्ट नहीं भेजी जाती हैं. ये रिपोर्ट, रिपोर्टिंग विंडो के खत्म होने पर भेजी जाती हैं.

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

इसके अलावा, जैसा कि पिछले प्रस्ताव में पहले ही बताया गया है, किसी विंडो में रिपोर्ट का क्रम, रैंडम होता है.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

ग़ैर-ज़रूरी नकली कन्वर्ज़न के उदाहरण

सार्वजनिक चर्चा में शामिल होना

समस्या #84
समस्या #273

रिपोर्टिंग की सीमाएं (इवेंट-लेवल की रिपोर्ट और एग्रीगेट की जा सकने वाली रिपोर्ट)

रिपोर्टिंग के लिए ऑरिजिन की सीमाएं

क्या बदलाव हो रहा है और क्यों?

नए प्रस्ताव में साफ़ तौर पर यह तय किया गया है कि दो साइटों के बीच कितनी पार्टियां इवेंट मेज़र कर सकती हैं.

  • हर {publisher, advertiser} के लिए, ज़्यादा से ज़्यादा 30 दिनों में 100 यूनीक रिपोर्टिंग ऑरिजिन (आम तौर पर, विज्ञापन टेक्नोलॉजी) रजिस्टर किए जा सकते हैं. यह काउंटर, हर विज्ञापन पर क्लिक या व्यू (सोर्स इवेंट) के लिए बढ़ेगा. भले ही, उन इवेंट को एट्रिब्यूट न किया गया हो.
  • हर {publisher, advertiser} के लिए, रिपोर्ट भेजने वाली यूनीक रिपोर्टिंग ऑरिजिन (आम तौर पर, विज्ञापन टेक्नोलॉजी कंपनियां) की ज़्यादा से ज़्यादा संख्या हर 30 दिन में 10 होनी चाहिए. एट्रिब्यूट किए गए हर कन्वर्ज़न के लिए, इस काउंटर में बढ़ोतरी की जाएगी.

ये सीमाएं इतनी ज़्यादा होनी चाहिए कि वे किसी भी व्यक्ति या कंपनी की कन्वर्ज़न मेज़र करने की क्षमता को सीमित न करें. हालांकि, ये सीमाएं इतनी कम भी होनी चाहिए कि वे एपीआई के गलत इस्तेमाल को कम करने में मदद कर सकें.

कूलडाउन / दर की सीमाओं की रिपोर्टिंग

क्या बदलाव हो रहा है और क्यों?

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

नए प्रस्ताव में, हर {source site, destination, reporting origin} (आम तौर पर {publisher, advertiser, adtech}) के लिए, 30 दिनों में 100 रिपोर्ट शेड्यूल की जा सकती हैं.

इस सीमा के बाद, ब्राउज़र इस {source site, destination, reporting origin} (आम तौर पर {publisher, advertiser, adtech}) से मैच करने वाली रिपोर्ट शेड्यूल करना बंद कर देगा. ऐसा तब तक होगा, जब तक कि उस {source site, destination, reporting origin} के लिए, पिछले 30 दिनों की रोलिंग रिपोर्ट की संख्या 100 से कम नहीं हो जाती.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

रिपोर्ट करने के लिए कूलडाउन / दर की सीमाएं

डेस्टिनेशन कैपिंग (सिर्फ़ इवेंट-लेवल की रिपोर्ट)

क्या बदलाव हो रहा है और क्यों?

डेस्टिनेशन कैपिंग में बदलाव किया गया है, ताकि रिपोर्टिंग ऑरिजिन (आम तौर पर, कोई विज्ञापन टेक्नोलॉजी) को दायरे में शामिल किया जा सके: हर {publisher, adtech} के लिए, 100 यूनीक पेंडिंग डेस्टिनेशन (आम तौर पर, विज्ञापन देने वाली साइटें या ऐसी साइटें जहां कन्वर्ज़न होने की उम्मीद है) की अनुमति है.

यह निजता सुरक्षा की सुविधा है, जिससे ब्राउज़िंग इतिहास को फिर से बनाने की प्रोसेस को सीमित किया जा सकता है.

इस बारे में ज़्यादा जानने के लिए, तकनीकी जानकारी देने वाले वीडियो को देखें

बाकी सोर्स के दायरे में आने वाले यूनीक डेस्टिनेशन की संख्या को सीमित करना

सभी संसाधन

हेडर इमेज, Unsplash पर मौजूद Diana Polekhina की है.