मिन्हाज़ काज़ी, डेवलपर एडवोकेट, 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 इस्तेमाल करने के तरीके कोटा टोकन के लिए कई बकेट की जांच करेंगे:
- हर प्रॉपर्टी के लिए हर दिन
- हर घंटे हर प्रॉपर्टी के लिए
- हर प्रोजेक्ट के लिए, हर घंटे में हर प्रॉपर्टी के लिए
- हर प्रॉपर्टी के लिए एक साथ किए जाने वाले अनुरोध
- हर प्रोजेक्ट के लिए, हर घंटे में सर्वर से जुड़ी गड़बड़ियां
जब भी किसी प्रॉपर्टी के लिए Data API अनुरोध मिलता है, तब इन पांच बकेट की जांच की जाती है. अगर कोई भी बकेट खाली होगी, तो अनुरोध 429 गड़बड़ी के साथ तुरंत रद्द हो जाएगा. अगर कोई भी बकेट खाली नहीं है, तो हर प्रॉपर्टी के लिए एक साथ किए जाने वाले अनुरोधों बकेट से एक टोकन का इस्तेमाल किया जाएगा. इसके बाद, एपीआई अनुरोध पूरा हो जाएगा. अनुरोध कितनी जटिल है, यह तय करने के लिए प्रोसेस पूरी होने के बाद पहली तीन बकेट में से हर एक से एक तय संख्या में टोकन का इस्तेमाल किया जाएगा. हर प्रॉपर्टी के लिए एक ही समय पर किए जाने वाले अनुरोधों को भी, इस समय टोकन के तौर पर जोड़ा जाएगा.
हर प्रोजेक्ट के लिए हर घंटे के हिसाब से तय किए गए कोटा से यह पक्का होता है कि एक या उससे ज़्यादा उपयोगकर्ताओं के लिए, कोटा कम होने से आपके ऐप्लिकेशन के दूसरे उपयोगकर्ताओं पर कोई असर न पड़े. यहां, प्रोजेक्ट आपके ऐप्लिकेशन के GCP प्रोजेक्ट का संदर्भ देता है. आम तौर पर, हर प्रॉपर्टी के लिए हर घंटे का कोटा चार गुना होता है, जो कि हर प्रॉपर्टी के लिए, हर घंटे के कोटा से चार गुना होता है. इसलिए, असली उपयोगकर्ताओं के लिए किसी प्रॉपर्टी को हर घंटे हर प्रॉपर्टी के हिसाब से कोटा खत्म होने से पहले, कम से कम चार अलग-अलग प्रोजेक्ट से ऐक्सेस किया जाना चाहिए. प्रोजेक्ट और प्रॉपर्टी, दोनों लेवल पर कोटा लागू करने से यह पक्का होता है कि कोटा की समस्याएं एक ही प्रॉपर्टी तक सीमित हैं. साथ ही, इन समस्याओं का असर उन दूसरी प्रॉपर्टी पर नहीं पड़ेगा जिन्हें आपका ऐप्लिकेशन ऐक्सेस कर रहा है.
सर्वर की गड़बड़ियां का कोटा, एपीआई से मिले रिस्पॉन्स के बारे में है. इसमें 500 या 503 कोड शामिल हैं. अगर आपका ऐप्लिकेशन किसी प्रॉपर्टी को ऐक्सेस करते समय बहुत ज़्यादा गड़बड़ियां जनरेट करता है, तो उससे हर प्रोजेक्ट के लिए, हर घंटे में प्रॉपर्टी के हिसाब से सर्वर की गड़बड़ियां खत्म हो जाएंगी.
सभी कोटा टोकन, तय इंटरवल में तय की गई सीमा के हिसाब से फिर से भरे जाते हैं. कोटा की अपडेट की गई जानकारी के लिए, Google Analytics Data API कोटा देखें. उदाहरण के लिए, कोर तरीकों को हर प्रोजेक्ट के लिए, हर घंटे बकेट में 1,250 कोटा टोकन मिलते हैं. यह मान लें कि आपके ऐप्लिकेशन से किए गए एक औसत अनुरोध में 10 कोटा टोकन इस्तेमाल किए जाते हैं. ऐसे में, आपका ऐप्लिकेशन किसी स्टैंडर्ड प्रॉपर्टी के लिए हर घंटे 125 कोर अनुरोध कर पाएगा. साथ ही, किसी भी Analytics 360 प्रॉपर्टी के लिए इस रकम से 10 गुना (1250 कोर अनुरोध) कर पाएगा. कोटा टोकन की ज़्यादा सीमा, Analytics 360 प्रॉपर्टी के मुख्य फ़ायदों में से एक है.
शुरुआती तीन बकेट के लिए टोकन का इस्तेमाल, अनुरोध की जटिलता पर निर्भर करता है. इसलिए, अनुरोध को लागू करने से पहले, टोकन के इस्तेमाल का सटीक अनुमान लगाना मुश्किल होता है. आम तौर पर, इन चीज़ों से किसी अनुरोध की जटिलता बढ़ जाती है, जिसकी वजह से टोकन का इस्तेमाल होता है:
- ज़्यादा डाइमेंशन का अनुरोध करना
- ज़्यादा समयसीमा के लिए क्वेरी की जा रही है
- ज़्यादा एलिमेंट वाले डाइमेंशन शामिल हैं
- ज़्यादा इवेंट संख्या वाली प्रॉपर्टी के बारे में क्वेरी करना
इसलिए, दो अलग-अलग प्रॉपर्टी के लिए एक ही क्वेरी से टोकन का इस्तेमाल पूरी तरह से अलग-अलग हो सकता है. इसकी वजह यह है कि डाइमेंशन के एलिमेंट की संख्या अलग-अलग हो सकती है या ट्रैफ़िक की मात्रा अलग-अलग हो सकती है. हालांकि, एक जैसे ट्रैफ़िक और मिलते-जुलते कॉन्फ़िगरेशन वाली प्रॉपर्टी में, एक जैसे टोकन का इस्तेमाल हो सकता है. इस अनुमान का इस्तेमाल, प्लानिंग और ऐप्लिकेशन डिज़ाइन के चरणों के दौरान ग्राहक के टोकन के इस्तेमाल का अनुमान लगाने के लिए किया जा सकता है.
कोटा के इस्तेमाल की निगरानी करना
कोटा के इस्तेमाल पर नज़र रखने और असली उपयोगकर्ता को यह जानकारी देने के लिए, एपीआई अनुरोध के मुख्य हिस्से में "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 का ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, कोटा मैनेजमेंट के सबसे सही तरीके लागू करें. इन तरीकों के बारे में नीचे बताया गया है. साथ ही, अपनी प्रॉपर्टी को 360 पर अपग्रेड करने से, एपीआई के ज़रिए ऐक्सेस किए जाने वाले डेटा की मात्रा बढ़ सकती है.
सबसे सही तरीके
अपने ऐप्लिकेशन के लिए कोटा के इस्तेमाल को कम करने के दो तरीके हैं:
- कम एपीआई अनुरोध भेजना
- कम जटिल एपीआई अनुरोध भेजना
इन दो सिद्धांतों को ध्यान में रखते हुए, यहां बताए गए तरीकों को लागू किया जा सकता है:
- कैश मेमोरी में सेव करना: कैश मेमोरी में सेव करने की लेयर लागू करने से आपके ऐप्लिकेशन की उपयोगिता और कोटा मैनेजमेंट, दोनों को फ़ायदा होगा. Google Analytics खुद आपके एपीआई अनुरोधों को कैश मेमोरी में सेव करेगा, लेकिन बार-बार किए जाने वाले अनुरोधों पर अब भी कोटा टोकन लागू होगा. एपीआई रिस्पॉन्स को कैश मेमोरी में सेव करके, बार-बार किए जाने वाले अनुरोधों की संख्या को काफ़ी कम किया जा सकता है. उदाहरण के लिए, स्टैंडर्ड प्रॉपर्टी के इंट्रा-डे डेटा में कैश मेमोरी के खत्म होने का समय चार घंटे या इससे ज़्यादा हो सकता है. Google Analytics के लिए डेटा अपडेट होने की फ़्रीक्वेंसी लेख पढ़ें.
- मर्ज करने के अनुरोध: कई एपीआई अनुरोधों को मर्ज करके देखें. उदाहरण के लिए, 10 दिन की अवधि के लिए एक अनुरोध की तुलना में, दो दिन के अंदर डेटा के लिए पांच अनुरोध, कोटा टोकन का तीन गुना हो सकते हैं. अगर आपके पास ऐसे कई अनुरोध हैं जो सिर्फ़ एक डाइमेंशन के हिसाब से अलग-अलग हैं, तो उन्हें एक ही अनुरोध में मर्ज करने पर विचार करें.
- अनुरोधों को आसान बनाना: अपने अनुरोधों को आपके ऐप्लिकेशन और उपयोगकर्ता के लिए ज़रूरी डेटा की कम से कम मात्रा तक सीमित करें. बड़ी संख्या में पंक्तियां/कॉलम या जटिल फ़िल्टर मानदंड
ज़्यादा कोटा टोकन का इस्तेमाल करेंगे. आम तौर पर, तारीख की सीमा
ज़्यादा महंगे होती हैं.जैसे, तारीख की सीमा को 28 दिन से बदलकर 365
दिन करना. ऐसा करने पर, कोटा टोकन का तीन गुना ज़्यादा इस्तेमाल हो सकता है. जब भी मुमकिन हो, कम एलिमेंट वाले डाइमेंशन इस्तेमाल करें. जैसे,
dateHourMinuteके बजायdateHourका अनुरोध करें. 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 Export का इस्तेमाल करें. इससे उपयोगकर्ता, इवेंट लेवल का डेटा BigQuery में एक्सपोर्ट कर सकेंगे और अपना विश्लेषण कर सकेंगे.
Data API कोटा के बारे में कुछ और सवाल पूछने के लिए, GA Discord पर जाएं या Stack Overflow पर पूछें. अगर आपको Data API से जुड़ी किसी सुविधा के अनुरोध करने हैं, तो उन्हें समस्या के ट्रैकर में पोस्ट करें.