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

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

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

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

  • आम तौर पर होने वाली गड़बड़ियां सेक्शन में, किसी गड़बड़ी के बारे में ज़्यादा जानकारी मिलती है.
  • google.rpc.Status में, एपीआई के इस्तेमाल किए जाने वाले लॉजिकल गड़बड़ी मॉडल के बारे में जानकारी दी गई है.
  • कैननिकल गड़बड़ी के कोड में, Google Ads API के संदर्भ में gRPC और एचटीटीपी से तय किए गए कैननिकल गड़बड़ी के कोड की सूची और जानकारी दी गई है.

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

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

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

इसी तरह, अगर आपके Google Cloud प्रोजेक्ट के पास सिर्फ़ टेस्ट ऐक्सेस लेवल है और वह किसी प्रोडक्शन (नॉन-टेस्ट) खाते के लिए अनुरोध करने की कोशिश करता है, तो एपीआई एक AuthorizationError दिखाता है. इसकी एनम वैल्यू, एपीआई के वर्शन पर निर्भर करती है:

ऐसी गड़बड़ियां जिन्हें ठीक करने की कोशिश की जा सकती है

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

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

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

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

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

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

आगे बढ़ें
एपीआई से जुड़ी गड़बड़ियों को समझना