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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऐप्लिकेशन इंस्टॉल करने के बाद का एट्रिब्यूशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एट्रिब्यूशन सोर्स के रीडायरेक्ट, 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 पर रीडायरेक्ट करते हैं. ट्रिगर होने पर, दोनों एमएमपी उस ट्रिगर को Attribution Reporting API के साथ रजिस्टर करते हैं. इसके बाद, AdTech #3 को एक ही ट्रिगर के लिए दो अलग-अलग रीडायरेक्ट मिलते हैं. पहला रीडायरेक्ट, MMP #1 से और दूसरा MMP #2 से.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इस उदाहरण में बताया गया है कि Attribution Reporting API, उपयोगकर्ता की कार्रवाइयों की सीरीज़ पर कैसे प्रतिक्रिया देता है.

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

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

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

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

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

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

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

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

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

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

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

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

एट्रिब्यूशन

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

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

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

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

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

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

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

डीबग करना

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

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

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

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

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

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

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

मुख्य खोज की शुरुआत के साथ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

समयसीमा खत्म हो चुके सोर्स को, अनुरोध की दर की सीमाओं में नहीं गिना जाता.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिफ़रेंशियल प्राइवसी के लिए ग़ैर-ज़रूरी डेटा का फ़्रेमवर्क

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

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

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

\[ p = \frac{k}{k + e^ε - 1} \]

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

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

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

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

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

रिपोर्ट भेजने के लिए खास समयावधि (डिफ़ॉल्ट तौर पर लागू)

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

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

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

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

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

यह अतिरिक्त सुविधा, Attribution Reporting API में दो चरणों में मिलेगी:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एग्रीगेटेबल रिपोर्ट अकाउंटिंग

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

Aggregatable Reports API

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

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

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

\[ Laplace(\frac{L1}{ε}) \]

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

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

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

  • यूआरआई का एक की-वैल्यू मैप बनाएं, जिसका इस्तेमाल 1) इंटरैक्शन रिपोर्टिंग और 2) सोर्स रजिस्ट्रेशन, दोनों के लिए किया जा सके.
  • एग्रीगेट की गई खास जानकारी वाली रिपोर्ट के लिए, सोर्स साइड की मैपिंग में CustomAudience को शामिल करें. इसके लिए, 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 ही एट्रिब्यूशन का एक ऐसा सोर्स है जिसे मंज़ूरी दी गई है. API, इस ट्रिगर को #1 पर क्लिक करने का एट्रिब्यूट देता है.
  7. उपयोगकर्ता, विज्ञापन देने वाले के ऐप्लिकेशन में अपने कार्ट में कोई आइटम जोड़ता है. यह आइटम, 1 (कन्वर्ज़न #4) की प्राथमिकता के साथ रजिस्टर किया गया है.
    • क्लिक #1, ज़रूरी शर्तें पूरी करने वाला एकमात्र एट्रिब्यूशन सोर्स है. एपीआई एट्रिब्यूट, क्लिक #1 के लिए इस ट्रिगर को ट्रिगर करते हैं.
  8. उपयोगकर्ता, विज्ञापन देने वाले के ऐप्लिकेशन में खरीदारी करता है. इसे 2 (कन्वर्ज़न #5) प्राथमिकता के साथ रजिस्टर किया गया है.
    • क्लिक #1 ही एट्रिब्यूशन का एक ऐसा सोर्स है जिसे मंज़ूरी दी गई है. API, इस ट्रिगर को #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 की अनुमतियों का एलान किया हो). इससे यह पक्का होता है कि रोल आउट के दौरान एपीआई को पूरी तरह से समझा जा सकता है, सभी गड़बड़ियां ठीक की जा सकती हैं, और विज्ञापन आईडी के हिसाब से दिए गए विकल्पों से परफ़ॉर्मेंस की तुलना ज़्यादा आसानी से की जा सकती है. डीबग करने वाली रिपोर्ट दो तरह की होती हैं: एट्रिब्यूशन की सफलता और ज़्यादा जानकारी वाली रिपोर्ट.

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

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

सोर्स और ट्रिगर रजिस्ट्रेशन, दोनों में 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 एंडपॉइंट.

हर वर्बोस रिपोर्ट में ये फ़ील्ड होते हैं:

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

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

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

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

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

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

किसी कीवर्ड को मैच न करने की कई वजहें हो सकती हैं.

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

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

अनजाने में होने वाली वजहें:

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

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

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

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

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