Data API की सीमाएं और कोटा

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 की सीमा से कम रहें. स्टैंडर्ड के लिए यह सीमा 10 और Analytics 360 के लिए 50 है.
  • फिर से कोशिश करने की सीमाओं के साथ एक्स्पोनेंशियल बैकऑफ़ लागू करें: अगर कोई अनुरोध 429 RESOURCE_EXHAUSTED, 500 INTERNAL या 503 UNAVAILABLE की वजह से पूरा नहीं हो पाता है, तो गड़बड़ी के जवाब में बताए गए तरीके के मुताबिक, ट्रंकेटेड एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करके फिर से कोशिश करें.

चैट टोकन का इस्तेमाल और निगरानी

Ask Advisor chat के अनुरोधों के लिए, टोकन का इस्तेमाल मॉडल कंप्यूटेशन, रीज़निंग, और डेटा वापस पाने की लागत को दिखाने के लिए किया जाता है. Chat में टोकन के इस्तेमाल पर इनका असर पड़ता है:

  • क्वेरी और विश्लेषण का दायरा: अनुरोध किए गए विश्लेषण की जटिलता और दायरा.
  • मॉडल के इनपुट और आउटपुट टोकन: प्रोसेस किए गए कॉन्टेक्स्ट डेटा और जनरेट किए गए जवाब की संख्या.
  • थिंकिंग टोकन: नतीजों को इकट्ठा करने के लिए, मॉडल के रीज़निंग के चरण ज़रूरी हैं.
  • एग्ज़ीक्यूशन लेटेंसी: कई चरणों वाले डेटा एक्सप्लोरेशन को प्रोसेस करने में लगने वाला समय.

चैट टोकन के इस्तेमाल पर नज़र रखने के लिए, अपनी ChatRequest में "returnPropertyQuota": true सेट करें. जवाब में PropertyChatQuota ऑब्जेक्ट शामिल होगा. इसमें tokensPerDay और tokensPerHour फ़ील्ड होंगे. इनमें इस्तेमाल किए गए और बचे हुए बैलेंस की जानकारी होगी.