गड़बड़ी के प्रकार

हमने गड़बड़ियों को इन खास कैटगरी में रखा है:

• पुष्टि करना
• फिर से कोशिश की जा सकती है
• पुष्टि
• सिंक से जुड़े

हालांकि, इन कैटगरी में सभी संभावित गड़बड़ियां शामिल नहीं होती हैं. इनमें से कुछ कैटगरी को एक से ज़्यादा कैटगरी में रखा जा सकता है. इसके बावजूद, ये आपके ऐप्लिकेशन में गड़बड़ियों को ठीक करने की शुरुआत करने का ज़रिया बन सकते हैं. किसी खास गड़बड़ी के बारे में ज़्यादा जानने के लिए, सामान्य गड़बड़ियां देखें.

पुष्टि करने से जुड़ी गड़बड़ियां

पुष्टि करने से यह पता चलता है कि किसी उपयोगकर्ता ने आपके ऐप्लिकेशन को अपनी ओर से Google Ads ऐक्सेस करने की अनुमति दी है या नहीं. पुष्टि करने की प्रोसेस को, OAuth2 फ़्लो से जनरेट किए गए क्रेडेंशियल की मदद से मैनेज किया जाता है.

पुष्टि करने में होने वाली गड़बड़ी की सबसे आम वजह यह है कि पुष्टि हो चुके उपयोगकर्ता ने आपके ऐप्लिकेशन को अपनी ओर से कार्रवाई करने की अनुमति वापस ले ली है. उदाहरण के लिए, अगर आपका ऐप्लिकेशन इंडिपेंडेंट क्लाइंट के लिए अलग-अलग Google Ads खाते मैनेज करता है और उस क्लाइंट के खाते को मैनेज करते समय हर क्लाइंट के तौर पर अलग-अलग पुष्टि करता है, तो क्लाइंट किसी भी समय आपके ऐप्लिकेशन का ऐक्सेस रद्द कर सकता है. आपका ऐक्सेस कब रद्द किया गया था, इसके आधार पर एपीआई सीधे तौर पर AuthenticationError.OAUTH_TOKEN_REVOKED गड़बड़ी दिखा सकता है या क्लाइंट लाइब्रेरी में पहले से मौजूद क्रेडेंशियल ऑब्जेक्ट, टोकन निरस्त किए जाने का अपवाद दिखा सकते हैं. दोनों ही मामलों में, अगर आपके ऐप्लिकेशन में आपके क्लाइंट के लिए यूज़र इंटरफ़ेस (यूआई) मौजूद है, तो ऐप्लिकेशन से OAuth2 फ़्लो को फिर से लॉन्च करने के लिए कहा जा सकता है. इससे, आपके ऐप्लिकेशन को उसकी ओर से कार्रवाई करने की अनुमति वापस मिल जाएगी.

फिर से कोशिश की जा सकने वाली गड़बड़ियां

TRANSIENT_ERROR या INTERNAL_ERROR जैसी कुछ गड़बड़ियों से पता चलता है कि कुछ समय के लिए होने वाली समस्या ठीक हो सकती है. इसके लिए, थोड़ी देर रुकने के बाद फिर से अनुरोध करें.

उपयोगकर्ताओं के किए गए अनुरोधों के लिए, एक रणनीति यह है कि आप अपने यूज़र इंटरफ़ेस (यूआई) में तुरंत गड़बड़ी दिखाएं. साथ ही, उपयोगकर्ता को फिर से कोशिश करने का विकल्प दें. इसके अलावा, ज़्यादा बार कोशिश करने या उपयोगकर्ता के इंतज़ार करने का कुल समय पूरा होने के बाद ही आपके ऐप्लिकेशन को यूज़र इंटरफ़ेस (यूआई) में गड़बड़ी दिख सकती है.

बैक एंड पर किए गए अनुरोधों के लिए, आपके ऐप्लिकेशन को अपने-आप बार-बार कोशिश करने की ज़्यादा से ज़्यादा संख्या तक अनुरोध करना चाहिए.

अनुरोधों को फिर से करने की कोशिश करते समय, एक्स्पोनेंशियल बैकऑफ़ नीति का इस्तेमाल करें. उदाहरण के लिए, अगर पहली बार कोशिश करने से 5 सेकंड पहले रोका जा सकता है, तो दूसरी बार कोशिश करने के 10 सेकंड बाद और तीसरी कोशिश के बाद 20 सेकंड बाद. एक्स्पोनेंशियल बैकऑफ़ यह पक्का करने में मदद करता है कि आप एपीआई को बहुत ज़्यादा ज़ोर से कॉल नहीं कर रहे हैं.

पुष्टि करने से जुड़ी गड़बड़ियां

पुष्टि करने में हुई गड़बड़ियों से पता चलता है कि किसी कार्रवाई का इनपुट स्वीकार नहीं किया गया. उदाहरण के लिए, PolicyViolationError, DateError, DateRangeError, StringLengthError, और UrlFieldError.

पुष्टि करने से जुड़ी गड़बड़ियां आम तौर पर, उन अनुरोधों में होती हैं जिन्हें उपयोगकर्ता ने शुरू किया होता है. इनमें वे अनुरोध शामिल होते हैं जिनमें उपयोगकर्ता ने अमान्य इनपुट डाला हो. इन मामलों में, आपको एपीआई से जुड़ी जो गड़बड़ी मिलती है उसके हिसाब से आपको उपयोगकर्ता को गड़बड़ी का सही मैसेज देना चाहिए. एपीआई कॉल करने से पहले, सामान्य गलतियों के लिए उपयोगकर्ता के इनपुट की पुष्टि भी की जा सकती है. इससे आपका ऐप्लिकेशन बेहतर तरीके से काम करेगा और एपीआई का बेहतर तरीके से इस्तेमाल किया जा सकेगा. बैक एंड से आने वाले अनुरोधों के लिए आपका ऐप्लिकेशन, फ़ेल हो चुकी कार्रवाई को समीक्षा के लिए समीक्षा के लिए सूची में जोड़ सकता है.

सिंक करने से जुड़ी गड़बड़ियां

कई Google Ads ऐप्लिकेशन अपने Google Ads ऑब्जेक्ट को स्टोर करने के लिए, एक लोकल डेटाबेस रखते हैं. इस तरीके की एक चुनौती यह है कि स्थानीय डेटाबेस, Google Ads में मौजूद असल ऑब्जेक्ट के साथ सिंक से बाहर हो सकता है. उदाहरण के लिए, हो सकता है कि कोई उपयोगकर्ता सीधे Google Ads में किसी विज्ञापन ग्रुप को मिटा दे, लेकिन ऐप्लिकेशन और लोकल डेटाबेस को इस बदलाव की जानकारी न हो. साथ ही, वह एपीआई कॉल जारी करता रहता है, जैसे कि विज्ञापन ग्रुप मौजूद हो. सिंक करने की ये समस्याएं कई तरह की गड़बड़ियों की वजह से दिख सकती हैं. जैसे, DUPLICATE_CAMPAIGN_NAME, DUPLICATE_ADGROUP_NAME, AD_NOT_UNDER_ADGROUP, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD वगैरह.

उपयोगकर्ता के किए गए अनुरोधों के लिए, एक रणनीति यह है कि उपयोगकर्ता को सिंक की संभावित समस्या के बारे में चेतावनी दी जाए. तुरंत एक ऐसा जॉब लॉन्च किया जाए जो Google Ads ऑब्जेक्ट की सही क्लास को फिर से हासिल करे और लोकल डेटाबेस को अपडेट करे. इसके बाद, उपयोगकर्ता को यूज़र इंटरफ़ेस (यूआई) रीफ़्रेश करने के लिए कहें.

बैक-एंड अनुरोधों के लिए, कुछ गड़बड़ियां आपके ऐप्लिकेशन को आपके लोकल डेटाबेस को अपने-आप और बढ़ते हुए सही करने के लिए ज़रूरी जानकारी देती हैं. उदाहरण के लिए, CANNOT_OPERATE_ON_REMOVED_ADGROUPAD को आपके ऐप्लिकेशन को अपने स्थानीय डेटाबेस में, उस विज्ञापन को 'हटाया गया' के तौर पर मार्क करना चाहिए. जिन गड़बड़ियों को आप इस तरीके से ठीक नहीं कर सकते उनकी वजह से आपका ऐप्लिकेशन बेहतर तरीके से सिंक करने का काम लॉन्च कर सकता है या समीक्षा के लिए मैन्युअल ऑपरेटर की सूची में जोड़ दिया जा सकता है.