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

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

अनुरोध का टाइप, सीमा, और गड़बड़ी का कोड
एक्सप्लोरर ऐक्सेस लेवल वाली कार्रवाइयां	प्रोडक्शन खातों के लिए, हर दिन 2,880 एपीआई कार्रवाइयां टेस्ट खातों के लिए, हर दिन 15,000 एपीआई कार्रवाइयां	RESOURCE_EXHAUSTED
बेसिक ऐक्सेस लेवल वाली कार्रवाइयां	टेस्ट और प्रोडक्शन, दोनों तरह के खातों के लिए, हर दिन 15,000 एपीआई कार्रवाइयां	RESOURCE_EXHAUSTED
बदलाव करने के अनुरोध	हर अनुरोध में, बदलाव करने की 10,000 कार्रवाइयां हर अनुरोध में, कार्रवाई से जुड़ी 100 कार्रवाइयां	TOO_MANY_MUTATE_OPERATIONS TOO_MANY_ACTION_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
KeywordPlanAdGroup हर KeywordPlan के लिए	200
KeywordPlanAdGroupKeyword हर KeywordPlan के लिए	10,000
KeywordPlanCampaignKeyword (नेगेटिव कीवर्ड)	1,000
KeywordPlanCampaign हर KeywordPlan के लिए	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 ऑब्जेक्ट, किसी create या remove कार्रवाई में मौजूद किसी एक असली उपयोगकर्ता से जुड़ा होता है. किसी एक 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 आइटम शामिल किए जा सकते हैं. अगर यह सीमा पार हो जाती है, तो a FILTER_HAS_TOO_MANY_VALUES गड़बड़ी दिखती है.