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

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

  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, डेस्टिनेशन खातों या अनुरोध हेडर को स्वीकार नहीं करता. इसके बजाय, Data Manager API, से जुड़े ओरिजनल इनजेशन अनुरोध से डेस्टिनेशन की पहचान करता है. साथ ही, यह पुष्टि करता है कि अनुरोध करने वाले के पास हर Destination पर operating_account को ऐक्सेस करने की अनुमति है.request_id

अनुरोध का स्टेटस देखने के लिए, RetrieveRequestStatusRequest में इस्तेमाल किए गए क्रेडेंशियल को इन ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, ओरिजनल इनजेस्ट करने के अनुरोध में शामिल हर डेस्टिनेशन के operating_account के लिए ज़रूरी हैं:

  • एक जैसा ऐक्सेस पाथ: क्रेडेंशियल के पास हर operating_account को ऐक्सेस करने की अनुमति होनी चाहिए. इसके लिए, ओरिजनल डेटा ट्रांसफ़र करने के अनुरोध में बताए गए एक जैसे ऐक्सेस पाथ का इस्तेमाल करना होगा.

    उदाहरण के लिए, अगर Google Ads operating_account के लिए डेटा ट्रांसफ़र करने के अनुरोध में, पैरंट मैनेजर खाते को login_account के तौर पर तय किया गया है, तो क्रेडेंशियल के पास उसी मैनेजर खाते के ज़रिए operating_account का ऐक्सेस भी होना चाहिए. अगर क्रेडेंशियल से जुड़ा Google खाता, चाइल्ड operating_account को सीधे तौर पर ऐक्सेस कर सकता है, तब भी अनुरोध पूरा नहीं होगा और PERMISSION_DENIED गड़बड़ी का मैसेज दिखेगा. ऐसा तब होगा, जब उस खाते के पास, डेटा ट्रांसफ़र के दौरान तय किए गए login_account मैनेजर खाते से ऐक्सेस न हो.

  • ऐक्सेस का सही लेवल: क्रेडेंशियल से जुड़े Google खाते के पास, operating_account में डेटा डालने की अनुमति वाला ऐक्सेस लेवल या भूमिका होनी चाहिए.

    उदाहरण के लिए, Google Ads में, Google खाते के पास एडमिन या स्टैंडर्ड ऐक्सेस लेवल होना चाहिए. रीड-ओनली ऐक्सेस लेवल वाले खाते के क्रेडेंशियल के साथ किए गए अनुरोध में, PERMISSION_DENIED गड़बड़ी होती है.

पोलिंग की रणनीति

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 घंटे की कुल अवधि से पहले किया गया आखिरी अनुरोध

बैकऑफ़ में देरी के लिए, कुछ रैंडम jitter जोड़ें, ताकि "थंडरिंग हर्ड" की समस्या को रोका जा सके. इस समस्या में, कई क्लाइंट एक साथ फिर से कोशिश करते हैं.

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

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

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

डेस्टिनेशन की पूरी स्थिति देखना

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

request_status की संभावित वैल्यू यहां दी गई हैं:

  • PROCESSING: मंज़िल के डेटा को अब भी प्रोसेस किया जा रहा है. इस चरण में, मंज़िल के लिए चेतावनी और गड़बड़ियां नहीं दिखती हैं.

  • SUCCESS: डेस्टिनेशन के लिए अनुरोध प्रोसेस करने की प्रक्रिया पूरी हो गई है. इसमें कोई गड़बड़ी नहीं हुई. प्रोसेसिंग के दौरान फ़्लैग की गई चेतावनी देखें.

  • FAILURE: गड़बड़ियों की वजह से, डेस्टिनेशन के सभी रिकॉर्ड प्रोसेस नहीं किए जा सके. चेतावनी और गड़बड़ियां देखें, ताकि यह पता लगाया जा सके कि सभी रिकॉर्ड क्यों अपलोड नहीं हो पाए. साथ ही, प्रोसेसिंग के दौरान फ़्लैग की गई चेतावनियां भी देखें.

  • PARTIAL_SUCCESS: डेस्टिनेशन के कुछ रिकॉर्ड ट्रांसफ़र हो गए, लेकिन अन्य रिकॉर्ड में गड़बड़ियां होने की वजह से ट्रांसफ़र नहीं हो सके. गड़बड़ियां देखें, ताकि यह पता लगाया जा सके कि कुछ रिकॉर्ड क्यों इंपोर्ट नहीं हो पाए. प्रोसेसिंग के दौरान फ़्लैग की गई चेतावनियां भी देखें.

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

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

इवेंट के डेटा को प्रोसेस करने की स्थिति

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

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

ऑडियंस के सदस्यों के डेटा को शामिल करने का स्टेटस

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

composite_data_ingestion_status

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

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

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

google_user_id_data_ingestion_status

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

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

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 आईडी की संख्या, आपकी उम्मीद के मुताबिक है या नहीं.

partner_provided_id_data_ingestion_status

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

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

ppid_data_ingestion_status

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

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

user_data_ingestion_status

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

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

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

user_id_data_ingestion_status

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

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

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

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

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

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

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

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

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

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

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

warning_info

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

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

error_info

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