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

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

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

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

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

  • अगर आपको एपीआई के बारे में पहले से ही जानकारी है. उदाहरण के लिए, हम डब्ल्यूआईसीजी रिपॉज़िटरी (डेटा स्टोर करने की जगह) से जुड़ी चर्चा में हिस्सा ले रहे हैं. साथ ही, आपको इस प्रोग्राम के बैच को समझना है प्रस्ताव में जनवरी 2022 में किए गए बदलाव.
  • अगर किसी डेमो में या प्रोडक्शन के किसी प्रयोग में Attribution Reporting API का इस्तेमाल किया जा रहा है.

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

माइग्रेशन जारी है

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

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

नाम में बदलाव

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

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

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

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

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

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

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

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

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

नए प्रस्ताव में, इन पैरामीटर की वैल्यू Adtech सर्वर पर तय की गई है.

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

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

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

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

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

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

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

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

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

समस्या #261

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

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

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

इसके अलावा, नए प्रस्ताव में कन्वर्ज़न पेज पर 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)
    }]

रीडायरेक्शन (ज़रूरी नहीं)

इसके अलावा, AdTech सर्वर ऐसा रिस्पॉन्स दे सकता है जिसमें Attribution-Reporting-Register-Event-Trigger को रीडायरेक्ट किया गया हो. हालांकि, ऐसा करना ज़रूरी नहीं है. इससे तीसरे पक्ष को कन्वर्ज़न इवेंट की निगरानी करने और ब्राउज़र को एट्रिब्यूट करने का निर्देश देने में मदद मिलती है.

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

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

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

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

समस्या #91

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

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

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

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

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

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

वर्कलेट-फ़्री मैकेनिज़्म कैसे काम करता है?

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

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

समस्या #194

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

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

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

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

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

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

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

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

नई सुविधाएं

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

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

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

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

तीसरे पक्ष की रिपोर्टिंग कैसे काम करती है?

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

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

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

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

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

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

समस्या #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 हेडर को source_data के आधार पर trigger_data को सेट करने के लिए, filters फ़ील्ड को चुनिंदा फ़िल्टर करने की ज़रूरत है.

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

वैकल्पिक एट्रिब्यूशन फ़िल्टर

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

लेख #194
समस्या #201

निजता सुरक्षा में किए गए बदलाव

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

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

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

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

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

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

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

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

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

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

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

नकली आउटपुट ये हो सकता है:

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

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

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

क्लिक के लिए तीन रिपोर्टिंग विंडो होती हैं (क्लिक के 2 दिन, 7 दिन या 30 दिन बाद). हर नकली किसी एक रिपोर्टिंग विंडो को रैंडम तरीके से रिपोर्ट असाइन की जाती है.

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

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

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

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

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

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

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

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

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

ये सीमाएं इतनी ज़्यादा होती हैं कि ये किसी भी कलाकार की क्षमता पर असर नहीं डालतीं हैं, लेकिन यह काफ़ी कम है. इससे एपीआई के गलत इस्तेमाल के कुछ मामलों को कम किया जा सकता है.

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

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

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

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

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

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

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

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

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

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

तकनीकी जानकारी वाले पेज पर जाकर ज़्यादा जानें

उन यूनीक डेस्टिनेशन की संख्या को सीमित करना जिन्हें स्वीकार नहीं किया गया है

सभी संसाधन

हेडर इमेज, Unस्प्लैश पर डियाना पोलेखीना से ली गई है.