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

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

अनुरोध का टाइप, सीमा, और गड़बड़ी का कोड
पेज पर नंबर डाले गए अनुरोध हर पेज में 10,000 लाइनें INVALID_PAGE_SIZE
बुनियादी ऐक्सेस के साथ कार्रवाइयां हर दिन 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 वाले अनुरोध) को उपयोगकर्ता के हर दिन के ऑपरेशन कोटा में नहीं गिना जाता. हालांकि, अगर पेज पर नंबर डालने के अनुरोध में ऐसे पेज टोकन होते हैं जिनकी समयसीमा खत्म हो गई है या जो अमान्य हैं, तो उनके अनुरोध को अपवाद माना जाएगा. साथ ही, इन्हें हर दिन की कार्रवाई के कोटा में गिना जाएगा.

खोज के अनुरोध जैसे पेजों पर नंबर में डाले गए अनुरोधों पर भी Page size cannot exceed 10,000 rows लागू होती है. अगर इस सीमा का उल्लंघन होता है, तो इसे अस्वीकार कर दिया जाता है. साथ ही, इस तरह की गड़बड़ी होती है: INVALID_PAGE_SIZE.

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

दूसरी तरह के अनुरोध

ऐसे अनुरोध जो Get, Mutate, Search या SearchStream अनुरोध नहीं हैं, उन्हें उपयोगकर्ता के हर दिन की कार्रवाइयों के कोटा के तहत एक कार्रवाई के तौर पर गिना जाता है.

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

एपीआई के अपवाद दिखाने वाले अनुरोध

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

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

प्लानिंग से जुड़ी सेवाएं

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

  • हर सीआईडी या डेवलपर टोकन के लिए, हर सेकंड एक अनुरोध तक सीमित किया जा सकता है:

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

  • हर 60 सेकंड में, 60 अनुरोधों के आधार पर एक क्यूपीएस का हिसाब लगाया जाता है.

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

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

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

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

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

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

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

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

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

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

    इस सीमा का उल्लंघन करने वाले अनुरोध, गड़बड़ी के साथ अस्वीकार कर दिए जाते हैं: 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 वाली गड़बड़ी दिखेगी.

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