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

सुझाव/राय देना या शिकायत करना

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

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

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

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

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

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

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

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

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

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

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

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

  1. विज्ञापन तकनीक 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, कन्वर्ज़न ट्रिगर को एट्रिब्यूशन सोर्स से कैसे मैच करता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एट्रिब्यूशन

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

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

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

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

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

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

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

डीबग करना

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

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

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

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

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

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

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

कुंजी की खोज की शुरुआत के साथ:

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

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

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

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

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

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

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

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

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

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

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

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

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

विज्ञापन टेक्नोलॉजी की संख्या से जुड़ी सीमाएं

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

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

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

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

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

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

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

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

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

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

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

कूलडाउन और रेट की सीमाएं

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Attribution Reporting API में इस अतिरिक्त सुविधा को दो चरणों में शामिल किया जाएगा:

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

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

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

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

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

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

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

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

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

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

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

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

  • ट्रिगर वैल्यू की रिपोर्ट, जैसे कि रेवेन्यू
  • कई तरह के ट्रिगर को मैनेज करना

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

Attribution Reporting API की मदद से तैयार की गई रिपोर्ट और उसे कैसे भेजा जाता है, इसका डायग्राम इस तरह से दिखाया गया है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एग्रीगेटेबल रिपोर्ट एपीआई

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

इकट्ठा किए जा सकने वाले सोर्स डेटा को रजिस्टर करना

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

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

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

फ़ाइनल कुंजियों के लिए, ज़्यादा से ज़्यादा 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

वर्बोस डीबगिंग रिपोर्ट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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