Data API-এর ক্ষেত্রে নিম্নলিখিত সীমা ও কোটা প্রযোজ্য।
কোটা কীভাবে প্রযোজ্য হয়
Google Analytics Data API v1-এর সব অনুরোধের জন্য Google Cloud প্রজেক্ট প্রয়োজন এবং এই পৃষ্ঠায় উল্লেখ করা কোটা মেনে চলতে হবে। কলিং প্রোজেক্ট শনাক্ত করার জন্য ব্যবহৃত পদ্ধতি নির্বিশেষে কোটা ব্যবহার করা হয়, যার মধ্যে রয়েছে:
- OAuth 2.0 ক্রেডেনশিয়ালের মাধ্যমে যাচাই করা অনুরোধ।
- শুধুমাত্র API কী ব্যবহার করে যাচাই করা অনুরোধ।
কোটা ও বিলিংয়ের উদ্দেশ্যে কোনও অনুরোধকে নির্দিষ্ট Google Cloud প্রোজেক্টের সাথে যুক্ত করতে API কী ব্যবহার করা হয়। আপনার প্রোজেক্টের ক্রেডেনশিয়াল বা API কী ব্যবহার করে করা সব API কল আপনার প্রোজেক্ট ও Google Analytics প্রপার্টির প্রযোজ্য কোটার মধ্যে গণনা করা হবে।
কোটার বিভাগ
Data API-এর চারটি অনুরোধ কোটা বিভাগ আছে: কোর, রিয়েল-টাইম, ফানেল এবং চ্যাট।
Core পদ্ধতির জন্য API অনুরোধে Core কোটা চার্জ করা হয়। রিয়েলটাইম পদ্ধতিতে API অনুরোধের জন্য রিয়েলটাইম কোটা চার্জ করা হয়। 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কোড সহ ব্যর্থ হলে, ভুল সংক্রান্ত উত্তর-এ বর্ণিত ট্রানকেট করা এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করে আবার চেষ্টা করুন।
চ্যাট টোকেন ব্যবহার ও মনিটর করা
Ask Advisor chat
অনুরোধের জন্য, টোকেন মডেল কম্পিউটেশন, যুক্তি এবং অন্তর্নিহিত ডেটা
পুনরুদ্ধারের খরচকে উপস্থাপন করে। চ্যাট টোকেন ব্যবহার এগুলির দ্বারা প্রভাবিত হয়:
- কোয়েরি ও বিশ্লেষণাত্মক স্কোপ: অনুরোধ করা বিশ্লেষণের জটিলতা ও ব্যাপ্তি।
- মডেল ইনপুট ও আউটপুট টোকেন: প্রসেস করা প্রাসঙ্গিক ডেটার ভলিউম এবং উত্তরের ন্যারেটিভ জেনারেট করা।
- থিঙ্কিং টোকেন: ফলাফল সিন্থেসাইজ করার জন্য মডেলের রিজনিং ধাপ প্রয়োজন।
- এক্সিকিউশন ল্যাটেন্সি: একাধিক ধাপের ডেটা এক্সপ্লোরেশনের জন্য প্রয়োজনীয় প্রসেসিং সময়।
চ্যাট টোকেনের ব্যবহার মনিটর করতে, আপনার
ChatRequest-এ
"returnPropertyQuota": true
সেট করুন। উত্তরে
PropertyChatQuota
অবজেক্ট থাকবে, যাতে
tokensPerDay
এবং
tokensPerHour
ফিল্ডে খরচ করা এবং বাকি ব্যালেন্সের তথ্য থাকবে।