यहां इवेंट और ऑडियंस के अपलोड किए गए डेटा की पुष्टि करने और डेटा से जुड़ी समस्याओं का पता लगाने के लिए, सुझाया गया वर्कफ़्लो दिया गया है.
- इवेंट भेजने के अनुरोध करना या दर्शक जोड़ना या हटाना.
- हर
IngestEventsResponse
,IngestAudienceMembersResponse
याRemoveAudienceMembersResponse
सेrequest_id
कैप्चर करें. - हर
request_id
के लिए,RetrieveRequestStatus
अनुरोध भेजें. - हर
RetrieveRequestStatusResponse
की समीक्षा करें, ताकि यह पुष्टि की जा सके कि आपके अपलोड किए गए डेटा ठीक से काम कर रहे हैं. साथ ही, अपने डेटा से जुड़ी किसी भी समस्या का पता लगाया जा सके. - डेटा से जुड़ी समस्याएं ठीक करें.
- पहले चरण पर वापस जाएं और तब तक इसे दोहराएं, जब तक अपलोड की गई सभी समस्याएं ठीक न हो जाएं.
अनुरोध बनाना
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
से पता चलता है कि गड़बड़ी के उस टाइप की वजह से कितने रिकॉर्ड प्रोसेस नहीं हो सके.