Google Analytics Data API के लिए कोटा मैनेज करना

मिनहाज़ काज़ी, डेवलपर एडवोकेट, Google Analytics – फ़रवरी 2023

अगर [Google Analytics Data API] का इस्तेमाल करके ऐप्लिकेशन डेवलप किए जा रहे हैं, तो आपको एपीआई के कोटे और सीमाओं के काम करने के तरीके के बारे में पता होना चाहिए. अगर आपका ऐप्लिकेशन अच्छी तरह से डिज़ाइन किया गया है, तो उपयोगकर्ताओं के कोटे की सीमाएं पार होने की संभावना कम होती है. कुछ काम के सबसे सही तरीकों से, एपीआई के लिए परफ़ॉर्म करने वाली क्वेरी भी मिलती हैं. इससे आपके ऐप्लिकेशन में रिपोर्ट और डैशबोर्ड की स्पीड बढ़ सकती है. साथ ही, उपयोगकर्ता को बेहतर अनुभव मिल सकता है. इस लेख में, Google Analytics Data API को लागू करने के लिए, कोटा सिस्टम और सबसे सही तरीकों के बारे में बताया गया है.

Google Analytics Data API के लिए कोटा सिस्टम को समझना

Google Analytics का इस्तेमाल लाखों डेवलपर और उपयोगकर्ता करते हैं. इसलिए, एपीआई के अनुरोधों पर कोटा लागू करने से, सिस्टम को उसकी क्षमता से ज़्यादा डेटा प्रोसेस करने से बचाया जा सकता है. साथ ही, सिस्टम के संसाधनों का बराबर बंटवारा भी पक्का किया जा सकता है. Google Analytics 4 प्रॉपर्टी के लिए, Data API, एपीआई कोटा को मैनेज करने के लिए, टोकन बकेट सिस्टम का इस्तेमाल करता है. इस कॉन्सेप्ट को समझने के लिए, मान लें कि एक बकेट है, जिसमें ज़्यादा से ज़्यादा टोकन रखे जा सकते हैं. कोई भी एपीआई अनुरोध, सबसे पहले बकेट की जांच करेगा. अगर कोई टोकन नहीं बचा है, तो अनुरोध पूरा नहीं होगा. इसके अलावा, अनुरोध पूरा हो जाएगा. साथ ही, अनुरोध की जटिलता के आधार पर, बकेट से एक या उससे ज़्यादा टोकन खर्च हो जाएंगे. बकेट में टोकन, तय समय के अंतराल पर ज़्यादा से ज़्यादा संख्या में फिर से भर दिए जाते हैं.

इस्तेमाल किए जा रहे Data API के तरीके के आधार पर, कोटा की तीन अलग-अलग कैटगरी होती हैं:

• रीयल टाइम (runRealtimeReport के लिए)
• फ़नल (runFunnelReport के लिए)
• कोर (अन्य सभी तरीकों के लिए)

Data API के तरीके, [कोटा टोकन][Google Analytics Data API के कोटे] के लिए कई बकेट की जांच करेंगे:

1. हर दिन हर प्रॉपर्टी के लिए
2. हर घंटे हर प्रॉपर्टी के लिए
3. हर घंटे हर प्रोजेक्ट के लिए हर प्रॉपर्टी के लिए
4. हर प्रॉपर्टी के लिए एक साथ किए जाने वाले अनुरोध
5. हर घंटे हर प्रोजेक्ट के लिए हर प्रॉपर्टी के लिए, सर्वर से जुड़ी गड़बड़ियां

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

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

चेतावनी: हमारा सुझाव है कि डेवलपर, कई एपीआई प्रोजेक्ट में कोटा टोकन को शेयर न करें. यह Google API की सेवा की शर्तों का उल्लंघन है.

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

सभी कोटा टोकन, तय समय के अंतराल पर, तय सीमा तक फिर से भर दिए जाते हैं. कोटा की अपडेट की गई जानकारी के लिए, [Google Analytics Data API के कोटे] देखें. उदाहरण के लिए, कोर तरीकों को हर घंटे हर प्रोजेक्ट के लिए हर प्रॉपर्टी बकेट में 1,250 कोटा टोकन मिलते हैं. मान लें कि आपके ऐप्लिकेशन से किए गए किसी औसत अनुरोध में 10 कोटा टोकन खर्च होते हैं. ऐसे में, आपका ऐप्लिकेशन, स्टैंडर्ड प्रॉपर्टी के लिए हर घंटे 125 कोर अनुरोध और किसी भी Analytics 360 प्रॉपर्टी के लिए 10 गुना (1,250 कोर अनुरोध) कर पाएगा. कोटा टोकन की ज़्यादा सीमा, Analytics 360 प्रॉपर्टी के मुख्य फ़ायदों में से एक है.

पहले तीन बकेट के लिए टोकन का खर्च, अनुरोध की जटिलता पर निर्भर करता है. इसलिए, अनुरोध पूरा होने से पहले, टोकन के सटीक इस्तेमाल का अनुमान लगाना मुश्किल है. आम तौर पर, इन वजहों से किसी अनुरोध की जटिलता बढ़ जाती है. इसलिए, टोकन का इस्तेमाल बढ़ जाता है:

• ज़्यादा डाइमेंशन का अनुरोध करना
• ज़्यादा समय की सीमा के लिए क्वेरी करना
• ज़्यादा एलिमेंट वाले डाइमेंशन शामिल करना
• ज़्यादा इवेंट की संख्या वाली प्रॉपर्टी के लिए क्वेरी करना

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

ध्यान दें: अगर आपने पहले Universal Analytics के लिए Reporting API का इस्तेमाल किया है, तो आपको पता होगा कि Reporting API, ऐप्लिकेशन/एपीआई प्रोजेक्ट लेवल पर कोटा लागू करता था. लेकिन Data API के लिए, Google Analytics प्रॉपर्टी लेवल के साथ-साथ, एपीआई प्रोजेक्ट लेवल पर भी कोटा लागू किया जाता है.

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

कोटा के इस्तेमाल की निगरानी करने और असली उपयोगकर्ता को यह जानकारी देने के लिए, एपीआई के अनुरोध के मुख्य हिस्से में "returnPropertyQuota": true जोड़ा जा सकता है. इससे, एपीआई के जवाब के साथ PropertyQuota ऑब्जेक्ट मिलेगा. PropertyQuota ऑब्जेक्ट में, सभी पांच बकेट के लिए, खर्च की गई रकम और बचे हुए कोटे की स्थिति शामिल होगी. यहां अनुरोध के मुख्य हिस्से और जवाब का एक उदाहरण दिया गया है:

अनुरोध

{
  "dimensions": [
    {
      "name": "medium"
    }
  ],
  "metrics": [
    {
      "name": "activeUsers"
    }
  ],
  "dateRanges": [
    {
      "startDate": "yesterday",
      "endDate": "yesterday"
    }
  ],
  "returnPropertyQuota": true
}

जवाब

{
  "dimensionHeaders": [
    {
      "name": "medium"
    }
  ],
  "metricHeaders": [
    {
      "name": "activeUsers",
      "type": "TYPE_INTEGER"
    }
  ],
  ...
  
  "propertyQuota": {
    "tokensPerDay": {
      "consumed": 1,
      "remaining": 24997
    },
    "tokensPerHour": {
      "consumed": 1,
      "remaining": 4997
    },
    "concurrentRequests": {
      "consumed": 0,
      "remaining": 10
    },
    "serverErrorsPerProjectPerHour": {
      "consumed": 0,
      "remaining": 10
    },
    "potentiallyThresholdedRequestsPerHour": {
      "consumed": 0,
      "remaining": 120
    },
    "tokensPerProjectPerHour": {
      "consumed": 1,
      "remaining": 1247
    }
  },
  
  "kind": "analyticsData#runReport",
  ...
}

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

ध्यान दें: Data API के मौजूदा चरण में, PropertyQuota ऑब्जेक्ट वापस पाने के लिए, आपको एपीआई का कोई अनुरोध पूरा करना होगा. अगर प्रॉपर्टी के लिए, कोटा टोकन की कोई बकेट पहले ही खत्म हो चुकी है, तो आपका अनुरोध 429 गड़बड़ी के साथ पूरा नहीं होगा. साथ ही, जवाब में PropertyQuota ऑब्जेक्ट शामिल नहीं होगा. अगर आपको इससे कोई समस्या हो रही है और आपको लगता है कि आपके ऐप्लिकेशन को कोटा की जानकारी ऐक्सेस करने का कोई अलग तरीका मिलने से फ़ायदा होगा, तो समस्या ट्रैकर पर इस सुविधा के अनुरोध को +1 करें.

कोटा मैनेजमेंट

हमारा सुझाव है कि Data API का ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, कोटा मैनेजमेंट के सबसे सही तरीकों को लागू करें. इनकी जानकारी यहां दी गई है. इसके अलावा, अपनी प्रॉपर्टी को 360 पर अपग्रेड करने से, एपीआई के ज़रिए ऐक्सेस किए जाने वाले डेटा की मात्रा बढ़ सकती है.

सबसे सही तरीके

आपके ऐप्लिकेशन के लिए, कोटा के इस्तेमाल को कम करने के मुख्य तौर पर दो तरीके हैं:

• एपीआई के कम अनुरोध भेजना
• एपीआई के कम जटिल अनुरोध भेजना

इन दो सिद्धांतों को ध्यान में रखते हुए, यहां कुछ तरीके दिए गए हैं जिन्हें लागू किया जा सकता है:

• कैशिंग: कैशिंग लेयर लागू करने से, आपके ऐप्लिकेशन के लिए इस्तेमाल में आसानी और कोटा मैनेजमेंट, दोनों में फ़ायदा होगा. Google Analytics, आपके एपीआई के अनुरोधों को कैश करेगा. हालांकि, बार-बार किए जाने वाले अनुरोधों के लिए, कोटा टोकन खर्च होंगे. एपीआई के जवाब को कैश करके, बार-बार किए जाने वाले अनुरोधों की संख्या को काफ़ी हद तक कम किया जा सकता है. उदाहरण के लिए, स्टैंडर्ड प्रॉपर्टी के लिए, इंट्रा-डे डेटा के लिए, कैश की समयसीमा खत्म होने में चार घंटे या उससे ज़्यादा समय लग सकता है. Google Analytics में डेटा के अपडेट होने की दर देखें.
• अनुरोधों को मर्ज करना: एपीआई के कई अनुरोधों को एक में मर्ज करने की कोशिश करें. उदाहरण के लिए, दो दिनों की समयावधि में डेटा के लिए किए गए पांच अनुरोधों में, 10 दिनों की समयावधि के लिए किए गए एक अनुरोध की तुलना में, तीन गुना ज़्यादा कोटा टोकन खर्च हो सकते हैं. अगर आपके पास कई ऐसे अनुरोध हैं जिनमें सिर्फ़ एक डाइमेंशन का अंतर है, तो उन्हें एक अनुरोध में मर्ज करने पर विचार करें.
• अनुरोधों को आसान बनाना: अपने अनुरोधों को, आपके ऐप्लिकेशन और उपयोगकर्ता के लिए ज़रूरी डेटा की कम से कम मात्रा तक सीमित रखें. ज़्यादा लाइनों/कॉलम या फ़िल्टर के जटिल मानदंड से, ज़्यादा कोटा टोकन खर्च होंगे. आम तौर पर, तारीख की लंबी सीमाएं ज़्यादा महंगी होती हैं. उदाहरण के लिए, तारीख की सीमा को 28 दिनों से 365 दिनों में बदलने पर, तीन गुना ज़्यादा कोटा टोकन खर्च हो सकते हैं. आपके पास, कम एलिमेंट वाले डाइमेंशन का इस्तेमाल करने का विकल्प भी है. उदाहरण के लिए, dateHour के बजाय dateHourMinuteका अनुरोध करें.
• limit का असरदार तरीके से इस्तेमाल करना: एपीआई के अनुरोध में limit को बदलकर, दिखाई जाने वाली लाइनों की संख्या कम करने से, खर्च होने वाले कोटा टोकन पर ज़्यादा असर नहीं पड़ता. उदाहरण के लिए, 10 हज़ार लाइनों की सीमा वाले पांच अनुरोधों में, 50 हज़ार लाइनों की सीमा वाले एक अनुरोध की तुलना में, पांच गुना ज़्यादा कोटा टोकन खर्च हो सकते हैं.
• सही तरीके की कैटगरी का इस्तेमाल करना: जैसा कि ऊपर बताया गया है, कोटा की सीमाएं, तरीकों की तीन कैटगरी में बंटी होती हैं. इस्तेमाल के सही उदाहरण के लिए, सही तरीके का इस्तेमाल करने से, अन्य कैटगरी के लिए कोटा बचाया जा सकता है. उदाहरण के लिए, कोर तरीकों से मिले डेटा का इस्तेमाल करके, अपने ऐप्लिकेशन में फ़नल बनाने के बजाय, फ़नल बनाने के लिए runFunnelReport तरीके का इस्तेमाल करें.
• डिफ़ॉल्ट सेटिंग अपडेट करना: अपने प्लैटफ़ॉर्म पर रिपोर्ट बनाने या उन्हें पसंद के मुताबिक बनाने के दौरान, हो सकता है कि उपयोगकर्ता आपके ऐप्लिकेशन में दिखने वाले डिफ़ॉल्ट विकल्पों को अपडेट न करें और रनटाइम पर ही उनमें बदलाव करें. अगर आपके ऐप्लिकेशन में तारीख की डिफ़ॉल्ट सीमा 365 दिन है और उपयोगकर्ता आम तौर पर 28 दिनों की रिपोर्ट देखते हैं, तो इससे नियमित तौर पर, ज़रूरत से ज़्यादा कोटा खर्च होगा. डिफ़ॉल्ट सेटिंग में सीमाओं और विकल्पों को सीमित करने पर विचार करें. साथ ही, उपयोगकर्ताओं को अपने इस्तेमाल के उदाहरणों के लिए, सबसे सही सेटिंग चुनने दें. इसके अलावा, कुछ मामलों में, यह भी तय किया जा सकता है कि उपयोगकर्ता किन डिफ़ॉल्ट सेटिंग में बदलाव कर सकते हैं.
• अनुरोधों को लाइन में लगाना और लेज़ी लोडिंग: हर प्रॉपर्टी के लिए एक साथ किए जाने वाले अनुरोध टोकन की सीमा का ध्यान रखें. आपके ऐप्लिकेशन को एक ही समय में बहुत ज़्यादा अनुरोध नहीं भेजने चाहिए. अगर आपके ऐप्लिकेशन में यूज़र इंटरफ़ेस (यूआई) के ज़्यादा एलिमेंट हैं, जिससे एपीआई के बहुत ज़्यादा अनुरोध किए जाते हैं, तो यूआई को पेज में बांटने, लेज़ी लोडिंग, और फिर से कोशिश करने के लिए, एक्सपोनेन्शियल बैकऑफ़ के साथ अनुरोधों को लाइन में लगाने पर विचार करें. अपने ऐप्लिकेशन के हर प्रॉपर्टी के लिए एक साथ किए जाने वाले अनुरोध टोकन के इस्तेमाल की निगरानी करने के लिए, returnPropertyQuota तरीके का इस्तेमाल करें.

उपयोगकर्ता अनुभव और उम्मीदों को मैनेज करना

• उपयोगकर्ताओं को उन क्वेरी के बारे में फ़ीडबैक दें जिनमें टोकन का ज़्यादा इस्तेमाल होने की संभावना हो. उदाहरण के लिए, ज़्यादा एलिमेंट वाले कई डाइमेंशन या लंबी समयावधि वाली क्वेरी में, ज़्यादा टोकन खर्च हो सकते हैं. ऐसी क्वेरी के लिए, चेतावनी और पुष्टि करने वाला प्रॉम्प्ट देने से, उपयोगकर्ता रिपोर्ट में गैर-ज़रूरी बदलाव करने से बच सकते हैं. साथ ही, उन्हें अपनी क्वेरी के दायरे को सीमित करने में मदद मिल सकती है.
• रिपोर्टिंग के पसंद के मुताबिक बनाए गए समाधानों के लिए, उपयोगकर्ताओं को अपनी रिपोर्ट में मौजूद हर एलिमेंट के लिए, क्वेरी के इस्तेमाल को समझने का तरीका बताएं. उदाहरण के लिए, डीबग व्यू दिया जा सकता है, जिसमें रिपोर्ट के हर एलिमेंट के लिए, कोटा टोकन के इस्तेमाल की सूची दी गई हो.
• कोटा से जुड़ी गड़बड़ी के खास टाइप के बारे में फ़ीडबैक दें और उपयोगकर्ता को कार्रवाई करने का सुझाव दें.
• Google Analytics 360 प्रॉपर्टी के लिए, स्टैंडर्ड प्रॉपर्टी की तुलना में, 5 से 10 गुना ज़्यादा कोटा सीमा मिलती है. इसलिए, Google Analytics 360 प्रॉपर्टी के साथ आपको ज़्यादा फ़्लेक्सिबिलिटी मिलती है.

Google Analytics 4 के लिए, Data API के लिए, डिफ़ॉल्ट सीमाओं से ज़्यादा एपीआई कोटा उपलब्ध नहीं हैं. Google Analytics 360, Google Analytics 4 प्रॉपर्टी के लिए, ज़्यादा कोटा सीमाएं उपलब्ध कराता है. अगर सबसे सही तरीकों को लागू करने के बाद भी, आपके उपयोगकर्ताओं के कोटे की सीमाएं पार हो रही हैं, तो उन्हें अपनी प्रॉपर्टी को 360 पर अपग्रेड करने पर विचार करना चाहिए. उपयोगकर्ताओं के पास, Google Analytics BigQuery एक्सपोर्ट का इस्तेमाल करने का विकल्प भी है. इससे उपयोगकर्ता, इवेंट लेवल का डेटा BigQuery पर एक्सपोर्ट कर पाएंगे और अपना विश्लेषण कर पाएंगे.

Data API के कोटे के बारे में ज़्यादा जानने के लिए, GA Discord पर जाएं या Stack Overflow पर सवाल पूछें. अगर आपके पास Data API के बारे में कोई खास सुविधा का अनुरोध है, तो उसे हमारे समस्या ट्रैकर पर पोस्ट किया जा सकता है.