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

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

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

2. हर अनुरोध का कुल स्टेटस देखें. अनुरोध पूरा होने पर, Status में code की वैल्यू 0 (OK enum value, 200 OK HTTP response) होती है. साथ ही, 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 पर, इनमें से सिर्फ़ एक फ़ील्ड सेट किया जाता है:

• events_ingestion_status
• audience_members_ingestion_status
• audience_members_removal_status

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

अगर अनुरोध 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

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 अब भी रिकॉर्ड को प्रोसेस करता है. हालांकि, वह PROCESSING_WARNING_REASON_USER_IDENTIFIER_DECRYPTION_ERROR की चेतावनी दिखाता है.AdIdentifiers

हालांकि, अगर 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 शामिल होता है.