Cohort Analysis দিয়ে Retention সমস্যা ধরার পদ্ধতি

সর্বাধিক আলোচিত

নতুন ব্যবহারকারী আসছে, সাইন আপ করছে, কিন্তু কয়েক দিন বা কয়েক সপ্তাহ পর তাদের বড় একটি অংশ আর ফিরছে না। শুধু সামগ্রিক Customer Retention বা Customer Churn দেখলে বোঝা যায় সমস্যা আছে, কিন্তু ঠিক কখন থেকে সেটি শুরু হচ্ছে বা কোন ধরনের ব্যবহারকারীর মধ্যে বেশি হচ্ছে—সেটি ধরা কঠিন।

এই জায়গাতেই Cohort Analysis বা কোহর্ট অ্যানালাইসিস কাজে আসে। বিশেষ করে SaaS cohort analysis-এ একই সময়ে যাত্রা শুরু করা বা একই ধরনের কাজ করা ব্যবহারকারীদের আলাদা দলে রেখে সময়ের সঙ্গে তাদের আচরণ তুলনা করা হয়। ফলে দেখা যায়, ব্যবহারকারীরা অনবোর্ডিংয়ের পরই হারিয়ে যাচ্ছে, নাকি কয়েক সপ্তাহ ব্যবহারের পর; কোনো নির্দিষ্ট acquisition channel-এর ব্যবহারকারীদের retention কম, নাকি গুরুত্বপূর্ণ একটি feature ব্যবহার না করা গ্রুপের সমস্যা বেশি।

তবে একটি সীমা শুরুতেই মনে রাখা দরকার। Cohort Analysis সাধারণত সমস্যাটি কোথায় এবং কোন দলের মধ্যে বেশি তা দেখায়। শুধু একটি cohort chart দেখে ব্যবহারকারী কেন চলে যাচ্ছে, তার কারণ নিশ্চিতভাবে প্রমাণ করা যায় না।

Cohort Analysis কী দেখায়?

একটি cohort হলো এমন ব্যবহারকারীদের দল, যাদের মধ্যে নির্দিষ্ট কোনো মিল আছে।

সবচেয়ে সহজ উদাহরণ হলো signup cohort। ধরা যাক:

  • 6–12 July-এর মধ্যে সাইন আপ করা ব্যবহারকারীরা একটি cohort
  • 13–19 July-এর ব্যবহারকারীরা আরেকটি cohort
  • 20–26 July-এর ব্যবহারকারীরা তৃতীয় cohort

এরপর প্রতিটি দলের কতজন Week 1, Week 2 বা Week 4-এও নির্ধারিত গুরুত্বপূর্ণ কাজটি করছে, তা তুলনা করা যায়।

আবার সময়ের পাশাপাশি আচরণ ধরেও cohort বানানো যায়। যেমন:

  • সাইন আপের প্রথম 3 দিনের মধ্যে প্রথম project তৈরি করেছে যারা
  • onboarding শেষ করেছে যারা
  • প্রথম 7 দিনের মধ্যে teammate invite করেছে যারা
  • নির্দিষ্ট feature ব্যবহার করেছে যারা
  • checkout সম্পন্ন করেছে যারা

Amplitude-এর behavioral cohort-এও নির্দিষ্ট সময়সীমার মধ্যে ব্যবহারকারীর করা বা না-করা কাজের ভিত্তিতে দল তৈরি করা যায়।

এখানেই Cohort Analysis সাধারণ segmentation থেকে আলাদা। Segmentation বলে কারা কোন দলে আছে। Cohort Analysis দেখায়, একটি নির্দিষ্ট দল সময়ের সঙ্গে কীভাবে আচরণ করছে।

আগে ঠিক করুন, Retention বলতে কী বোঝাচ্ছেন

Cohort chart তৈরির আগেই সবচেয়ে জরুরি সিদ্ধান্ত হলো: কোন কাজ করলে একজন ব্যবহারকারীকে retained ধরা হবে?

কেউ আবার login করলেই কি সে retained user?

সব পণ্যে নয়।

একটি invoicing software-এ meaningful return event হতে পারে নতুন invoice তৈরি করা। Project management software-এ task update বা project-এ কাজ করা বেশি অর্থবহ হতে পারে। E-commerce ব্যবসায় আবার repeat purchase-ই গুরুত্বপূর্ণ হতে পারে।

তাই সাধারণ retention analysis-এ দুটি event পরিষ্কার রাখা সুবিধাজনক।

Start Event: যে ঘটনা থেকে ব্যবহারকারীর retention journey মাপা শুরু হবে।
উদাহরণ: Sign Up, Trial Started বা First Purchase।

Return Event: পরবর্তী সময়ে কোন কাজ করলে ব্যবহারকারীকে retained ধরা হবে।
উদাহরণ: Project Created, Invoice Sent বা Order Completed।

Mixpanel-এর retention guidance-এও পণ্যের জন্য অর্থবহ return action বেছে নেওয়ার ওপর জোর দেওয়া হয়েছে। Amplitude-এ retention analysis Start Event ও Return Event-এর মধ্যকার সময়ের ভিত্তিতে করা হয়।

এরপর ঠিক করতে হবে সময়ের একক—দিন, সপ্তাহ নাকি মাস।

প্রতিদিন ব্যবহার করার কথা এমন পণ্যকে শুধু monthly retention দিয়ে দেখলে শুরুর সমস্যাগুলো চাপা পড়ে যেতে পারে। আবার মাসে একবার স্বাভাবিকভাবে প্রয়োজন হয় এমন পণ্যকে Day 1 retention দিয়ে বিচার করাও বিভ্রান্তিকর হতে পারে। তাই পণ্যের স্বাভাবিক usage interval আগে বোঝা দরকার।

একটি বেসিক Cohort Analysis করতে কী ডেটা লাগবে?

একটি বেসিক Cohort Analysis করতে কী ডেটা লাগবে

নিজস্ব spreadsheet, database বা analytics system দিয়ে analysis করতে হলে এমন তথ্য দরকার, যাতে একই ব্যবহারকারীকে শনাক্ত করা এবং তার গুরুত্বপূর্ণ event-এর সময় জানা যায়।

সাধারণভাবে প্রয়োজন হতে পারে:

  • একটি স্থিতিশীল user_id, account_id বা সমমানের identifier
  • Start Event-এর সময়
  • Return Event বা গুরুত্বপূর্ণ activity-এর সময়
  • event-এর ধরন
  • প্রয়োজনে acquisition channel, plan, country, platform বা version-এর মতো property

Amplitude-এর event model-এও user identifier, event type, event time এবং event properties ব্যবহৃত হয়।

আরও পড়ুনঃ SaaS-এর Hidden Cost: Hosting, Support, API ও Compliance

B2B SaaS-এ user নাকি account?

B2B পণ্যে এই সিদ্ধান্তটি গুরুত্বপূর্ণ।

একটি প্রতিষ্ঠানের 10 জন সদস্যের মধ্যে কয়েকজন নিষ্ক্রিয় হয়ে গেলেও প্রতিষ্ঠানটি গ্রাহক হিসেবে সক্রিয় থাকতে পারে। তাই product adoption বুঝতে user-level retention দরকার হতে পারে। কিন্তু customer health বা subscription ধরে রাখার প্রশ্নে account-level analysis বেশি প্রাসঙ্গিক হতে পারে।

এই কারণেই B2B product analytics-এ user ও account—দুই স্তরেই analysis করার প্রয়োজন দেখা যায়। Amplitude-ও account-level analysis সমর্থন করে।

ধাপে ধাপে Cohort Chart তৈরি করুন

1. ব্যবহারকারীকে শুরুর সময় অনুযায়ী ভাগ করুন

ধরা যাক, weekly acquisition cohort ব্যবহার করছেন।

তাহলে:

  • 6–12 July → Cohort A
  • 13–19 July → Cohort B
  • 20–26 July → Cohort C

Spreadsheet-এ আলাদা Cohort Week column রাখা যায়। Analytics tool-এ সাধারণত interval নির্বাচন করেই এই grouping করা হয়।

2. Return Event কত দিন বা সপ্তাহ পরে হয়েছে, তা বের করুন

একজন ব্যবহারকারী 8 July-এ Start Event করেছে এবং 16 July-এ Return Event করেছে—এমন হলে Start Event থেকে ব্যবধান ধরে activity-টিকে নির্দিষ্ট retention interval-এ রাখা হবে।

এই interval অনেক ক্ষেত্রে calendar week নয়; বরং প্রত্যেক ব্যবহারকারীর নিজস্ব Start Event থেকে গণনা করা হয়।

3. প্রতিটি interval-এ retained unique user গণনা করুন

একজন ব্যবহারকারী Week 1-এ Return Event 20 বার করলেও user retention হিসাবের সময় তাকে 20 জন ধরা যাবে না। ব্যবহারকারীভিত্তিক retention হলে numerator-এ retained unique user গণনা করতে হবে।

ধরা যাক একটি cohort-এ 200 জন ব্যবহারকারী আছে।

Week 1-এ 120 জন Return Event করলে:

Week 1 Retention = 120 ÷ 200 × 100 = 60%

Week 2-এ 90 জন করলে:

Week 2 Retention = 90 ÷ 200 × 100 = 45%

নিজে spreadsheet দিয়ে হিসাব করলে denominator-এর নিয়ম পুরো analysis-এ একই রাখা জরুরি।

4. Retention matrix বানান

নিচের সংখ্যাগুলো একটি কাল্পনিক SaaS উদাহরণ।

Signup Cohort Week 0 Week 1 Week 2 Week 3 Week 4
6 July 100% 54% 42% 35% 33%
13 July 100% 56% 45% 39% 37%
20 July 100% 68% 61% 58%
27 July 100% 65% 60%

এই উদাহরণে Week 0-কে 100% রাখা হয়েছে, কারণ cohort membership-ই এখানে baseline।

কিন্তু Week 0 সব retention setup-এ 100% হবে না। Start Event ও Return Event আলাদা হলে একই Week 0 interval-এর মধ্যে Return Event না করা ব্যবহারকারীদের কারণে retention 100%-এর কম হতে পারে।

টেবিলটি বাম থেকে ডানে পড়লে একটি cohort সময়ের সঙ্গে কীভাবে ধরে রাখা যাচ্ছে, তা বোঝা যায়। ওপর থেকে নিচে পড়লে একই বয়সে বিভিন্ন cohort তুলনা করা যায়।

শেষের ফাঁকা ঘরগুলো 0% retention নয়। নতুন cohort এখনও ওই interval পর্যন্ত পৌঁছায়নি। Cohort chart-এ এই অসম্পূর্ণ অংশ স্বাভাবিক।

কোথায় Retention সমস্যা হচ্ছে, তা কীভাবে ধরবেন

শুধু সবচেয়ে কম শতাংশের দিকে তাকালে অনেক সময় ভুল সিদ্ধান্ত হয়। বরং দেখুন, একাধিক cohort-এ একই ধরনের pattern আছে কি না।

শুরুতেই বড় পতন হলে

Start Event-এর পর প্রথম interval-এই যদি বেশির ভাগ cohort-এ বড় drop দেখা যায়, তাহলে নতুন ব্যবহারকারীরা দ্রুত পণ্যের মূল সুবিধা পাচ্ছে কি না, সেটি তদন্ত করা দরকার।

যে জায়গাগুলো দেখা যেতে পারে:

  • onboarding-এ বড় কোনো বাধা আছে কি না
  • প্রথম গুরুত্বপূর্ণ কাজটি শেষ করতে সমস্যা হচ্ছে কি না
  • acquisition message ও বাস্তব product experience-এর মধ্যে অমিল আছে কি না
  • প্রয়োজনীয় feature ব্যবহারকারীরা খুঁজে পাচ্ছে কি না

তবে cohort chart দেখে সরাসরি “onboarding-ই দায়ী” বলা ঠিক হবে না। Funnel analysis দিয়ে কোন ধাপে বেশি drop-off হচ্ছে, সেটি আলাদাভাবে দেখা দরকার।

প্রথম দিকে ভালো, পরে retention কমে গেলে

Week 1 ভালো হলেও Week 2 বা Week 3 থেকে ধারাবাহিক পতন হলে প্রশ্নটি বদলে যায়। ব্যবহারকারী হয়তো শুরুতে মূল্য পাচ্ছে, কিন্তু পণ্যটি তার নিয়মিত কাজের অংশ হয়ে উঠছে না।

এখানে activation এবং long-term retention-কে এক জিনিস ধরে নেওয়া ঠিক নয়। অনবোর্ডিং শেষ করা বা প্রথম গুরুত্বপূর্ণ কাজটি করা দীর্ঘমেয়াদি retention-এর সঙ্গে সম্পর্কিত হতে পারে, কিন্তু সেটি নিজে কারণ প্রমাণ করে না।

কোনো পরিবর্তনের পর নতুন cohort ভালো করলে

ধরা যাক 18 July-এ onboarding বদলানো হলো এবং এরপরের cohort-গুলোর retention আগের চেয়ে ভালো।

এটি পরিবর্তনটি কার্যকর হতে পারে—এমন একটি hypothesis দেয়।

কিন্তু একই সময়ে acquisition source, campaign, audience mix, pricing বা অন্য product change-ও বদলাতে পারে। তাই cohort difference দেখেই কারণ নিশ্চিত করা উচিত নয়। Behavioral cohort analysis-এও correlation থেকে hypothesis তৈরি করা যায়; causal effect প্রমাণের জন্য আলাদা পরীক্ষা প্রয়োজন।

Behavioral Cohort দিয়ে সম্ভাব্য কারণ সংকুচিত করুন

Acquisition cohort সাধারণত বলে কখন retention বদলেছে। Behavioral cohort সাহায্য করে দেখতে, কোন আচরণের সঙ্গে সেই পরিবর্তনের সম্পর্ক বেশি।

ধরা যাক একটি project management SaaS-এ দুটি cohort তৈরি করা হলো:

Cohort A: প্রথম 7 দিনের মধ্যে অন্তত একজন teammate invite করেছে।
Cohort B: একই সময়ে কাউকে invite করেনি।

এরপর দুই দলের Week 4 বা Week 8 retention তুলনা করা যায়।

একইভাবে দেখা যেতে পারে:

  • template ব্যবহার করেছে বনাম করেনি
  • integration যুক্ত করেছে বনাম করেনি
  • প্রথম report তৈরি করেছে বনাম করেনি
  • নির্দিষ্ট feature ব্যবহার করেছে বনাম করেনি

যদি Cohort A-এর retention বেশি হয়, তার অর্থ এই নয় যে teammate invite করলেই retention বাড়বে। আগে থেকেই বেশি আগ্রহী ব্যবহারকারীরা ওই কাজটি বেশি করে থাকতে পারে।

তাই সঠিক সিদ্ধান্ত হবে: আচরণটির সঙ্গে বেশি retention-এর সম্পর্ক পাওয়া গেছে; এখন সেটি পরীক্ষা করার মতো hypothesis।

Channel, Plan বা Platform অনুযায়ী Cohort ভাঙুন

সামগ্রিক retention মোটামুটি ভালো দেখালেও ভেতরে বড় পার্থক্য থাকতে পারে।

একটি কাল্পনিক উদাহরণ:

  • Organic signup → Week 4 retention 45%
  • Paid Campaign A → 22%
  • Partner referral → 48%

শুধু acquisition volume বা CAC দেখে Paid Campaign A ভালো মনে হতে পারে। কিন্তু সেই ব্যবহারকারীরা দ্রুত churn করলে channelটির দীর্ঘমেয়াদি মূল্য আলাদাভাবে পরীক্ষা করা দরকার।

Cohort ভাগ করা যেতে পারে:

  • plan
  • acquisition source
  • country বা region
  • platform
  • device
  • app version
  • company বা account type

Amplitude-এর user properties-এও platform, device, version এবং custom plan বা referral source-এর মতো property ব্যবহারের সুযোগ আছে।

খুব ছোট cohort নিয়ে সাবধান

অতিরিক্ত segmentation করলে cohort দ্রুত ছোট হয়ে যায়।

20 জনের cohort-এ 2 জন ব্যবহারকারীর পার্থক্যই 10 percentage point পরিবর্তন তৈরি করে। তাই ছোট cohort-এ percentage-এর পাশাপাশি actual user count দেখা এবং একই pattern একাধিক cohort-এ পাওয়া যাচ্ছে কি না পরীক্ষা করা দরকার।

যে ভুলগুলো Cohort Analysis-কে বিভ্রান্তিকর করে

যে ভুলগুলো Cohort Analysis-কে বিভ্রান্তিকর করে

সহজ বলে ভুল Return Event বেছে নেওয়া

Login বা App Open সহজে track করা যায়। কিন্তু সব product-এর ক্ষেত্রে এগুলো meaningful retention বোঝায় না। Return Event এমন হওয়া ভালো, যা পণ্যের প্রকৃত ব্যবহার বা value-এর কাছাকাছি।

অসম্পূর্ণ cohort-কে 0% ধরা

একটি নতুন cohort এখনও Week 4-এ পৌঁছায়নি মানে তার Week 4 retention শূন্য নয়। পর্যাপ্ত সময়ই পেরোয়নি।

Tracking সমস্যা উপেক্ষা করা

Event tracking বদল, identifier-এর সমস্যা, duplicate event বা instrumentation error থেকেও হঠাৎ অস্বাভাবিক pattern তৈরি হতে পারে। Amplitude-এর event ingestion-এ identifier ও timestamp গুরুত্বপূর্ণ; duplicate event ঠেকাতে insert_id ব্যবহারের ব্যবস্থাও রয়েছে।

তাই অস্বাভাবিক পরিবর্তন দেখলে শুধু product change নয়, tracking setup-ও পরীক্ষা করা উচিত।

অত্যধিক segmentation করা

Country × device × plan × campaign × version একসঙ্গে ভাগ করলে এমন ছোট cohort তৈরি হতে পারে, যেখানে প্রকৃত pattern-এর চেয়ে স্বাভাবিক ওঠানামাই বেশি চোখে পড়ে।

Product inactivity আর subscription churn গুলিয়ে ফেলা

কেউ কিছুদিন product ব্যবহার না করলেও তার paid subscription চালু থাকতে পারে। আবার subscription বাতিল করলেও তার পুরোনো product activity analytics-এ থেকে যায়।

Customer churn সাধারণত নির্দিষ্ট সময়ের মধ্যে customer বা subscriber হারানোর মেট্রিক। Product retention আবার নির্ধারিত Return Event-এর ভিত্তিতে মাপা হতে পারে। Population ও সংজ্ঞা এক না হলে এই দুই মেট্রিককে সরাসরি তুলনা করা ঠিক নয়।

Drop-off পাওয়ার পর কী করবেন

Cohort chart তৈরি করাই লক্ষ্য নয়। Chart থেকে এমন একটি প্রশ্ন বের করা দরকার, যেটি পরীক্ষা করা যায়।

ধরা যাক প্রথম 7 দিনের মধ্যে একটি নির্দিষ্ট কাজ করা ব্যবহারকারীদের Week 4 retention বেশি।

তখন পরবর্তী কাজ হতে পারে:

  1. ওই কাজটির আগে ব্যবহারকারীর journey দেখুন।
  2. Funnel-এর কোন ধাপে সবচেয়ে বেশি drop-off হচ্ছে, তা পরীক্ষা করুন।
  3. Retained ও churned cohort-এর অন্যান্য আচরণ তুলনা করুন।
  4. Support ticket, cancellation feedback, survey বা user interview-এর মতো qualitative evidence দেখুন।
  5. একটি নির্দিষ্ট onboarding বা product change পরীক্ষা করুন।
  6. পরিবর্তনের পর নতুন cohort-এর ফলাফল আগের comparable cohort-এর সঙ্গে মিলিয়ে দেখুন।

Quantitative cohort data-এর সঙ্গে qualitative feedback ব্যবহার করলে সমস্যার সম্ভাব্য কারণ যাচাই করা সহজ হয়।

শুরু করার সবচেয়ে বাস্তবসম্মত পথ

প্রথম SaaS cohort analysis-এ অনেক dimension নিয়ে শুরু করার প্রয়োজন নেই।

একটি পরিষ্কার Start Event নিন। এরপর এমন একটি Return Event নির্ধারণ করুন, যা ব্যবহারকারী পণ্য থেকে বাস্তব মূল্য পাচ্ছে—এমন ইঙ্গিত দেয়। পণ্যের স্বাভাবিক ব্যবহারের ধরন অনুযায়ী day, week বা month interval নির্বাচন করুন।

তারপর দুটি প্রশ্ন দিয়ে analysis শুরু করুন:

কোন interval-এ retention সবচেয়ে বেশি কমছে?

পরে যারা retained থাকছে, তাদের শুরুর আচরণে কী পার্থক্য ছিল?

প্রথম প্রশ্নটি সমস্যার সময়কাল সংকুচিত করবে। দ্বিতীয়টি behavioral cohort তৈরির দিক দেখাবে।

Cohort Analysis নিজে থেকে কাস্টমার কেন চলে যাচ্ছে তার চূড়ান্ত উত্তর দেয় না। এর ব্যবহারিক মূল্য হলো একটি অস্পষ্ট retention সমস্যাকে নির্দিষ্ট সময়, cohort ও আচরণে ভেঙে ফেলা। এরপর funnel analysis, qualitative feedback এবং প্রয়োজনে controlled experiment দিয়ে সম্ভাব্য কারণ যাচাই করা যায়।

শেষ কথা

SaaS cohort analysis সবচেয়ে বেশি কাজে লাগে তখনই, যখন retention সমস্যাকে একটি মোট শতাংশ হিসেবে না দেখে সময়, ব্যবহারকারীর ধরন এবং আচরণ অনুযায়ী আলাদা করে দেখা হয়। কোনো cohort কোথায় দ্রুত কমছে এবং retained ব্যবহারকারীরা শুরুতে কী ভিন্ন কাজ করছে—এই দুই তথ্য থেকেই পরবর্তী তদন্তের দিক পরিষ্কার হয়।

তবে correlation-কে কারণ ধরে নেওয়া উচিত নয়। Cohort Analysis সম্ভাব্য সমস্যার জায়গা দেখায়; কারণ নিশ্চিত করতে funnel data, user feedback এবং প্রয়োজন হলে controlled experiment ব্যবহার করতে হয়। তাই শুরুতে জটিল dashboard নয়—একটি পরিষ্কার Start Event, অর্থবহ Return Event এবং উপযুক্ত সময়ের interval দিয়েই analysis শুরু করা সবচেয়ে বাস্তবসম্মত।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

Cohort Analysis এবং segmentation-এর মধ্যে পার্থক্য কী?

Segmentation ব্যবহারকারীদের বৈশিষ্ট্য বা আচরণের ভিত্তিতে ভাগ করে। Cohort Analysis-এ সেই নির্দিষ্ট দল সময়ের সঙ্গে কীভাবে আচরণ করছে, সেটিও দেখা হয়।

Retention 70% হলে Churn কি 30%?

একই population, একই সময়কাল এবং পরস্পর-সম্পূরক সংজ্ঞা ব্যবহার করলে customer retention 70% হলে customer churn 30% হতে পারে। কিন্তু product-activity retention, subscription churn এবং revenue churn একই মেট্রিক নয়।

B2B SaaS-এ user retention নাকি account retention বেশি দরকার?

দুটির উদ্দেশ্য আলাদা। Individual adoption বুঝতে user-level retention উপযোগী। কোনো গ্রাহক প্রতিষ্ঠান সামগ্রিকভাবে পণ্যটি ব্যবহার করছে কি না দেখতে account-level analysis বেশি কার্যকর হতে পারে।

সর্বশেষ