एट्रिब्यूशन रिपोर्टिंग: क्रॉस ऐप्लिकेशन और वेब मेज़रमेंट

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

ट्रिगर पाथ

Attribution Reporting API के डिज़ाइन का सुझाव में बताया गया है कि यह एपीआई, Android डिवाइस पर इन ट्रिगर पाथ के एट्रिब्यूशन को चालू करता है. यहां वेब को इस तरह से परिभाषित किया गया है: (1) Android पर चलने वाला स्टैंडअलोन ब्राउज़र (जैसे, Chrome) या (2) Android ऐप्लिकेशन में चलने वाला WebView.

  • App-to-app: उपयोगकर्ता किसी ऐप्लिकेशन में विज्ञापन देखता है. इसके बाद, वह उसी ऐप्लिकेशन या इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन में ग्राहक में बदलता है.
  • App-to-web: जब कोई उपयोगकर्ता, ऐप्लिकेशन में विज्ञापन देखता है और वेब पर जाकर ग्राहक में बदलता है.
  • Web-to-app: उपयोगकर्ता को वेब पर कोई विज्ञापन दिखता है. इसके बाद, वह ऐप्लिकेशन में कन्वर्ज़न करता है.
  • Web-to-web: उपयोगकर्ता को वेब पर कोई विज्ञापन दिखता है और वह वेब पर ही ग्राहक में बदल जाता है.

ऊपर दिए गए ट्रिगर पाथ का मतलब है कि ये ज़रूरी शर्तें पूरी होनी चाहिए:

  • विज्ञापन टेक्नोलॉजी के लिए: ऐप्लिकेशन से वेब पर ले जाने वाले पाथ को चालू करने के लिए, एपीआई कॉल और रिपोर्टिंग से जुड़े अपडेट.
  • ऐप्लिकेशन और ब्राउज़र के लिए: वेब एट्रिब्यूशन सोर्स और वेब ट्रिगर के रजिस्ट्रेशन को Android पर पास करने की सुविधा.

इस दस्तावेज़ में बताया गया है कि Attribution Reporting API को ऐप्लिकेशन से वेब, वेब से ऐप्लिकेशन, और वेब से वेब ट्रिगर पाथ के साथ काम करने के लिए कैसे बढ़ाया जाता है. इसमें यह भी बताया गया है कि विज्ञापन टेक्नोलॉजी कंपनियों और ऐप्लिकेशन को, इन ट्रिगर पाथ को सपोर्ट करने की ज़रूरी शर्तों को पूरा करने के लिए, कौनसे बदलाव करने होंगे.

Attribution Reporting API का ऐक्सेस पाना

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

नाम दर्ज करने की प्रोसेस पूरी होने के बाद, अगर बिना नाम दर्ज किए रजिस्ट्रेशन करने का अनुरोध मिलता है, तो एपीआई रजिस्ट्रेशन को खारिज कर देगा.

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

विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों के लिए बदलाव

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

पंजीकरण और एट्रिब्यूशन में बदलाव

एट्रिब्यूशन सोर्स रजिस्टर करते समय, विज्ञापन टेक्नोलॉजी कंपनियां डेस्टिनेशन फ़ील्ड तय करती हैं. यह फ़ील्ड, ऐप्लिकेशन पैकेज का वह नाम होता है जहां ट्रिगर इवेंट होता है. ऐप्लिकेशन से वेब को मेज़र करने की सुविधा चालू करने के लिए, हम एक ऐप्लिकेशन डेस्टिनेशन फ़ील्ड (ऐप्लिकेशन पैकेज का नाम) और एक वेब डेस्टिनेशन फ़ील्ड (eTLD+1) के साथ काम करने की योजना बना रहे हैं.

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

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

ऐप्लिकेशन और वेब की रिपोर्ट पाना

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

वेब से वेब पर होने वाले मेज़रमेंट के असर

ऐप्लिकेशन यह तय करते हैं कि Attribution Reporting API को रजिस्ट्रेशन कब पास करना है. यहां कुछ बातों का ध्यान रखना ज़रूरी है:

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

यहां दिए गए उदाहरण में बताया गया है कि ब्राउज़र ऐप्लिकेशन, Attribution Reporting API के साथ कैसे काम कर सकते हैं. इससे, जब उपयोगकर्ता ब्राउज़र ऐप्लिकेशन और नॉन-ब्राउज़र ऐप्लिकेशन, दोनों में किसी विज्ञापन पर क्लिक करता है, तो सटीक मेज़रमेंट मिल पाता है:

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

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

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

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

ब्राउज़र के उलट, WebView सिर्फ़ Attribution-Reporting-Eligible हेडर में ओएस के साथ रजिस्ट्रेशन करने की सुविधा देता है. हालांकि, ऐसा सिर्फ़ तब होता है, जब Android का Attribution Reporting API उपलब्ध हो. अगर Android का Attribution Reporting API उपलब्ध नहीं है, तो WebView Attribution-Reporting-Eligible हेडर सेट नहीं करता है. साथ ही, कोई रजिस्ट्रेशन नहीं किया जाता है.

ओएस का इस्तेमाल करके, एट्रिब्यूशन सोर्स / ट्रिगर रजिस्टर करने के लिए:

  • विज्ञापन टेक्नोलॉजी कंपनियों को सोर्स रजिस्ट्रेशन का जवाब, Attribution-Reporting-Register-OS-Source हेडर का इस्तेमाल करके देना चाहिए. इससे WebView से registerSource() या registerWebSource() को सेकंडरी एपीआई कॉल शुरू होता है.
  • विज्ञापन टेक्नोलॉजी कंपनियां, Attribution-Reporting-Register-OS-Trigger हेडर का इस्तेमाल करके भी ट्रिगर रजिस्ट्रेशन का जवाब दे सकती हैं. इससे, WebView से registerWebTrigger() या registerTrigger() को दूसरा एपीआई कॉल शुरू होता है.

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

इस बारे में ज़्यादा जानकारी के लिए कि WebView, registerSource() / registerWebSource() और registerTrigger() / registerWebTrigger() का इस्तेमाल करेगा या नहीं (साथ ही, इस व्यवहार को बदलने का तरीका), WebView से एट्रिब्यूशन सोर्स और ट्रिगर रजिस्ट्रेशन लेख पढ़ें.

ट्रांज़िशन के दौरान डीबग करने से जुड़ी रिपोर्ट

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

एक ही ऐप्लिकेशन में होने वाले वेब-टू-वेब एट्रिब्यूशन (उदाहरण के लिए, एक ही ब्राउज़र ऐप्लिकेशन में) के लिए, एट्रिब्यूशन-सक्सेस और वर्बोस रिपोर्ट सिर्फ़ तब उपलब्ध होती हैं, जब तीसरे पक्ष की कुकी उपलब्ध हों. ये रिपोर्ट, विज्ञापन आईडी की उपलब्धता पर आधारित नहीं होती हैं.

ऐप्लिकेशन से वेब पर, वेब से ऐप्लिकेशन पर, और वेब से वेब पर क्रॉस-ऐप्लिकेशन एट्रिब्यूशन के लिए, एट्रिब्यूशन-सक्सेस और वर्बोस रिपोर्ट उपलब्ध होती हैं. ऐसा तब होता है, जब ऐप्लिकेशन पर AdID उपलब्ध हो और विज्ञापन टेक्नोलॉजी, वेब पर वही (सही) AdID पास कर सके.

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

ऐप्लिकेशन से वेब पर होने वाले कन्वर्ज़न के लिए, एट्रिब्यूशन-सक्सेस डीबगिंग रिपोर्ट चालू करने के लिए, ये शर्तें पूरी होनी चाहिए:

  • उपयोगकर्ता ने विज्ञापन आईडी का इस्तेमाल करके, दिलचस्पी के मुताबिक विज्ञापन दिखाए जाने की सुविधा से ऑप्ट आउट न किया हो
  • पब्लिशर ऐप्लिकेशन में, AdID की अनुमतियों का एलान किया गया हो
  • विज्ञापन टेक्नोलॉजी को ट्रिगर रजिस्ट्रेशन में AdID वैल्यू पास करनी होगी (वेब कॉन्टेक्स्ट से)

ऐप्लिकेशन से वेब पर रीडायरेक्ट करने की सुविधा के लिए, ज़्यादा जानकारी वाली डीबग रिपोर्ट चालू करने के लिए:

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

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

ऐप्लिकेशन के लिए बदलाव

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

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

ब्राउज़र, Android के एट्रिब्यूशन रिपोर्टिंग एपीआई के साथ कैसे इंटिग्रेट हो सकते हैं, ताकि क्रॉस ऐप्लिकेशन और वेब मेज़रमेंट को चालू किया जा सके. इसका उदाहरण देखने के लिए, Privacy Sandbox for the Web का प्रपोज़ल देखें. प्रस्ताव में, ब्राउज़र इन अनुरोध हेडर को जोड़ेगा:

  • Attribution-Reporting-Eligible यह ब्रॉडकास्ट करता है कि एट्रिब्यूशन के लिए ओएस-लेवल की सहायता उपलब्ध है या नहीं. इस मामले में, हेडर से पता चलता है कि Android का एट्रिब्यूशन रिपोर्टिंग एपीआई उपलब्ध है या नहीं.
  • अगर उपलब्ध हो, तो विज्ञापन टेक्नोलॉजी कंपनियां Attribution-Reporting-Register-OS-Source का इस्तेमाल करके जवाब दे सकती हैं. इससे ब्राउज़र ऐप्लिकेशन से registerWebSource() को दूसरा एपीआई कॉल शुरू होता है.
  • विज्ञापन टेक्नोलॉजी, Attribution-Reporting-Register-OS-Trigger हेडर का इस्तेमाल करके, ट्रिगर रजिस्ट्रेशन का जवाब भी दे सकती हैं. इससे ब्राउज़र ऐप्लिकेशन से registerWebTrigger() को दूसरा एपीआई कॉल शुरू होता है.

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

एट्रिब्यूशन सोर्स रजिस्टर करते समय, ऐप्लिकेशन registerWebSource() को कॉल कर सकते हैं. इसके लिए, इन पैरामीटर की ज़रूरत होती है:

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

    हर यूआरआई के साथ एक बूलियन Debug फ़्लैग होना चाहिए. इससे यह पता चलता है कि तकनीशियनों की ओर से दी गई डीबग कुंजियों को रिपोर्ट में शामिल किया जाना चाहिए या नहीं.
  • इनपुट इवेंट: यह InputEvent ऑब्जेक्ट (क्लिक इवेंट के लिए) या null (व्यू इवेंट के लिए) होता है
  • सोर्स ऑरिजिन: वह ऑरिजिन जिस पर सोर्स हुआ (पब्लिशर की वेबसाइट).
  • ओएस डेस्टिनेशन: ऐप्लिकेशन का पैकेज नाम, जहां ट्रिगर इवेंट होता है.
  • वेब डेस्टिनेशन: यह एक eTLD+1 होता है, जहां ट्रिगर इवेंट होता है.
  • पुष्टि किया गया डेस्टिनेशन: ओएस या वेब डेस्टिनेशन यूआरआई इंटेंट का इस्तेमाल, उपयोगकर्ता के क्लिक करने पर नेविगेशन के लिए किया जाता है.

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

  • एपीआई, विज्ञापन टेक्नोलॉजी की ओर से तय किए गए डेस्टिनेशन की पुष्टि, ऐप्लिकेशन की ओर से तय किए गए डेस्टिनेशन से करता है. अगर डेस्टिनेशन अलग-अलग होते हैं, तो एपीआई एट्रिब्यूशन सोर्स के रजिस्ट्रेशन को खारिज कर देता है.

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

registerWebSource() को कॉल करने के लिए, ऐप्लिकेशन को अनुमति वाली सूची में शामिल होना चाहिए. अनुमति वाली सूची में शामिल होने के लिए, यह फ़ॉर्म भरें. अनुमति वाली सूची का मकसद, वेब कॉन्टेक्स्ट के लिए भरोसा कायम करने से जुड़ी निजता की समस्याओं को कम करना है.

ट्रिगर (कन्वर्ज़न) रजिस्ट्रेशन

ट्रिगर रजिस्ट्रेशन पर, ऐप्लिकेशन registerWebTrigger() को कॉल कर सकते हैं. इसके लिए, इन पैरामीटर की ज़रूरत होती है:

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

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

डिफ़ॉल्ट रूप से, WebView registerSource() और registerWebTrigger() का इस्तेमाल करेगा. यह कुकी, ऐप्लिकेशन के साथ सोर्स और ट्रिगर होने पर WebView के टॉप-लेवल ऑरिजिन के साथ ट्रिगर को जोड़ती है.

अगर किसी ऐप्लिकेशन को अलग-अलग व्यवहार की ज़रूरत होती है (जैसे कि वेबव्यू में वेब कॉन्टेंट होस्ट करने वाले ऐप्लिकेशन), तो उन्हें androidx.webkit.WebViewSettingsCompat क्लास में setAttributionRegistrationBehavior तरीके का इस्तेमाल करना होगा. इस तरीके से यह तय किया जाएगा कि WebView को registerWebSource() या registerSource() और registerWebTrigger() या registerTrigger() को कॉल करना चाहिए या नहीं.

setAttributionRegistrationBehavior के लिए ये विकल्प उपलब्ध हैं:

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

निजता और सुरक्षा से जुड़ी बातें

इस सेक्शन में, Attribution Reporting API का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, निजता और सुरक्षा से जुड़ी बातों के बारे में बताया गया है.

रिपोर्ट पर लागू किए गए, निजता की सुरक्षा से जुड़े तरीकों पर असर

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

अगर ऐप्लिकेशन के लिए अनुरोध भेजने की अलग-अलग सीमाएं तय की जाती हैं, तो कोई विरोधी, एपीआई के लिए तय की गई सीमाओं के साथ-साथ ऐप्लिकेशन के लिए तय की गई सीमाओं का भी इस्तेमाल कर सकता है. इस समस्या को कम करने के लिए, ऐप्लिकेशन को यह पुष्टि करनी चाहिए कि दिया गया एट्रिब्यूशन सोर्स, ऐप्लिकेशन के मेज़रमेंट सलूशन और Android Attribution Reporting API, दोनों पर रजिस्टर नहीं है.

वेब कॉन्टेक्स्ट के लिए भरोसा कायम करना

वेब कॉन्टेक्स्ट एपीआई कॉल में, एपीआई को ऐप्लिकेशन पर भरोसा होता है कि वह सोर्स और डेस्टिनेशन के ऑरिजिन का पता लगाएगा और उन्हें तय करेगा. इससे निजता और सुरक्षा से जुड़ी समस्याएं हो सकती हैं:

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

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

कोई भी ऐप्लिकेशन registerWebTrigger() को कॉल कर सकता है, क्योंकि ट्रिगर करने वाले पक्ष की निजता और सुरक्षा से जुड़ी बातों को, सोर्स-साइड के साथ मिलीभगत के बिना लागू नहीं किया जा सकता.

उपयोगकर्ता नियंत्रण

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

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

आने वाले समय में ध्यान रखने वाली बातें और खुले सवाल

Attribution Reporting API के लिए, ऐप्लिकेशन से वेब पर इंटरऑपरेबिलिटी की सुविधा पर काम जारी है. हम कम्यूनिटी से कुछ आइडिया के बारे में सुझाव/राय पाना चाहते हैं:

  1. Android Privacy Sandbox के साथ काम करने वाले डिवाइस पर, Android Attribution Reporting API के साथ ब्राउज़र मेज़रमेंट समाधानों का इस्तेमाल कैसे किया जाएगा? क्या आपको सभी चीज़ें Android को पास करनी हैं?
  2. क्या हर एट्रिब्यूशन सोर्स और ट्रिगर के लिए, दो पिंग मिलने की कोई समस्या है? इनमें से एक पिंग ब्राउज़र या ऐप्लिकेशन से और दूसरा Attribution Reporting API से मिलता है.
  3. हम अलग-अलग एपीआई में डीबग करने की प्रोसेस को आपके लिए कैसे आसान बना सकते हैं?
  4. प्रस्ताव में यह पुष्टि करने की सुविधा शामिल नहीं है कि ऐप्लिकेशन और वेब डेस्टिनेशन, अफ़िलिएट हैं. आने वाले समय में, हम Digital Asset Links का इस्तेमाल करके, इन डेस्टिनेशन की पुष्टि कर सकते हैं. इसके लिए, हमें असोसिएशन की जांच करनी होगी. क्या इससे इस्तेमाल के किसी उदाहरण पर असर पड़ेगा? क्या इस पुष्टि के लिए, Digital Asset Links का इस्तेमाल करना सही है?
  5. एट्रिब्यूशन सोर्स रजिस्टर करते समय, आपको डेस्टिनेशन तय करना होगा. वेब से ऐप्लिकेशन पर रीडायरेक्ट करने के मामले में, आपको ऐप्लिकेशन लिंक तय करना पड़ सकता है. इस ऐप्लिकेशन लिंक के बारे में बताने के लिए, किन फ़ॉर्मैट का इस्तेमाल किया जाता है?
  6. ऐप्लिकेशन से वेब पर एट्रिब्यूशन सोर्स रजिस्टर करते समय, उस सोर्स इवेंट को ऐप्लिकेशन से Android Attribution Reporting API के साथ रजिस्टर करना होगा. उदाहरण के लिए, अगर उपयोगकर्ता किसी विज्ञापन पर क्लिक करता है और वह क्लिक, ब्राउज़र या ब्राउज़र के कस्टम टैब में खुलता है, तो उस क्लिक (सोर्स इवेंट) को ब्राउज़र के कॉन्टेक्स्ट में रजिस्टर करने के बजाय, ऐप्लिकेशन से रजिस्टर किया जाना चाहिए. अगर आपको इस बारे में कोई समस्या है या इस्तेमाल के ऐसे अन्य उदाहरण हैं जो समर्थित फ़्लो के बारे में बताने वाले इस लेख में शामिल कैटगरी में नहीं आते हैं, तो हमसे संपर्क करें.