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

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

• आने वाले समय में होने वाले बदलावों और ऐसी समस्याओं की सूची अपडेट की गई है जिनके बारे में आपको पहले से पता है

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

खास जानकारी

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

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

• इवेंट-लेवल की रिपोर्ट के लिए उपलब्ध बिट की संख्या सीमित करता है

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

• उपलब्ध ट्रिगर (कन्वर्ज़न) के लिए दर की सीमाएं और विज्ञापन टेक्नोलॉजी से जुड़ी उन कंपनियों की संख्या के बारे में जानकारी देता है जिन्हें एट्रिब्यूशन के एक सोर्स से जोड़ा जा सकता है

• इसमें आवाज़ में अलग-अलग तरह का शोर जोड़ने की तकनीकें शामिल हैं

ऊपर दिए गए तरीकों से, दो अलग-अलग ऐप्लिकेशन या डोमेन में उपयोगकर्ता की पहचान को लिंक करने की सुविधा सीमित हो जाती है.

Attribution Reporting API का इस्तेमाल इन उदाहरणों में किया जा सकता है:

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

Attribution Reporting API इस तरह काम करता है. इस दस्तावेज़ के बाद के सेक्शन में, इसके बारे में ज़्यादा जानकारी दी गई है:

1. Attribution Reporting API का इस्तेमाल करने के लिए, विज्ञापन टेक्नोलॉजी रजिस्ट्रेशन की प्रोसेस पूरी करती है.
2. विज्ञापन टेक्नोलॉजी, Attribution Reporting API के साथ एट्रिब्यूशन सोर्स रजिस्टर करती है. जैसे, विज्ञापन पर क्लिक या विज्ञापन व्यू.
3. विज्ञापन टेक्नोलॉजी, Attribution Reporting API की मदद से ट्रिगर रजिस्टर करती है. ये ट्रिगर, विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन या वेबसाइट पर होने वाले उपयोगकर्ता कन्वर्ज़न होते हैं.
4. Attribution Reporting API, ट्रिगर को एट्रिब्यूशन सोर्स (कन्वर्ज़न एट्रिब्यूशन) से मैच करता है. साथ ही, एक या उससे ज़्यादा ट्रिगर को डिवाइस से बाहर भेजा जाता है. ऐसा विज्ञापन टेक्नोलॉजी को इवेंट-लेवल और इकट्ठा की जा सकने वाली रिपोर्ट के ज़रिए किया जाता है.

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

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

एट्रिब्यूशन सोर्स (क्लिक या व्यू) रजिस्टर करना

Attribution Reporting API, विज्ञापन पर मिले क्लिक और व्यू को एट्रिब्यूशन सोर्स के तौर पर देखता है. विज्ञापन पर क्लिक या विज्ञापन व्यू को रजिस्टर करने के लिए, registerSource() को कॉल करें. इस API को इन पैरामीटर की ज़रूरत होती है:

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

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

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

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

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

यहां वर्कफ़्लो का एक उदाहरण दिया गया है:

1. विज्ञापन टेक्नोलॉजी एसडीके, एट्रिब्यूशन सोर्स रजिस्ट्रेशन शुरू करने के लिए एपीआई को कॉल करता है. साथ ही, एपीआई को कॉल करने के लिए यूआरआई तय करता है:

   registerSource(
       Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
       myClickEvent);
   

2. यह एपीआई, https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA से अनुरोध करता है. इसके लिए, इनमें से किसी एक हेडर का इस्तेमाल किया जाता है:

   <!-- For click events -->
   Attribution-Reporting-Source-Info: navigation
   
   <!-- For view events -->
   Attribution-Reporting-Source-Info: event
   

3. विज्ञापन टेक्नोलॉजी से जुड़ी इस कंपनी का एचटीटीपीएस सर्वर, हेडर के साथ जवाब देता है. इसमें ये शामिल हैं:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "234",
       "expiry": "60000",
       "priority": "5"
   }
   Attribution-Reporting-Redirect:
   https://adtechpartner1.example?their_ad_click_id=567
   Attribution-Reporting-Redirect:
   https://adtechpartner2.example?their_ad_click_id=890
   

4. एपीआई, Attribution-Reporting-Redirect में दिए गए हर यूआरएल के लिए अनुरोध करता है. इस उदाहरण में, विज्ञापन टेक्नोलॉजी पार्टनर के दो यूआरएल दिए गए हैं. इसलिए, एपीआई https://adtechpartner1.example?their_ad_click_id=567 को एक अनुरोध और https://adtechpartner2.example?their_ad_click_id=890 को दूसरा अनुरोध करता है.

5. विज्ञापन टेक्नोलॉजी से जुड़ी इस कंपनी का एचटीटीपीएस सर्वर, हेडर के साथ जवाब देता है. इसमें ये शामिल हैं:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "789",
       "expiry": "120000",
       "priority": "2"
   }
   

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

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

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

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

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

विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म, registerTrigger() तरीके का इस्तेमाल करके ट्रिगर रजिस्टर कर सकते हैं. जैसे, इंस्टॉल या इंस्टॉल के बाद होने वाले इवेंट जैसे कन्वर्ज़न.

registerTrigger() तरीके के लिए, ट्रिगर यूआरआई पैरामीटर ज़रूरी है. एपीआई, ट्रिगर से जुड़े मेटाडेटा को फ़ेच करने के लिए, इस यूआरआई पर अनुरोध भेजता है.

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

• ट्रिगर डेटा: ट्रिगर इवेंट की पहचान करने के लिए डेटा (क्लिक के लिए 3 बिट, व्यू के लिए 1 बिट). यह 64-बिट का साइंड इंटिजर होना चाहिए, जिसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया गया हो.

• ट्रिगर की प्राथमिकता (ज़रूरी नहीं): इससे यह पता चलता है कि एट्रिब्यूशन के एक ही सोर्स के लिए, इस ट्रिगर की प्राथमिकता अन्य ट्रिगर की तुलना में क्या है. यह 64-बिट का साइंड इंटिजर होना चाहिए. इसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया गया हो. प्राथमिकता तय करने से रिपोर्टिंग पर क्या असर पड़ता है, इस बारे में ज़्यादा जानने के लिए, प्राथमिकता तय करने से जुड़ा सेक्शन देखें.

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

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

• एग्रीगेशन वैल्यू (ज़रूरी नहीं): यह वैल्यू की ऐसी सूची होती है जो हर कुंजी में योगदान देती है.

• फ़िल्टर (ज़रूरी नहीं): इनका इस्तेमाल, चुनिंदा ट्रिगर या ट्रिगर डेटा को फ़िल्टर करने के लिए किया जाता है. ज़्यादा जानकारी के लिए, इस पेज पर ट्रिगर फ़िल्टर सेक्शन देखें.

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

एक से ज़्यादा विज्ञापन टेक्नोलॉजी कंपनियां, एक ही ट्रिगर इवेंट को रजिस्टर कर सकती हैं. इसके लिए, वे Attribution-Reporting-Redirect फ़ील्ड में रीडायरेक्ट का इस्तेमाल कर सकती हैं या registerTrigger() तरीके को कई बार कॉल कर सकती हैं. हमारा सुझाव है कि आप डुप्लीकेट हटाने की कुंजी फ़ील्ड का इस्तेमाल करें. इससे, रिपोर्ट में डुप्लीकेट ट्रिगर शामिल नहीं होंगे. ऐसा तब होता है, जब एक ही विज्ञापन टेक्नोलॉजी कंपनी, एक ही ट्रिगर इवेंट के लिए कई जवाब देती है. डुप्लीकेट कॉपी हटाने वाली कुंजी का इस्तेमाल कब और कैसे करना है, इस बारे में ज़्यादा जानें.

डेवलपर गाइड में ऐसे उदाहरण दिए गए हैं जिनसे पता चलता है कि ट्रिगर रजिस्ट्रेशन स्वीकार करने का तरीका क्या है.

यहां वर्कफ़्लो का एक उदाहरण दिया गया है:

1. विज्ञापन टेक्नोलॉजी वाला एसडीके, एपीआई को कॉल करता है. इससे पहले से रजिस्टर किए गए यूआरआई का इस्तेमाल करके, ट्रिगर रजिस्ट्रेशन शुरू किया जा सकता है. ज़्यादा जानकारी के लिए, Privacy Sandbox खाते के लिए रजिस्टर करें लेख पढ़ें.

   registerTrigger(
       Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
   

2. एपीआई, https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA से अनुरोध करता है.

3. विज्ञापन टेक्नोलॉजी से जुड़ी इस कंपनी का एचटीटीपीएस सर्वर, हेडर के साथ जवाब देता है. इसमें ये शामिल हैं:

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{
       "trigger_data": "1122",
       // This returns 010 for click-through conversions (CTCs) and 0 for
       // view-through conversions (VTCs) in reports
       "priority": "3",
       "deduplication_key": "3344"
       }],
   }
   Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
   

4. एपीआई, Attribution-Reporting-Redirect में दिए गए हर यूआरएल के लिए अनुरोध करता है. इस उदाहरण में, सिर्फ़ एक यूआरएल दिया गया है. इसलिए, एपीआई https://adtechpartner.example?app_install=567 को अनुरोध भेजता है.

5. विज्ञापन टेक्नोलॉजी से जुड़ी इस कंपनी का एचटीटीपीएस सर्वर, हेडर के साथ जवाब देता है. इसमें ये शामिल हैं:

   Attribution-Reporting-Register-Trigger: {
   "event_trigger_data":[{
     "trigger_data": "5566",
     "priority": "3",
     "deduplication_key": "3344"
   }]
   }
   

   पिछले चरणों में किए गए अनुरोधों के आधार पर, दो ट्रिगर रजिस्टर किए जाते हैं.

एट्रिब्यूशन की सुविधाएं

यहां दिए गए सेक्शन में बताया गया है कि Attribution Reporting API, कन्वर्ज़न ट्रिगर को एट्रिब्यूशन सोर्स से कैसे मैच करता है.

सोर्स को प्राथमिकता देने वाला एट्रिब्यूशन एल्गोरिदम लागू किया गया

Attribution Reporting API, ट्रिगर (कन्वर्ज़न) को एट्रिब्यूशन सोर्स से मैच करने के लिए, सोर्स-प्रायोरिटाइज़्ड एट्रिब्यूशन एल्गोरिदम का इस्तेमाल करता है.

प्राथमिकता वाले पैरामीटर की मदद से, ट्रिगर के एट्रिब्यूशन को सोर्स के हिसाब से पसंद के मुताबिक बनाया जा सकता है:

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

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

ट्रिगर फ़िल्टर

सोर्स और ट्रिगर रजिस्ट्रेशन में, ये काम करने के लिए अतिरिक्त वैकल्पिक सुविधाएं शामिल होती हैं:

• कुछ ट्रिगर को फ़िल्टर करके, उन्हें अनदेखा किया जा सकता है.
• सोर्स डेटा के आधार पर, इवेंट-लेवल की रिपोर्ट के लिए ट्रिगर डेटा चुनें.
• इवेंट-लेवल की रिपोर्ट से किसी ट्रिगर को बाहर रखने का विकल्प चुनें.

ट्रिगर को चुनिंदा तौर पर फ़िल्टर करने के लिए, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनी, सोर्स और ट्रिगर रजिस्ट्रेशन के दौरान फ़िल्टर डेटा तय कर सकती है. इसमें कुंजियां और वैल्यू शामिल होती हैं. अगर सोर्स और ट्रिगर, दोनों के लिए एक ही कुंजी तय की जाती है, तो इंटरसेक्शन खाली होने पर ट्रिगर को अनदेखा कर दिया जाता है. उदाहरण के लिए, कोई सोर्स "product": ["1234"] तय कर सकता है. यहां product फ़िल्टर कुंजी है और 1234 वैल्यू है. अगर ट्रिगर फ़िल्टर को "product": ["1111"] पर सेट किया जाता है, तो ट्रिगर को अनदेखा कर दिया जाता है. अगर product से मेल खाने वाली कोई ट्रिगर फ़िल्टर कुंजी नहीं है, तो फ़िल्टर को अनदेखा कर दिया जाता है.

विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म, ट्रिगर को चुनिंदा तौर पर फ़िल्टर करने के लिए, एक और तरीका अपना सकते हैं. वे कुकी के खत्म होने की अवधि को कम कर सकते हैं. ट्रिगर रजिस्टर करने पर, विज्ञापन टेक्नोलॉजी कंपनी यह तय कर सकती है कि कन्वर्ज़न कब हुआ. इसके लिए, वह लुकबैक विंडो को सेकंड में तय कर सकती है. उदाहरण के लिए, सात दिन की लुकबैक विंडो को इस तरह से तय किया जाएगा: "_lookback_window": 604800 // 7d

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

विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म, सोर्स इवेंट डेटा के आधार पर ट्रिगर डेटा भी चुन सकते हैं. उदाहरण के लिए, source_type को एपीआई, navigation या event के तौर पर अपने-आप जनरेट करता है. ट्रिगर रजिस्टर करते समय, trigger_data को "source_type": ["navigation"] के लिए एक वैल्यू और "source_type": ["event"] के लिए दूसरी वैल्यू के तौर पर सेट किया जा सकता है.

अगर इनमें से कोई भी शर्त पूरी होती है, तो ट्रिगर को इवेंट-लेवल की रिपोर्ट से बाहर रखा जाता है:

• कोई trigger_data तय नहीं किया गया है.
• सोर्स और ट्रिगर, दोनों में एक ही फ़िल्टर कुंजी दी गई है, लेकिन वैल्यू मेल नहीं खातीं. ध्यान दें कि इस मामले में, इवेंट-लेवल और एग्रीगेट की जा सकने वाली, दोनों तरह की रिपोर्ट के लिए ट्रिगर को अनदेखा किया जाता है.

पोस्ट-इंस्टॉल एट्रिब्यूशन

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

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

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

आने वाले समय में, हम इस डिज़ाइन को बेहतर एट्रिब्यूशन मॉडल के साथ काम करने के लिए बढ़ा सकते हैं.

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

यहां दी गई सूची में, इंस्टॉल के बाद एट्रिब्यूशन के बारे में कुछ अतिरिक्त नोट दिए गए हैं:

• अगर पुष्टि किया गया इंस्टॉल, install_attribution_window की ओर से तय किए गए दिनों के अंदर नहीं होता है, तो इंस्टॉल के बाद एट्रिब्यूशन लागू नहीं होता.
• पुष्टि किए गए इंस्टॉल, विज्ञापन टेक्नोलॉजी कंपनियां रजिस्टर नहीं करती हैं. साथ ही, इन्हें रिपोर्ट में नहीं भेजा जाता है. इन्हें विज्ञापन टेक्नोलॉजी कंपनी की दर की सीमाओं में शामिल नहीं किया जाता. पुष्टि किए गए इंस्टॉल का इस्तेमाल सिर्फ़ एट्रिब्यूशन सोर्स की पहचान करने के लिए किया जाता है. इस सोर्स को इंस्टॉल का क्रेडिट दिया जाता है.
• ऊपर दी गई टेबल के उदाहरण में, ट्रिगर 1 और ट्रिगर 2, ऐप्लिकेशन को पहली बार खोलने और पोस्ट-इंस्टॉल कन्वर्ज़न को दिखाते हैं. हालांकि, विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म किसी भी तरह के ट्रिगर को रजिस्टर कर सकते हैं. दूसरे शब्दों में कहें, तो पहला ट्रिगर, फ़र्स्ट ओपन ट्रिगर होना ज़रूरी नहीं है.
• अगर post_install_exclusivity_window की समयसीमा खत्म होने के बाद ज़्यादा ट्रिगर रजिस्टर किए जाते हैं, तो भी क्लिक 1 को एट्रिब्यूशन मिल सकता है. हालांकि, इसके लिए यह ज़रूरी है कि क्लिक 1 की समयसीमा खत्म न हुई हो और वह दर की सीमाओं तक न पहुंचा हो.
  • अगर ज़्यादा प्राथमिकता वाला एट्रिब्यूशन सोर्स रजिस्टर किया जाता है, तो हो सकता है कि क्लिक 1 अब भी न दिखे या उसे खारिज कर दिया जाए.
• अगर विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन को अनइंस्टॉल करके फिर से इंस्टॉल किया जाता है, तो फिर से इंस्टॉल किए गए ऐप्लिकेशन को पुष्टि किया गया नया इंस्टॉल माना जाता है.
• अगर पहला क्लिक, व्यू इवेंट था, तो भी "पहली बार ऐप्लिकेशन खोलने" और इंस्टॉल के बाद के ट्रिगर, दोनों को इससे एट्रिब्यूट किया जाता है. एपीआई, हर व्यू के लिए सिर्फ़ एक ट्रिगर को एट्रिब्यूट करने की अनुमति देता है. हालांकि, इंस्टॉल के बाद के एट्रिब्यूशन के मामले में, हर व्यू के लिए दो ट्रिगर को एट्रिब्यूट करने की अनुमति है. ऐप्लिकेशन इंस्टॉल होने के बाद एट्रिब्यूशन के मामले में, विज्ञापन टेक्नोलॉजी कंपनी को दो अलग-अलग रिपोर्टिंग विंडो मिल सकती हैं. ये दो दिन या सोर्स की समयसीमा खत्म होने पर मिल सकती हैं.

ऐप्लिकेशन और वेब पर आधारित ट्रिगर पाथ के सभी कॉम्बिनेशन काम करते हैं

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

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

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

विज्ञापन टेक्नोलॉजी कंपनियों और ऐप्लिकेशन को, अलग-अलग ऐप्लिकेशन और वेब पर मेज़रमेंट के लिए ट्रिगर पाथ की सुविधा चालू करने के लिए, कौनसे बदलाव करने होंगे, इस बारे में जानें.

एक एट्रिब्यूशन सोर्स के लिए, एक से ज़्यादा ट्रिगर को प्राथमिकता देना

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

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

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

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

विज्ञापन टेक्नोलॉजी से जुड़ी कई कंपनियों को एट्रिब्यूशन सोर्स या ट्रिगर रजिस्टर करने की अनुमति दें

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

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

• एपीआई से रिपोर्ट रजिस्टर करने और पाने के लिए, इन-हाउस सर्वर सेट अप करना.
• किसी मौजूदा मोबाइल मेज़रमेंट पार्टनर का इस्तेमाल जारी रखना.

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

registerSource() तरीके में, एट्रिब्यूशन सोर्स रीडायरेक्ट इस्तेमाल किए जा सकते हैं:

1. registerSource() तरीके को कॉल करने वाली विज्ञापन टेक्नोलॉजी, अपने जवाब में एक अतिरिक्त Attribution-Reporting-Redirect फ़ील्ड दे सकती है. यह फ़ील्ड, पार्टनर विज्ञापन टेक्नोलॉजी के रीडायरेक्ट यूआरएल के सेट को दिखाता है.
2. इसके बाद, एपीआई रीडायरेक्ट यूआरएल को कॉल करता है, ताकि पार्टनर की विज्ञापन टेक्नोलॉजी, एट्रिब्यूशन सोर्स को रजिस्टर कर सकें.

Attribution-Reporting-Redirect फ़ील्ड में, पार्टनर की विज्ञापन टेक्नोलॉजी के कई यूआरएल शामिल किए जा सकते हैं. साथ ही, पार्टनर की विज्ञापन टेक्नोलॉजी, अपना Attribution-Reporting-Redirect फ़ील्ड तय नहीं कर सकती.

एपीआई, विज्ञापन से जुड़ी अलग-अलग टेक्नोलॉजी को हर बार registerSource() कॉल करने की अनुमति देता है.

ट्रिगर

ट्रिगर रजिस्ट्रेशन के लिए, तीसरे पक्षों को इसी तरह से सहायता मिलती है: विज्ञापन टेक्नोलॉजी कंपनियां, अतिरिक्त Attribution-Reporting-Redirect फ़ील्ड का इस्तेमाल कर सकती हैं या वे registerTrigger() तरीके को कॉल कर सकती हैं.

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

डुप्लीकेट ट्रिगर मैनेज करना

कोई विज्ञापन टेक्नोलॉजी कंपनी, एक ही ट्रिगर को एपीआई के साथ कई बार रजिस्टर कर सकती है. इन स्थितियों में, आपको यह सुविधा मिल सकती है:

• उपयोगकर्ता एक ही कार्रवाई (ट्रिगर) कई बार करता है. उदाहरण के लिए, उपयोगकर्ता एक ही रिपोर्टिंग विंडो में एक ही प्रॉडक्ट को कई बार ब्राउज़ करता है.
• विज्ञापन देने वाले व्यक्ति या कंपनी का ऐप्लिकेशन, कन्वर्ज़न मेज़रमेंट के लिए कई एसडीके का इस्तेमाल करता है. ये सभी एसडीके, एक ही विज्ञापन टेक्नोलॉजी पर रीडायरेक्ट होते हैं. उदाहरण के लिए, विज्ञापन देने वाले व्यक्ति या कंपनी का ऐप्लिकेशन, मेज़रमेंट पार्टनर के तौर पर दो कंपनियों का इस्तेमाल करता है: MMP #1 और MMP #2. दोनों एमएमपी, विज्ञापन टेक्नोलॉजी #3 पर रीडायरेक्ट करती हैं. ट्रिगर होने पर, दोनों एमएमपी उस ट्रिगर को Attribution Reporting API के साथ रजिस्टर करते हैं. इसके बाद, विज्ञापन टेक्नोलॉजी #3 को एक ही ट्रिगर के लिए दो अलग-अलग रीडायरेक्ट मिलते हैं. एक रीडायरेक्ट, MMP #1 से और दूसरा MMP #2 से मिलता है.

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

सुझाया गया तरीका: डुप्लीकेट हटाने के लिए इस्तेमाल की जाने वाली कुंजी

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

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

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

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

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

ट्रिगर रजिस्ट्रेशन कॉल शुरू करने वाली विज्ञापन टेक्नोलॉजी, जैसे कि एसडीके, Attribution-Reporting-Redirect में दिए गए यूआरएल में एक पैरामीटर शामिल करती हैं. जैसे, duplicate_trigger_id. उस duplicate_trigger_id पैरामीटर में, विज्ञापन देने वाले व्यक्ति या कंपनी के लिए एसडीके का नाम और ट्रिगर टाइप जैसी जानकारी शामिल हो सकती है. इसके बाद, विज्ञापन टेक्नोलॉजी कंपनियां, डुप्लीकेट ट्रिगर के इस सबसेट को इवेंट-लेवल की रिपोर्ट में भेज सकती हैं. विज्ञापन टेक्नोलॉजी कंपनियां भी इस duplicate_trigger_id को अपनी एग्रीगेशन कुंजियों में शामिल कर सकती हैं.

क्रॉस-नेटवर्क एट्रिब्यूशन का उदाहरण

इस सेक्शन में दिए गए उदाहरण में, विज्ञापन देने वाला व्यक्ति या कंपनी, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाले दो प्लैटफ़ॉर्म (विज्ञापन टेक्नोलॉजी A और विज्ञापन टेक्नोलॉजी B) और एक मेज़रमेंट पार्टनर (एमएमपी) का इस्तेमाल कर रही है.

शुरू करने के लिए, विज्ञापन टेक्नोलॉजी A, विज्ञापन टेक्नोलॉजी B, और MMP, सभी को Attribution Reporting API का इस्तेमाल करने के लिए रजिस्टर करना होगा. ज़्यादा जानकारी के लिए, Privacy Sandbox खाते के लिए रजिस्टर करना लेख पढ़ें.

यहां दी गई सूची में, उपयोगकर्ता की कार्रवाइयों की एक काल्पनिक सीरीज़ दी गई है. हर कार्रवाई एक दिन के अंतर पर होती है. साथ ही, यह भी बताया गया है कि Attribution Reporting API, विज्ञापन टेक्नोलॉजी A, विज्ञापन टेक्नोलॉजी B, और एमएमपी के हिसाब से इन कार्रवाइयों को कैसे मैनेज करता है:

पहला दिन: उपयोगकर्ता, AdTech A के दिखाए गए विज्ञापन पर क्लिक करता है

विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनी A, अपने यूआरआई के साथ registerSource() को कॉल करती है. एपीआई, यूआरआई से अनुरोध करता है. इसके बाद, Ad tech A के सर्वर से मिले जवाब के मेटाडेटा के साथ क्लिक रजिस्टर किया जाता है.

विज्ञापन टेक्नोलॉजी कंपनी A, Attribution-Reporting-Redirect हेडर में MMP का यूआरआई भी शामिल करती है. एपीआई, MMP के यूआरआई को अनुरोध भेजता है. इसके बाद, MMP के सर्वर से मिले जवाब के मेटाडेटा के साथ क्लिक रजिस्टर किया जाता है.

दूसरा दिन: उपयोगकर्ता, AdTech B के दिखाए गए विज्ञापन पर क्लिक करता है

विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनी B, अपने यूआरआई के साथ registerSource() को कॉल करती है. एपीआई, यूआरआई को अनुरोध भेजता है. इसके बाद, Ad tech B के सर्वर रिस्पॉन्स से मिले मेटाडेटा के साथ क्लिक रजिस्टर किया जाता है.

विज्ञापन टेक्नोलॉजी से जुड़ी कंपनी A की तरह, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनी B ने भी Attribution-Reporting-Redirect हेडर में MMP का यूआरआई शामिल किया है. एपीआई, MMP के यूआरआई को अनुरोध भेजता है. इसके बाद, क्लिक को MMP के सर्वर से मिले जवाब के मेटाडेटा के साथ रजिस्टर किया जाता है.

तीसरा दिन: उपयोगकर्ता, Ad tech A की ओर से दिखाया गया विज्ञापन देखता है

एपीआई, पहले दिन की तरह ही जवाब देता है. हालांकि, Ad tech A और MMP के लिए एक व्यू रजिस्टर किया जाता है.

चौथा दिन: उपयोगकर्ता, ऐप्लिकेशन इंस्टॉल करता है. यह ऐप्लिकेशन, कन्वर्ज़न मेज़रमेंट के लिए एमएमपी का इस्तेमाल करता है

एमएमपी, registerTrigger() को अपने यूआरआई के साथ कॉल करता है. एपीआई, यूआरएल को अनुरोध भेजता है. साथ ही, कन्वर्ज़न को MMP के सर्वर रिस्पॉन्स से मिले मेटाडेटा के साथ रजिस्टर किया जाता है.

एमएमपी, Attribution-Reporting-Redirect हेडर में विज्ञापन टेक्नोलॉजी A और विज्ञापन टेक्नोलॉजी B के यूआरआई भी शामिल करता है. एपीआई, विज्ञापन टेक्नोलॉजी A और विज्ञापन टेक्नोलॉजी B के सर्वर से अनुरोध करता है. इसके बाद, सर्वर से मिले रिस्पॉन्स के मेटाडेटा के हिसाब से कन्वर्ज़न रजिस्टर किया जाता है.

यहां दिए गए डायग्राम में, ऊपर दी गई सूची में बताई गई प्रोसेस को दिखाया गया है:

एट्रिब्यूशन इस तरह काम करता है:

• विज्ञापन टेक्नोलॉजी A, व्यू की तुलना में क्लिक को ज़्यादा प्राथमिकता देती है. इसलिए, पहले दिन के क्लिक को इंस्टॉल का क्रेडिट मिलता है.
• विज्ञापन टेक्नोलॉजी कंपनी B को दूसरे दिन इंस्टॉल का एट्रिब्यूशन मिलता है.
• एमएमपी, क्लिक को व्यू से ज़्यादा प्राथमिकता देता है. इसलिए, इंस्टॉल को दूसरे दिन के क्लिक से एट्रिब्यूट किया जाता है. दूसरे दिन के क्लिक को सबसे ज़्यादा प्राथमिकता दी जाती है. यह विज्ञापन का सबसे हालिया इवेंट है.

रीडायरेक्ट के बिना क्रॉस-नेटवर्क एट्रिब्यूशन

हमारा सुझाव है कि रीडायरेक्ट का इस्तेमाल करें, ताकि कई विज्ञापन टेक्नोलॉजी कंपनियां एट्रिब्यूशन सोर्स और ट्रिगर रजिस्टर कर सकें. हालांकि, हम यह भी जानते हैं कि कुछ मामलों में रीडायरेक्ट का इस्तेमाल करना मुमकिन नहीं होता. इस सेक्शन में, बिना रीडायरेक्ट के क्रॉस-नेटवर्क एट्रिब्यूशन की सुविधा इस्तेमाल करने का तरीका बताया गया है.

हाई लेवल फ़्लो

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

सोर्स का रजिस्ट्रेशन

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

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

ट्रिगर रजिस्ट्रेशन

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

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

एट्रिब्यूशन

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

• उपयोगकर्ता ने विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनियों A, B, C, और D के दिखाए गए विज्ञापनों पर क्लिक किया. इसके बाद, उपयोगकर्ता ने विज्ञापन देने वाले व्यक्ति या कंपनी का ऐप्लिकेशन इंस्टॉल किया. यह ऐप्लिकेशन, मेज़रमेंट से जुड़ी विज्ञापन टेक्नोलॉजी के पार्टनर (एमएमपी) का इस्तेमाल करता है.
• विज्ञापन टेक्नोलॉजी कंपनी A, अपने सोर्स को MMP पर रीडायरेक्ट करती है.
• विज्ञापन टेक्नोलॉजी कंपनियां B और C, रीडायरेक्ट नहीं करती हैं. हालांकि, वे अपनी एग्रीगेशन कुकी शेयर करती हैं.
• Ad tech D, न तो रीडायरेक्ट करता है और न ही एग्रीगेशन कुंजियां शेयर करता है.

एमएमपी, विज्ञापन टेक्नोलॉजी A से एक सोर्स रजिस्टर करता है. साथ ही, एट्रिब्यूशन कॉन्फ़िगरेशन तय करता है. इसमें विज्ञापन टेक्नोलॉजी B और विज्ञापन टेक्नोलॉजी D शामिल होती हैं.

एमएमपी के लिए एट्रिब्यूशन में अब ये शामिल हैं:

• विज्ञापन टेक्नोलॉजी कंपनी A, क्योंकि MMP ने उस विज्ञापन टेक्नोलॉजी कंपनी के रीडायरेक्ट से एक सोर्स रजिस्टर किया है.
• विज्ञापन टेक्नोलॉजी से जुड़ी कंपनी B, क्योंकि विज्ञापन टेक्नोलॉजी से जुड़ी कंपनी B ने कुंजियां शेयर की हैं और MMP ने इसे एट्रिब्यूशन कॉन्फ़िगरेशन में शामिल किया है.

एमएमपी के एट्रिब्यूशन में ये शामिल नहीं हैं:

• विज्ञापन टेक्नोलॉजी C, क्योंकि एमएमपी ने इसे एट्रिब्यूशन कॉन्फ़िगरेशन में शामिल नहीं किया है.
• विज्ञापन टेक्नोलॉजी कंपनी D, क्योंकि उसने न तो रीडायरेक्ट किया और न ही एग्रीगेशन कुंजियां शेयर कीं.

डीबग करना

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

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

• ऐप्लिकेशन से ऐप्लिकेशन के बीच मेज़रमेंट, जहां AdId का इस्तेमाल करने की अनुमति है
• ऐप्लिकेशन से वेब पर होने वाले कन्वर्ज़न का मेज़रमेंट, जहां AdId को अनुमति दी गई है और ऐप्लिकेशन सोर्स और वेब ट्रिगर, दोनों में मैचिंग की जा रही है
• वेब से वेब मेज़रमेंट (एक ही ब्राउज़र ऐप्लिकेशन पर), जब सोर्स और ट्रिगर, दोनों पर ar_debug मौजूद हो

रीडायरेक्ट के बिना क्रॉस-नेटवर्क एट्रिब्यूशन के लिए कुंजियों का पता लगाना

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

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

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

कीवर्ड डिस्कवरी की सुविधा लॉन्च होने के बाद:

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

संक्षेप में, मुख्य खोज की सुविधा की मदद से, एमएमपी को पहले से जानकारी दिए बिना एग्रीगेशन कुंजियां मिल जाती हैं. साथ ही, इससे सोर्स कुंजियों की बड़ी संख्या को प्रोसेस करने से बचा जा सकता है.

डेज़ी चेन रीडायरेक्ट

किसी सोर्स या ट्रिगर रजिस्ट्रेशन के एचटीटीपीएस सर्वर-रिस्पॉन्स में कई Attribution-Reporting-Redirect हेडर उपलब्ध कराकर, विज्ञापन टेक्नोलॉजी कंपनी Attribution Reporting API का इस्तेमाल कर सकती है. इससे, वह रजिस्ट्रेशन के लिए एक ही एपीआई कॉल से, कई सोर्स और ट्रिगर रजिस्टर कर सकती है.

सर्वर से मिले रिस्पॉन्स में, विज्ञापन टेक्नोलॉजी कंपनी एक यूआरएल के साथ Location (302 रीडायरेक्ट) हेडर भी शामिल कर सकती है. इससे, तय सीमा तक एक और रजिस्ट्रेशन किया जा सकता है.

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

ब्राउज़र के ज़रिए इस्तेमाल किए जाने वाले registerWebSource और registerWebTrigger के लिए, रीडायरेक्ट स्वीकार नहीं किए जाते. ज़्यादा जानकारी के लिए, वेब और ऐप्लिकेशन, दोनों पर लागू होने वाली इंप्लिमेंटेशन गाइड देखें.

एट्रिब्यूशन रिपोर्ट में मेज़रमेंट डेटा देखना

Attribution Reporting API की मदद से, यहां दी गई तरह की रिपोर्ट जनरेट की जा सकती हैं. इनके बारे में इस पेज पर बाद में ज़्यादा जानकारी दी गई है:

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

ये दोनों रिपोर्ट एक-दूसरे की पूरक हैं और इनका इस्तेमाल एक साथ किया जा सकता है.

इवेंट-लेवल की रिपोर्ट

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

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

इवेंट-लेवल की रिपोर्ट में, इस तरह का डेटा शामिल होता है:

• डेस्टिनेशन: विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन के पैकेज का नाम या eTLD+1, जहां ट्रिगर हुआ
• एट्रिब्यूशन सोर्स आईडी: वही एट्रिब्यूशन सोर्स आईडी जिसका इस्तेमाल एट्रिब्यूशन सोर्स रजिस्टर करने के लिए किया गया था
• ट्रिगर टाइप: एट्रिब्यूशन सोर्स के टाइप के आधार पर, कम फ़िडेलिटी वाले ट्रिगर डेटा के 1 या 3 बिट

निजता बनाए रखने वाले तरीके, सभी रिपोर्ट पर लागू किए गए

एट्रिब्यूशन सोर्स और ट्रिगर से जुड़ी प्राथमिकताओं को ध्यान में रखने के बाद, ये सीमाएं लागू होती हैं.

विज्ञापन टेक्नोलॉजी कंपनियों की संख्या पर पाबंदियां

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

• हर {सोर्स ऐप्लिकेशन, डेस्टिनेशन ऐप्लिकेशन, 30 दिन, डिवाइस} के लिए, एट्रिब्यूशन सोर्स के साथ 100 विज्ञापन टेक्नोलॉजी.
• हर {सोर्स ऐप्लिकेशन, डेस्टिनेशन ऐप्लिकेशन, 30 दिन, डिवाइस} के लिए, एट्रिब्यूट किए गए 10 विज्ञापन टेक्नोलॉजी ट्रिगर.
• विज्ञापन से जुड़ी टेक्नोलॉजी देने वाली 20 कंपनियां, एट्रिब्यूशन के किसी एक सोर्स या ट्रिगर को रजिस्टर कर सकती हैं (Attribution-Reporting-Redirect के ज़रिए)

अलग-अलग डेस्टिनेशन की संख्या की सीमाएं

इन सीमाओं की वजह से, विज्ञापन टेक्नोलॉजी से जुड़ी कंपनियों के लिए, किसी उपयोगकर्ता के ऐप्लिकेशन इस्तेमाल करने के व्यवहार को समझने के लिए, बड़ी संख्या में ऐप्लिकेशन से क्वेरी करना मुश्किल हो जाता है.

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

जिन सोर्स की समयसीमा खत्म हो गई है उन्हें दर की सीमाओं में नहीं गिना जाता.

हर दिन, हर सोर्स ऐप्लिकेशन के लिए एक रिपोर्टिंग ऑरिजिन

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

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

1. Ad Tech A का रिपोर्टिंग ऑरिजिन 1, ऐप्लिकेशन B पर एक सोर्स रजिस्टर करता है
2. 12 घंटे बाद, विज्ञापन टेक्नोलॉजी कंपनी A का रिपोर्टिंग ऑरिजिन 2, ऐप्लिकेशन B पर सोर्स रजिस्टर करने की कोशिश करता है

दूसरे सोर्स, यानी कि विज्ञापन टेक्नोलॉजी कंपनी A के रिपोर्टिंग ओरिजिन 2 को एपीआई अस्वीकार कर देगा. विज्ञापन टेक्नोलॉजी A का रिपोर्टिंग ऑरिजिन 2, अगले दिन तक ऐप्लिकेशन B पर उसी डिवाइस पर सोर्स को रजिस्टर नहीं कर पाएगा.

कूलडाउन पीरियड और दर की सीमाएं

{source, destination} पेयर के बीच उपयोगकर्ता की पहचान से जुड़ी जानकारी के लीक होने की संभावना को कम करने के लिए, एपीआई किसी उपयोगकर्ता के लिए तय समय में भेजी गई कुल जानकारी की मात्रा को सीमित करता है.

फ़िलहाल, यह सुझाव दिया गया है कि हर विज्ञापन टेक्नोलॉजी को, हर {सोर्स ऐप्लिकेशन, डेस्टिनेशन ऐप्लिकेशन, 30 दिन, डिवाइस} के लिए एट्रिब्यूट किए गए 100 ट्रिगर तक सीमित किया जाए.

यूनीक डेस्टिनेशन की संख्या

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

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

इवेंट-लेवल की रिपोर्ट पर लागू होने वाले निजता बनाए रखने के तरीके

ट्रिगर डेटा की फ़िडेलिटी सीमित होती है

यह एपीआई, व्यू-थ्रू ट्रिगर के लिए 1 बिट और क्लिक-थ्रू ट्रिगर के लिए 3 बिट उपलब्ध कराता है. एट्रिब्यूशन सोर्स, मेटाडेटा के पूरे 64 बिट का इस्तेमाल कर सकते हैं.

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

डिफ़रेंशियल प्राइवसी नॉइज़ के लिए फ़्रेमवर्क

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

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

k-रैंडमाइज़्ड रिस्पॉन्स एक ऐसा एल्गोरिदम है जो epsilon differentially private है. ऐसा तब होता है, जब यह समीकरण पूरा होता है:

ε की कम वैल्यू के लिए, k-रैंडमाइज़्ड रिस्पॉन्स मैकेनिज़्म की मदद से, असली आउटपुट को सुरक्षित रखा जाता है. नॉइज़ के सटीक पैरामीटर पर काम चल रहा है. साथ ही, ये सुझाव, शिकायत या राय के आधार पर बदल सकते हैं. फ़िलहाल, ये पैरामीटर सुझाए गए हैं:

• नेविगेशन सोर्स के लिए p=0.24%
• इवेंट सोर्स के लिए p=0.00025%

उपलब्ध ट्रिगर (कन्वर्ज़न) की सीमाएं

हर एट्रिब्यूशन सोर्स के लिए, ट्रिगर की संख्या सीमित होती है. फ़िलहाल, यह सीमा इस तरह तय की गई है:

• विज्ञापन व्यू एट्रिब्यूशन सोर्स के लिए 1-2 ट्रिगर (सिर्फ़ पोस्ट-इंस्टॉल एट्रिब्यूशन के मामले में 2 ट्रिगर उपलब्ध हैं)
• क्लिक विज्ञापन एट्रिब्यूशन सोर्स के लिए तीन ट्रिगर

रिपोर्ट भेजने के लिए तय की गई समय सीमा (डिफ़ॉल्ट सेटिंग)

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

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

• दो दिन: डिवाइस, उन सभी ट्रिगर को इकट्ठा करता है जो एट्रिब्यूशन सोर्स रजिस्टर होने के दो दिनों के अंदर हुए थे. एट्रिब्यूशन सोर्स रजिस्टर होने के दो दिन और एक घंटे बाद, रिपोर्ट भेजी जाती है.
• सात दिन: डिवाइस, उन सभी ट्रिगर को इकट्ठा करता है जो एट्रिब्यूशन सोर्स रजिस्टर होने के दो दिन बाद, लेकिन सात दिन से पहले हुए थे. यह रिपोर्ट, एट्रिब्यूशन सोर्स रजिस्टर होने के सात दिन और एक घंटे बाद भेजी जाती है.
• समय की कस्टम अवधि, जिसे एट्रिब्यूशन सोर्स के "expiry" एट्रिब्यूट से तय किया जाता है. रिपोर्ट, समयसीमा खत्म होने के एक घंटे बाद भेजी जाती है. यह वैल्यू, एक दिन से कम या 30 दिनों से ज़्यादा नहीं हो सकती.

इवेंट-लेवल के लिए ज़रूरत के मुताबिक कॉन्फ़िगरेशन

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

यह अतिरिक्त सुविधा, एट्रिब्यूशन रिपोर्टिंग एपीआई में दो चरणों में जोड़ी जाएगी:

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

पहला चरण (लाइट फ़्लेक्सिबल इवेंट लेवल) का इस्तेमाल इन कामों के लिए किया जा सकता है:

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

दूसरे चरण (इवेंट लेवल पर पूरी तरह से फ़्लेक्सिबल) का इस्तेमाल, पहले चरण में उपलब्ध सभी सुविधाओं के लिए किया जा सकता है. साथ ही, इसके लिए भी किया जा सकता है:

• किसी रिपोर्ट में ट्रिगर डेटा की कार्डिनैलिटी में बदलाव करना
• ट्रिगर डेटा की कार्डिनैलिटी कम करके, कुल नॉइज़ की मात्रा कम करें

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

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

• दुनिया भर में और हर trigger_data के लिए, ज़्यादा से ज़्यादा 20 रिपोर्ट
• हर trigger_data के लिए, ज़्यादा से ज़्यादा पांच रिपोर्टिंग विंडो हो सकती हैं
• ट्रिगर डेटा की कार्डिनैलिटी ज़्यादा से ज़्यादा 32 होनी चाहिए. यह नियम, पहले चरण (लाइट फ़्लेक्सिबल इवेंट लेवल) पर लागू नहीं होता

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

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

एग्रीगेट की जा सकने वाली रिपोर्ट का इस्तेमाल करने से पहले, आपको अपना क्लाउड खाता सेट अप करना होगा. साथ ही, एग्रीगेट की जा सकने वाली रिपोर्ट पाना शुरू करना होगा.

एग्रीगेट की जा सकने वाली रिपोर्ट, डिवाइस से ज़्यादा सटीक ट्रिगर डेटा को इवेंट-लेवल की रिपोर्ट की तुलना में ज़्यादा तेज़ी से उपलब्ध कराती हैं. इस ज़्यादा सटीक डेटा के बारे में सिर्फ़ इकट्ठा किए गए डेटा से पता लगाया जा सकता है. साथ ही, यह किसी खास ट्रिगर या उपयोगकर्ता से जुड़ा नहीं होता. एग्रीगेशन कुंजियां 128 बिट तक होती हैं. इससे एग्रीगेट की जा सकने वाली रिपोर्ट, रिपोर्टिंग के इस्तेमाल के उदाहरणों के साथ काम कर पाती हैं. जैसे:

• ट्रिगर वैल्यू के लिए रिपोर्ट, जैसे कि रेवेन्यू
• ज़्यादा ट्रिगर टाइप हैंडल करना

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

इस डायग्राम में दिखाया गया है कि Attribution Reporting API, एग्रीगेट की जा सकने वाली रिपोर्ट कैसे तैयार करता है और उन्हें कैसे भेजता है. इसका पूरा डिज़ाइन यहां दिया गया है:

1. डिवाइस, विज्ञापन से जुड़ी टेक्नोलॉजी को एन्क्रिप्ट (सुरक्षित) की गई एग्रीगेट की जा सकने वाली रिपोर्ट भेजता है. प्रोडक्शन एनवायरमेंट में, विज्ञापन से जुड़ी टेक्नोलॉजी कंपनियां इन रिपोर्ट का सीधे तौर पर इस्तेमाल नहीं कर सकतीं.
2. विज्ञापन से जुड़ी टेक्नोलॉजी कंपनी, एग्रीगेट की जा सकने वाली रिपोर्ट का एक बैच, एग्रीगेशन सेवा को भेजती है, ताकि एग्रीगेशन किया जा सके.
3. एग्रीगेशन सेवा, एग्रीगेट की जा सकने वाली रिपोर्ट के बैच को पढ़ती है. इसके बाद, उन्हें डिक्रिप्ट करके एग्रीगेट करती है.
4. फ़ाइनल एग्रीगेट, विज्ञापन टेक्नोलॉजी कंपनी को खास जानकारी वाली रिपोर्ट में वापस भेजे जाते हैं.

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

• डेस्टिनेशन: ऐप्लिकेशन के पैकेज का नाम या eTLD+1 वेब यूआरएल, जहां ट्रिगर हुआ.
• तारीख: एट्रिब्यूशन सोर्स से जुड़े इवेंट के होने की तारीख.
• Payload: ट्रिगर वैल्यू, एन्क्रिप्ट (सुरक्षित) किए गए की/वैल्यू पेयर के तौर पर इकट्ठा की जाती हैं. इनका इस्तेमाल भरोसेमंद एग्रीगेशन सेवा में, एग्रीगेशन का हिसाब लगाने के लिए किया जाता है.

एग्रीगेशन सेवाएं

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

इन सेवाओं को अलग-अलग पक्ष मैनेज करते हैं. इनके बारे में इस पेज पर बाद में ज़्यादा जानकारी दी गई है:

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

एग्रीगेशन सेवा

विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म को, Google की ओर से उपलब्ध कराए गए बाइनरी पर आधारित एग्रीगेशन सेवा को पहले से ही डिप्लॉय करना होगा.

यह एग्रीगेशन सेवा, क्लाउड में होस्ट किए गए ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में काम करती है. टीईई से सुरक्षा से जुड़े ये फ़ायदे मिलते हैं:

• इससे यह पक्का किया जाता है कि टीईई में काम करने वाला कोड, Google की ओर से उपलब्ध कराया गया खास बाइनरी कोड है. जब तक यह शर्त पूरी नहीं हो जाती, तब तक एग्रीगेशन सेवा उन डिक्रिप्शन कुंजियों को ऐक्सेस नहीं कर सकती जिनकी उसे काम करने के लिए ज़रूरत होती है.
• यह प्रोसेस को सुरक्षित रखता है. साथ ही, इसे बाहरी निगरानी या छेड़छाड़ से बचाता है.

सुरक्षा से जुड़े इन फ़ायदों की वजह से, एग्रीगेशन सेवा के लिए संवेदनशील कार्रवाइयां करना ज़्यादा सुरक्षित हो जाता है. जैसे, एन्क्रिप्ट (सुरक्षित) किए गए डेटा को ऐक्सेस करना.

एग्रीगेशन सेवा के डिज़ाइन, वर्कफ़्लो, और सुरक्षा से जुड़ी बातों के बारे में ज़्यादा जानने के लिए, GitHub पर एग्रीगेशन सेवा से जुड़ा दस्तावेज़ देखें.

क्रिप्टोग्राफ़िक कुंजी के लिए मैनेजमेंट सेवा

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

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

यह सेवा ट्रैक करती है कि विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनी की Aggregation Service, किसी खास ट्रिगर को कितनी बार ऐक्सेस करती है. इस ट्रिगर में कई एग्रीगेशन कुंजियां हो सकती हैं. साथ ही, यह सेवा डिक्रिप्शन की सही संख्या के हिसाब से ऐक्सेस को सीमित करती है. ज़्यादा जानकारी के लिए, Attribution Reporting API के लिए एग्रीगेशन सेवा का डिज़ाइन प्रपोज़ल देखें.

Aggregatable Reports API

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

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

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

• (कुंजी) कुंजी का नाम: यह कुंजी के नाम के लिए एक स्ट्रिंग है. इसका इस्तेमाल जॉइन की के तौर पर किया जाता है. इससे ट्रिगर-साइड की के साथ मिलकर फ़ाइनल की बनती है.
• (वैल्यू) मुख्य हिस्सा: यह कुंजी के लिए बिटस्ट्रिंग वैल्यू होती है.

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

फ़ाइनल कुंजियों को ज़्यादा से ज़्यादा 128 बिट तक सीमित किया जाता है. इससे ज़्यादा लंबी कुंजियों को छोटा कर दिया जाता है. इसका मतलब है कि JSON में मौजूद हेक्स स्ट्रिंग में ज़्यादा से ज़्यादा 32 अंक होने चाहिए.

एग्रीगेशन कुंजियों के स्ट्रक्चर और उन्हें कॉन्फ़िगर करने के तरीके के बारे में ज़्यादा जानें.

इस उदाहरण में, विज्ञापन टेक्नोलॉजी से जुड़ी सेवा देने वाली कंपनी, एपीआई का इस्तेमाल करके यह डेटा इकट्ठा करती है:

• कैंपेन लेवल पर कन्वर्ज़न की कुल संख्या
• भौगोलिक स्तर पर खरीदारी की वैल्यू को एग्रीगेट करना

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

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

ट्रिगर रजिस्ट्रेशन में दो अतिरिक्त फ़ील्ड शामिल होते हैं.

पहले फ़ील्ड का इस्तेमाल, ट्रिगर साइड पर एग्रीगेट की की सूची को रजिस्टर करने के लिए किया जाता है. विज्ञापन टेक्नोलॉजी कंपनी को एचटीटीपी हेडर Attribution-Reporting-Register-Trigger में aggregatable_trigger_data फ़ील्ड के साथ जवाब देना चाहिए. साथ ही, सूची में मौजूद हर एग्रीगेट कुंजी के लिए, ये फ़ील्ड शामिल होने चाहिए:

• मुख्य हिस्सा: यह कुंजी के लिए बिटस्ट्रिंग वैल्यू होती है.
• सोर्स की: एट्रिब्यूशन सोर्स साइड की उन कुंजियों के नामों वाली स्ट्रिंग की सूची जिनके साथ ट्रिगर की को जोड़कर फ़ाइनल की बनाई जानी चाहिए.

दूसरे फ़ील्ड का इस्तेमाल, वैल्यू की ऐसी सूची को रजिस्टर करने के लिए किया जाता है जो हर कुंजी में योगदान देती है. विज्ञापन टेक्नोलॉजी कंपनी को, एचटीटीपी हेडर Attribution-Reporting-Register-Trigger में aggregatable_values फ़ील्ड के साथ जवाब देना चाहिए. दूसरे फ़ील्ड का इस्तेमाल, वैल्यू की ऐसी सूची को रजिस्टर करने के लिए किया जाता है जो हर कुंजी में योगदान देती है. यह $ [1, 2^{16}] $ की रेंज में पूर्णांक हो सकती है.

हर ट्रिगर, एग्रीगेट की जा सकने वाली रिपोर्ट में कई योगदान दे सकता है. किसी सोर्स इवेंट में किए गए कुल योगदान की रकम, $ L1 $ पैरामीटर से तय होती है. यह पैरामीटर, किसी सोर्स के लिए सभी एग्रीगेट कुंजियों के योगदान (वैल्यू) का ज़्यादा से ज़्यादा योग होता है. $ L1 $ का मतलब है, सोर्स इवेंट के हिसाब से हिस्टोग्राम के योगदान की L1 संवेदनशीलता या मानदंड. इन सीमाओं से ज़्यादा योगदान करने पर, आने वाले समय में किए जाने वाले योगदान अपने-आप हट जाएंगे. शुरुआती प्रस्ताव में, $ L1 $ को $ 2^{16} $ (65536) पर सेट करने का सुझाव दिया गया है.

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

यहां दिए गए उदाहरण में, निजता बजट को campaignCounts और geoValue के बीच बराबर बांटा गया है. इसके लिए, हर एक के लिए $ L1 $ के योगदान को बांटा गया है:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

ऊपर दिए गए उदाहरण से, ये हिस्टोग्राम जनरेट होते हैं:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

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

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

डिफ़रेंशियल प्राइवसी

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

Protected Audience API और Attribution Reporting API का इंटिग्रेशन

Protected Audience और Attribution Reporting API के बीच क्रॉस-एपीआई इंटिग्रेशन की मदद से, विज्ञापन टेक्नोलॉजी कंपनियां अलग-अलग रीमार्केटिंग तरीकों के लिए एट्रिब्यूशन परफ़ॉर्मेंस का आकलन कर सकती हैं. इससे उन्हें यह समझने में मदद मिलती है कि किस तरह की ऑडियंस से सबसे ज़्यादा आरओआई मिलता है.

क्रॉस-एपीआई इंटिग्रेशन की मदद से, विज्ञापन टेक्नोलॉजी कंपनियां ये काम कर सकती हैं:

• उन यूआरआई का की-वैल्यू मैप बनाएं जिनका इस्तेमाल इन दोनों के लिए किया जाना है: 1) इंटरैक्शन रिपोर्टिंग और 2) सोर्स रजिस्ट्रेशन.
• Attribution Reporting API का इस्तेमाल करके, एग्रीगेट की गई खास जानकारी वाली रिपोर्ट के लिए, सोर्स-साइड की मैपिंग में CustomAudience शामिल करें.

जब कोई उपयोगकर्ता किसी विज्ञापन को देखता है या उस पर क्लिक करता है, तब:

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

Protected Audience में इसे कैसे चालू किया जाता है, इस बारे में ज़्यादा जानने के लिए, Protected Audience API के बारे में जानकारी देने वाले दस्तावेज़ का संबंधित सेक्शन देखें.

रजिस्ट्रेशन की प्राथमिकता, एट्रिब्यूशन, और रिपोर्टिंग के उदाहरण

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

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

मान लें कि कोई उपयोगकर्ता ये काम करता है:

1. उपयोगकर्ता को विज्ञापन दिखता है. विज्ञापन टेक्नोलॉजी, एपीआई के साथ एट्रिब्यूशन सोर्स रजिस्टर करती है. इसकी प्राथमिकता 0 (व्यू #1) होती है.
2. उपयोगकर्ता को 0 (व्यू #2) की प्राथमिकता के साथ रजिस्टर किया गया विज्ञापन दिखता है.
3. उपयोगकर्ता, 1 प्राथमिकता के साथ रजिस्टर किए गए विज्ञापन पर क्लिक करता है (क्लिक #1).
4. उपयोगकर्ता, विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन में कन्वर्ज़न करता है (लैंडिंग पेज पर पहुंचता है). विज्ञापन टेक्नोलॉजी कंपनी, एपीआई के साथ ट्रिगर रजिस्टर करती है. इसकी प्राथमिकता 0 (कन्वर्ज़न #1) होती है.
   • ट्रिगर रजिस्टर होने के बाद, API रिपोर्ट जनरेट करने से पहले एट्रिब्यूशन करता है.
   • यहां एट्रिब्यूशन के तीन सोर्स उपलब्ध हैं: व्यू #1, व्यू #2, और क्लिक #1. एपीआई, इस ट्रिगर को पहले क्लिक से जोड़ता है, क्योंकि यह सबसे ज़्यादा प्राथमिकता वाला और सबसे नया है.
   • पहले और दूसरे व्यू को खारिज कर दिया जाता है. साथ ही, उन्हें आने वाले समय में एट्रिब्यूशन के लिए इस्तेमाल नहीं किया जा सकता.
5. उपयोगकर्ता, विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन में अपनी कार्ट में कोई आइटम जोड़ता है. यह ऐप्लिकेशन, 1 (कन्वर्ज़न #2) की प्राथमिकता के साथ रजिस्टर किया गया है.
   • क्लिक #1, एट्रिब्यूशन का ज़रूरी सोर्स है. एपीआई, इस ट्रिगर को पहले क्लिक के तौर पर एट्रिब्यूट करता है.
6. उपयोगकर्ता, विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन में, कार्ट में कोई आइटम जोड़ता है. यह ऐप्लिकेशन, 1 (कन्वर्ज़न #3) की प्राथमिकता के साथ रजिस्टर किया गया है.
   • क्लिक #1, एट्रिब्यूशन का ज़रूरी सोर्स है. एपीआई, इस ट्रिगर को पहले क्लिक के तौर पर एट्रिब्यूट करता है.
7. उपयोगकर्ता, विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन में अपनी कार्ट में एक आइटम जोड़ता है. यह ऐप्लिकेशन, 1 (कन्वर्ज़न #4) की प्राथमिकता के साथ रजिस्टर किया गया है.
   • क्लिक #1, एट्रिब्यूशन का ज़रूरी सोर्स है. एपीआई, इस ट्रिगर को पहले क्लिक के तौर पर एट्रिब्यूट करता है.
8. उपयोगकर्ता, विज्ञापन देने वाले व्यक्ति या कंपनी के ऐप्लिकेशन में खरीदारी करता है. यह ऐप्लिकेशन, 2 (कन्वर्ज़न #5) की प्राथमिकता के साथ रजिस्टर किया गया है.
   • क्लिक #1, एट्रिब्यूशन का ज़रूरी सोर्स है. एपीआई, इस ट्रिगर को पहले क्लिक के तौर पर एट्रिब्यूट करता है.

इवेंट-लेवल की रिपोर्ट में ये सुविधाएं होती हैं:

• डिफ़ॉल्ट रूप से, क्लिक से जुड़े पहले तीन ट्रिगर और व्यू से जुड़ा पहला ट्रिगर, रिपोर्टिंग की तय अवधि के बाद भेजे जाते हैं.
• रिपोर्टिंग विंडो में, अगर ज़्यादा प्राथमिकता वाले ट्रिगर रजिस्टर किए जाते हैं, तो उन्हें प्राथमिकता दी जाती है. साथ ही, वे सबसे हाल ही के ट्रिगर की जगह ले लेते हैं.
• ऊपर दिए गए उदाहरण में, विज्ञापन टेक्नोलॉजी कंपनी को दो दिन की रिपोर्टिंग विंडो के बाद, तीन इवेंट रिपोर्ट मिलती हैं. ये रिपोर्ट, कन्वर्ज़न #2, कन्वर्ज़न #3, और कन्वर्ज़न #5 के लिए होती हैं.
  • सभी पांच ट्रिगर, पहले क्लिक को एट्रिब्यूट किए गए हैं. डिफ़ॉल्ट रूप से, एपीआई पहले तीन ट्रिगर के लिए रिपोर्ट भेजेगा: कन्वर्ज़न #1, कन्वर्ज़न #2, और कन्वर्ज़न #3.
  • हालांकि, कन्वर्ज़न #4 की प्राथमिकता (1), कन्वर्ज़न #1 की प्राथमिकता (0) से ज़्यादा है. इसलिए, कन्वर्ज़न #4 की इवेंट रिपोर्ट, कन्वर्ज़न #1 की इवेंट रिपोर्ट की जगह ले लेती है.
  • इसके अलावा, कन्वर्ज़न #5 की प्राथमिकता (2), किसी भी अन्य ट्रिगर से ज़्यादा है. कन्वर्ज़न #5 की इवेंट रिपोर्ट, कन्वर्ज़न #4 की रिपोर्ट की जगह ले लेती है, ताकि उसे भेजा जा सके.

एग्रीगेट की जा सकने वाली रिपोर्ट में ये विशेषताएं होती हैं:

• एन्क्रिप्ट की गई एग्रीगेट की जा सकने वाली रिपोर्ट, विज्ञापन टेक्नोलॉजी कंपनी को प्रोसेस होने के तुरंत बाद भेज दी जाती हैं. ट्रिगर रजिस्टर होने के कुछ घंटों बाद ऐसा होता है.

  विज्ञापन टेक्नोलॉजी कंपनी के तौर पर, एग्रीगेट की जा सकने वाली रिपोर्ट में मौजूद बिना एन्क्रिप्ट (सुरक्षित) की गई जानकारी के आधार पर, बैच बनाए जाते हैं. यह जानकारी, एग्रीगेट की जा सकने वाली रिपोर्ट के shared_info फ़ील्ड में मौजूद होती है. इसमें टाइमस्टैंप और रिपोर्टिंग ओरिजिन शामिल होता है. एग्रीगेशन की-वैल्यू पेयर में मौजूद किसी भी एन्क्रिप्ट (सुरक्षित) की गई जानकारी के आधार पर, बैच नहीं बनाया जा सकता. यहां कुछ बुनियादी रणनीतियां दी गई हैं, जिनका इस्तेमाल किया जा सकता है रिपोर्ट को रोज़ाना या हर हफ़्ते बैच करना. आम तौर पर, हर बैच में कम से कम 100 रिपोर्ट होनी चाहिए.

• विज्ञापन से जुड़ी टेक्नोलॉजी कंपनी यह तय करती है कि एग्रीगेट की जा सकने वाली रिपोर्ट को कब और कैसे बैच किया जाए. साथ ही, उन्हें एग्रीगेशन सेवा को कब भेजा जाए.

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

• ऊपर दिए गए उदाहरण में, पांच एग्रीगेट की जा सकने वाली रिपोर्ट भेजी गई हैं. हर रिपोर्ट, रजिस्टर किए गए एक ट्रिगर के लिए है.

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

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

ऐप्लिकेशन से वेब और वेब से ऐप्लिकेशन पर मेज़रमेंट के साथ डीबग करने की रिपोर्ट के बारे में ज़्यादा जानने के लिए, ट्रांज़िशन वाली डीबग रिपोर्ट से जुड़ी गाइड पढ़ें.

एट्रिब्यूशन-सक्सेस डीबग करने वाली रिपोर्ट

सोर्स और ट्रिगर, दोनों तरह के रजिस्ट्रेशन में नया 64-बिट debug_key फ़ील्ड (स्ट्रिंग के तौर पर फ़ॉर्मैट किया गया) स्वीकार किया जाता है. इसे विज्ञापन टेक्नोलॉजी कंपनी भरती है. source_debug_key और trigger_debug_key को इवेंट-लेवल और एग्रीगेट, दोनों तरह की रिपोर्ट में बिना किसी बदलाव के पास किया जाता है.

अगर सोर्स और ट्रिगर, दोनों की डीबग कुंजियों का इस्तेमाल करके कोई रिपोर्ट बनाई जाती है, तो डुप्लीकेट डीबग रिपोर्ट को .well-known/attribution-reporting/debug/report-event-attribution एंडपॉइंट पर कुछ समय बाद भेजा जाता है. डीबग रिपोर्ट, सामान्य रिपोर्ट की तरह ही होती हैं. इनमें दोनों डीबग कुंजी फ़ील्ड शामिल होते हैं. इन कुंजियों को दोनों में शामिल करने से, सामान्य रिपोर्ट को डीबग रिपोर्ट की अलग स्ट्रीम से जोड़ा जा सकता है.

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

डीबग करने की ज़्यादा जानकारी वाली रिपोर्ट

ज़्यादा जानकारी वाली डीबग रिपोर्ट की मदद से डेवलपर, एट्रिब्यूशन सोर्स या ट्रिगर रजिस्ट्रेशन में हुई कुछ गड़बड़ियों पर नज़र रख सकते हैं. ये डीबग रिपोर्ट, एट्रिब्यूशन सोर्स या ट्रिगर रजिस्ट्रेशन के बाद कुछ समय में भेज दी जाती हैं.well-known/attribution-reporting/debug/verbose एंडपॉइंट.

ज़्यादा जानकारी वाली हर रिपोर्ट में ये फ़ील्ड शामिल होते हैं:

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

विज्ञापन टेक्नोलॉजी कंपनियों को, ज़्यादा जानकारी वाली डीबग रिपोर्ट पाने के लिए ऑप्ट इन करना होगा. इसके लिए, उन्हें Attribution-Reporting-Register_Source और Attribution-Reporting-Register-Trigger हेडर में मौजूद नए debug_reporting डिक्शनरी फ़ील्ड का इस्तेमाल करना होगा.

• सोर्स की वर्बोस रिपोर्ट के लिए, सिर्फ़ सोर्स रजिस्ट्रेशन हेडर पर ऑप्ट-इन करना ज़रूरी है.
• ट्रिगर डीबग रिपोर्ट के लिए, सिर्फ़ ट्रिगर रजिस्ट्रेशन हेडर पर ऑप्ट-इन करना ज़रूरी है.

डीबग रिपोर्ट का इस्तेमाल कैसे करें

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

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

जब कोई मैच नहीं होता है, तो इसकी कई वजहें हो सकती हैं.

उम्मीद के मुताबिक काम करता है:

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

अनचाही वजहें:

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

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

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

इसके अलावा, हम कुछ समस्याओं के बारे में कम्यूनिटी से सुझाव/राय पाना चाहते हैं:

1. क्या इस्तेमाल के कुछ ऐसे उदाहरण हैं जिनमें आपको एपीआई से, पुष्टि किए गए इंस्टॉल की रिपोर्ट भेजने के लिए कहना है? इन रिपोर्ट को, विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म की दर से जुड़ी सीमाओं में गिना जाएगा.
2. क्या आपको सोर्स रजिस्ट्रेशन के लिए, ऐप्लिकेशन से विज्ञापन टेक्नोलॉजी को InputEvent पास करने में कोई समस्या आ सकती है?
3. क्या आपके पास पहले से लोड किए गए ऐप्लिकेशन या फिर से इंस्टॉल किए गए ऐप्लिकेशन के लिए, एट्रिब्यूशन के इस्तेमाल के कोई खास उदाहरण हैं?