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

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

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

ppid_data_ingestion_status

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

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

user_id_data_ingestion_status

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

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

composite_data_ingestion_status

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

data_type_counts की जांच करके पक्का करें कि आइडेंटिफ़ायर की संख्या आपकी उम्मीद के मुताबिक है. इस सूची में, DataType को मिले सभी आइडेंटिफ़ायर (जैसे कि ईमेल पता, फ़ोन नंबर, घर का पता, और आईपी पता) की जानकारी दी गई है.

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

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

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

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

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

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

कंपोज़िट डेटा के लिए, data_type_counts देखें. इससे यह पुष्टि की जा सकेगी कि आइडेंटिफ़ायर की संख्या आपकी उम्मीद के मुताबिक है या नहीं. इस सूची में, DataType को मिले सभी आइडेंटिफ़ायर की जानकारी दी गई है. जैसे, ईमेल पता, फ़ोन नंबर, घर या ऑफ़िस का पता, और आईपी पता.

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

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

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

warning_info

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

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

error_info

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