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

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

अनुरोध का टाइप, सीमा, और गड़बड़ी का कोड
पेज पर नंबर डाले गए अनुरोध हर पेज के लिए 10,000 लाइनें INVALID_PAGE_SIZE
सामान्य ऐक्सेस वाली कार्रवाइयां हर दिन 15,000 एपीआई से जुड़ी कार्रवाइयां RESOURCE_EXHAUSTED
बदलाव के अनुरोध हर अनुरोध के लिए 10,000 कार्रवाइयां TOO_MANY_MUTATE_OPERATIONS
योजना सेवा के अनुरोध 1 क्यूपीएस RESOURCE_EXHAUSTED
कन्वर्ज़न अपलोड करने की सेवा के अनुरोध हर अनुरोध के लिए 2,000 कन्वर्ज़न TOO_MANY_CONVERSIONS_IN_REQUEST
बिलिंग और खाता बजट सेवा के अनुरोध बदलाव के हर अनुरोध के लिए 1 कार्रवाई TOO_MANY_MUTATE_OPERATIONS

हर दिन एपीआई के लिए कार्रवाइयां करने की सीमाएं

एपीआई के इस्तेमाल की हर दिन की सीमाएं, एपीआई की कुल संख्या के हिसाब से तय होती हैं हर डेवलपर टोकन के हिसाब से की जाने वाली कार्रवाइयां. API कार्रवाइयों, अनुरोधों को पाने और कार्रवाइयों में बदलाव करने का कुल योग होता है. सीमाएं हर दिन के एपीआई ऑपरेशन के लिए, डेवलपर टोकन के ऐक्सेस लेवल का इस्तेमाल किया जाता है. कॉन्टेंट बनाने ऐक्सेस लेवल और अनुमति वाले इस्तेमाल की गाइड में के पास एपीआई कार्रवाइयों की एक खास सीमा होती है.

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

gRPC की सीमाएं

Google Ads API की सभी क्लाइंट लाइब्रेरी, gRPC का इस्तेमाल करें, ताकि अनुरोध और जवाब जनरेट किए जा सकें. डिफ़ॉल्ट रूप से, gRPC में मैसेज का साइज़ 4 एमबी से ज़्यादा नहीं होना चाहिए. हालांकि, हमारी क्लाइंट लाइब्रेरी मैसेज का साइज़ 4 एमबी के लिए ही सेट करती हैं परफ़ॉर्मेंस बढ़ाने के लिए 64 एमबी.

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

इस सीमा का उल्लंघन करने वाले अनुरोध, जनरेट नहीं होंगे GoogleAdsError, लेकिन यह 429 Resource Exhausted gRPC गड़बड़ी. gRPC गड़बड़ी कोड की सूची देखें और मैसेज.

बदलाव के अनुरोध

उपयोगकर्ता के रोज़ के ऑपरेशन कोटा की गिनती करने के अलावा, एक बदलाव अनुरोध में 10,000 से ज़्यादा कार्रवाइयां नहीं हो सकतीं.

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

खास सेवाओं और अनुरोधों के टाइप के लिए अतिरिक्त सीमाएं और ज़रूरी बातें यहां दी गई हैं नीचे बताया गया है.

खोज के अनुरोध

Search या SearchStream अनुरोध को उपयोगकर्ता की कार्रवाई के तौर पर एक कार्रवाई के तौर पर गिना जाता है हर दिन के लिए काम करने का कोटा. SearchStream के एक अनुरोध को, एक एपीआई कार्रवाई के तौर पर गिना जाता है बैच की संख्या पर ध्यान दिए बिना.

पेज पर नंबर डाले गए अनुरोध

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

खोज के अनुरोध जैसे जिन अनुरोधों को कई पेजों में बांटा गया है वे भी Page size cannot exceed 10,000 rows सीमा और अगर यह नीति का उल्लंघन करती है, तो उन्हें अस्वीकार कर दिया जाएगा इस सीमा को इस गड़बड़ी के साथ सबमिट करें: INVALID_PAGE_SIZE.

खोज नतीजों को पेजों में बांटने के बारे में ज़्यादा जानकारी के लिए, पेज के हिसाब से पेजों को बांटना नतीजे.

अन्य तरह के अनुरोध

ऐसा अनुरोध जो Get, Mutate, Search या SearchStream से जुड़ा अनुरोध नहीं है उपयोगकर्ता के हर दिन के ऑपरेशन कोटा के लिए, एक कार्रवाई को माना जाता है.

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

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

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

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

प्लानिंग से जुड़ी सेवाएं

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

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

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

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

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

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

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

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

  • बदलाव करने के अनुरोधों के लिए सिर्फ़ 1 कार्रवाई करने की अनुमति है.

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

इसे लागू करने के लिए, OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS या UserDataError.TOO_MANY_USER_IDENTIFIERS तभी गड़बड़ी मिलती है जब किसी डेटा में 20 से ज़्यादा user_identifiers UserData सेट हो गया है.

दूसरी तरह की सीमाएं

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

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

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

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