अनुरोध की स्थिति और गड़बड़ी की जानकारी देखना

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

अपलोड की स्थिति देखने और गड़बड़ी की जानकारी की समीक्षा करने के लिए, RetrieveRequestStatus के साथ मिले request_id का इस्तेमाल करें.

अपने अनुरोधों की स्थिति देखने और इवेंट और ऑडियंस अपलोड की स्थिति की पुष्टि करने के लिए, यहां सुझाया गया वर्कफ़्लो दिया गया है:

  1. इवेंट भेजने या ऑडियंस सेगमेंट के सदस्यों को जोड़ने या हटाने के लिए अनुरोध जारी करना.

  2. डेटा डालने के हर अनुरोध की स्थिति देखना. सफल अनुरोध में Status होता है. इसमें code की वैल्यू 0 (enum वैल्यू OK, एचटीटीपी रिस्पॉन्स 200 OK) के बराबर होती है. साथ ही, यह IngestEventsResponse, IngestAudienceMembersResponse या RemoveAudienceMembersResponse दिखाता है.

    अगर अनुरोध पूरा नहीं होता है, तो गड़बड़ी को ठीक करने के लिए अनुरोध में बदलाव करें और उसे फिर से भेजें.

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

  3. 30 मिनट इंतज़ार करें. इसके बाद, हर सफल request_id के लिए, RetrieveRequestStatus का अनुरोध भेजें.

    RetrieveRequestStatusRequest के लिए, request_id की एक वैल्यू ज़रूरी है. डेटा डालने के अनुरोध के बाद मिले हर अनुरोध आईडी के लिए, स्टेटस का अलग अनुरोध भेजें.

    हर request_id के लिए, समय-समय पर यह तरीका तब तक दोहराएं, जब तक हर डेस्टिनेशन के लिए डेस्टिनेशन स्टेटस, SUCCESS, PARTIAL_SUCCESS या FAILURE न हो जाए. हर अनुरोध के बीच इंतज़ार करने के लिए, सुझाई गई पोलिंग रणनीति का पालन करें.

  4. हर RetrieveRequestStatusResponse की समीक्षा करें, ताकि यह पुष्टि की जा सके कि आपके अपलोड सही तरीके से काम कर रहे हैं. साथ ही, अपने डेटा से जुड़ी किसी भी समस्या का पता लगाया जा सके.

  5. डेटा से जुड़ी समस्याएं ठीक करें.

  6. पहले चरण पर वापस जाएं और तब तक दोहराएं, जब तक कि अपलोड की गई फ़ाइलों से जुड़ी सभी समस्याएं हल न हो जाएं.

डेस्टिनेशन का स्टेटस देखना

RetrieveRequestStatusResponse में मौजूद request_status_per_destination में, डेटा डालने के अनुरोध में मौजूद हर डेस्टिनेशन के लिए एक अलग एंट्री होती है.

उदाहरण के लिए, अगर आपके IngestAudienceMembersRequest में destinations सूची में तीन एंट्री शामिल हैं, तो तीन अलग-अलग ऑडियंस को डेटा भेजने के लिए, स्टेटस रिस्पॉन्स में request_status_per_destination में तीन एंट्री शामिल होंगी. हर ऑडियंस के लिए एक एंट्री होगी.

हर RequestStatusPerDestination पर request_status फ़ील्ड की जांच करें, ताकि यह पता चल सके कि Data Manager API ने उस डेस्टिनेशन के लिए डेटा प्रोसेस कर लिया है या नहीं.

request_status की ये वैल्यू हो सकती हैं:

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

  • SUCCESS: डेस्टिनेशन के लिए अनुरोध प्रोसेस करने की प्रोसेस बिना किसी गड़बड़ी के पूरी हो गई. प्रोसेसिंग के दौरान फ़्लैग की गई चेतावनियां देखें.

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

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

गड़बड़ी की जानकारी देखें

जब किसी डेस्टिनेशन के लिए request_status की संख्या SUCCESS, FAILURE या PARTIAL_SUCCESS तक पहुंच जाए, तो रिस्पॉन्स में मौजूद गड़बड़ी की जानकारी देखें. इससे, संख्या की पुष्टि करने और समस्याओं को हल करने में मदद मिलेगी.

हर डेस्टिनेशन के हिसाब से, इवेंट या ऑडियंस का स्टेटस देखना

डेटा डालने के अनुरोध के टाइप के हिसाब से, स्टेटस फ़ील्ड की जांच करें. हर RequestStatusPerDestination पर, इनमें से सिर्फ़ एक फ़ील्ड सेट किया गया हो:

इवेंट डेटा जोड़े जाने का स्टेटस

अगर अनुरोध IngestEventsRequest था, तो events_ingestion_status फ़ील्ड में जानकारी अपने-आप भर जाती है.

IngestEventStatus के record_count की जांच करें, ताकि यह पुष्टि की जा सके कि मिले रिकॉर्ड की कुल संख्या आपकी उम्मीद के मुताबिक है. record_count में, अपलोड किए गए और अपलोड नहीं किए जा सके, दोनों तरह के रिकॉर्ड शामिल होते हैं.

ऑडियंस सेगमेंट के सदस्यों को शामिल करने की स्थिति

अगर अनुरोध IngestAudienceMembersRequest था, तो audience_members_ingestion_status फ़ील्ड में जानकारी अपने-आप भर जाती है. हर तरह के ऑडियंस डेटा की जांच करने के लिए, यहां IngestAudienceMembersStatus फ़ील्ड दिया गया है. इनमें से सिर्फ़ एक फ़ील्ड सेट किया गया है.

composite_data_ingestion_status

IngestCompositeDataStatus के record_count को देखें और पुष्टि करें कि आपको स्वास्थ्य से जुड़ी जानकारी का जो इतिहास मिला है वह आपकी उम्मीद के मुताबिक है. record_count में, सफल और असफल, दोनों तरह के रिकॉर्ड शामिल होते हैं.

data_type_counts की जांच करके पक्का करें कि आइडेंटिफ़ायर की संख्या आपकी उम्मीद के मुताबिक हो. इस सूची में, DataType को मिले सभी आइडेंटिफ़ायर की जानकारी दी गई है. जैसे, ईमेल पता, फ़ोन नंबर, घर या ऑफ़िस का पता, और आईपी पता.

अगर अनुरोध में ज़रूरत के मुताबिक रिकॉर्ड थे, तो upload_match_rate_range में अनुरोध के रिकॉर्ड के लिए, मैच रेट की रेंज शामिल होती है.

google_user_id_data_ingestion_status

IngestGoogleUserIdDataStatus का record_count देखें और पुष्टि करें कि आपको स्वास्थ्य से जुड़ी जानकारी का जो इतिहास मिला है वह आपकी उम्मीद के मुताबिक है. record_count में, सफल और असफल, दोनों तरह के रिकॉर्ड शामिल होते हैं.

google_user_id_count देखें और पुष्टि करें कि आपको मिले Google यूज़र आईडी की संख्या, आपकी उम्मीद के मुताबिक है.

mobile_data_ingestion_status

IngestMobileDataStatus के record_count को देखें और पुष्टि करें कि आपको स्वास्थ्य से जुड़ी जानकारी के इतिहास की जितनी संख्या मिली है वह आपकी उम्मीद के मुताबिक है. record_count में, सफल और असफल, दोनों तरह के रिकॉर्ड शामिल होते हैं.

mobile_id_count देखें और पुष्टि करें कि आपको जितने मोबाइल आईडी मिले हैं उनकी संख्या आपकी उम्मीद के मुताबिक है.

pair_data_ingestion_status

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

pair_id_count की जांच करके, यह पुष्टि करें कि आपको मिले PAIR आईडी की संख्या, आपकी उम्मीद के मुताबिक है.

partner_provided_id_data_ingestion_status

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

partner_provided_id_count को देखकर पुष्टि करें कि पार्टनर से मिले आईडी की संख्या आपकी उम्मीद के मुताबिक है या नहीं.

ppid_data_ingestion_status

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

ppid_count की जांच करके पक्का करें कि आपको मिले पीपीआईडी की संख्या, आपकी उम्मीद के मुताबिक हो.

user_data_ingestion_status

IngestUserDataStatus के record_count को देखें और पुष्टि करें कि आपको स्वास्थ्य से जुड़ी जानकारी के इतिहास की जितनी फ़ाइलें मिली हैं उनकी संख्या आपकी उम्मीद के मुताबिक है. record_count में, सफल और असफल, दोनों तरह के रिकॉर्ड शामिल होते हैं.

user_identifier_count को देखकर पुष्टि करें कि आपको मिले यूज़र आइडेंटिफ़ायर की संख्या आपकी उम्मीद के मुताबिक है.

अगर अनुरोध में ज़रूरत के मुताबिक रिकॉर्ड थे, तो upload_match_rate_range में अनुरोध के रिकॉर्ड के लिए, मैच रेट की रेंज शामिल होती है.

user_id_data_ingestion_status

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

user_id_count को देखकर पुष्टि करें कि मिले यूज़र आईडी की संख्या, आपकी उम्मीद के मुताबिक है या नहीं.

ऑडियंस सेगमेंट के सदस्यों को हटाने की स्थिति

अगर अनुरोध RemoveAudienceMembersRequest था, तो audience_members_removal_status फ़ील्ड में जानकारी अपने-आप भर जाती है. हर तरह के ऑडियंस डेटा की जांच करने के लिए, यहां RemoveAudienceMembersStatus फ़ील्ड दिया गया है. इनमें से सिर्फ़ एक फ़ील्ड सेट किया गया है.

composite_data_removal_status
कंपोज़िट डेटा को हटाने का स्टेटस
google_user_id_data_removal_status
Google यूज़र आईडी के डेटा को हटाने का स्टेटस
mobile_data_removal_status
मोबाइल डेटा के लिए, हटाने की स्थिति.
pair_data_removal_status
PAIR डेटा को हटाने का स्टेटस.
partner_provided_id_data_removal_status
पार्टनर से मिले आईडी डेटा को हटाने का स्टेटस
ppid_data_removal_status
पीपीआईडी डेटा को हटाने की स्थिति.
user_data_removal_status
उपयोगकर्ता के डेटा को हटाने की स्थिति.
user_id_data_removal_status
यूज़र आईडी के डेटा को हटाने का स्टेटस

record_count की जांच करके पुष्टि करें कि मिले रिकॉर्ड की कुल संख्या, आपकी उम्मीद के मुताबिक है. record_count में, सफल और असफल, दोनों तरह के रिकॉर्ड शामिल होते हैं.

इसके अलावा, मिले आइडेंटिफ़ायर की कुल संख्या की पुष्टि करने के लिए, user_identifier_count, mobile_id_count, pair_id_count, ppid_count, user_id_count, google_user_id_count या partner_provided_id_count देखें.

कंपोज़िट डेटा के लिए, data_type_counts की जांच करके पक्का करें कि आइडेंटिफ़ायर की संख्या आपकी उम्मीदों के मुताबिक हो. इस सूची में, DataType को मिले सभी आइडेंटिफ़ायर की जानकारी दी गई है. जैसे, ईमेल पता, फ़ोन नंबर, घर या ऑफ़िस का पता, और आईपी पता.

चेतावनियां और गड़बड़ियां देखना

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

  • गड़बड़ी का मतलब है कि एपीआई ने रिकॉर्ड को पूरी तरह से अस्वीकार कर दिया है.

  • चेतावनी से पता चलता है कि एपीआई ने रिकॉर्ड को अस्वीकार नहीं किया. हालांकि, उसे रिकॉर्ड के डेटा के कुछ हिस्सों को अनदेखा करना पड़ा.

उदाहरण के लिए, अगर किसी Event में एन्क्रिप्ट (सुरक्षित) किया गया UserIdentifier डेटा और AdIdentifiers, जैसे कि gclid शामिल है और UserIdentifier डेटा को डिक्रिप्ट नहीं किया जा सकता, तो Data Manager API अब भी AdIdentifiers का इस्तेमाल करके रिकॉर्ड को प्रोसेस करता है. हालांकि, यह चेतावनी PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR दिखाता है.

हालांकि, अगर Event में AdIdentifiers नहीं है और UserIdentifier डेटा को डिक्रिप्ट नहीं किया जा सकता, तो Data Manager API पूरे रिकॉर्ड को अस्वीकार कर देता है और गड़बड़ी PROCESSING_ERROR_REASON_USER_IDENTIFIER_DECRYPTION_ERROR की रिपोर्ट करता है. ऐसा इसलिए होता है, क्योंकि मान्य Event में ad_identifiers या user_data में से कम से कम एक होना चाहिए.

यहां जवाब के वे फ़ील्ड दिए गए हैं जिनमें चेतावनी और गड़बड़ी की जानकारी शामिल है. ये फ़ील्ड तब भरे जाते हैं, जब डेस्टिनेशन का स्टेटस SUCCESS, PARTIAL_SUCCESS या FAILURE पर पहुंच जाता है.

warning_info

एक WarningInfo ऑब्जेक्ट. इसके warning_counts फ़ील्ड में, WarningCount ऑब्जेक्ट की सूची होती है. हर WarningCount में चेतावनी के टाइप के साथ एक reason और चेतावनी के टाइप वाले रिकॉर्ड की संख्या बताने वाला एक record_count होता है.

warning_info को देखें, भले ही डेस्टिनेशन का कुल स्टेटस SUCCESS हो.

error_info

एक ErrorInfo ऑब्जेक्ट. इसके error_counts फ़ील्ड में, ErrorCount ऑब्जेक्ट की सूची होती है. हर ErrorCount में गड़बड़ी के टाइप के साथ एक reason और उस गड़बड़ी की वजह से फ़ेल हुए रिकॉर्ड की संख्या बताने वाला एक record_count होता है.

पोलिंग की रणनीति

एक्स्पोनेंशियल बैकऑफ़ एल्गोरिदम का इस्तेमाल करके, समय-समय पर RetrieveRequestStatusRequest भेजें. ऐसा तब तक करें, जब तक कि ओरिजनल अनुरोध में मौजूद हर डेस्टिनेशन के लिए, request_status, SUCCESS, FAILURE या PARTIAL_SUCCESS तक न पहुंच जाए. इसमें 24 घंटे लग सकते हैं. हालांकि, Data Manager API कुछ अनुरोधों को 30 मिनट में भी प्रोसेस कर सकता है.

यहां शुरुआती इंतज़ार के सही समय और फिर से कोशिश करने के कॉन्फ़िगरेशन का एक उदाहरण दिया गया है. इससे, लाइव होने और कोटा के इस्तेमाल को संतुलित किया जा सकता है:

सेटिंग वैल्यू
गड़बड़ी की जानकारी पाने के लिए, पहले अनुरोध से पहले इंतज़ार करने का समय (मिनट में) 30
बैकऑफ़ मल्टीप्लायर 1.3
ज़्यादा से ज़्यादा बैकऑफ़ (मिनट में) 60 (1 घंटा)
ज़्यादा से ज़्यादा कुल समय (मिनट में) 1440 (24 घंटे)

इस कॉन्फ़िगरेशन के साथ, अनुरोधों का क्रम और बीता हुआ समय यहां दिया गया है:

ग्राफ़

पोलिंग की रणनीति

डेटा

कोशिश डेटा डालने के अनुरोध के बाद से बीता समय (hh:mm) कॉल करने से पहले लगने वाला समय नोट
1 00:30 30.0 मिनट सबसे पहले, स्टेटस की उपलब्धता देखें
2 01:09 39.0 मिनट
3 01:59 50.7 मिनट
4 02:59 60.0 मिनट देरी की सीमा अब एक घंटे तक सीमित है
5 03:59 60.0 मिनट
6 04:59 60.0 मिनट
7 05:59 60.0 मिनट
8 06:59 60.0 मिनट
9 07:59 60.0 मिनट
10 08:59 60.0 मिनट
11 09:59 60.0 मिनट
12 10:59 60.0 मिनट
13 11:59 60.0 मिनट 12 घंटे का निशान
14 12:59 60.0 मिनट
15 13:59 60.0 मिनट
16 14:59 60.0 मिनट
17 15:59 60.0 मिनट
18 16:59 60.0 मिनट
19 17:59 60.0 मिनट
20 18:59 60.0 मिनट
21 19:59 60.0 मिनट
22 20:59 60.0 मिनट
23 21:59 60.0 मिनट
24 22:59 60.0 मिनट
25 23:59 60.0 मिनट 24 घंटे की तय समयसीमा से पहले किया गया आखिरी अनुरोध

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

अनुमति पाने के लिए ज़रूरी शर्तें

RetrieveRequestStatusRequest में डेस्टिनेशन खाते या अनुरोध के हेडर स्वीकार नहीं किए जाते. इसके बजाय, Data Manager API, request_id से जुड़े डेटा को शामिल करने के ओरिजनल अनुरोध से डेस्टिनेशन की पहचान करता है. साथ ही, यह पुष्टि करता है कि कॉलर के पास हर Destination पर operating_account का ऐक्सेस है या नहीं.

किसी अनुरोध की स्थिति देखने के लिए, RetrieveRequestStatusRequest में इस्तेमाल किए गए क्रेडेंशियल को, डेटा डालने के मूल अनुरोध में मौजूद हर डेस्टिनेशन के operating_account के लिए, इन ज़रूरी शर्तों को पूरा करना होगा:

  • एक जैसा ऐक्सेस पाथ: क्रेडेंशियल के पास हर operating_account का ऐक्सेस होना चाहिए. इसके लिए, डेटा डालने के मूल अनुरोध में बताए गए एक जैसे ऐक्सेस पाथ का इस्तेमाल करना होगा.

    उदाहरण के लिए, अगर Google Ads operating_account के लिए डेटा डालने के अनुरोध में, पैरंट मैनेजर खाते को login_account के तौर पर बताया गया है, तो क्रेडेंशियल के पास उसी मैनेजर खाते के ज़रिए operating_account का ऐक्सेस भी होना चाहिए. भले ही, क्रेडेंशियल से जुड़े Google खाते के पास चाइल्ड operating_account का सीधा ऐक्सेस हो, लेकिन अगर उस खाते के पास डेटा डालने के दौरान तय किए गए login_account मैनेजर खाते का ऐक्सेस नहीं है, तो अनुरोध पूरा नहीं हो पाता और PERMISSION_DENIED गड़बड़ी का मैसेज दिखता है.

  • ज़रूरी ऐक्सेस लेवल: क्रेडेंशियल से जुड़े Google खाते के पास, operating_account में डेटा डालने की अनुमति वाला ऐक्सेस लेवल या भूमिका होनी चाहिए.

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

पीछे जाएं
उपयोगकर्ता का डेटा एन्क्रिप्ट (सुरक्षित) करें
आगे बढ़ें
एपीआई से जुड़ी गड़बड़ियों को समझना