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

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

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

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

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

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

  3. 30 मिनट इंतज़ार करें. इसके बाद, हर पूरे हुए request_id के लिए, RetrieveRequestStatus अनुरोध भेजें.

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

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

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

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

अनुरोध भेजें

A RetrieveRequestStatusRequest के लिए, single 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 घंटे पूरे होने से पहले का आखिरी अनुरोध

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

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

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

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

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

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

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

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

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

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

अगर अनुरोध IngestEventsRequest था, तो events_ingestion_status फ़ील्ड दिखेगा.

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

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

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

user_data_ingestion_status

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

ppid_data_ingestion_status

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

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

user_id_data_ingestion_status

यह पुष्टि करने के लिए कि मिले रिकॉर्ड की कुल संख्या आपकी उम्मीदों के मुताबिक है, record_count का IngestUserIdDataStatus देखें. 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 में, अनुरोध के लिए चेतावनियों और गड़बड़ियों का ब्रेकडाउन शामिल होता है.

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

उदाहरण के लिए, अगर Google Ads के ऑफ़लाइन कन्वर्ज़न के लिए किसी 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 की गड़बड़ी की रिपोर्ट करता है. ऐसा इसलिए, क्योंकि Google Ads के ऑफ़लाइन कन्वर्ज़न के मान्य 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 से पता चलता है कि कितने रिकॉर्ड में उस टाइप की गड़बड़ी थी.