Data API-এর ক্ষেত্রে নিম্নলিখিত সীমা ও কোটা প্রযোজ্য।
কোটা কীভাবে প্রযোজ্য হয়
Google Analytics Data API v1-এ সব অনুরোধের জন্য Google Cloud প্রোজেক্ট প্রয়োজন এবং এই পৃষ্ঠায় উল্লেখ করা কোটা অনুযায়ী তা করা হয়। কলিং প্রোজেক্ট শনাক্ত করার জন্য ব্যবহৃত পদ্ধতি নির্বিশেষে কোটা ব্যবহার করা হয়, যার মধ্যে রয়েছে:
- OAuth 2.0 ক্রেডেনশিয়ালের মাধ্যমে যাচাই করা অনুরোধ।
- শুধুমাত্র API কী ব্যবহার করে যাচাই করা অনুরোধ।
কোটা ও বিলিংয়ের উদ্দেশ্যে নির্দিষ্ট Google Cloud প্রোজেক্টের সাথে অনুরোধ যুক্ত করতে API কী ব্যবহার করা হয়। আপনার প্রোজেক্ট থেকে ক্রেডেনশিয়াল বা API কী ব্যবহার করে করা সমস্ত API কল আপনার প্রোজেক্ট এবং Google Analytics প্রপার্টির প্রযোজ্য কোটার বিপরীতে গণনা করা হবে।
কোটার বিভাগ
Data API-তে চারটি অনুরোধ কোটা বিভাগ আছে: Core, Realtime, Funnel এবং Chat.
Core পদ্ধতিতে API অনুরোধের জন্য Core কোটা চার্জ করা হয়। Realtime পদ্ধতিতে API অনুরোধের জন্য Realtime কোটা চার্জ করা হয়। Funnel পদ্ধতিতে API অনুরোধের জন্য Funnel কোটা চার্জ করা হয়। Chat পদ্ধতিতে API অনুরোধের জন্য Chat কোটা চার্জ করা হয়। প্রতিটি অনুরোধে শুধুমাত্র এক ধরনের কোটা ব্যবহার করা হয়।
| কোটার বিভাগ | API পদ্ধতি |
|---|---|
| Core | runReport, runPivotReport, batchRunReports, batchRunPivotReports, runAccessReport, getMetadata, checkCompatibility, createAudienceExports |
| রিয়েলটাইম | runRealtimeReport |
| ফানেল | runFunnelReport |
| চ্যাট | properties.chat |
Analytics প্রপার্টি কোটা
সব অনুরোধ প্রপার্টি কোটা ব্যবহার করে।
| কোটার নাম | স্ট্যান্ডার্ড প্রপার্টি সীমা | Analytics 360 প্রপার্টি সীমা |
|---|---|---|
| প্রতিদিন প্রপার্টি পিছু কোর টোকেন | ২০০,০০০ | ২,০০০,০০০ |
| প্রতি প্রপার্টিতে প্রতি ঘণ্টায় কোর টোকেন | ৪০,০০০ | ৪০০,০০০ |
| প্রতি প্রপার্টিতে প্রতি প্রোজেক্টে প্রতি ঘণ্টায় কোর টোকেন | ১৪,০০০ | ১৪০,০০০ |
| প্রপার্টি প্রতি কোর কনকারেন্ট অনুরোধ | 10 | 50 |
| প্রতি প্রজেক্টে প্রতি প্রপার্টিতে প্রতি ঘণ্টায় কোর সার্ভার সংক্রান্ত সমস্যা | 10 | 50 |
| প্রতিদিন প্রপার্টি প্রতি রিয়েল-টাইম টোকেন | ২০০,০০০ | ২,০০০,০০০ |
| প্রতি প্রপার্টিতে প্রতি ঘণ্টায় রিয়েল-টাইম টোকেন | ৪০,০০০ | ৪০০,০০০ |
| প্রতি প্রপার্টিতে প্রতি প্রোজেক্টে প্রতি ঘণ্টায় রিয়েল-টাইম টোকেন | ১৪,০০০ | ১৪০,০০০ |
| প্রপার্টি পিছু রিয়েল-টাইম কনকারেন্ট অনুরোধ | 10 | 50 |
| প্রতি প্রজেক্ট, প্রতি প্রপার্টি, প্রতি ঘণ্টায় রিয়েল-টাইম সার্ভার সংক্রান্ত সমস্যা | 10 | 50 |
| প্রতিদিন প্রপার্টি পিছু ফানেল টোকেন | ২০০,০০০ | ২,০০০,০০০ |
| প্রতি প্রপার্টিতে প্রতি ঘণ্টায় ফানেল টোকেন | ৪০,০০০ | ৪০০,০০০ |
| প্রতি প্রপার্টিতে প্রতি প্রোজেক্টে প্রতি ঘণ্টায় ফানেল টোকেন | ১৪,০০০ | ১৪০,০০০ |
| প্রপার্টি প্রতি ফানেল কনকারেন্ট অনুরোধ | 10 | 50 |
| প্রতি প্রোজেক্ট প্রতি প্রপার্টি প্রতি ঘণ্টায় ফানেল সার্ভার সংক্রান্ত সমস্যা | 10 | 50 |
| প্রতিদিন প্রপার্টি পিছু চ্যাট টোকেন | ৩,৭৫০,০০০ | ৩,৭৫০,০০০ |
| প্রতি প্রপার্টিতে প্রতি ঘণ্টায় চ্যাট টোকেন | ৫,০০,০০০ | ৫,০০,০০০ |
- একই সময়ে কতগুলি অনুরোধ এক্সিকিউট করা হচ্ছে তার সংখ্যা দিয়ে কনকারেন্ট অনুরোধ পরিমাপ করা হয়। আপনার অনুরোধের কনকারেন্সি কমাতে, অতিরিক্ত অনুরোধ পাঠানোর আগে আগের অনুরোধ সম্পূর্ণ হওয়ার জন্য অপেক্ষা করুন।
- সার্ভার সংক্রান্ত সমস্যার কোড হল 500 এবং 503। সার্ভার ত্রুটি কোটা শুধুমাত্র তখনই চার্জ করা হয় যখন একটি অনুরোধের ফলে সার্ভার ত্রুটি হয়। কোনও প্রোজেক্ট ও প্রপার্টি পেয়ারের জন্য সার্ভার সমস্যার কোটা শেষ হয়ে গেলে, প্রোজেক্ট থেকে প্রপার্টিতে পাঠানো সব অনুরোধ ব্লক করা হয়। সমস্যার কারণে পাওয়া উত্তরের সম্পূর্ণ তালিকা দেখতে, সমস্যার কারণে পাওয়া উত্তর দেখুন।
- প্রতিটি অনুরোধের জন্য প্রতি প্রপার্টি প্রতি ঘণ্টায় টোকেন এবং প্রতি প্রোজেক্ট প্রতি প্রপার্টি প্রতি ঘণ্টায় টোকেন, উভয় কোটা থেকে টোকেন খরচ হয়। এর অর্থ হল, "প্রতি প্রপার্টি প্রতি ঘণ্টা টোকেন" কোটা "প্রতি প্রজেক্ট প্রতি প্রপার্টি প্রতি ঘণ্টা টোকেন" কোটার আগে শেষ হওয়ার জন্য, ৩টির বেশি প্রজেক্টের মাধ্যমে একটি প্রপার্টি অ্যাক্সেস করতে হবে।
প্রপার্টিতে প্রতি ঘণ্টায় সম্ভাব্য থ্রেশহোল্ড করা ১২০টি অনুরোধের অনুমতি দেওয়া হয়। userAgeBracket, userGender, brandingInterest, audienceId এবং
audienceName ডাইমেনশনগুলি সম্ভাব্য থ্রেশহোল্ড করা হয়েছে। রিপোর্ট দেখছেন এমন কোনও ব্যক্তি যাতে কোনও ব্যবহারকারীর জনসংখ্যাতত্ত্ব বা আগ্রহ অনুমান করতে না পারেন, তার জন্য থ্রেশহোল্ড প্রয়োগ করা হয়।
প্রপার্টি টোকেন কোটা
Google Analytics Data API v1-এ প্রতিটি অনুরোধের সাথে টোকেন ব্যবহার করা হয়।
অনুরোধের জটিলতার উপর নির্ভর করে টোকেনের সংখ্যা চার্জ করা হয়। বেশিরভাগ
অনুরোধের জন্য ১০ বা তার কম টোকেন চার্জ করা হলেও, আরও জটিল অনুরোধের (যেমন
Ask Advisor chat
কোয়েরি) জন্য আরও বেশি টোকেন খরচ হবে।
টোকেন ব্যবহারের উপর প্রভাব ফেলে এমন বিষয়
কোনও অনুরোধের জন্য সঠিক টোকেন খরচ এক্সিকিউশনের সময় নির্ধারণ করা হয়, যা সুনির্দিষ্টভাবে আগে থেকে গণনা করাকে চ্যালেঞ্জিং করে তোলে। অনুরোধের সাথে সম্পর্কিত বিভিন্ন ফ্যাক্টর এবং Google Analytics প্রপার্টির অন্তর্নিহিত ডেটার উপর ভিত্তি করে খরচ নির্ধারিত হয়। এইসব কারণে খরচ বেশি হতে পারে:
- সারি সংখ্যা: আরও বেশি সংখ্যক সারির জন্য অনুরোধ করা হচ্ছে।
- ডাইমেনশন ও মেট্রিকের সংখ্যা: আরও বেশি সংখ্যক ডাইমেনশন ও মেট্রিক যোগ করা।
- ফিল্টারের জটিলতা: জটিল ফিল্টার এক্সপ্রেশন ব্যবহার করা।
- তারিখের রেঞ্জের দৈর্ঘ্য: দীর্ঘ সময়সীমা জুড়ে কোয়েরি করা।
- ডেটা কার্ডিনালিটি: উচ্চ কার্ডিনালিটি (অনেক অনন্য মান,
যেমন
pagePath, কাস্টম ডাইমেনশন) সহ ডাইমেনশন টোকেন খরচ উল্লেখযোগ্যভাবে বৃদ্ধি করতে পারে। - প্রপার্টি ইভেন্ট ভলিউম: বেশি সংখ্যক ইভেন্ট সহ প্রপার্টিতে কোয়েরি করলে, কম ডেটা সহ প্রপার্টিতে একই কোয়েরি করার তুলনায় বেশি টোকেন খরচ হতে পারে।
টোকেন ব্যবহার মনিটর করা
আপনার নির্দিষ্ট API কলের জন্য টোকেন খরচ নির্ধারণ করার সবচেয়ে কার্যকর উপায়
হল অনুরোধের প্রধান অংশে
"returnPropertyQuota": true
প্যারামিটার অন্তর্ভুক্ত করা (
runReport,
batchRunReports,
runPivotReport,
batchRunPivotReports,
runRealtimeReport এবং
runFunnelReport-এ কাজ করে)।
API রেসপন্সে তখন
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 প্রপার্টি কোটা-এর
কোটার সাথে সম্পর্কিত। একটি API অনুরোধের
টোকেন চার্জ tokensPerDay, tokensPerHour
এবং tokensPerProjectPerHour থেকে একসাথে কেটে নেওয়া হয়। কোনও কোটা বাকেট 0 বাকি থাকলে,
সেই প্রপার্টিতে পরবর্তী অনুরোধের জন্য 429 RESOURCE_EXHAUSTED সমস্যা দেখায়।
429 RESOURCE_EXHAUSTED সংক্রান্ত সমস্যা এড়ানোর পেশাদার পদ্ধতি
- ডায়নামিক্যালি ব্যালেন্স
remainingমনিটর করুন: রেসপন্সেpropertyQuota.tokensPerProjectPerHour.remainingএবংpropertyQuota.tokensPerHour.remainingচেক করুন এবং বাকি টোকেন নিরাপত্তার থ্রেশহোল্ডের নিচে নেমে গেলে জরুরি নয় এমন ব্যাকগ্রাউন্ড জব থ্রটল বা পজ করুন। - ব্যাচ সম্পর্কিত কোয়েরি: একটি HTTP কলে সর্বাধিক ৫টি রিপোর্ট গ্রুপ করতে এবং HTTP রাউন্ড-ট্রিপ ওভারহেড কমাতে
batchRunReportsবাbatchRunPivotReportsব্যবহার করুন (মনে রাখবেন যে ব্যাচের প্রতিটি রিপোর্ট এখনও টোকেন এবংconcurrentRequestsকোটার জন্য আলাদাভাবে গণনা করা হয়)। - কোয়েরির জটিলতা ও কার্ডিনালিটি কমানো: শুধুমাত্র আপনার প্রয়োজনীয় ডাইমেনশন ও মেট্রিকের জন্য অনুরোধ সীমিত করুন, যেখানে সম্ভব
dateRangesছোট করুন এবং ঘন ঘন পোলিং কোয়েরিতে একাধিক হাই-কার্ডিনালিটি ডাইমেনশন (যেমনpagePathবাfullPageUrl) একত্রিত করা এড়িয়ে চলুন। - অনুরোধের কনকারেন্সি নিয়ন্ত্রণ করা: অনুরোধ সারিবদ্ধ করুন বা ওয়ার্কার পুলের সাইজ সীমিত করুন যাতে
ইন-ফ্লাইট অনুরোধ
concurrentRequestsসীমার (Standard-এর জন্য ১০, Analytics 360-এর জন্য ৫০) নিচে থাকে। - আবার চেষ্টা করার সীমা সহ এক্সপোনেনশিয়াল ব্যাকঅফ প্রয়োগ করুন: কোনও অনুরোধ
429 RESOURCE_EXHAUSTED,500 INTERNALবা503 UNAVAILABLE-এর কারণে ব্যর্থ হলে, ত্রুটি সংক্রান্ত উত্তরে বর্ণিত ট্রাঙ্কেট করা এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করে আবার চেষ্টা করুন।
Chat টোকেন ব্যবহার ও মনিটর করা
Ask Advisor chat
অনুরোধের ক্ষেত্রে, টোকেন মডেল কম্পিউটেশন, যুক্তি এবং অন্তর্নিহিত ডেটা
পুনরুদ্ধারের খরচকে বোঝায়। চ্যাট টোকেন ব্যবহার নিম্নলিখিত বিষয়ের উপর নির্ভর করে:
- কোয়েরি ও বিশ্লেষণাত্মক স্কোপ: অনুরোধ করা বিশ্লেষণের জটিলতা ও ব্যাপ্তি।
- মডেল ইনপুট ও আউটপুট টোকেন: প্রসেস করা প্রাসঙ্গিক ডেটার ভলিউম এবং তৈরি করা উত্তরের বিবরণ।
- থিঙ্কিং টোকেন: ফলাফল সিন্থেসাইজ করার জন্য প্রয়োজনীয় মডেল রিজনিংয়ের ধাপ।
- এক্সিকিউশন লেটেন্সি: মাল্টি-স্টেপ ডেটা এক্সপ্লোরেশনের জন্য প্রয়োজনীয় প্রসেসিং সময়।
চ্যাট টোকেনের ব্যবহার মনিটর করতে, আপনার
ChatRequest-এ
"returnPropertyQuota": true
সেট করুন। উত্তরে
PropertyChatQuota
অবজেক্ট থাকবে, যাতে
tokensPerDay
এবং
tokensPerHour
ফিল্ডে খরচ করা এবং বাকি থাকা ব্যালেন্সের তথ্য থাকবে।