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

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 की मदद से मैनेज किया जाता है.

create या remove ऑपरेशन में मौजूद हर UserData ऑब्जेक्ट, किसी एक असली उपयोगकर्ता से जुड़ा होता है. एक UserData ऑब्जेक्ट में मौजूद user_identifiers फ़ील्ड में, ज़्यादा से ज़्यादा 20 आइडेंटिफ़ायर शामिल किए जा सकते हैं. किसी एक UserData ऑब्जेक्ट में इस सीमा से ज़्यादा वैल्यू डालने पर, OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS या UserDataError.TOO_MANY_USER_IDENTIFIERS गड़बड़ी होगी.

20 से ज़्यादा आइडेंटिफ़ायर वाले उपयोगकर्ताओं को मैनेज करना

अगर किसी एक एंड-यूज़र के पास 20 से ज़्यादा ऐसे आइडेंटिफ़ायर हैं जिन्हें आपको अपलोड करना है, तो आपको इन आइडेंटिफ़ायर को कई UserData ऑब्जेक्ट में डिस्ट्रिब्यूट करना चाहिए. यह पक्का करने के लिए कि Google इन सभी आइडेंटिफ़ायर को एक ही व्यक्ति से जोड़ सके, उस व्यक्ति के लिए हर UserData ऑब्जेक्ट में कम से कम एक सामान्य user_identifier शामिल होना चाहिए. जैसे, एक ही hashed_email, hashed_phone_number या third_party_user_id. Google, शेयर किए गए इन आइडेंटिफ़ायर का इस्तेमाल करके, अलग-अलग UserData ऑपरेशंस से मिली जानकारी को लिंक और मर्ज करता है. इससे सही एंड-यूज़र प्रोफ़ाइल को जानकारी मिलती है.

अगर आपको हैश किए गए ईमेल या फ़ोन नंबर जैसी व्यक्तिगत पहचान से जुड़ी जानकारी पर भरोसा है, तो पक्का करें कि वे Google Ads API की ज़रूरी शर्तों के मुताबिक नॉर्मलाइज़ और हैश किए गए हों. जैसे, SHA-256, छोटे अक्षर, कोई सफ़ेद जगह नहीं. इससे लिंक करने में होने वाली गड़बड़ियों को रोका जा सकता है.

उदाहरण के लिए, अगर किसी उपयोगकर्ता के पास 30 ईमेल पते हैं, तो दो UserData ऑब्जेक्ट भेजे जा सकते हैं.

• UserData 1: {third_party_user_id: "user123", hashed_email: "email1@...", ... hashed_email: "email19@..."}
• UserData 2: {third_party_user_id: "user123", hashed_email: "email20@...", ... hashed_email: "email30@..."}

एक OfflineUserDataJob में सभी कार्रवाइयों के लिए, user_identifiers की कुल सीमा 1,00,000 ही रहेगी.

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

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

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

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