০৮ ডিসে, ২০২৫·4 মিনিট
SaaS মেট্রিক, চার্ন ও এনগেজমেন্ট ট্র্যাক করার জন্য কিভাবে ওয়েব অ্যাপ তৈরি করবেন
SaaS KPI—MRR, churn, retention ও এনগেজমেন্ট ট্র্যাক করার জন্য ডেটা ডিজাইন, ইভেন্ট, ড্যাশবোর্ড ও অ্যালার্ট নিয়ে বাস্তবিক নির্দেশিকা।
SaaS KPI—MRR, churn, retention ও এনগেজমেন্ট ট্র্যাক করার জন্য ডেটা ডিজাইন, ইভেন্ট, ড্যাশবোর্ড ও অ্যালার্ট নিয়ে বাস্তবিক নির্দেশিকা।
চার্ট বা ডাটাবেস বাছার আগে সিদ্ধান্ত নিন—এই অ্যাপটি আসলে কার জন্য এবং তারা সোমবার সকালে কোন সিদ্ধান্ত নিতে চাইবে।
একটি SaaS মেট্রিকস অ্যাপ সাধারণত কয়েকটি ভুমিকার জন্য দরকারী, প্রত্যেকটির আলাদা-আলাদা দরকারি ভিউ থাকে:
যদি আপনি প্রথম দিন থেকেই সবার সব মেট্রিক দিতে চেষ্টা করেন, আপনি দেরি করে শিপ করবেন—এবং বিশ্বাস কমবে।
“ভাল” হল KPIs-এর জন্য একটি উৎসস্থল: এমন একটা জায়গা যেখানে টিম একই সংখ্যাগুলোতে একমত, একই সংজ্ঞা ব্যবহার করে, এবং যেকোনো সংখ্যাকে তার ইনপুট (সাবস্ক্রিপশন, ইনভয়েস, ইভেন্ট) দিয়ে ব্যাখ্যা করতে পারে। কেউ যদি জিজ্ঞাসা করে “গত সপ্তাহে কেন churn বেড়েছে?”, অ্যাপটি দ্রুত সেই প্রশ্নের উত্তর দিতে সাহায্য করা উচিত—তিনটি স্প্রেডশীটে রফতানি না করে।
আপনার MVP দুটি ব্যবহারিক ফলাফল তৈরি করা উচিত:
MVP: বিশ্বাসযোগ্য কয়েকটি KPI (MRR, net revenue churn, logo churn, retention), মৌলিক সেগমেন্টেশন (প্ল্যান, অঞ্চল, কহর্ট মাস), এবং এক বা দুটি এনগেজমেন্ট সূচক।
পর্ব 2: ফোরকাস্টিং, উন্নত কহর্ট বিশ্লেষণ, এক্সপেরিমেন্ট ট্র্যাকিং, মাল্টি-প্রোডাক্ট অ্যাট্রিবিউশন, এবং আরও গভীরে অ্যালার্টিং নিয়ম।
একটি স্পষ্ট MVP স্কোপ একটি প্রতিশ্রুতি: আপনি আগে কিছু নির্ভরযোগ্য শিপ করবেন, তারপর বাড়াবেন।
SaaS মেট্রিকস ড্যাশবোর্ড তৈরির আগে সিদ্ধান্ত নিন কোন সংখ্যাগুলোকে প্রথম দিনে “সঠিক” রাখতে হবে। একটি ছোট, ভাল-সংজ্ঞায়িত সেট দীর্ঘ তালিকার চেয়ে ভালো যাদের কেউ বিশ্বাস করে না। আপনার লক্ষ্য হল churn ট্র্যাকিং, রিটেনশন, এবং ব্যবহারকারীর এনগেজমেন্ট এনালিটিক্স এতটা ধারাবাহিক করা যাতে প্রোডাক্ট, ফাইন্যান্স এবং সেলস গণিত নিয়ে আর বিতর্ক না করে।
প্রতিষ্ঠাতারা যে প্রশ্নগুলো সাপ্তাহিকভাবে করে সেই গুলোর সঙ্গে মানানসই একটি কোর সেট দিয়ে শুরু করুন:
যদি পরে আপনি কহর্ট বিশ্লেষণ, এক্সপ্যানশন রাজস্ব, LTV, বা CAC যোগ করেন, তা ঠিক আছে—কিন্তু সেগুলো নির্ভরযোগ্য সাবস্ক্রিপশন অ্যানালিটিক্স দেরি করবে না।
প্রতিটি মেট্রিককে একটি ছোট স্পেসিফ হিসেবে লিখুন: এটি কী মাপছে, সূত্র, বাদ দেওয়া অংশ, এবং সময়নির্ধারণ। উদাহরণ:
এই সংজ্ঞাগুলো আপনার অ্যাপের চুক্তি হয়ে যায়—UI টুলটিপ এবং ডকসে ব্যবহার করুন যাতে আপনার SaaS KPI ওয়েব অ্যাপ সূত্রকে ধরে রাখে।
নির্ধারণ করুন আপনার অ্যাপ দৈনিক, সাপ্তাহিক, মাসিক রিপোর্ট করবে (অনেকে দৈনিক + মাসিক দিয়ে শুরু করে)। তারপর সিদ্ধান্ত নিন:
স্লাইসিং মেট্রিককে কার্যকর করে। আপনি কোন মাত্রাগুলোকে অগ্রাধিকার দেবেন তার তালিকা করুন:
শুরুতেই এগুলো লক করে রাখা পরে রি-ওয়ার্ক কমায় এবং যখন আপনি অটোমেটেড রিপোর্ট চালু করবেন তখন আপনার অ্যানালিটিক্স অ্যালার্টস ধারাবাহিক থাকবে।
MRR, churn, বা এনগেজমেন্ট গণনা করার আগে, আপনাকে স্পষ্টভাবে জানতে হবে কে অর্থ প্রদান করছে, তারা কি সাবস্ক্রাইব করেছে, এবং তারা প্রোডাক্টে কি করছে। একটি পরিষ্কার ডেটা মডেল ডাবল-কাউন্টিং প্রতিরোধ করে এবং পরে এজ-কেস হ্যান্ডল করা সহজ করে।
অধিকাংশ SaaS মেট্রিক অ্যাপ চারটি টেবিল দিয়ে মডেল করা যায় (বা কালেকশন):
আপনি যদি ইনভয়েস ট্র্যাক করেন, তাহলে Invoices/Charges যোগ করুন নগদ-ভিত্তিক রিপোর্টিং, রিকনসিলিয়েশন এবং রিফান্ড হ্যান্ডল করার জন্য।
স্থায়ী IDs বাছুন এবং রিলেশনশিপগুলো স্পষ্ট করুন:
user_id একটি account_id-এর অন্তর্গত (একটি অ্যাকাউন্টে বহু ইউজার)।subscription_id একটি account_id-এর অন্তর্গত (সাধারণত অ্যাকাউন্ট প্রতি এক সক্রিয় সাবস্ক্রিপশন থাকে, কিন্তু যদি আপনার প্রাইসিং একাধিককে সমর্থন করে তবে একাধিক অনুমোদন করুন)।event-এ থাকা উচিত event_id, occurred_at, user_id, এবং সাধারণত account_id যাতে অ্যাকাউন্ট-স্তরের অ্যানালিটিক্স করা যায়।ইমেইলকে প্রাইমারী কী হিসেবে ব্যবহার করবেন না; মানুষ ইমেইল পরিবর্তন করে।
সাবস্ক্রিপশন পরিবর্তনগুলোকে সময়ের উপর অবস্থান হিসেবে মডেল করুন। শুরু/শেষ টাইমস্ট্যাম্প এবং সম্ভব হলে কারণ ধরে রাখুন:
আপনার যদি একাধিক প্রোডাক্ট, ওয়ার্কস্পেস টাইপ বা অঞ্চল থাকে, একটি লাইটওয়েট ডাইমেনশন যোগ করুন যেমন product_id বা workspace_id এবং সেটি সাবস্ক্রিপশন ও ইভেন্টে ধারাবাহিকভাবে অন্তর্ভুক্ত করুন। এটি পরে কহর্ট বিশ্লেষণ ও সেগমেন্টেশন সরল রাখে।
এনগেজমেন্ট মেট্রিকগুলো শুধুমাত্র তাদের পেছনের ইভেন্টগুলোর মতোই বিশ্বাসযোগ্য। “অ্যাক্টিভ ইউজার” বা “ফিচার গ্রহণ” ট্র্যাক করার আগে সিদ্ধান্ত নিন প্রোডাক্টে কোন কাজগুলো কাস্টমারের জন্য অর্থপূর্ণ অগ্রগতি বোঝায়।
ইউজার যাত্রার কীগুলো বর্ণনা করে এমন একটি ছোট, মনোনীত ইভেন্ট সেট দিয়ে শুরু করুন। উদাহরণ:
ইভেন্ট নামগুলো past tense-এ রাখুন, Title Case ব্যবহার করুন, এবং এতটাই নির্দিষ্ট রাখুন যাতে চার্ট পড়ে বোঝা যায় কি ঘটেছে।
কনটেক্সট ছাড়া একটি ইভেন্ট সেগমেন্ট করা কঠিন। এমন প্রপার্টি যোগ করুন যা আপনি ড্যাশবোর্ডে ছাঁটাই করতে ব্যবহার করবেন:
টাইপ (স্ট্রিং বনাম নাম্বার বনাম বুলিয়ান) নিয়ে কঠোর হন এবং অনুমোদিত মানগুলিতে ধারাবাহিক থাকুন (যেমন pro, Pro, ও PRO একসঙ্গে মিশবেন না)।
ইভেন্ট পাঠান:
এনগেজমেন্ট ট্র্যাকিংয়ের জন্য “সম্পন্ন” আউটকামের ক্ষেত্রে backend ইভেন্ট পছন্দ করুন যাতে রিটেনশন মেট্রিক ভাঙে না ব্যর্থ প্রচেষ্টা বা ব্লক হওয়া রিকোয়েস্টে।
একটা ছোট ট্র্যাকিং প্ল্যান লিখুন এবং আপনার রেপোতে রাখুন। নামকরণ কনভেনশন, প্রতিটি ইভেন্টের প্রয়োজনীয় প্রপার্টি, এবং উদাহরণ সংজ্ঞায়িত করুন। এই এক পেজ নীরবভাবে ড্রিফট হওয়া প্রতিরোধ করে যা পরে churn ট্র্যাকিং ও কহর্ট বিশ্লেষণ ভাঙতে পারে। যদি আপনার একটি “Tracking Plan” পেজ থাকে আপনার অ্যাপ ডকসে, সেটার লিংক ইন্টারনালি রাখুন (উদাহরণ: /docs/tracking-plan) এবং আপডেটকে কোড রিভিউ-এর মতো বিবেচনা করুন।
আপনার SaaS মেট্রিকস অ্যাপ কেবল তখনই বিশ্বাসযোগ্য যখন এতে ডেটা সঠিকভাবে প্রবাহিত হয়। চার্ট বানানোর আগে সিদ্ধান্ত নিন কি ইনজেস্ট করবেন, কত ঘনঘন, এবং ভুল সংশোধন কিভাবে করবেন যখন বাস্তবতা বদلے (রিফান্ড, প্ল্যান এডিট, দেরিতে আসা ইভেন্ট)।
অধিকাংশ টিম চারটি ক্যাটাগরির সঙ্গে শুরু করে:
প্রতিটি ফিল্ডের জন্য সংক্ষিপ্ত "source of truth" নোট রাখুন (যেমন “MRR is computed from Stripe subscription items”)।
বিভিন্ন সোর্সের জন্য বিভিন্ন প্যাটার্ন ভালো কাজ করে:
প্রায়ই আপনি "কি বদলেছে" জানার জন্য ওয়েবহুক এবং “সব কিছু যাচাই করার জন্য” একটি নাইটলি সিঙ্ক মিশ্র করবেন।
র'])
Land raw inputs into a staging schema first. Normalize timestamps to UTC, map plan IDs to internal names, and deduplicate events by idempotency keys. This is where you handle quirks like Stripe prorations or “trialing” statuses.
Metrics break when late data arrives or bugs are fixed. Build:
This foundation makes churn and engagement calculations stable—and debuggable.
Start by defining the Monday-morning decisions the app should support (e.g., “Is revenue risk increasing?”).
A solid MVP usually includes:
Treat definitions as a contract and make them visible in the UI.
For each metric, document:
Then implement those rules once in shared calculation code (not separately per chart).
A practical day-one set is:
Keep expansion, CAC/LTV, forecasting, and advanced attribution for phase 2 so you don’t delay reliability.
A common, explainable baseline model is:
If you need reconciliation and refunds, add .
Model subscriptions as state over time, not a single mutable row.
Capture:
This makes MRR timelines reproducible and avoids “mystery” churn spikes when history gets rewritten.
Pick a small vocabulary of events that represent real value (not vanity clicks), such as “Created Project,” “Connected Integration,” or “Published Report.”
Best practices:
Most teams combine three ingestion patterns:
Land everything into a staging layer first (normalize time zones, dedupe with idempotency keys), and keep a way to backfill and reprocess when rules or data change.
Separate layers:
agg_daily_mrr) for fast dashboardsFor performance:
Start with a single page that answers growth and risk in under a minute:
Then add drill-down paths that explain “why”:
Use a small set of high-signal rules tied to clear actions, such as:
Reduce noise with minimum thresholds, cooldowns, and grouping.
Every alert should include context (value, delta, time window, top segment) and a drill-down link to a filtered view (e.g., /dashboards/mrr?plan=starter®ion=eu).
Use stable IDs (not emails) and make relationships explicit (e.g., every event includes user_id and usually account_id).
/docs/tracking-plandate/timestamp, customer_id, subscription_id, user_id)Include an inline metric definition tooltip on every KPI to prevent debates.