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

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

एपीआई के रोज़ाना के ऑपरेशन की सीमाएं

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर खाते के लिए, 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 गड़बड़ी का मैसेज मिलेगा.

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