एपीआई की सीमाएं और कोटा

Google Ads API, एपीआई से जुड़ी कार्रवाइयों पर सीमाएं लागू करता है, जैसे कि एक बार में किए जाने वाले बदलाव के अनुरोध में भेजी जाने वाली कार्रवाइयों की संख्या. यहां दी गई टेबल में, कुछ अहम सीमाओं और कोटे के बारे में जानकारी दी गई है.

अनुरोध का टाइप, सीमाएं, और गड़बड़ी कोड
बुनियादी ऐक्सेस के साथ काम करना हर दिन 15,000 एपीआई ऑपरेशन RESOURCE_EXHAUSTED
अनुरोधों में बदलाव करना हर अनुरोध के लिए 10,000 कार्रवाइयां TOO_MANY_MUTATE_OPERATIONS
सेवा के अनुरोधों को प्लान करना 1 क्यूपीएस RESOURCE_EXHAUSTED
कन्वर्ज़न अपलोड करने की सेवा के अनुरोध हर अनुरोध के लिए 2,000 कन्वर्ज़न TOO_MANY_CONVERSIONS_IN_REQUEST
बिलिंग और खाते के बजट से जुड़ी सेवा के अनुरोध हर बदलाव के अनुरोध के लिए एक कार्रवाई TOO_MANY_MUTATE_OPERATIONS

एपीआई के हर दिन के इस्तेमाल की सीमाएं

एपीआई के इस्तेमाल की हर दिन की सीमाएं, हर डेवलपर टोकन के लिए किए गए एपीआई ऑपरेशन की संख्या पर आधारित होती हैं. एपीआई ऑपरेशन, अनुरोध पाने और कार्रवाई में बदलाव करने का कुल योग होता है. हर दिन एपीआई के इस्तेमाल की सीमाएं, डेवलपर टोकन के ऐक्सेस लेवल पर निर्भर करती हैं. ऐक्सेस लेवल और इस्तेमाल की अनुमति देने वाली गाइड में, हर ऐक्सेस लेवल के लिए एपीआई के इस्तेमाल की खास सीमाओं के बारे में बताया गया है.

इन सीमाओं का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: RESOURCE_EXHAUSTED.

gRPC की सीमाएं

Google Ads API की सभी क्लाइंट लाइब्रेरी, अनुरोध और जवाब जनरेट करने के लिए gRPC का इस्तेमाल करती हैं. डिफ़ॉल्ट रूप से, gRPC के मैसेज का साइज़ 4 एमबी होता है. हालांकि, हमारी क्लाइंट लाइब्रेरी, मैसेज का ज़्यादा से ज़्यादा साइज़ 64 एमबी पर सेट करती हैं, ताकि परफ़ॉर्मेंस बेहतर हो सके.

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

इस सीमा का उल्लंघन करने वाले अनुरोधों से, GoogleAdsError नहीं जनरेट होगा. हालांकि, इससे 429 Resource Exhausted gRPC गड़बड़ी का मैसेज जनरेट होगा. gRPC गड़बड़ी कोड और मैसेज की सूची देखें.

बदलाव के अनुरोध

उपयोगकर्ता के हर दिन के ऑपरेशन कोटे के अलावा, बदलाव करने के अनुरोध में हर अनुरोध के लिए 10,000 से ज़्यादा ऑपरेशन नहीं होने चाहिए.

इस सीमा का उल्लंघन करने वाले अनुरोधों को गड़बड़ी के इस मैसेज के साथ अस्वीकार कर दिया जाता है: TOO_MANY_MUTATE_OPERATIONS.

यहां कुछ खास सेवाओं और अनुरोध के टाइप के लिए, अतिरिक्त सीमाओं और बातों के बारे में बताया गया है.

अनुरोध खोजना

Search या SearchStream अनुरोध को, उपयोगकर्ता के रोज़ के ऑपरेशन कोटे के हिसाब से एक ऑपरेशन माना जाता है. चाहे बैच की संख्या कुछ भी हो, एक SearchStream अनुरोध को एक एपीआई ऑपरेशन के तौर पर गिना जाता है.

पेज के हिसाब से अनुरोध

पेज पर मौजूद अनुरोधों (उदाहरण के लिए, ऐसे अनुरोध जिनमें मान्य next_page_token शामिल है) को उपयोगकर्ता के हर दिन के ऑपरेशन कोटे में नहीं गिना जाता. हालांकि, पेजेशन के ऐसे अनुरोध जिनमें पेज का एक्सपायर हो चुका या अमान्य टोकन शामिल है, वे अपवाद के तौर पर जनरेट होंगे और उन्हें हर दिन के ऑपरेशन के कोटे में गिना जाएगा.

पेजेशन के बारे में ज़्यादा जानकारी के लिए, नतीजों को पेज करके देखना लेख पढ़ें.

अन्य तरह के अनुरोध

Get, Mutate, Search या SearchStream अनुरोध के अलावा, किसी भी अनुरोध को उपयोगकर्ता के रोज़ के ऑपरेशन कोटे के हिसाब से एक ऑपरेशन माना जाता है.

ऐसे अनुरोधों के कुछ उदाहरण यहां दिए गए हैं:

ऐसे अनुरोध जो एपीआई अपवाद दिखाते हैं

GoogleAdsFailure के साथ अस्वीकार किए गए अनुरोध, अब भी उपयोगकर्ता के रोज़ाना के ऑपरेशन कोटा में गिने जाते हैं.

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

प्लानिंग की सेवाएं

कीमत और जटिलता की वजह से, प्लानिंग सेवा के इन तरीकों पर अलग-अलग सीमाएं लागू होती हैं. ये सीमाएं, दूसरे तरह के अनुरोधों पर निर्भर करती हैं.

कीवर्ड प्लान बनाते समय इन सीमाओं का ध्यान रखें.

कीवर्ड प्लान ऑब्जेक्ट ज़्यादा से ज़्यादा संख्या
KeywordPlan हर खाता 10,000
हर KeywordPlan के लिए KeywordPlanAdGroup 200
हर KeywordPlan के लिए KeywordPlanAdGroupKeyword 10,000
KeywordPlanCampaignKeyword (नेगेटिव कीवर्ड) 1,000
हर KeywordPlan के लिए KeywordPlanCampaign 1

कन्वर्ज़न अपलोड करने की सेवा

कन्वर्ज़न अडजस्टमेंट अपलोड करने की सेवा

  • हर अनुरोध के लिए, 2,000 कन्वर्ज़न में बदलाव किए जा सकते हैं:

    इन सीमाओं का उल्लंघन करने वाले अनुरोधों को इस गड़बड़ी के साथ अस्वीकार कर दिया जाता है: TOO_MANY_ADJUSTMENTS_IN_REQUEST.

बिलिंग और खाते के बजट से जुड़ी सेवाएं

  • बदलाव सिर्फ़ उन खातों में किए जा सकते हैं जिन्हें महीने के इनवॉइस के लिए कॉन्फ़िगर किया गया है.

    इस सीमा का उल्लंघन करने वाले अनुरोधों को गड़बड़ी के इस मैसेज के साथ अस्वीकार कर दिया जाता है: MUTATE_NOT_ALLOWED.

  • डेटा में बदलाव करने के अनुरोधों के लिए, सिर्फ़ एक कार्रवाई की अनुमति है.

    इस सीमा का उल्लंघन करने वाले अनुरोधों को गड़बड़ी के इस मैसेज के साथ अस्वीकार कर दिया जाता है: TOO_MANY_MUTATE_OPERATIONS.

  • एक ही खाते के बजट ऑर्डर में बदलाव करने के बीच, आपको कम से कम 12 घंटे इंतज़ार करना चाहिए. 12 घंटे बीतने से पहले बदलाव करने पर, ऐसा हो सकता है कि आपके खाते में गड़बड़ियां हो जाएं. इन गड़बड़ियों को ठीक करने का विकल्प नहीं होता. इन्हें सिर्फ़ आपके Google Ads खाते के प्रतिनिधि ही ठीक कर सकते हैं.

ग्राहक खातों के लिए न्योते

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

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

  • क्लाइंट खातों में, एक बार में 70 से ज़्यादा न्योते नहीं हो सकते. अगर कोई अनुरोध भेजा जाता है जिसकी वजह से यह वैल्यू तय सीमा से ज़्यादा हो जाती है, तो यह गड़बड़ी दिखती है: ACCESS_INVITATION_ERROR_PENDING_INVITATIONS_LIMIT_EXCEEDED.

उपयोगकर्ता डेटा

उपयोगकर्ता के डेटा को UserDataService और OfflineUserDataJobService की मदद से मैनेज किया जाता है. किसी UserData ऑपरेशन को बनाने या हटाने के लिए, user_identifiers का हर सेट किसी एक उपयोगकर्ता के लिए होना चाहिए.

इसे लागू करने के लिए, UserData सेट में 20 से ज़्यादा user_identifiers होने पर, OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS या UserDataError.TOO_MANY_USER_IDENTIFIERS गड़बड़ी का मैसेज दिखता है.

अन्य तरह की सीमाएं

दोहराया गया फ़ील्ड, जैसे कि कार्रवाइयों की सूची, जिसमें अनुरोध में बहुत ज़्यादा आइटम होते हैं, तो गड़बड़ी हो सकती है: REQUEST_SIZE_LIMIT_EXCEEDED. गड़बड़ी का यह मैसेज, दूसरी समस्याओं की वजह से भी मिल सकता है.

अगर आपको यह सीमा दिखती है और आपने बार-बार इस्तेमाल होने वाले फ़ील्ड का इस्तेमाल करके अनुरोध किया है, तो बदलाव करने के अनुरोध में ऑपरेशन की सूची को डिप्लॉय करके, बार-बार इस्तेमाल होने वाले फ़ील्ड में आइटम की संख्या कम करने की कोशिश करें.

GAQL क्वेरी बनाते समय, IN क्लॉज़ में ज़्यादा से ज़्यादा 20,000 आइटम हो सकते हैं. इस सीमा से ज़्यादा अनुरोध करने पर, FILTER_HAS_TOO_MANY_VALUES वाला गड़बड़ी का मैसेज दिखता है.

पीछे जाएं
खास जानकारी
आगे बढ़ें
सिस्टम की सीमाएं