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

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

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

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

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

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

  3. पूरे हुए हर request_id के लिए, RetrieveRequestStatus अनुरोध भेजें.

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

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

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

अनुरोध भेजें

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

एपीआई एक्सप्लोरर का इस्तेमाल करके, अपने ब्राउज़र में कोई अनुरोध आज़माएं.

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

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

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

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

सबसे पहले, request_status फ़ील्ड देखें, ताकि यह पता चल सके कि Data Manager API ने RequestStatusPerDestination के destination के लिए डेटा को प्रोसेस कर लिया है या नहीं. `request_status` की ये वैल्यू हो सकती हैं:Here are the possible values of request_status:

  • PROCESSING: डेस्टिनेशन के लिए डेटा अब भी प्रोसेस किया जा रहा है.
  • SUCCESS: डेस्टिनेशन के लिए अनुरोध की प्रोसेसिंग बिना किसी गड़बड़ी के पूरी हो गई है.
  • FAILURE: गड़बड़ियों की वजह से, डेस्टिनेशन के सभी रिकॉर्ड प्रोसेस नहीं हो पाए.
  • PARTIAL_SUCCESS: डेस्टिनेशन के कुछ रिकॉर्ड प्रोसेस हो गए हैं, लेकिन गड़बड़ियों की वजह से कुछ रिकॉर्ड प्रोसेस नहीं हो पाए.

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

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

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

अगर अनुरोध IngestEventsRequest था, तो events_ingestion_status फ़ील्ड में डेटा दिखेगा.

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

ऑडियंस के सदस्यों को जोड़ने का स्टेटस

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

user_data_ingestion_status

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

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

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

mobile_data_ingestion_status

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

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

pair_data_ingestion_status

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

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

ppid_data_ingestion_status

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

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

user_id_data_ingestion_status

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

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

ऑडियंस के सदस्यों को हटाने का स्टेटस

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

user_data_removal_status
उपयोगकर्ता के डेटा को हटाने का स्टेटस.
mobile_data_removal_status
मोबाइल डेटा को हटाने का स्टेटस.
pair_data_removal_status
पीएआईआर डेटा को हटाने का स्टेटस.
ppid_data_removal_status
पीपीआईडी डेटा को हटाने का स्टेटस.
user_id_data_removal_status
यूज़र आईडी डेटा को हटाने का स्टेटस

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

इसके अलावा, user_identifier_count, mobile_id_count या pair_id_count की जांच करके, मिले उपयोगकर्ता आइडेंटिफ़ायर, मोबाइल आईडी या पीएआईआर आईडी की कुल संख्या की पुष्टि करें.

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

डेस्टिनेशन और अनुरोध के टाइप के स्टेटस फ़ील्ड के अलावा, 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 में से कम से कम एक होना चाहिए.

यहां जवाब के वे फ़ील्ड दिए गए हैं जिनमें चेतावनी और गड़बड़ी की जानकारी शामिल होती है.

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