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

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
बिलिंग और खाता बजट सेवा के अनुरोध बदलाव के हर अनुरोध के लिए 1 कार्रवाई TOO_MANY_MUTATE_OPERATIONS

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

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

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

gRPC की सीमाएं

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

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

इस सीमा का उल्लंघन करने वाले अनुरोध, GoogleAdsError जनरेट नहीं करेंगे, बल्कि 429 Resource Exhausted जीआरपीसी गड़बड़ी जनरेट करेंगे. 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.

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

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

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

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

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

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

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

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

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