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

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

Attribution Reporting API के डिज़ाइन के प्रस्ताव में बताया गया है कि एपीआई, Android वाले किसी एक डिवाइस पर इन ट्रिगर पाथ का एट्रिब्यूशन चालू करता है:

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

  • इवेंट-लेवल रिपोर्ट के लिए, हम एक डेस्टिनेशन फ़ील्ड का इस्तेमाल करेंगे. इससे यह पता चलता है कि ट्रिगर वेब (डेस्टिनेशन एक ईटीएलडी+1 है) पर हुआ है या ऐप्लिकेशन (डेस्टिनेशन ऐप्लिकेशन पैकेज का नाम है) पर
  • एग्रीगेट की जा सकने वाली रिपोर्ट के लिए, डेस्टिनेशन को क्लियरटेक्स्ट में भेजा जाता है.

वेब-टू-वेब मेज़रमेंट के असर

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

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

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

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

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

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

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

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

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

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

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

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

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

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 के Attribution Reporting API के साथ इंटिग्रेट करने का उदाहरण देखने के लिए, वेब के लिए प्राइवसी सैंडबॉक्स का प्रस्ताव देखें. ब्राउज़र, अनुरोध में ये हेडर जोड़ेगा:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

रिपोर्ट में निजता बनाए रखने के लिए लागू किए गए तरीकों पर असर

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

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

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

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

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

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

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

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

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

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

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

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

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