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

सुझाव या राय देना

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

• आने वाले समय में होने वाले बदलावों और पहले से मालूम समस्याओं की सूची को अपडेट किया गया है
• इवेंट लेवल पर ज़्यादा सुविधाओं वाले कॉन्फ़िगरेशन के लिए, इवेंट लेवल पर कम सुविधाओं वाले कॉन्फ़िगरेशन को लॉन्च किया गया
• सितंबर 2023 से, registerWebSource, registerWebTrigger, registerAppSource और registerAppTrigger को उन फ़ील्ड के लिए स्ट्रिंग का इस्तेमाल करना चाहिए संख्या वाली वैल्यू हो सकती है (जैसे कि priority, source_event_id, debug_key, trigger_data, deduplication_key वगैरह)
• साल 2023 की चौथी तिमाही में, Android Attribution Reporting API में Google Cloud की सहायता जोड़ी जाएगी. इससे Google Cloud पर एग्रीगेशन सेवा का इस्तेमाल करके, खास जानकारी वाली रिपोर्ट जनरेट की जा सकेंगी. इसकी पूरी जानकारी यहां दी गई है. ज़्यादा जानकारी के लिए डिप्लॉयमेंट गाइड देखें Google Cloud के साथ एग्रीगेशन सेवा सेट अप करने के बारे में जानकारी.
• निजता बनाए रखने के लिए, यूनीक डेस्टिनेशन की संख्या के हिसाब से किराये की नई सीमाएं.
• लुकबैक विंडो ट्रिगर फ़िल्टर के लिए, अपडेट की गई सुविधा, साल 2024 की पहली तिमाही में लॉन्च होगी. ज़्यादा जानकारी के लिए यह नोट देखें.

खास जानकारी

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

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

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

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

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() पर कॉल करें. इस एपीआई के लिए, ये पैरामीटर ज़रूरी हैं:

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

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

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

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

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

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

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

   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"
   }
   

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

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

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

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

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

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

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

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

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

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

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

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

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

1. पहले से रजिस्टर किए गए यूआरआई का इस्तेमाल करके, ट्रिगर रजिस्ट्रेशन शुरू करने के लिए, AdTech SDK, एपीआई को कॉल करता है. ज़्यादा जानकारी के लिए, 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, कन्वर्ज़न ट्रिगर को एट्रिब्यूशन सोर्स से कैसे मैच करता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इवेंट	इवेंट होने का दिन	नोट
क्लिक 1	1	install_attribution_window 172800 (2 दिन) पर सेट हो, और post_install_exclusivity_window 864000 पर सेट है (10 दिन)
पुष्टि किया गया इंस्टॉल	2	यह एपीआई, पुष्टि किए गए इंस्टॉल को एट्रिब्यूट करता है, लेकिन वे इंस्टॉल उन्हें ट्रिगर नहीं माना जाता. इसलिए, इस रिपोर्ट में कोई रिपोर्ट नहीं भेजी जाती है अंक.
ट्रिगर 1 (फ़र्स्ट ओपन)	2	पहला ट्रिगर, विज्ञापन टेक्नोलॉजी से रजिस्टर किया गया. इस उदाहरण में, यह दिखाता है कि पहली बार खोला जाता है, लेकिन यह कोई भी ट्रिगर टाइप हो सकता है. पहले क्लिक को एट्रिब्यूट किया गया (पुष्टि किए गए इंस्टॉल के एट्रिब्यूशन से मेल खाता है).
क्लिक 2	4	क्लिक 1 के तौर पर, install_attribution_window और post_install_exclusivity_window के लिए एक ही वैल्यू का इस्तेमाल करता है
दूसरा ट्रिगर (इंस्टॉल के बाद)	5	दूसरा ट्रिगर, विज्ञापन टेक्नोलॉजी से रजिस्टर किया गया. इस उदाहरण में, यह दिखाता है कि जैसे कि पोस्ट-इंस्टॉल कन्वर्ज़न. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है क्लिक 1 को एट्रिब्यूट किया गया (पुष्टि किए गए इंस्टॉल के एट्रिब्यूशन से मेल खाता है). क्लिक 2 को खारिज कर दिया जाता है और आने वाले समय में उसे एट्रिब्यूशन नहीं दिया जा सकता.

नीचे दी गई सूची में, पोस्ट-इंस्टॉल करने के बारे में कुछ और जानकारी दी गई है विशेषता:

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

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

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

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

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

क्रॉस-ऐप्लिकेशन और वेब मेज़रमेंट के लिए ट्रिगर पाथ के साथ काम करने के लिए, विज्ञापन टेक्नोलॉजी और ऐप्लिकेशन में किए जाने वाले बदलावों के बारे में जानें.

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

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

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

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

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

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

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

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

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

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

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

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

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

ट्रिगर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

शुरुआत करने के लिए, AdTech A, AdTech B, और MMP को अपने-आप रजिस्टर होने की प्रोसेस पूरी करनी होगी, ताकि Attribution Reporting API. Privacy Sandbox खाते के लिए रजिस्टर करना लेख पढ़ें ज़्यादा जानकारी देखें.

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

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

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

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

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

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

AdTech A की तरह, AdTech B ने भी Attribution-Reporting-Redirect हेडर में एमएमपी का यूआरआई शामिल किया है. एपीआई, MMP की यूआरआई, और क्लिक को MMP के सर्वर से मिले मेटाडेटा के साथ रजिस्टर किया जाता है जवाब.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एट्रिब्यूशन

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

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

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

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

• AdTech A, क्योंकि MMP ने उस AdTech के रीडायरेक्ट से एक सोर्स रजिस्टर किया था.
• Ad tech B ने, क्योंकि Ad tech B ने अपनी कुंजियां शेयर की थीं और MMP ने इसे अपने एट्रिब्यूशन कॉन्फ़िगरेशन.

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

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

डीबग करना

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

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

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

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

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

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

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

मुख्य खोज की सुविधा के लॉन्च के बाद:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AdTech A की रिपोर्टिंग ऑरिजिन 2 के लिए, दूसरा सोर्स एपीआई से अस्वीकार कर दिया जाएगा. AdTech A की रिपोर्टिंग ऑरिजिन 2, डेटा स्रोत उसी डिवाइस पर अगले दिन तक काम करेगा.

कूलडाउन और रेट लिमिट

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

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

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

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

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

इवेंट-लेवल की रिपोर्ट में निजता की सुरक्षा के लिए इस्तेमाल किए जाने वाले तरीके

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

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

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

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

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

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

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

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

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

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

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

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

रिपोर्ट भेजने के लिए खास टाइम विंडो (डिफ़ॉल्ट व्यवहार)

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

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

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

सुविधाजनक इवेंट-लेवल कॉन्फ़िगरेशन

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

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

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

पहला चरण (इवेंट के लेवल को आसानी से बदलने की सुविधा का लाइट वर्शन) का इस्तेमाल इन कामों के लिए किया जा सकता है:

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

दूसरा चरण (इवेंट के सभी लेवल पर लागू होने वाला) का इस्तेमाल, ये सभी काम करने के लिए किया जा सकता है पहले चरण में ये सुविधाएँ उपलब्ध हैं और:

• रिपोर्ट में ट्रिगर डेटा के एलिमेंट की संख्या में बदलाव करें
• ट्रिगर डेटा की एलिमेंट की संख्या कम करके, ग़ैर-ज़रूरी डेटा की संख्या कम करना

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

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

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

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

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

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

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

• रेवेन्यू जैसी ट्रिगर वैल्यू की रिपोर्ट
• अलग-अलग तरह के ट्रिगर हैंडल करना

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

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

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

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

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

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

ये सेवाएं, एग्रीगेशन की सुविधा देती हैं. साथ ही, एग्रीगेट किए गए डेटा को गलत तरीके से ऐक्सेस होने से बचाती हैं.

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

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

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

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

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

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

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

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

डिजिटल बटन को मैनेज करने की सेवा

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

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

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

एग्रीगेशन रिपोर्ट एपीआई

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

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

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

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

दूसरे फ़ील्ड का इस्तेमाल वैल्यू की सूची रजिस्टर करने के लिए किया जाता है. इन वैल्यू को को जोड़ा जा सकता है. विज्ञापन टेक्नोलॉजी, aggregatable_values फ़ील्ड के साथ जवाब देगी एचटीटीपी हेडर Attribution-Reporting-Register-Trigger में. दूसरा फ़ील्ड है का इस्तेमाल उन वैल्यू की सूची को रजिस्टर करने के लिए किया जाता है जिन्हें हर कुंजी में योगदान देना चाहिए. इससे हर कुंजी को $ [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) सोर्स रजिस्ट्रेशन.
• एग्रीगेट की गई खास जानकारी वाली रिपोर्टिंग के लिए, सोर्स-साइड की पासकोड मैपिंग में CustomAudience शामिल करें. इसके लिए, Attribution Reporting API का इस्तेमाल करें.

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

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

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

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

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

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

उस मामले पर विचार करें जहां उपयोगकर्ता निम्न करता है:

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

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

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

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

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

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

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

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

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

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

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

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

एट्रिब्यूशन की सफलता की डीबगिंग रिपोर्ट

सोर्स और ट्रिगर रजिस्ट्रेशन, दोनों ही 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, दोनों सेट हों.

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

Verbose डीबगिंग रिपोर्ट की मदद से, डेवलपर एट्रिब्यूशन सोर्स या ट्रिगर रजिस्ट्रेशन का इस्तेमाल करता है. डीबग करने की ये रिपोर्ट भेजी जाती हैं एट्रिब्यूशन सोर्स के बाद सीमित समय के साथ या को अपनाएं.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. क्या कोई ऐसा उपयोग का मामला है जहां आप चाहते हैं कि API पुष्टि किया गया इंस्टॉल? इन रिपोर्ट को, विज्ञापन टेक्नोलॉजी प्लैटफ़ॉर्म की तय की गई दर की सीमाओं में गिना जाएगा.
2. क्या आपको सोर्स रजिस्ट्रेशन के लिए, ऐप्लिकेशन से विज्ञापन टेक्नोलॉजी को InputEvent पास करने में कोई समस्या आ रही है?
3. क्या आपके पास पहले से लोड किए गए ऐप्लिकेशन या फिर फिर से इंस्टॉल किए गए ऐप्लिकेशन के लिए, एट्रिब्यूशन के इस्तेमाल के कोई खास उदाहरण हैं?