गड़बड़ी की जानकारी

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

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

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

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

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

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

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

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

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

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

अनुरोध भेजें

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

अनुमति देना

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 को सीधे तौर पर ऐक्सेस कर सकता है, तब भी अनुरोध पूरा नहीं होगा और PERMISSION_DENIED गड़बड़ी का मैसेज दिखेगा. ऐसा तब होगा, जब उस खाते के पास, डेटा ट्रांसफ़र के दौरान तय किए गए login_account मैनेजर खाते से ऐक्सेस न हो.

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

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

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

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 घंटे की कुल अवधि से पहले किया गया आखिरी अनुरोध

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

जवाबों की समीक्षा करें

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

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

डेस्टिनेशन की पूरी स्थिति देखना

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

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

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

  • 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 होता है, जो उन रिकॉर्ड की संख्या बताता है जिनमें उस टाइप की चेतावनी थी.

अगर डेस्टिनेशन का स्टेटस SUCCESS है, तब भी warning_info देखें.

error_info

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