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

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

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

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

प्रमाणीकरण से जुड़ी गड़बड़ियां

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