মিনহাজ কাজী, ডেভেলপার অ্যাডভোকেট, Google Analytics – ফেব্রুয়ারি ২০২৩
আপনি [Google Analytics Data API] ব্যবহার করে অ্যাপ্লিকেশন ডেভেলপ করলে, API-এর কোটা ও সীমা কীভাবে কাজ করে তা আপনাকে বুঝতে হবে। আপনার অ্যাপ্লিকেশন ভালভাবে ডিজাইন করা হলে, ব্যবহারকারীরা কোটা সীমার মধ্যে থাকার সম্ভাবনা বেশি। কিছু প্রাসঙ্গিক পেশাদার পদ্ধতি API-তে পারফর্ম্যান্ট কোয়েরি তৈরি করতেও সাহায্য করে। এটি আপনার অ্যাপ্লিকেশনে রিপোর্ট ও ড্যাশবোর্ডের গতি বাড়াতে পারে এবং এর ফলে আরও ভাল ব্যবহারকারীর অভিজ্ঞতা পাওয়া যেতে পারে। এই নিবন্ধে কোটা সিস্টেম এবং Google Analytics Data API প্রয়োগ করার জন্য পেশাদার পদ্ধতি সম্পর্কে আলোচনা করা হয়েছে।
Google Analytics Data API-এর কোটা সিস্টেম বোঝা
যেহেতু Google Analytics লক্ষ লক্ষ ডেভেলপার ও ব্যবহারকারী ব্যবহার করেন, তাই API অনুরোধের কোটা সিস্টেমকে তার ম্যানেজ করার ক্ষমতা থেকে বেশি ডেটা প্রসেস করা থেকে রক্ষা করে, একই সাথে সিস্টেম রিসোর্সের সমান ডিস্ট্রিবিউশন নিশ্চিত করে। Google Analytics 4 প্রপার্টির জন্য ডেটা API, API কোটা ম্যানেজ করার জন্য টোকেন বাকেট সিস্টেম ব্যবহার করে। ধারণাটি বোঝার জন্য: মনে করুন, একটি বালতি আছে যাতে সর্বাধিক সংখ্যক টোকেন রাখা যায়। যেকোনও API অনুরোধ প্রথমে বাকেট চেক করবে। আর কোনও টোকেন না থাকলে, অনুরোধটি সম্পূর্ণ হবে না। অন্যথায়, অনুরোধটি এক্সিকিউট করা হবে এবং অনুরোধের জটিলতার উপর নির্ভর করে বাকেট থেকে এক বা একাধিক টোকেন ব্যবহার করা হবে। নির্দিষ্ট সময় অন্তর সর্বাধিক সংখ্যক টোকেন বাকেটে যোগ করা হয়।
আপনি কোন Data API পদ্ধতি ব্যবহার করছেন তার উপর নির্ভর করে, তিনটি আলাদা কোটা বিভাগ আছে:
- রিয়েলটাইম (
runRealtimeReport-এর জন্য) - ফানেল (
runFunnelReport-এর জন্য) - কোর (অন্যান্য সব পদ্ধতির জন্য)
এবং Data API পদ্ধতিগুলি [কোটা টোকেন][Google Analytics Data API কোটা]-এর জন্য একাধিক বাকেট চেক করবে:
- প্রতিটি প্রপার্টির জন্য প্রতিদিন
- প্রতি প্রপার্টি প্রতি ঘণ্টা
- প্রতিটি প্রপার্টিতে প্রতিটি প্রোজেক্টের জন্য প্রতি ঘণ্টা
- প্রতিটি প্রপার্টির জন্য কনকারেন্ট অনুরোধ
- প্রতিটি প্রপার্টিতে প্রতিটি প্রোজেক্টে প্রতি ঘণ্টায় সার্ভার সংক্রান্ত সমস্যা
কোনও প্রপার্টির জন্য Data API অনুরোধ এলে, এই পাঁচটি বাকেট যেকোনও সময় চেক করা হয়। যেকোনও একটি বাকেট খালি থাকলে, অনুরোধটি সঙ্গে সঙ্গে 429 এরর সহ ব্যর্থ হবে। কোনও বাকেট খালি না থাকলে, প্রতিটি প্রপার্টির জন্য কনকারেন্ট অনুরোধ বাকেট থেকে একটি টোকেন ব্যবহার করা হবে এবং তারপরে API অনুরোধটি এক্সিকিউট করা হবে। অনুরোধের জটিলতার উপর ভিত্তি করে, এক্সিকিউশন সম্পূর্ণ হলে প্রথম তিনটি বাকেট থেকে নির্দিষ্ট সংখ্যক টোকেন খরচ হবে। এছাড়াও, প্রতিটি প্রপার্টির জন্য কনকারেন্ট অনুরোধের টোকেনও এই সময় রিফিল করা হবে।
প্রতি প্রজেক্ট, প্রতি প্রপার্টি, প্রতি ঘণ্টার কোটা নিশ্চিত করে যে এক বা একাধিক ব্যবহারকারীর কোটা শেষ হয়ে গেলেও আপনার অ্যাপ্লিকেশনের অন্যান্য ব্যবহারকারীদের উপর কোনও প্রভাব পড়বে না। এখানে, প্রোজেক্ট বলতে আপনার অ্যাপ্লিকেশনের GCP প্রোজেক্ট-কে বোঝানো হয়েছে। প্রতি প্রপার্টি প্রতি ঘণ্টার কোটা সাধারণত প্রতি প্রোজেক্ট প্রতি প্রপার্টি প্রতি ঘণ্টার কোটার চারগুণ হয়। তাই, সাধারণ ব্যবহারকারীদের জন্য, প্রতি প্রপার্টি প্রতি ঘণ্টা কোটা শেষ হওয়ার আগে অন্তত চারটি আলাদা আলাদা প্রোজেক্টের মাধ্যমে কোনও প্রপার্টি অ্যাক্সেস করতে হবে। প্রোজেক্ট ও প্রপার্টি, উভয় লেভেলে কোটা প্রয়োগ করা হলে তা নিশ্চিত করে যে কোটা সংক্রান্ত সমস্যা একটি প্রপার্টিতেই সীমাবদ্ধ থাকে এবং আপনার অ্যাপ্লিকেশন অ্যাক্সেস করছে এমন অন্যান্য প্রপার্টিকে প্রভাবিত করে না।
সার্ভার সংক্রান্ত সমস্যার কোটা বলতে 500 বা 503 কোড সহ API উত্তরকে বোঝায়। আপনার অ্যাপ্লিকেশন কোনও প্রপার্টি অ্যাক্সেস করার সময় অত্যধিক বেশি সমস্যা তৈরি করলে, এটি প্রতি প্রোজেক্টে, প্রতি প্রপার্টিতে, প্রতি ঘণ্টায় সার্ভার সংক্রান্ত সমস্যার কোটা শেষ করে ফেলবে।
উল্লিখিত সময় অন্তর কোটা টোকেনগুলি সর্বাধিক সীমা পর্যন্ত আবার পূরণ করা হয়। আপডেট করা কোটা সংক্রান্ত তথ্যের জন্য [Google Analytics Data API কোটা] দেখুন। যেমন, কোর পদ্ধতি প্রতি প্রজেক্ট প্রতি প্রপার্টি প্রতি ঘণ্টা বাকেটে ১,২৫০টি কোটা টোকেন পায়। ধরে নেওয়া যাক, আপনার অ্যাপ্লিকেশন থেকে করা একটি অনুরোধে গড়ে ১০টি কোটা টোকেন খরচ হয়। সেক্ষেত্রে, আপনার অ্যাপ্লিকেশন একটি স্ট্যান্ডার্ড প্রপার্টির জন্য প্রতি ঘণ্টায় ১২৫টি Core অনুরোধ এবং যেকোনও Analytics 360 প্রপার্টির জন্য এর ১০ গুণ (১২৫০টি Core অনুরোধ) করতে পারবে। Analytics 360 প্রপার্টির অন্যতম প্রধান সুবিধা হল কোটা টোকেনের উচ্চতর সীমা।
প্রথম তিনটি বাকেটের জন্য টোকেন খরচ যেহেতু অনুরোধের জটিলতার উপর নির্ভর করে, তাই অনুরোধ এক্সিকিউট করার আগে টোকেন ব্যবহারের সঠিক সংখ্যা অনুমান করা কঠিন। নিম্নলিখিত বিষয়গুলি সাধারণত কোনও অনুরোধের জটিলতা বাড়িয়ে দেয়, যার ফলে টোকেন ব্যবহার করতে হয়:
- আরও বেশি ডাইমেনশনের অনুরোধ করা
- আরও বেশি সময়সীমা কোয়েরি করা
- উচ্চ কার্ডিনালিটি সহ ডাইমেনশন সহ
- আরও বেশি ইভেন্ট সংখ্যা সহ প্রপার্টি কোয়েরি করা
তাই, দুটি আলাদা প্রপার্টির জন্য একই কোয়েরি করলে, সম্পূর্ণ আলাদা টোকেন ব্যবহার হতে পারে, কারণ ডাইমেনশনের কার্ডিনালিটি আলাদা হতে পারে অথবা ট্রাফিকের ভলিউম আলাদা হতে পারে। তবে, আপনি একই লেভেলের ট্রাফিক ও একই ধরনের কনফিগারেশন সহ প্রপার্টিতে একই ধরনের টোকেন ব্যবহার হবে বলে আশা করতে পারেন। প্ল্যানিং ও অ্যাপ্লিকেশন ডিজাইন ফেজ চলাকালীন, গ্রাহকের টোকেন ব্যবহার সম্পর্কে পূর্বাভাস দেওয়ার জন্য আপনি এই অনুমান ব্যবহার করতে পারেন।
কোটা ব্যবহার মনিটর করা
কোটা ব্যবহার মনিটর করতে এবং সেই তথ্য আপনার গ্রাহককে জানাতে, আপনি API অনুরোধের বডিতে
"returnPropertyQuota": true যোগ করতে পারেন। এটি API উত্তরের সাথে
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-তে আপগ্রেড করলে API-এর মাধ্যমে অ্যাক্সেস করা ডেটার পরিমাণ বাড়তে পারে।
পেশাদার পদ্ধতি
আপনার অ্যাপ্লিকেশনের জন্য কোটা ব্যবহার কমানোর মূলত দুটি উপায় রয়েছে:
- কম API অনুরোধ পাঠানো
- কম জটিল API অনুরোধ পাঠানো
এই দুটি নীতি মাথায় রেখে, এখানে এমন কিছু প্র্যাক্টিস দেওয়া হল যা আপনি প্রয়োগ করতে পারেন:
- ক্যাশিং: ক্যাশিং লেয়ার প্রয়োগ করলে আপনার অ্যাপ্লিকেশনের ব্যবহারযোগ্যতা ও কোটা ম্যানেজমেন্ট, দু'টি ক্ষেত্রেই সুবিধা হবে। Google Analytics নিজেই আপনার API অনুরোধ ক্যাশে করবে, তবে বারবার অনুরোধ করলে কোটা টোকেন খরচ হবে। API থেকে পাওয়া উত্তর ক্যাশে করে, আপনি বারবার করা অনুরোধের সংখ্যা অনেক কমিয়ে দিতে পারবেন। যেমন, সাধারণ প্রপার্টির জন্য ইন্ট্রাডে ডেটার ক্যাশে এক্সপায়ার হওয়ার সময় ৪ ঘণ্টা বা তার বেশি হতে পারে। Google Analytics-এর জন্য ডেটা ফ্রেশনেস দেখুন।
- অনুরোধ মার্জ করা: একাধিক API অনুরোধকে একটি অনুরোধে মার্জ করার চেষ্টা করুন। যেমন, ২ দিনের মধ্যে ৫টি ডেটার অনুরোধ করলে, ১০ দিনের মধ্যে ১টি অনুরোধের তুলনায় ৩ গুণ বেশি কোটা টোকেন ব্যবহার হতে পারে। আপনার যদি একাধিক অনুরোধ থাকে যেগুলি শুধুমাত্র একটি ডাইমেনশন দ্বারা পরিবর্তিত হয়, তাহলে সেগুলিকে একটি অনুরোধে মার্জ করার কথা বিবেচনা করুন।
- অনুরোধ সরল করা: আপনার অ্যাপ্লিকেশন ও ব্যবহারকারীর প্রয়োজনীয়
ন্যূনতম ডেটার জন্য অনুরোধ করুন। অনেক বেশি সারি/কলাম বা
জটিল ফিল্টার করার মাপকাঠি বেশি কোটা টোকেন ব্যবহার করবে। দীর্ঘ তারিখের রেঞ্জ
সাধারণত আরও বেশি দামি হয় (যেমন, তারিখের রেঞ্জ ২৮ দিন থেকে ৩৬৫
দিন করলে কোটা টোকেন ৩ গুণ বেশি খরচ হতে পারে)। এছাড়াও, যখনই সম্ভব, আপনি কম কার্ডিনালিটি সহ
ডাইমেনশন ব্যবহার করার কথা বিবেচনা করতে পারেন (যেমন,
dateHourMinute-এর পরিবর্তেdateHourঅনুরোধ করুন)। limit-এর কার্যকর ব্যবহার: API-এর অনুরোধেlimitপরিবর্তন করে ফিরে আসা সারির সংখ্যা কমানো হলে, কোটা টোকেন ব্যবহারের উপর উল্লেখযোগ্য প্রভাব পড়ে না। যেমন, ১০,০০০ সারি সংক্রান্ত সীমা সহ ৫টি অনুরোধ, ৫০,০০০ সীমা সহ ১টি অনুরোধের তুলনায় পাঁচগুণ বেশি কোটা টোকেন ব্যবহার করতে পারে।- সঠিক পদ্ধতি বিভাগ ব্যবহার করা: উপরে উল্লেখ করা হয়েছে যে, কোটা সীমা
তিনটি পদ্ধতি বিভাগ জুড়ে বিস্তৃত। সঠিক ব্যবহারের ক্ষেত্রে সঠিক পদ্ধতি ব্যবহার করলে, অন্যান্য
বিভাগে কোটা সেভ করা যেতে পারে। যেমন, Core পদ্ধতি থেকে পাওয়া ডেটা ব্যবহার করে আপনার অ্যাপ্লিকেশনে নিজের ফানেল তৈরি করার
পরিবর্তে, ফানেল তৈরি করার জন্য
runFunnelReportপদ্ধতি ব্যবহার করুন। - ডিফল্ট সেটিংস আপডেট করা: আপনার প্ল্যাটফর্মে রিপোর্ট তৈরি বা কাস্টমাইজ করার সময়, ব্যবহারকারীরা আপনার অ্যাপ্লিকেশনের দেখানো ডিফল্ট বিকল্প আপডেট নাও করতে পারেন এবং শুধু রানটাইমে সেগুলি পরিবর্তন করতে পারেন। আপনার অ্যাপ্লিকেশনে যদি ৩৬৫ দিনের ডিফল্ট তারিখের রেঞ্জ থাকে এবং ব্যবহারকারী সাধারণত ২৮ দিনের রিপোর্ট দেখেন, তাহলে নিয়মিতভাবে প্রয়োজনীয় কোটার চেয়ে বেশি কোটা খরচ হয়ে যাবে। ডিফল্ট সেটিংসে রেঞ্জ ও বেছে নেওয়ার বিকল্প সীমিত করার কথা বিবেচনা করুন এবং ব্যবহারকারীদের তাদের ব্যবহারের ক্ষেত্রে অপ্টিমাল সেটিংস বেছে নিতে দিন। অথবা কিছু ক্ষেত্রে, ব্যবহারকারীরা কোন ডিফল্ট পরিবর্তন করতে পারবেন তাও আপনি সীমিত করতে পারবেন।
- অনুরোধের সারি ও লেজি লোডিং: প্রতিটি প্রপার্টির জন্য কনকারেন্ট
অনুরোধ টোকেন সীমা সম্পর্কে সচেতন থাকুন। আপনার অ্যাপ্লিকেশন একই সময়ে
অত্যধিক অনুরোধ পাঠালে চলবে না। আপনার অ্যাপ্লিকেশনে প্রচুর UI এলিমেন্ট
থাকলে এবং এর ফলে প্রচুর API অনুরোধ করা হলে, UI-তে
পেজিনেশন, লেজি লোডিং এবং আবার চেষ্টা করার জন্য এক্সপোনেনশিয়াল
ব্যাকঅফ সহ অনুরোধগুলিকে সারিবদ্ধ করার কথা বিবেচনা করুন। আপনার অ্যাপ্লিকেশনের প্রতি প্রপার্টি কনকারেন্ট অনুরোধ টোকেন ব্যবহার
returnPropertyQuotaপদ্ধতি ব্যবহার করে নিবিড়ভাবে মনিটর করুন।
ব্যবহারকারীর অভিজ্ঞতা ও প্রত্যাশা ম্যানেজ করা
- সম্ভাব্য বেশি টোকেন ব্যবহার করে কোয়েরি চালানোর আগে ব্যবহারকারীকে মতামত দিন। যেমন, একাধিক হাই কার্ডিনালিটি ডাইমেনশন বা দীর্ঘ সময়সীমা সহ কোয়েরি প্রচুর টোকেন ব্যবহার করতে পারে। এই ধরনের কোয়েরির জন্য সতর্কতা ও কনফার্মেশন প্রম্পট প্রদান করলে, ব্যবহারকারীরা রিপোর্টে অপ্রয়োজনীয় পরিবর্তন করা থেকে বিরত থাকতে পারবেন এবং এর ফলে তারা কোয়েরির স্কোপ সীমিত করতে পারবেন।
- কাস্টমাইজ করা রিপোর্টিং সমাধানের জন্য, ব্যবহারকারীদের তাদের রিপোর্টে প্রতিটি এলিমেন্টের কোয়েরি ব্যবহার সম্পর্কে বোঝার একটি উপায় প্রদান করুন। যেমন, আপনি প্রতিটি রিপোর্ট এলিমেন্টের জন্য কোটা টোকেন ব্যবহারের তালিকা সহ একটি ডিবাগ ভিউ প্রদান করতে পারেন।
- কোটা সংক্রান্ত সমস্যার নির্দিষ্ট ধরন সম্পর্কে মতামত দাও এবং ব্যবহারকারীকে কী করতে হবে তা সাজেস্ট করো।
- Google Analytics 360 প্রপার্টিতে সাধারণ প্রপার্টির তুলনায় ৫-১০ গুণ বেশি কোটা সীমা থাকে বলে, Google Analytics 360 প্রপার্টিতে আপনি আরও বেশি নমনীয়তা পান।
Google Analytics 4-এর জন্য ডেটা API-এর ক্ষেত্রে ডিফল্ট সীমার উপরে API কোটা বাড়ানোর সুবিধা উপলভ্য নেই। Google Analytics 360-এ Google Analytics 4 প্রপার্টির জন্য কোটা সংক্রান্ত আরও বেশি সীমা প্রদান করা হয়। পেশাদার পদ্ধতি প্রয়োগ করার পরেও আপনার ব্যবহারকারীরা কোটা সংক্রান্ত সীমায় পৌঁছে গেলে, তাদের প্রপার্টি 360-তে আপগ্রেড করারকথা বিবেচনা করা উচিত। ব্যবহারকারীদের জন্য আরেকটি বিকল্প হল Google Analytics BigQuery এক্সপোর্ট ব্যবহার করা। এর ফলে ব্যবহারকারীরা BigQuery-তে ইভেন্ট লেভেল ডেটা এক্সপোর্ট করতে এবং নিজেদের বিশ্লেষণ চালাতে পারবেন।
Data API কোটা সংক্রান্ত আরও প্রশ্ন থাকলে, GA Discord-এ যান অথবা Stack Overflow-তে প্রশ্ন করুন। Data API সংক্রান্ত নির্দিষ্ট ফিচারের অনুরোধ থাকলে, আপনি সেগুলি আমাদের ইস্যু ট্র্যাকারে পোস্ট করতে পারেন।