Data API पर ये सीमाएं और कोटा लागू होते हैं.
कोटा कैसे लागू होता है
Google Analytics Data API v1 के सभी अनुरोधों के लिए, Google Cloud प्रोजेक्ट की ज़रूरत होती है. साथ ही, इन पर इस पेज पर बताए गए कोटा लागू होते हैं. कोटे का इस्तेमाल, कॉल करने वाले प्रोजेक्ट की पहचान करने के लिए इस्तेमाल किए गए तरीके के हिसाब से होता है. इसमें ये शामिल हैं:
- OAuth 2.0 क्रेडेंशियल से पुष्टि किए गए अनुरोध.
- सिर्फ़ एपीआई पासकोड का इस्तेमाल करके पुष्टि किए गए अनुरोध.
एपीआई पासकोड का इस्तेमाल, किसी अनुरोध को किसी खास Google Cloud प्रोजेक्ट से जोड़ने के लिए किया जाता है. ऐसा कोटा और बिलिंग के लिए किया जाता है. आपके प्रोजेक्ट के क्रेडेंशियल या एपीआई पासकोड का इस्तेमाल करके किए गए सभी एपीआई कॉल, आपके प्रोजेक्ट और Google Analytics प्रॉपर्टी के लागू होने वाले कोटे में गिने जाएंगे.
कोटा की कैटगरी
Data API के अनुरोध के लिए, कोटा की चार कैटगरी हैं: कोर, रीयलटाइम, फ़नल, और चैट.
कोर तरीकों के लिए किए गए एपीआई अनुरोधों पर, कोर कोटा के हिसाब से शुल्क लगता है. रीयलटाइम के तरीकों के लिए किए गए एपीआई अनुरोधों पर, रीयलटाइम के कोटे के हिसाब से शुल्क लगता है. फ़नल के तरीकों के लिए किए गए एपीआई अनुरोधों पर, फ़नल के कोटे के हिसाब से शुल्क लगता है. Chat के तरीकों के लिए किए गए एपीआई अनुरोधों पर, Chat के कोटा के हिसाब से शुल्क लगता है. हर अनुरोध के लिए, सिर्फ़ एक तरह का कोटा इस्तेमाल किया जाता है.
| कोटा कैटगरी | एपीआई के तरीके |
|---|---|
| Core | runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports |
| रीयलटाइम | runRealtimeReport |
| फ़नल | runFunnelReport |
| Chat | properties.chat |
Analytics प्रॉपर्टी के कोटे
सभी अनुरोध, प्रॉपर्टी के कोटे का इस्तेमाल करते हैं.
| कोटे का नाम | स्टैंडर्ड प्रॉपर्टी की सीमा | Analytics 360 प्रॉपर्टी की सीमा |
|---|---|---|
| हर प्रॉपर्टी के लिए हर दिन कोर टोकन | 2,00,000 | 20,00,000 |
| हर घंटे हर प्रॉपर्टी के लिए कोर टोकन | 40,000 | 400,000 |
| हर प्रोजेक्ट, हर प्रॉपर्टी, और हर घंटे के हिसाब से कोर टोकन | 14,000 | 1,40,000 |
| हर प्रॉपर्टी के लिए, एक साथ किए जाने वाले मुख्य अनुरोध | 10 | 50 |
| हर घंटे, हर प्रॉपर्टी के लिए, हर प्रोजेक्ट में सर्वर से जुड़ी मुख्य गड़बड़ियां | 10 | 50 |
| हर प्रॉपर्टी के लिए हर दिन रीयलटाइम टोकन | 2,00,000 | 20,00,000 |
| हर प्रॉपर्टी के लिए हर घंटे रीयलटाइम टोकन | 40,000 | 400,000 |
| हर प्रॉपर्टी के हर प्रोजेक्ट के लिए, हर घंटे के हिसाब से रीयलटाइम टोकन | 14,000 | 1,40,000 |
| हर प्रॉपर्टी के लिए, एक साथ किए जाने वाले अनुरोधों की रीयलटाइम संख्या | 10 | 50 |
| हर प्रोजेक्ट, हर प्रॉपर्टी, और हर घंटे के हिसाब से रीयल टाइम में सर्वर की गड़बड़ियां | 10 | 50 |
| हर प्रॉपर्टी के लिए हर दिन फ़नल टोकन | 2,00,000 | 20,00,000 |
| हर प्रॉपर्टी के लिए, हर घंटे के हिसाब से फ़नल टोकन | 40,000 | 400,000 |
| हर प्रॉपर्टी के हर प्रोजेक्ट के लिए, हर घंटे फ़नल टोकन | 14,000 | 1,40,000 |
| हर प्रॉपर्टी के लिए, एक साथ किए गए फ़नल अनुरोध | 10 | 50 |
| हर प्रोजेक्ट, हर प्रॉपर्टी, और हर घंटे के हिसाब से फ़नल सर्वर की गड़बड़ियां | 10 | 50 |
| हर दिन हर प्रॉपर्टी के लिए चैट टोकन | 37,50,000 | 37,50,000 |
| हर प्रॉपर्टी के लिए, हर घंटे चैट टोकन | 5,00,000 | 5,00,000 |
- एक साथ किए जाने वाले अनुरोधों की संख्या, एक साथ प्रोसेस किए जा रहे अनुरोधों की संख्या से तय होती है. अनुरोधों की संख्या कम करने के लिए, अतिरिक्त अनुरोध भेजने से पहले पिछले अनुरोधों के पूरा होने का इंतज़ार करें.
- सर्वर की गड़बड़ियों के कोड 500 और 503 होते हैं. सर्वर की गड़बड़ियों के लिए कोटा का शुल्क सिर्फ़ तब लिया जाता है, जब किसी अनुरोध के जवाब में सर्वर की गड़बड़ी होती है. जब किसी प्रोजेक्ट और प्रॉपर्टी के लिए, सर्वर की गड़बड़ियों के कोटे खत्म हो जाते हैं, तो उस प्रोजेक्ट से प्रॉपर्टी के लिए किए गए सभी अनुरोध ब्लॉक कर दिए जाते हैं. गड़बड़ी वाले रिस्पॉन्स की पूरी सूची देखने के लिए, गड़बड़ी वाले रिस्पॉन्स देखें.
- हर अनुरोध के लिए, 'हर प्रॉपर्टी के लिए हर घंटे टोकन' और 'हर प्रोजेक्ट के लिए हर प्रॉपर्टी के लिए हर घंटे टोकन', दोनों के लिए कोटा इस्तेमाल किया जाता है. इसका मतलब है कि "हर घंटे, हर प्रॉपर्टी के लिए टोकन" का कोटा खत्म होने से पहले, एक प्रॉपर्टी को तीन से ज़्यादा प्रोजेक्ट से ऐक्सेस किया जाना चाहिए. ऐसा होने पर, "हर घंटे, हर प्रोजेक्ट, हर प्रॉपर्टी के लिए टोकन" का कोटा खत्म हो सकता है.
प्रॉपर्टी के लिए, हर घंटे 120 अनुरोध किए जा सकते हैं. हालांकि, ये अनुरोध तय सीमा को पार कर सकते हैं. ऐसा हो सकता है कि userAgeBracket, userGender, brandingInterest, audienceId, और audienceName डाइमेंशन पर थ्रेशोल्ड लागू किया गया हो. सीमाएं इसलिए तय की जाती हैं, ताकि रिपोर्ट देखने वाला कोई व्यक्ति अलग-अलग उपयोगकर्ताओं की डेमोग्राफ़िक्स या रुचियों का पता न लगा सके.
प्रॉपर्टी के टोकन का कोटा
Google Analytics Data API v1 को भेजे गए हर अनुरोध के लिए, टोकन इस्तेमाल किए जाते हैं.
अनुरोध के हिसाब से टोकन की संख्या तय होती है. ज़्यादातर अनुरोधों के लिए, 10 या इससे कम टोकन का शुल्क लिया जाएगा. हालांकि, ज़्यादा जटिल अनुरोधों (जैसे कि Ask Advisor chat क्वेरी) के लिए ज़्यादा टोकन का इस्तेमाल किया जाएगा.
टोकन के इस्तेमाल पर असर डालने वाले फ़ैक्टर
किसी अनुरोध के लिए टोकन की सटीक लागत का पता, अनुरोध पूरा होने के समय चलता है. इसलिए, पहले से सटीक अनुमान लगाना मुश्किल होता है. लागत, अनुरोध और Google Analytics प्रॉपर्टी में मौजूद डेटा से जुड़े कई फ़ैक्टर पर निर्भर करती है. इन वजहों से, आपको ज़्यादा लागत चुकानी पड़ सकती है:
- पंक्तियों की संख्या: ज़्यादा पंक्तियों का अनुरोध किया जा रहा है.
- डाइमेंशन और मेट्रिक की संख्या: ज़्यादा डाइमेंशन और मेट्रिक शामिल करना.
- फ़िल्टर की जटिलता: जटिल फ़िल्टर एक्सप्रेशन का इस्तेमाल करना.
- तारीख की सीमा: तारीख की लंबी अवधि के लिए क्वेरी करना.
- डेटा एलिमेंट की संख्या: ज़्यादा एलिमेंट वाले डाइमेंशन (कई यूनीक वैल्यू, जैसे कि
pagePath, कस्टम डाइमेंशन) की वजह से, टोकन की लागत काफ़ी बढ़ सकती है. - प्रॉपर्टी के इवेंट का वॉल्यूम: जिन प्रॉपर्टी में इवेंट का वॉल्यूम ज़्यादा होता है उन पर की गई क्वेरी, कम डेटा वाली प्रॉपर्टी पर की गई उसी क्वेरी की तुलना में ज़्यादा टोकन इस्तेमाल कर सकती है.
टोकन के इस्तेमाल पर नज़र रखना
किसी खास एपीआई कॉल के लिए टोकन की लागत का पता लगाने का सबसे असरदार तरीका यह है कि अनुरोध के मुख्य हिस्से में "returnPropertyQuota": true पैरामीटर शामिल करें. यह पैरामीटर runReport, batchRunReports, runPivotReport, batchRunPivotReports, runRealtimeReport, और runFunnelReport में काम करता है. इसके बाद, एपीआई के जवाब में PropertyQuota ऑब्जेक्ट शामिल होगा. इसमें यह जानकारी होगी कि उस अनुरोध के लिए कितने टोकन इस्तेमाल किए गए और कोटा का कितना बैलेंस बचा है.
returnPropertyQuota के साथ अनुरोध का उदाहरण
POST https://analyticsdata.googleapis.com/v1beta/properties/GA_PROPERTY_ID:runReport
{
"dateRanges": [
{ "startDate": "7daysAgo", "endDate": "yesterday" }
],
"dimensions": [
{ "name": "country" }
],
"metrics": [
{ "name": "activeUsers" }
],
"returnPropertyQuota": true
}
propertyQuota रिस्पॉन्स पेलोड का उदाहरण
"returnPropertyQuota": true सेट होने पर, जवाब में एक propertyQuota ऑब्जेक्ट शामिल होता है. इसमें हर फ़ील्ड में consumed और remaining पूर्णांकों के साथ एक QuotaStatus शामिल होता है:
{
"dimensionHeaders": [
{ "name": "country" }
],
"metricHeaders": [
{ "name": "activeUsers", "type": "TYPE_INTEGER" }
],
"rows": [
{
"dimensionValues": [{ "value": "United States" }],
"metricValues": [{ "value": "4820" }]
}
],
"propertyQuota": {
"tokensPerDay": {
"consumed": 1,
"remaining": 199999
},
"tokensPerHour": {
"consumed": 1,
"remaining": 39999
},
"concurrentRequests": {
"consumed": 0,
"remaining": 10
},
"serverErrorsPerProjectPerHour": {
"consumed": 0,
"remaining": 10
},
"potentiallyThresholdedRequestsPerHour": {
"consumed": 0,
"remaining": 120
},
"tokensPerProjectPerHour": {
"consumed": 1,
"remaining": 13999
}
}
}
propertyQuota में मौजूद हर फ़ील्ड, Analytics प्रॉपर्टी के कोटा में मौजूद किसी कोटा से जुड़ा होता है. एक एपीआई अनुरोध के टोकन का शुल्क, tokensPerDay, tokensPerHour, और tokensPerProjectPerHour से एक साथ काटा जाता है. अगर कोई कोटा बकेट 0 पर पहुंच जाती है, तो उस प्रॉपर्टी के लिए किए गए बाद के अनुरोधों में 429 RESOURCE_EXHAUSTED गड़बड़ी का मैसेज दिखता है.
429 RESOURCE_EXHAUSTED गड़बड़ियों से बचने के सबसे सही तरीके
- बैलेंस को डाइनैमिक तरीके से मॉनिटर करें
remaining: जवाबों मेंpropertyQuota.tokensPerProjectPerHour.remainingऔरpropertyQuota.tokensPerHour.remainingकी जांच करें. साथ ही, बचे हुए टोकन की संख्या सुरक्षा थ्रेशोल्ड से कम होने पर, बैकग्राउंड में चल रहे ऐसे कामों को थ्रॉटल करें या रोकें जो ज़रूरी नहीं हैं. - मिलती-जुलती क्वेरी को बैच में भेजना: एक एचटीटीपी कॉल में ज़्यादा से ज़्यादा पांच रिपोर्ट को ग्रुप करने के लिए,
batchRunReportsयाbatchRunPivotReportsका इस्तेमाल करें. इससे एचटीटीपी राउंड-ट्रिप का ओवरहेड कम हो जाता है. ध्यान दें कि बैच में मौजूद हर रिपोर्ट को अब भी टोकन औरconcurrentRequestsकोटे के लिए अलग-अलग गिना जाता है. - क्वेरी की जटिलता और कार्डिनलिटी कम करें: सिर्फ़ उन डाइमेंशन और मेट्रिक के लिए अनुरोध करें जिनकी आपको ज़रूरत है. जहां हो सके वहां
dateRangesको छोटा करें. साथ ही, बार-बार पोलिंग करने वाली क्वेरी में, ज़्यादा कार्डिनलिटी वाले कई डाइमेंशन (जैसे,pagePathयाfullPageUrl) को एक साथ इस्तेमाल करने से बचें. - एक साथ किए जाने वाले अनुरोधों को कंट्रोल करें: अनुरोधों को लाइन में लगाएं या वर्कर पूल के साइज़ को सीमित करें, ताकि प्रोसेस किए जा रहे अनुरोध
concurrentRequestsसीमा से कम रहें. Standard के लिए यह सीमा 10 और Analytics 360 के लिए 50 है. - फिर से कोशिश करने की सीमाओं के साथ एक्स्पोनेंशियल बैकऑफ़ लागू करें: अगर कोई अनुरोध
429 RESOURCE_EXHAUSTED,500 INTERNALया503 UNAVAILABLEके साथ पूरा नहीं होता है, तो गड़बड़ी वाले जवाब में बताए गए तरीके से, ट्रंकेटेड एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करके फिर से कोशिश करें.
चैट टोकन का इस्तेमाल और निगरानी
'सलाह पूछें' सुविधा chat के अनुरोधों के लिए, टोकन का मतलब मॉडल कंप्यूटेशन, तर्क, और डेटा वापस पाने की लागत से है. चैट टोकन के इस्तेमाल पर इन बातों का असर पड़ता है:
- क्वेरी और विश्लेषण का दायरा: अनुरोध किए गए विश्लेषण की जटिलता और दायरा.
- मॉडल के इनपुट और आउटपुट टोकन: प्रोसेस किए गए कॉन्टेक्स्ट के हिसाब से डेटा का वॉल्यूम और जनरेट की गई प्रतिक्रिया का ब्यौरा.
- थिंकिंग टोकन: नतीजों को इकट्ठा करने के लिए, मॉडल के रीज़निंग के चरण ज़रूरी हैं.
- डेटा प्रोसेस होने में लगने वाला समय: कई चरणों वाले डेटा एक्सप्लोरेशन के लिए, डेटा प्रोसेस होने में लगने वाला समय.
चैट टोकन के इस्तेमाल पर नज़र रखने के लिए, अपने ChatRequest में "returnPropertyQuota": true सेट करें. जवाब में PropertyChatQuota ऑब्जेक्ट शामिल होगा. इसमें tokensPerDay और tokensPerHour फ़ील्ड होंगे. इनमें इस्तेमाल किए गए और बचे हुए बैलेंस की जानकारी होगी.