Google Ads API, एपीआई से जुड़ी कार्रवाइयों पर सीमाएं लागू करता है, जैसे कि कार्रवाइयों की संख्या जिसे एक बदलाव के अनुरोध में भेजा जा सकता है. इस टेबल में खास जानकारी दी गई है ऐसी कुछ सीमाएं और कोटा होनी चाहिए जिनके बारे में आपको जानकारी होनी चाहिए.
अनुरोध का टाइप, सीमा, और गड़बड़ी का कोड | ||
---|---|---|
सामान्य ऐक्सेस वाली कार्रवाइयां | हर दिन 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
|
हर दिन एपीआई के लिए कार्रवाइयां करने की सीमाएं
एपीआई के इस्तेमाल की हर दिन की सीमाएं, एपीआई की कुल संख्या के हिसाब से तय होती हैं हर डेवलपर टोकन के हिसाब से की जाने वाली कार्रवाइयां. एपीआई कार्रवाइयों, अनुरोधों को पाने और कार्रवाइयों में बदलाव करने का कुल योग होता है. सीमाएं हर दिन के एपीआई ऑपरेशन के लिए, डेवलपर टोकन के ऐक्सेस लेवल का इस्तेमाल किया जाता है. कॉन्टेंट बनाने ऐक्सेस लेवल और अनुमति वाले इस्तेमाल की गाइड में के पास एपीआई कार्रवाइयों की एक खास सीमा होती है.
इन सीमाओं का उल्लंघन करने वाले अनुरोध, इस गड़बड़ी के साथ अस्वीकार किए जाते हैं:
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
) को उपयोगकर्ता के हर दिन के ऑपरेशन कोटा में नहीं गिना जाता.
हालांकि, पेज पर नंबर डालने के ऐसे अनुरोध जिनमें मौजूद टोकन की समयसीमा खत्म हो चुकी है या जो अमान्य है
एक अपवाद जनरेट करता है और उसे रोज़ के ऑपरेशन कोटा में गिना जाएगा.
खोज नतीजों को पेजों में बांटने के बारे में ज़्यादा जानकारी के लिए, पेज के हिसाब से पेजों को बांटना नतीजे.
अन्य तरह के अनुरोध
ऐसा अनुरोध जो 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
.1 क्यूपीएस का हिसाब, हर 60 सेकंड में 60 अनुरोधों के हिसाब से लगाया जाता है.
हर सीआईडी के लिए, हर सेकंड दो अनुरोध तक सीमित:
कीवर्ड प्लान बनाते समय इन सीमाओं का ध्यान रखें.
कीवर्ड प्लान ऑब्जेक्ट | ज़्यादा से ज़्यादा संख्या |
---|---|
KeywordPlan हर खाता |
10,000 |
KeywordPlanAdGroup हर KeywordPlan |
200 |
KeywordPlanAdGroupKeyword हर KeywordPlan |
10,000 |
KeywordPlanCampaignKeyword (नेगेटिव कीवर्ड) |
1,000 |
KeywordPlanCampaign हर KeywordPlan |
1 |
कन्वर्ज़न अपलोड करने वाली सेवा
हर अनुरोध के लिए, ज़्यादा से ज़्यादा 2,000 कॉल या क्लिक कन्वर्ज़न:
इन सीमाओं का उल्लंघन करने वाले अनुरोध, इस गड़बड़ी के साथ अस्वीकार किए जाते हैं:
TOO_MANY_CONVERSIONS_IN_REQUEST
.
कन्वर्ज़न अडजस्टमेंट अपलोड करने की सेवा
हर अनुरोध के लिए, कन्वर्ज़न में 2,000 बदलाव किए जा सकते हैं:
इन सीमाओं का उल्लंघन करने वाले अनुरोध, इस गड़बड़ी के साथ अस्वीकार किए जाते हैं:
TOO_MANY_ADJUSTMENTS_IN_REQUEST
.
बिलिंग और खाते की बजट सेवाएं
बदलाव सिर्फ़ उन खातों के लिए किए जा सकते हैं जिन्हें महीने के इनवॉइस के लिए कॉन्फ़िगर किया गया है.
इस सीमा का उल्लंघन करने वाले अनुरोध, इस गड़बड़ी के साथ अस्वीकार कर दिए जाते हैं:
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
गड़बड़ी दिखाई जाती है.