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

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

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

  • इवेंट-लेवल पर ज़्यादा सुविधाओं वाले कॉन्फ़िगरेशन के लिए, इवेंट-लेवल पर कम सुविधाओं वाले कॉन्फ़िगरेशन को लॉन्च किया गया

  • सितंबर 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-बिट का ऐसा पूर्णांक होना चाहिए जिसमें साइन हो और जिसे स्ट्रिंग के तौर पर फ़ॉर्मैट किया गया हो.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एट्रिब्यूशन सोर्स रीडायरेक्ट, 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 पर रीडायरेक्ट करते हैं. ट्रिगर होने पर, दोनों एमएमपी उस ट्रिगर को एट्रिब्यूशन रिपोरटिंग एपीआई के साथ रजिस्टर करते हैं. इसके बाद, विज्ञापन टेक्नोलॉजी #3 को एक ही ट्रिगर के लिए, दो अलग-अलग रीडायरेक्ट मिलते हैं. पहला रीडायरेक्ट, एमएमपी #1 से और दूसरा एमएमपी #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, और एमएमपी को एट्रिब्यूशन रिपोर्टिंग एपीआई का इस्तेमाल करने के लिए, रजिस्टर करना होगा. ज़्यादा जानकारी के लिए, Privacy Sandbox खाते के लिए रजिस्टर करें देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एट्रिब्यूशन

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

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

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

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

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

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

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

डीबग करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ब्राउज़र के इस्तेमाल किए जाने वाले registerWebSource और 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 विज्ञापन टेक्नोलॉजी.
  • 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 अलग-अलग डेस्टिनेशन तक सीमित किया जाए. साथ ही, हर सोर्स ऐप्लिकेशन के लिए ऐसे सोर्स का इस्तेमाल किया जाए जिनकी समयसीमा खत्म न हुई हो.

इवेंट-लेवल की रिपोर्ट पर लागू होने वाले, निजता की सुरक्षा करने वाले तरीके

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इवेंट-लेवल पर कॉन्फ़िगरेशन में बदलाव करने की सुविधा

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

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

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

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

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

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

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

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

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

  • कैंपेन लेवल पर कन्वर्ज़न की कुल संख्या
  • भौगोलिक लेवल पर परचेज़ वैल्यू को एग्रीगेट करना
// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • यूआरआई का की-वैल्यू मैप बनाएं, ताकि इसका इस्तेमाल 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, ज़रूरी शर्तें पूरी करने वाला एकमात्र एट्रिब्यूशन सोर्स है. एपीआई एट्रिब्यूट, क्लिक #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, दोनों सेट हों.

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

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