Google Analytics ডেটা API-এর জন্য কোটা পরিচালনা করা

মিনহাজ কাজী , ডেভেলপার অ্যাডভোকেট, গুগল অ্যানালিটিক্স – ফেব্রুয়ারি ২০২৩

আপনি যদি Google Analytics ডেটা API ব্যবহার করে অ্যাপ্লিকেশান তৈরি করেন, তাহলে API-এর জন্য কোটা এবং সীমাগুলি কীভাবে কাজ করে তা আপনার বোঝা উচিত। যদি আপনার অ্যাপ্লিকেশনটি ভালভাবে ডিজাইন করা হয় তবে ব্যবহারকারীদের কোটা সীমাতে আঘাত করার সম্ভাবনা কম। কিছু প্রাসঙ্গিক সর্বোত্তম অনুশীলনও এপিআই-এ পারফরম্যান্ট কোয়েরির দিকে পরিচালিত করে। এটি আপনার অ্যাপ্লিকেশানে রিপোর্ট এবং ড্যাশবোর্ডের গতি বাড়াতে পারে এবং এর ফলে আরও পছন্দসই ব্যবহারকারীর অভিজ্ঞতা পাওয়া যায়। এই নিবন্ধটি কোটা পদ্ধতি এবং Google Analytics ডেটা API বাস্তবায়নের জন্য সর্বোত্তম অনুশীলন নিয়ে আলোচনা করে।

Google Analytics ডেটা API-এর জন্য কোটা সিস্টেম বোঝা

যেহেতু Google Analytics লক্ষ লক্ষ বিকাশকারী এবং ব্যবহারকারীদের দ্বারা ব্যবহৃত হয়, API অনুরোধের কোটা সিস্টেম সংস্থানগুলির সুষম বন্টন নিশ্চিত করার সময় এটি পরিচালনা করতে পারে তার চেয়ে বেশি ডেটা প্রক্রিয়াকরণ থেকে রক্ষা করে৷ Google Analytics 4 বৈশিষ্ট্যগুলির জন্য ডেটা API API কোটা পরিচালনার জন্য একটি টোকেন বাকেট সিস্টেম ব্যবহার করে। ধারণাটি বোঝার জন্য: কল্পনা করুন যে একটি বালতি রয়েছে যা সর্বাধিক সংখ্যক টোকেন ধরে রাখতে পারে। যেকোনো API অনুরোধ প্রথমে বালতি পরীক্ষা করবে। যদি কোন টোকেন অবশিষ্ট না থাকে, তাহলে অনুরোধ ব্যর্থ হবে। অন্যথায়, অনুরোধটি কার্যকর হবে এবং অনুরোধের জটিলতার উপর নির্ভর করে বালতি থেকে এক বা একাধিক টোকেন গ্রহণ করবে। টোকেনগুলি নির্দিষ্ট সময়ের ব্যবধানে সর্বোচ্চ পর্যন্ত বালতিতে পূরণ করা হয়।

আপনি কোন ডেটা API পদ্ধতি ব্যবহার করছেন তার উপর নির্ভর করে, তিনটি পৃথক কোটা বিভাগ রয়েছে:

  • রিয়েলটাইম ( runRealtimeReport এর জন্য)
  • ফানেল ( runFunnelReport এর জন্য)
  • মূল (অন্যান্য সমস্ত পদ্ধতির জন্য)

এবং ডেটা API পদ্ধতিগুলি কোটা টোকেনের জন্য একাধিক বালতি পরীক্ষা করবে:

  1. প্রতি দিন সম্পত্তি প্রতি
  2. প্রতি ঘন্টায় সম্পত্তি প্রতি
  3. প্রতি ঘন্টায় সম্পত্তি প্রতি প্রকল্প প্রতি
  4. সম্পত্তি প্রতি সমসাময়িক অনুরোধ
  5. প্রতি ঘন্টায় সম্পত্তি প্রতি প্রকল্পের সার্ভার ত্রুটি

এই পাঁচটি বালতি যে কোনো সময় একটি সম্পত্তির জন্য একটি ডেটা API অনুরোধ আসে চেক করা হয়। যদি কোনো বালতি খালি থাকে, তাহলে অনুরোধটি অবিলম্বে 429 ত্রুটির সাথে ব্যর্থ হবে। যদি কোনো বালতি খালি না থাকে, তাহলে প্রতি সম্পত্তি বাকেটের সমবর্তী অনুরোধ থেকে একটি একক টোকেন গ্রহণ করা হবে এবং তারপর API অনুরোধটি কার্যকর করা হবে। অনুরোধের জটিলতার উপর ভিত্তি করে, এক্সিকিউশন শেষ হলে প্রথম তিনটি বালতি থেকে একটি নির্দিষ্ট পরিমাণ টোকেন ব্যবহার করা হবে। সম্পত্তি প্রতি সমসাময়িক অনুরোধ এই সময়ে একটি টোকেন পুনরায় পূরণ করা হবে।

প্রতি প্রোজেক্ট প্রতি সম্পত্তি প্রতি ঘন্টার কোটা নিশ্চিত করে যে এক বা একাধিক ব্যবহারকারীর জন্য কোটা হ্রাস আপনার অ্যাপ্লিকেশনের অন্যান্য ব্যবহারকারীদের প্রভাবিত করবে না। এখানে, প্রজেক্ট বলতে আপনার অ্যাপ্লিকেশনের GCP প্রজেক্টকে বোঝায়। প্রতি ঘন্টার প্রতি সম্পত্তি প্রতি ঘন্টার কোটা সাধারণত প্রতি প্রোজেক্ট প্রতি ঘন্টার কোটার চারগুণ। তাই শেষ ব্যবহারকারীদের জন্য, প্রতি ঘন্টার প্রতি সম্পত্তি কোটা শেষ হওয়ার আগে একটি সম্পত্তি কমপক্ষে চারটি ভিন্ন প্রকল্পের মাধ্যমে অ্যাক্সেস করতে হবে। প্রকল্প এবং সম্পত্তি উভয় স্তরেই কোটা প্রয়োগ নিশ্চিত করে যে কোটার সমস্যাগুলি একটি একক সম্পত্তিতে সীমাবদ্ধ এবং আপনার অ্যাপ্লিকেশন অ্যাক্সেস করা অন্যান্য বৈশিষ্ট্যগুলিকে প্রভাবিত করবে না।

সার্ভার ত্রুটির কোটা 500 বা 503 কোড সহ API প্রতিক্রিয়াগুলিকে বোঝায়৷ যদি আপনার অ্যাপ্লিকেশনটি একটি সম্পত্তি অ্যাক্সেস করার সময় অনেকগুলি ত্রুটি তৈরি করে, তাহলে এটি প্রতি ঘন্টার কোটা প্রতি প্রোজেক্ট প্রতি সার্ভারের ত্রুটিগুলিকে নিঃশেষ করবে৷

সমস্ত কোটা টোকেন উল্লিখিত বিরতিতে সীমাতে পূরণ করা হয়। আপডেট করা কোটা তথ্যের জন্য Google Analytics ডেটা API কোটা পড়ুন। উদাহরণস্বরূপ, মূল পদ্ধতিগুলি প্রতি ঘন্টার বালতি প্রতি সম্পত্তি প্রতি প্রকল্পে 1,250টি কোটা টোকেন পায়। আপনার অ্যাপ্লিকেশন থেকে একটি গড় অনুরোধ 10টি কোটা টোকেন ব্যবহার করে বলে ধরে নিলে, আপনার অ্যাপ্লিকেশন একটি স্ট্যান্ডার্ড প্রপার্টির জন্য প্রতি ঘন্টায় 125টি কোর রিকোয়েস্ট করতে সক্ষম হবে এবং যেকোনো Analytics 360 প্রপার্টির জন্য সেই পরিমাণ 10x (1250টি কোর রিকোয়েস্ট) করতে পারবে। উচ্চতর কোটা টোকেন সীমা হল Analytics 360 প্রপার্টির প্রধান সুবিধাগুলির মধ্যে একটি।

যেহেতু প্রথম তিনটি বালতির জন্য টোকেন খরচ অনুরোধের জটিলতার উপর নির্ভর করে, তাই অনুরোধ সম্পাদনের আগে সঠিক টোকেন ব্যবহারের পূর্বাভাস দেওয়া কঠিন। নিম্নলিখিতগুলি সাধারণত একটি অনুরোধের জটিলতা বাড়ায়, ফলে টোকেন ব্যবহার হয়:

  • আরো মাত্রা অনুরোধ
  • উচ্চতর সময় পরিসীমা জিজ্ঞাসা করা হচ্ছে
  • উচ্চ কার্ডিনালিটি সহ মাত্রা সহ
  • উচ্চ ইভেন্ট সংখ্যা সহ একটি সম্পত্তি জিজ্ঞাসা

অতএব, দুটি ভিন্ন বৈশিষ্ট্যের জন্য একই ক্যোয়ারী সম্পূর্ণ ভিন্ন টোকেন ব্যবহারের ফলে হতে পারে যেহেতু মাত্রার মূলত্ব পরিবর্তিত হতে পারে বা ট্রাফিকের ভলিউম ভিন্ন হতে পারে। যাইহোক, আপনি একই ধরণের ট্র্যাফিক এবং অনুরূপ কনফিগারেশন সহ বৈশিষ্ট্যগুলি একই রকম টোকেন ব্যবহার আশা করতে পারেন। পরিকল্পনা এবং অ্যাপ্লিকেশন ডিজাইনের পর্যায়গুলির সময় গ্রাহক টোকেন ব্যবহারের পূর্বাভাস দিতে আপনি এই ধারণাটি ব্যবহার করতে পারেন।

কোটা ব্যবহার নিরীক্ষণ

কোটার ব্যবহার নিরীক্ষণ করতে এবং আপনার শেষ ব্যবহারকারীর কাছে সেই তথ্য পৌঁছে দিতে, আপনি "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",
  ...
}

এইভাবে, প্রতিটি সফল ডেটা API অনুরোধের পরে, আপনি অনুরোধটি কতটা কোটা ব্যবহার করেছেন এবং সম্পত্তির জন্য কতটা কোটা বাকি আছে তা দেখার আশা করতে পারেন। আপনার অ্যাপ্লিকেশন ইন্টারফেসের মাধ্যমে ব্যবহারকারীর কাছে এই তথ্যটি প্রকাশ করাও সম্ভব।

কোটা ব্যবস্থাপনা

আমরা ডেটা API থেকে সর্বাধিক সুবিধা পেতে নীচে বিস্তারিত কোটা পরিচালনার সর্বোত্তম অনুশীলনগুলি প্রয়োগ করার পরামর্শ দিই৷ এছাড়াও আপনার বৈশিষ্ট্যগুলিকে 360 তে আপগ্রেড করলে API এর মাধ্যমে অ্যাক্সেস করা ডেটার পরিমাণ বাড়তে পারে।

সর্বোত্তম অনুশীলন

আপনার আবেদনের জন্য কোটা ব্যবহার কমানোর বিস্তৃতভাবে দুটি উপায় রয়েছে:

  • কম API অনুরোধ পাঠানো হচ্ছে
  • কম জটিল API অনুরোধ পাঠানো হচ্ছে

এই দুটি নীতি মাথায় রেখে, এখানে আপনি প্রয়োগ করতে পারেন এমন অনুশীলনগুলি রয়েছে:

  • ক্যাশিং: একটি ক্যাশিং স্তর প্রয়োগ করা আপনার আবেদনের জন্য ব্যবহারযোগ্যতা এবং কোটা ব্যবস্থাপনা উভয়কেই উপকৃত করবে। গুগল অ্যানালিটিক্স নিজেই আপনার API অনুরোধগুলি ক্যাশে করবে কিন্তু বারবার অনুরোধগুলি এখনও কোটা টোকেন বহন করবে। API প্রতিক্রিয়া ক্যাশে করে, আপনি পুনরাবৃত্তির অনুরোধের সংখ্যা ব্যাপকভাবে হ্রাস করতে পারেন। উদাহরণস্বরূপ, স্ট্যান্ডার্ড বৈশিষ্ট্যগুলির জন্য ইন্ট্রাডে ডেটাতে 4 ঘন্টা বা উচ্চতর ক্যাশের মেয়াদ শেষ হওয়ার সময় থাকতে পারে। Google Analytics-এর জন্য ডেটা সতেজতা দেখুন।
  • একত্রিত করার অনুরোধ: একাধিক API অনুরোধকে এককভাবে একত্রিত করার চেষ্টা করুন। উদাহরণস্বরূপ, 2 দিনের সময় ফ্রেমের মধ্যে ডেটার জন্য 5টি অনুরোধ 10 দিনের সময় ফ্রেমের জন্য 1টি অনুরোধের তুলনায় 3 গুণ কোটা টোকেন ব্যবহার করতে পারে। আপনার যদি একাধিক অনুরোধ থাকে যা শুধুমাত্র একটি মাত্র মাত্রার দ্বারা পরিবর্তিত হয়, তাহলে সেগুলিকে একটি একক অনুরোধে একত্রিত করার কথা বিবেচনা করুন৷
  • অনুরোধগুলি সরলীকরণ: আপনার আবেদনগুলি এবং ব্যবহারকারীর জন্য প্রয়োজনীয় ন্যূনতম পরিমাণ ডেটার মধ্যে আপনার অনুরোধগুলিকে সীমাবদ্ধ করুন৷ বড় সংখ্যক সারি/কলাম বা জটিল ফিল্টার মানদণ্ড আরও কোটা টোকেন গ্রহণ করবে। দীর্ঘ তারিখের ব্যাপ্তিগুলি সাধারণত বেশি ব্যয়বহুল হয় (যেমন তারিখের পরিসর 28 দিন থেকে 365 দিন পরিবর্তন করা কোটা টোকেনের 3 গুণ ব্যবহার করতে পারে)। আপনি যখনই সম্ভব কম কার্ডিনালিটি সহ মাত্রা ব্যবহার করার কথা বিবেচনা করতে পারেন (যেমন dateHourMinute এর পরিবর্তে dateHour অনুরোধ করুন)।
  • limit কার্যকর ব্যবহার: প্রত্যাবর্তিত সারির সংখ্যা কমাতে API অনুরোধে limit পরিবর্তন করা কোটা টোকেনগুলিকে উল্লেখযোগ্যভাবে প্রভাবিত করে না। উদাহরণস্বরূপ, 10k সারির সীমা সহ 5টি অনুরোধ 50k সীমা সহ 1টি অনুরোধের তুলনায় পাঁচগুণ কোটা টোকেন ব্যবহার করতে পারে।
  • সঠিক পদ্ধতির বিভাগ ব্যবহার করা: উপরে উল্লিখিত হিসাবে, কোটার সীমা তিনটি পদ্ধতি বিভাগে বিস্তৃত। সঠিক ব্যবহারের ক্ষেত্রে সঠিক পদ্ধতি ব্যবহার করলে অন্যান্য বিভাগে কোটা সংরক্ষণ করা যায়। উদাহরণস্বরূপ, মূল পদ্ধতি থেকে ডেটা ব্যবহার করে আপনার অ্যাপ্লিকেশনে আপনার নিজস্ব ফানেল তৈরি করার পরিবর্তে, ফানেল তৈরির জন্য runFunnelReport পদ্ধতি ব্যবহার করুন।
  • ডিফল্ট সেটিংস আপডেট করুন: যখন আপনার প্ল্যাটফর্মে প্রতিবেদনগুলি অনুমোদন বা কাস্টমাইজ করে, ব্যবহারকারীরা আপনার অ্যাপ্লিকেশন দ্বারা উপস্থাপিত ডিফল্ট বিকল্পগুলি আপডেট নাও করতে পারে এবং শুধুমাত্র রানটাইমে সেগুলি পরিবর্তন করতে পারে। যদি আপনার আবেদনের একটি ডিফল্ট তারিখের পরিসীমা 365 দিনের থাকে এবং ব্যবহারকারী সাধারণত 28 দিনের রিপোর্ট দেখেন, তাহলে এটি নিয়মিতভাবে প্রয়োজনের চেয়ে বেশি কোটা গ্রহণ করবে। ডিফল্ট সেটিংসে রেঞ্জ এবং নির্বাচন সীমিত করার কথা বিবেচনা করুন এবং ব্যবহারকারীদের তাদের ব্যবহারের ক্ষেত্রে সর্বোত্তম সেটিংস নির্বাচন করতে দিন। অথবা কিছু ক্ষেত্রে, ব্যবহারকারীরা কোন ডিফল্ট পরিবর্তন করতে পারে তাও আপনি সীমাবদ্ধ করতে পারেন।
  • সারিবদ্ধ অনুরোধ এবং অলস লোডিং: সম্পত্তি টোকেন সীমা প্রতি সমসাময়িক অনুরোধগুলি মনে রাখবেন। আপনার আবেদন একই সময়ে অনেক অনুরোধ পাঠানো উচিত নয়. আপনার অ্যাপ্লিকেশানে যদি প্রচুর সংখ্যক UI উপাদান থাকে যার ফলে উল্লেখযোগ্য সংখ্যক এপিআই অনুরোধ আসে, তাহলে UI-তে পৃষ্ঠা স্থাপন, অলস লোডিং এবং পুনঃপ্রচারের জন্য সূচকীয় ব্যাকঅফ সহ অনুরোধগুলি সারিবদ্ধ করার কথা বিবেচনা করুন। আপনার অ্যাপ্লিকেশানের সমসাময়িক অনুরোধ প্রতি সম্পত্তি টোকেন ব্যবহারে আক্রমণাত্মকভাবে নিরীক্ষণ করতে returnPropertyQuota পদ্ধতি ব্যবহার করুন।

ব্যবহারকারীর অভিজ্ঞতা এবং প্রত্যাশা পরিচালনা করা

  • সম্ভাব্য উচ্চ টোকেন ব্যবহারের সাথে প্রশ্নগুলি চালানোর আগে ব্যবহারকারীদের প্রতিক্রিয়া দিন। উদাহরণস্বরূপ, একাধিক উচ্চ কার্ডিনালিটি মাত্রা বা একটি বড় টাইম ফ্রেমের সাথে প্রশ্নগুলি প্রচুর সংখ্যক টোকেন ব্যবহার করতে পারে। এই ধরনের প্রশ্নের জন্য সতর্কতা এবং একটি নিশ্চিতকরণ প্রম্পট প্রদান করা ব্যবহারকারীদের প্রতিবেদনে অপ্রয়োজনীয় পরিবর্তন করা থেকে বিরত রাখতে পারে এবং তাদের প্রশ্নের সুযোগ সীমিত করতে সহায়তা করে।
  • কাস্টমাইজড রিপোর্টিং সমাধানের জন্য, ব্যবহারকারীদের তাদের রিপোর্টে প্রতিটি উপাদানের ক্যোয়ারী ব্যবহার বোঝার জন্য একটি উপায় প্রদান করুন। উদাহরণস্বরূপ, আপনি প্রতিটি রিপোর্ট উপাদানের জন্য কোটা টোকেন ব্যবহারের তালিকা করে একটি ডিবাগ ভিউ প্রদান করতে পারেন।
  • নির্দিষ্ট ধরনের কোটা ত্রুটির বিষয়ে প্রতিক্রিয়া প্রদান করুন এবং ব্যবহারকারীর পদক্ষেপ নির্ধারণ করুন।
  • যেহেতু Google Analytics 360 প্রপার্টিগুলি স্ট্যান্ডার্ড প্রপার্টিগুলির তুলনায় 5-10 গুণ কোটা সীমা পায়, তাই আপনি Google Analytics 360 বৈশিষ্ট্যগুলির সাথে আরও নমনীয়তা পান৷

এপিআই কোটা ডিফল্ট সীমার উপরে বৃদ্ধি Google Analytics 4 এর জন্য ডেটা API-এর জন্য উপলব্ধ নয়। Google Analytics 360 Google Analytics 4 বৈশিষ্ট্যের জন্য কোটার উচ্চ সীমা প্রদান করে। যদি আপনার ব্যবহারকারীরা সর্বোত্তম অনুশীলন প্রয়োগ করার পরেও কোটার সীমা অতিক্রম করে, তাহলে তাদের বৈশিষ্ট্যগুলি 360-এ আপগ্রেড করার কথা বিবেচনা করা উচিত। ব্যবহারকারীদের জন্য আরেকটি বিকল্প হল Google Analytics BigQuery এক্সপোর্ট ব্যবহার করা। এটি ব্যবহারকারীদের BigQuery-এ ইভেন্ট স্তরের ডেটা রপ্তানি করতে এবং তাদের নিজস্ব বিশ্লেষণ চালাতে দেবে।

ডেটা API কোটা সম্পর্কে আরও প্রশ্নের জন্য, GA ডিসকর্ডে যান বা স্ট্যাক ওভারফ্লোতে জিজ্ঞাসা করুন। আপনার যদি ডেটা API-এর আশেপাশে নির্দিষ্ট বৈশিষ্ট্যের অনুরোধ থাকে, আপনি সেগুলি আমাদের ইস্যু ট্র্যাকারে পোস্ট করতে পারেন।