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

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 के अलावा किसी अन्य तरह के अनुरोध को, उपयोगकर्ता के रोज़ाना के ऑपरेशन कोटे के हिसाब से एक ऑपरेशन माना जाता है.

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

• 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.

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

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

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