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

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

  1. इवेंट भेजने के अनुरोध करना या दर्शक जोड़ना या हटाना.

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

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

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

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

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

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

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

अनुरोध बनाना

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

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

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

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

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

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

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

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

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

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

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

IngestEventStatus के record_count की जांच करें. इससे यह पुष्टि की जा सकेगी कि मिले हुए रिकॉर्ड की कुल संख्या आपकी उम्मीदों के मुताबिक है. 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

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

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

pair_data_ingestion_status

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

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

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

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

user_data_removal_status
उपयोगकर्ता के डेटा को हटाने का स्टेटस.
mobile_data_removal_status
मोबाइल डेटा के लिए, हटाने की स्थिति.
pair_data_removal_status
PAIR डेटा को हटाने की स्थिति.

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

इसके अलावा, मिले हुए यूज़र आइडेंटिफ़ायर, मोबाइल आईडी या PAIR आईडी की कुल संख्या की पुष्टि करने के लिए, user_identifier_count, mobile_id_count या pair_id_count देखें.

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

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

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

उदाहरण के लिए, अगर किसी Event में एन्क्रिप्ट (सुरक्षित) किया गया UserIdentifier डेटा और gclid जैसे AdIdentifiers शामिल हैं और 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 होता है.
error_info
ErrorCount ऑब्जेक्ट की सूची. हर ErrorCount में, गड़बड़ी के टाइप के साथ reason और record_count होता है. record_count से पता चलता है कि गड़बड़ी के उस टाइप की वजह से कितने रिकॉर्ड प्रोसेस नहीं हो सके.