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

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

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

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

• BatchJobService.ListMutateJobResults
• ConversionUploadService.UploadCallConversions
• ConversionUploadService.UploadClickConversions
• OfflineUserDataJobService.AddOfflineUserDataJobOperations
• OfflineUserDataJobService.CreateOfflineUserDataJob
• UserDataService.UploadUserData

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

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

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

कीवर्ड प्लान करने की सेवा

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

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

  • KeywordPlanIdeaService.GenerateKeywordIdeas
  • KeywordPlanIdeaService.GenerateKeywordHistoricalMetrics
  • KeywordPlanIdeaService.GenerateKeywordForecastMetrics

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

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

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

  • KeywordPlanIdeaService.GenerateAdGroupTheme

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

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

ऑडियंस के बारे में अहम जानकारी देने वाली सेवा

AudienceInsightsService तरीकों के अंदर मौजूद इन तरीकों पर, कोटा की कुछ सीमाएं लागू होती हैं.

• हर सीआईडी के लिए, हर दिन करीब 200 अनुरोध किए जा सकते हैं:

  • AudienceInsightsService.generateAudienceCompositionInsights
  • AudienceInsightsService.generateSuggestedTargetingInsights

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

  • AudienceInsightsService.generateTargetingSuggestionMetrics

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

• हर अनुरोध में, कॉल या क्लिक कन्वर्ज़न की संख्या 2,000 से ज़्यादा नहीं होनी चाहिए:

  • ConversionUploadService.UploadCallConversions
  • ConversionUploadService.UploadClickConversions

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

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

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

  • ConversionAdjustmentUploadService.UploadConversionAdjustments

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

कन्वर्ज़न वैल्यू के नियम

• हर खाते के लिए, कन्वर्ज़न वैल्यू के नियमों की संख्या 1,00,000 से ज़्यादा नहीं होनी चाहिए.

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

ध्यान दें: Google Ads API का इस्तेमाल करके बनाए गए कन्वर्ज़न वैल्यू के नियम सिर्फ़ तब लागू होते हैं, जब वे कन्वर्ज़न वैल्यू के नियम सेट का हिस्सा हों. साथ ही, उस सेट में conversion_value_rules फ़ील्ड में ConversionValueRule संसाधन के नाम शामिल हों और ConversionValueRuleSet स्टेटस को ENABLED पर सेट किया गया हो. कन्वर्ज़न वैल्यू के वे नियम जो कन्वर्ज़न वैल्यू के किसी नियम सेट का हिस्सा नहीं हैं वे Google Ads के यूज़र इंटरफ़ेस (यूआई) में नहीं दिखते. इन्हें सिर्फ़ एपीआई का इस्तेमाल करके मैनेज किया जा सकता है.

अगर खाते के लिए, ConversionValueRuleSet में attachment_type की CUSTOMER पहले से मौजूद है, तो आपको कन्वर्ज़न वैल्यू के नए नियमों को उस सेट में जोड़ना होगा, ताकि वे लागू हो सकें. अगर कन्वर्ज़न वैल्यू के लिए ऐसा कोई नियम सेट मौजूद नहीं है, तो आपको एक नियम सेट बनाना होगा. साथ ही, उसमें कन्वर्ज़न वैल्यू के नियम जोड़ने होंगे. इसके बारे में नियम सेट बनाना लेख में बताया गया है.

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

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

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

आपके पास ज़्यादा से ज़्यादा 1,00,000 उपयोगकर्ता आइडेंटिफ़ायर इस्तेमाल करने का विकल्प होता है. इससे कोई फ़र्क़ नहीं पड़ता कि कितनी कार्रवाइयां की गई हैं.

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

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

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

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