একটি মূল্য পরীক্ষার লগ ব্যবহার করে অনুমান, ভ্যারিয়েন্ট, তারিখ ও ফলাফল সংরক্ষণ করুন, যাতে আপনার দল সফল কৌশল পুনরায় প্রয়োগ করতে পারে এবং ব্যর্থ পরীক্ষাগুলো আর পুনরায় চালানো বন্ধ করতে পারে।
মূল্য পরীক্ষাগুলো প্রায়ই ব্যর্থ হয় কারণ দলগুলো কী করেছে তা ভুলে যায়, সমস্যা অনবশ্যকই আইডিয়ার খারাপ হওয়ার কারণে নয়। একটি দল প্ল্যান বদলে দেখে বৃদ্ধিও হয়েছে (বা হ্রাস) এবং কাজ শেষ মনে করে। ছয় মাস পর কারো আবার একই প্রশ্ন উঠলে। পরীক্ষা আবার চালানো হয় কারণ বিস্তারিত পিচ, চ্যাট থ্রেড, অ্যানালিটিক্স স্ক্রিনশট এবং অসম্পূর্ণ ডকসের মধ্যে ছড়িয়ে থাকে।
একটি মূল্য পরীক্ষার লগ হচ্ছে আপনি চালানো প্রতিটি প্ল্যান ও ফিচার টেস্টের একটি শেয়ার্ড রেকর্ড। এটি অনুমান, আপনি কি বদল করেছেন, কখন চালানো হয়েছে, আপনি কী মাপেছেন এবং কী ঘটেছে—এসব ধারণ করে। এটি মূল্য সংক্রান্ত একটি ল্যাব নোটবুক, সাধারণ ভাষায় লেখা যাতে দল anybody বুঝতে পারে।
ফলাফল সরল: নতুন প্রশ্ন এলে আপনি দ্রুত দেখতে পাবেন আগে কী করা হয়েছিল, কোন পরিস্থিতিতে, এবং কেন তা কাজ করেছে (অথবা করেনি)। এর মানে দ্রুত সিদ্ধান্ত, কম পুনরাবৃত্ত ভুল এবং কোন ঘটেছে তা নিয়ে কম বিতর্ক।
এটি সেইসব পরীক্ষাগুলো তুলনা করতেও সাহায্য করে যা দেখতে একই মনে হলেও বাস্তবে আলাদা। “মূল্য ১০% বাড়ানো” ভিন্ন পরীক্ষারূপ হবে যদি তা কেবল নতুন ব্যবহারকারীর উপর প্রযোজ্য হয়, কেবল একটি অঞ্চলে হয়, বা সিজনাল স্পাইক চলাকালীন করা হয়।
এটা প্রতিটি পরীক্ষার পরে একটি পুস্তক লেখার ব্যাপার নয়। বরং একটি পরিষ্কার ট্রেইল রেখে যাওয়ার ব্যাপার: আপনি কি বিশ্বাস করেছিলেন, কি বদলানো হয়েছিল, আপনি কী দেখেছেন, এবং পরের বার কি ভিন্ন করবেন।
একটি মূল্য পরীক্ষা হচ্ছে যেকোন কন্ট্রোলড পরিবর্তন যা মানুষের পরিশোধিত পরিমাণ, প্ল্যান নির্বাচন, বা আপগ্রেড সময়কে বদলাতে পারে। যদি এটা রেভিনিউ, কনভার্সন, বা রিটেনশন সরাতে পারে, তা আপনার মূল্য পরীক্ষার লগে থাকা উচিত।
এটি কেবল দাম সংখ্যার পরিবর্তন নয়—অফারের পরিবর্তনও অন্তর্ভুক্ত। মূল্য পরিবর্তন সহজ: $29 থেকে $39 হয়ে যায়। কিন্তু মূল্য-ধারণা বদলানোও গুরুত্বপূর্ণ: একই দাম রেখে প্ল্যানের নাম বদলানো, সুবিধা পুনরায় উপস্থাপন করা, কী অন্তর্ভুক্ত তা বদলানো, বা “সবচেয়ে জনপ্রিয়” অপশন যোগ করা—গ্রাহকরা দুটোই প্রতিক্রিয়া দেবে।
সাধারণ মূল্য পরীক্ষাগুলো যা লগ করা দরকার: মূল্যবিন্দু (মাসিক/বার্ষিক রেট, ছাড়, ট্রায়াল, সেটআপ ফি), প্যাকেজিং (টিয়ার ও কোন ফিচার কোন টিয়ারে আছে), সীমা (সিট, ব্যবহার ক্যাপ, কোটা, ওভারেজ), অ্যাড-অন (পেইড এক্সট্রা, বান্ডল, প্রিমিয়াম সাপোর্ট), এবং আপগ্রেড পথ (কখন ও কিভাবে আপগ্রেড প্রম্পট দেখানো হয়)।
যা গণ্য হয় না: চেকআউট বাগ ঠিক করা, প্ল্যান পেজের টাইপো ঠিক করা, বা অনবোর্ডিং কপিতে আপডেট করা যদি তা প্ল্যানের অন্তর্গত কিছু বা পেইড এলিমেন্ট পরিবর্তন না করে। সেগুলো প্রোডাক্ট বা মার্কেটিং পরিবর্তন, মূল্য পরীক্ষা নয়।
বেশিরভাগ মূল্য পরীক্ষা কয়েকটি জায়গায় দেখা যায়: প্রাইসিং পেজ, চেকআউট, এবং ইন-অ্যাপ আপগ্রেড স্ক্রিন। কোনো পরীক্ষা চালানোর আগে একটাই প্রশ্ন জিজ্ঞেস করুন: “কে অবাক হতে পারে?” যদি গ্রাহকরা প্রতারিত, বিভ্রান্ত, বা লক আউট বোধ করতে পারে, তাহলে পরীক্ষাটিতে স্পষ্ট মেসেজিং ও সাবধানে রোলআউট দরকার।
প্ল্যান টেস্ট বদলায় কিভাবে আপনি আপনার অফার প্যাকেজ ও উপস্থাপন করেন: টিয়ার, বান্ডেল, প্ল্যান নাম, এবং প্রতিটি টিয়ারে কি আছে। এখানে আপনি পরীক্ষা করছেন মানুষ কিভাবে অপশনের মধ্যে নির্বাচন করে—না যে একটি নির্দিষ্ট ক্ষমতা মূল্য দেয় কি না।
ফিচার টেস্ট একটি নির্দিষ্ট ক্ষমতার অ্যাক্সেস বদলায়। সেটা হতে পারে একটি ফিচারকে উচ্চতর টিয়ারে গেট করা, একটি ব্যবহার সীমা যোগ করা, পেইড অ্যাড-অন অফার করা, বা কেউ ব্যবহার করলে পেইওয়াল দেখানো—আপনি যাচাই করছেন একটি নির্দিষ্ট মূল্যমানের জন্য মানুষ কি পরিশোধ করতে ইচ্ছুক।
আপনার মূল্য পরীক্ষার লগে কয়েকটা ডিটেইল ধরুন যাতে পরে পরীক্ষা তুলনা করা সহজ হয়:
প্ল্যান ও ফিচার পরিবর্তন একসাথে মেশাবেন না। যদি আপনি একই সময়ে টিয়ার নাম বদলান, ফিচারগুলো স্থানান্তর করেন, এবং নতুন সীমা যোগ করেন, ফলাফল পড়তে কঠিন হবে। আপগ্রেড বৃদ্ধির কারণ হতে পারে প্যাকেজিং, বা হতে পারে সীমা চাপ।
দ্রুত উদাহরণ: “Exports” Basic থেকে Pro-তে সরানো একটি ফিচার টেস্ট। “Basic” কে “Starter” নামকরণ করা এবং তৃতীয় একটি টিয়ার যোগ করা একটি প্ল্যান টেস্ট। আলাদা চালান (অথবা কমপক্ষে আলাদা ভ্যারিয়েন্ট হিসেবে লগ করুন) যাতে আপনি যা কাজ করেছে তা পুনরায় ব্যবহার করতে পারেন বেনজয় অনাবশ্যক রুচি ছাড়াই।
একটি মূল্য পরীক্ষার লগ তখনই পুনঃব্যবহারযোগ্য হয় যখন অনুমান স্পষ্ট এবং মেট্রিকগুলি ধারাবাহিক। যদি এন্ট্রি অস্পষ্ট আশা ভরে থাকে, পরের ব্যক্তি সেটিকে নতুন পরীক্ষার সাথে তুলনা করতে পারবে না।
অভিসন্ধি লিখুন কারণ ও প্রভাব হিসেবে। একটি বাক্যে পরিবর্তনকে আচরণ পরিবর্তনের সাথে এবং তা থেকে পরিমাপযোগ্য ফলাফলের সাথে যুক্ত করুন। উদাহরণ: “যদি আমরা ফিচার X কে Pro থেকে Business-এ সরাই, বেশি দল Business বেছে নেবে কারণ তারা রোলআউটে X প্রয়োজন, ফলে Business আপগ্রেড বাড়বে কিন্তু রিফান্ড বাড়বে না।”
পরিবর্তনের পেছনের কারণ সাধারণ ভাষায় যোগ করুন। “কারণ ব্যবহারকারীরা সপ্তাহ একে সীমায় পৌঁছায়” লেখা বেশি উপকারী “মনিটাইজেশন উন্নত করা” এর থেকে। কারণগুলো আপনাকে প্ল্যান ও ফিচার পরীক্ষাগুলোর মধ্যে প্যাটার্ন চিহ্নিত করতে সাহায্য করে।
মেট্রিকগুলির জন্য একটি প্রধান সাফল্য মেট্রিক বেছে নিন যা প্রশ্ন করে, “এটা কাজ করেছে কি?” তারপর ১–২টি গার্ডরেইল যোগ করুন যাতে আপনি মেট্রিক জিতে দীর্ঘমেয়াদে ব্যবসাকে ক্ষতি না করেন।
একটি সাধারণ সেটআপ যা পরীক্ষাগুলো মধ্যে তুলনা সহজ রাখে:
প্রসঙ্গে সিদ্ধান্তের নিয়ম আগে থেকে ঠিক করুন। নির্দিষ্ট থ্রেশহোল্ড লিখুন যে অনুযায়ী শিপ, রোলব্যাক, বা রিটেস্ট করবেন। উদাহরণ: “শিপ করুন যদি আপগ্রেড 8%+ বাড়ে এবং রিফান্ড 1 শতাংশ পয়েন্টের বেশি না বাড়ে। ফলাফল মিলিত হলে রিটেস্ট করুন। চর্ন বাড়লে রোলব্যাক করুন।”
আপনি যদি লগকে একটি ছোট অভ্যন্তরীণ টুল হিসেবে তৈরি করেন, এই ফিল্ডগুলো বাধ্যতামূলক করে দিলে এন্ট্রিগুলো পরিষ্কার ও তুলনাযোগ্য থাকবে।
একটি মূল্য পরীক্ষার লগ কেবল তখনই কার্যকর যখন পরে আপনি যে বিবরণ দেখতে পাবেন তা বিশ্বাসযোগ্য। নতুন কেও পরীক্ষাটি দুই মিনিটে বুঝে ফেলতে পারা উচিত, পুরনো চ্যাট খুঁজতে না গিয়ে।
পরিচয় ও টাইমলাইন দিয়ে শুরু করুন যাতে একাধিক পরীক্ষা গড়মিল না হয়:
তারপর পর্যাপ্ত সেটআপ বিবরণ ধরুন যাতে পরে ফলাফল তুলনা করা যায়। নোট করুন কে পরীক্ষাটি দেখেছে (নতুন বনাম বিদ্যমান ব্যবহারকারী), কোথায় দেখেছে (প্রাইসিং পেজ, চেকআউট, ইন-অ্যাপ প্রম্পট), এবং ট্রাফিক কিভাবে ভাগ হয়েছিল। ডিভাইস ও প্ল্যাটফর্ম উল্লেখ করুন যদি তা আচরণ প্রভাবিত করতে পারে (মোবাইল ওয়েব বনাম ডেস্কটপ, iOS বনাম Android)।
ভ্যারিয়েন্টগুলোর জন্য কন্ট্রোল ও প্রতিটি ভ্যারিয়েন্ট সাধারণ ভাষায় লিখুন। বদলগুলো সম্পর্কে স্পষ্ট থাকুন: প্ল্যান নাম, অন্তর্ভুক্ত ফিচার, সীমা, মূল্যবিন্দু, বিলিং পিরিয়ড, এবং পাতায় যেকোনো লেখা। ভিজ্যুয়াল গুরুত্বপূর্ণ হলে, যা স্ক্রিনশট দেখাবে তা বর্ণনা করুন (উদাহরণ: “ভ্যারিয়েন্ট B বার্ষিক টগল প্ল্যান কার্ডের উপরে সরিয়ে নিল এবং বাটন টেক্সট ‘Start free trial’ changed”).
ফলাফলগুলো কেবল বিজয়ী লেবেল নয়। সংখ্যাগুলো, সময়সীমা, এবং আপনার ধারণা সংরক্ষণ করুন:
অবশেষে, আশ্চর্যের ব্যাখ্যা দেয় এমন প্রসঙ্গ যোগ করুন: নিকটস্থ রিলিজ, সিজনালিটি (ছুটির দিন, কোয়ার্টারের শেষ), মার্কেটিং ক্যাম্পেইন, এবং সাপোর্ট ইনসিডেন্ট। সপ্তাহ দুইয়ে চেকআউট আউটেজ একটি “খারাপ” ভ্যারিয়েন্টকে প্রকৃতপক্ষে খারাপ দেখাতে পারে।
একটি লগ তখনই সময় বাঁচায় যখন মানুষ সঠিক এন্ট্রি খুঁজে পায়। কেউই “Test #12” মনে রাখবে না; তারা স্ক্রিন, পরিবর্তন, এবং কে প্রভাবিত হয়েছিল মনে রাখবে।
একটি নামকরণ প্যাটার্ন ব্যবহার করুন যা দল জুড়েই একই থাকবে:
উদাহরণ নাম:
তারপর কয়েকটি ট্যাগ যোগ করুন যাতে ফিল্টার করা দ্রুত হয়। ট্যাগগুলো ছোট ও পূর্বানুমোদিত রাখুন—সৃজনশীল শব্দচয়ন না করাই ভালো।
একটি ব্যবহারিক স্টার্টার সেট:
প্রতিটি এন্ট্রির মালিক নির্ধারণ করুন। একজন “ওনর” থাকা উচিত যার দায়িত্ব এন্ট্রি আপডেট রাখা এবং পরে প্রশ্নের উত্তর দেয়া। এন্ট্রি-তে ডেটা কোথায় আছে এবং পরীক্ষা পুনরায় চালানো নিরাপদ কি না তাও উল্লেখ করুন।
একটি জায়গা বেছে নিন আপনার মূল্য পরীক্ষার লগের জন্য। শুরু দলের জন্য একটি শেয়ারড স্প্রেডশীট কাজ করে। যদি আপনার কাছে ইতিমধ্যেই একটি ডাটাবেস বা অভ্যন্তরীণ অ্যাডমিন থাকে, সেটাই ব্যবহার করুন। মূল কথা হলো সকলের সহজে পাওয়া একটিই উৎস।
এক পৃষ্ঠার টেমপ্লেট তৈরি করুন যেখানে কেবল সেই ফিল্ডগুলো আছে যা ভবিষ্যতে সিদ্ধান্ত নেওয়ার জন্য সত্যিই জরুরি। ফর্ম হোমওয়ার্ক মনে হলে লোকেরা এড়িয়ে যাবে।
একটি সেটআপ যা ধরে থাকে:
নিয়মগুলো বাস্তবায়নযোগ্য করুন। উদাহরণ: “কোনও পরীক্ষার রিলিজ টিকিট নেই যতক্ষণ না একটি লগ এন্ট্রি আইডি আছে।” এই অভ্যাস শুরু তারিখ গায়েব হওয়া, অস্পষ্ট ভ্যারিয়েন্ট, এবং “আমরা মনে করি আমরা সেটা টেস্ট করেছি” ধরনের বিতর্ক আটকাবে।
একটি মূল্য পরীক্ষা সহজে শেখার যোগ্য হয় যখন আপনার নোট বাস্তবতার সাথে মিলে। মূল হলো ছোট পরিবর্তনগুলো ঘটার সঙ্গে সঙ্গে ধরে রাখা, কিন্তু লগকে দ্বিতীয় চাকরিতে না পরিণত করা।
নিখুঁত টাইমস্ট্যাম্প দিয়ে শুরু করুন। শুরু ও বন্ধের সময় (টাইমজোনসহ) লিখুন, শুধু তারিখ নয়। পরে আপনি ফলাফল তুলনা করলে বিজ্ঞাপন ব্যয়, ইমেইল পাঠানো, বা রিলিজের সাথে মিলাতে চাইলে “মঙ্গলবার সকাল” যথেষ্ট স্পষ্ট হবে না।
কোনো কিছুকে সংরক্ষণ করুন যা ফলাফল প্রভাবিত করতে পারে—সংক্ষিপ্ত চেঞ্জ ডাইরি রাখুন। মূল্য পরীক্ষাগুলো সাধারণত নিখুঁত স্থির প্রোডাক্ট পরিবেশে রান করে না। কপি পরিবর্তন, বাগ ফিক্স (বিশেষ করে চেকআউট বা ট্রায়াল ফ্লো), টার্গেটিং আপডেট (জিও, সেগমেন্ট, ট্রাফিক মিক্স), এলিজিবিলিটি রুলস, এবং সেলস/সাপোর্ট প্রসেস পরিবর্তনগুলো ট্র্যাক করুন।
অস্বাভাবিকতাও নোট করুন যা সংখ্যাকে বিকৃত করতে পারে। আউটেজ, পেমেন্ট প্রোভাইডারের সমস্যা, বা অস্বাভাবিক ট্রাফিক সোর্সের স্পাইক কনভার্সন ও রিফান্ডকে পরিবর্তন করতে পারে। কি ঘটেছিল, কখন, কতক্ষণ, এবং আপনি বিশ্লেষণ থেকে ঐ সময় বাদ দিয়েছেন কি না তা লিখে রাখুন।
গ্রাহক ফিডব্যাকও ডেটার অংশ। “Top 3 ticket themes” বা “সবচেয়ে প্রচলিত সেলস আপত্তি” মতো দ্রুত নোট যোগ করুন যাতে পরে পাঠকরা বুঝতে পারে চার্টের বাইরে কেন একটি ভ্যারিয়েন্ট কাজ করেছে বা ব্যর্থ হয়েছে।
নিশ্চিত করুন কে একটি টেস্ট আগেই বন্ধ করতে পারে এবং সেটা কিভাবে রেকর্ড হবে। এক নামকে দায়বদ্ধ করুন (সাধারণত এক্সপেরিমেন্ট ওনার), অনুমোদিত কারণ তালিকাভুক্ত করুন (সেফটি, লিগ্যাল, বড় রাজস্ব পতন, ভাঙা চেকআউট), এবং স্টপ সিদ্ধান্তটি সময়, কারণ, এবং অনুমোদনসহ রেকর্ড করুন।
অনেক মূল্য পরীক্ষার সমাপ্তি পরিষ্কার বিজয় নিয়ে হয় না। আগে থেকেই সিদ্ধান্ত নিন মিশ্র ফলাফল হলে কি করবেন যাতে ডেটা দেখার পরে নিয়ম নতুন করে বানাতে না হয় (শিপ, রোলব্যাক, বা ইটারেট)।
রিলিজের আগে নির্ধারিত সিদ্ধান্তের নিয়মের সঙ্গে ফলাফল তুলুন—নতুন কোনো নিয়ম এখানে বানাবেন না। যদি আপনার নিয়ম ছিল “ট্রায়াল-টু-পেইড 8% বাড়লে এবং অ্যাক্টিভেশন 2% থেকে বেশি না কমলে শিপ,” তাহলে ঐ সংখ্যাগুলো নিয়মের পাশে লিখে পাস বা ফেল চিহ্ন দিন।
সেগমেন্টগুলো সাবধানে তুলনা করুন এবং আপনি কেন ঐ কাটগুলি নিয়েছেন তা লিখে রাখুন। একটি মূল্য পরিবর্তন নতুন গ্রাহকদের সহায়ক কিন্তু নবায়নে ক্ষতিকর হতে পারে। ছোট টিমদের জন্য কাজ করে বড় অ্যাকাউন্টগুলোতে ব্যর্থ হতে পারে। সাধারণ সেগমেন্ট: নতুন বনাম রিটার্নিং, ছোট বনাম বড় গ্রাহক, self-serve বনাম sales-assisted, এবং অঞ্চল বা মুদ্রা।
এন্ট্রিটিকে একটি সংক্ষিপ্ত উপসংহারে বন্ধ করুন যা দ্রুত পড়ে বোঝা যায়: কী কাজ করেছে, কী হয়নি, এবং পরবর্তী কি পরীক্ষা। উদাহরণ: “বার্ষিক প্ল্যান অ্যাঙ্কর নতুন গ্রাহকদের জন্য আপগ্রেড বাড়িয়েছে, কিন্তু রিটার্নিং গ্রাহকদের মধ্যে রিফান্ড বাড়িয়েছে। পরবর্তী পরীক্ষা: অ্যাঙ্কর রাখবো, কিন্তু নবায়নের জন্য বাতিলকরণ বার্তা স্পষ্ট করবো।”
একটি পুনঃব্যবহারযোগ্য টেকঅওয়ে বাক্য যোগ করুন। উদাহরণ: “বার্ষিক দাম দিয়ে অ্যাঙ্করিং একুইজিশনে সাহায্য করে, কিন্তু তখনই যখন ইন-অ্যাপ ভ্যালু প্রুফ দামের আগে দেখানো হয়।”
একটি লগ তখনই সাহায্য করে যখন পরে এটি একটি মৌলিক প্রশ্নের উত্তর দিতে পারে: “আমরা কি চেষ্টা করেছি, আর কি করে আবার করব?” বেশিরভাগ শেখার ব্যর্থতা জটিল বিশ্লেষণে নয়, মৌলিক তথ্য গায়েব হওয়ায় ঘটে।
সর্বাধিক সাধারণ ভুলগুলো:
সরল উদাহরণ: একটি দল 10% দাম বাড়ায়, সপ্তাহ একে কনভার্সন ডিপ দেখে এবং বন্ধ করে দেয়। ছয় মাস পরে কেউ একই বাড়তি করার প্রস্তাব দেয় কারণ পুরনো এন্ট্রিটা কেবল লিখেছে “দাম বৃদ্ধি ব্যর্থ।” যদি লগে লেখা থাকতো “চেকআউট পেজ বাগ ও Black Friday ছাড়ের কারণে দ্রুত বন্ধ করা হয়েছিল,” তো দল আবার একই ভুল সেটআপ পুনরাবৃত্তি করত না।
আপনার মূল্য লগকে ল্যাব নোটের মতো আচরণ করুন: আপনি কি বদলিয়েছিলেন, আপনি কী আশা করেছিলেন, আপনি কী মাপলেন, এবং তখন কি চলছে—এসব লিখে রাখুন।
একটি মূল্য পরীক্ষার লগ কার্যকর হবে যদি এটি দ্রুত পূরণ করা যায় এবং ধারাবাহিক থাকে।
লঞ্চের আগে নিশ্চিত করুন এন্ট্রি আছে, অনুমান একটি বাক্যে, সাফল্য মেট্রিক ও ডেটা সোর্স স্পষ্ট, ভ্যারিয়েন্টগুলো সাধারণ ভাষায় বর্ণিত (কে কি দেখে, এবং কোথায়), এবং শুরু তারিখ/সময়/টাইমজোন রেকর্ড আছে। নতুন পরীক্ষা পরিকল্পনা করলে কিকঅফে “3টি সম্পর্কিত পুরনো এন্ট্রি পড়ুন” অন্তর্ভুক্ত করুন—এটা পুনরাবৃত্ত কাজ বন্ধ করে এবং সফল ভ্যারিয়েন্টগুলো পুনরায় কাজে লাগাতে সাহায্য করে।
স্টপ করার পরে স্টপ তারিখ/সময় ও কারণ রেকর্ড করুন, সংখ্যাসহ ফলাফল লেখুন (ভাবনা নয়), সিদ্ধান্ত জানান (ship, roll back, rerun, park), মূল শেখা এক বাক্যে লিখুন, এবং নির্দিষ্ট ব্যক্তিকে ফলো-আপ নম্বর ও ডিউ ডেট দিন।
নিচে একটি মিনি টেমপ্লেট রয়েছে যাকে আপনি ডক, স্প্রেডশীট, Notion পেজ, বা অভ্যন্তরীণ টুলে কপি করতে পারবেন (কিছু দল দ্রুত AppMaster-এ এটিকে একটি নো-কোড প্ল্যাটফর্মে তৈরি করে)।
Experiment name:
Owner:
Date created:
Status: planned / running / stopped
Hypothesis (one sentence):
Type: plan test / feature test
Audience + location (where shown):
Variants (A, B, C):
Start (date/time/timezone):
Stop (date/time/timezone) + reason:
Primary metric(s):
Guardrail metric(s):
Data source:
Results (numbers + notes):
Decision:
Key learning (one sentence):
Follow-up action + owner + due date:
Tags:
একটি SaaS দল যা একটি হেলপডেস্ক প্রোডাক্ট বিক্রি করে গত কোয়ার্টারে Pro প্ল্যান টেস্ট চালায়। তারা সেটা তাদের প্রাইসিং এক্সপেরিমেন্ট লগে অনুমান, সঠিক পেইওয়াল কপি, তারিখ, ও ফলাফলসহ সংরক্ষণ করে।
Test A (May 6 to May 27):
ওরা Pro-কে $49 থেকে $59 per seat করে এবং লাইনে যোগ করে: “Best for growing teams that need advanced automations.” দর্শক ছিল সব নতুন ওয়েবসাইট ভিজিটর।
ফলাফল স্পষ্ট: ট্রায়াল স্টার্ট একই ছিল, কিন্তু পেইড কনভার্সন 6.2% থেকে 4.9% এ নেমে আসে, এবং সাপোর্ট চ্যাটে “price increase” নিয়ে দ্বিগুণ প্রশ্ন ছিল। সিদ্ধান্ত: $49-এ রোল ব্যাক।
দুই মাস পরে Product আবার Pro দাম বাড়াতে চায়। লগ না থাকলে কেউ হয়তো একই কাজটি পুনরায় করত। কিন্তু দল তাদের পুরনো এন্ট্রিগুলো দেখলে দেখল যে পতনটা ছোট টিম গুলোতে কেন্দ্রীভূত ছিল।
তাই তারা সফল কৌশলটি ভিন্ন সেগমেন্টে পুনরায় ব্যবহার করে।
Test B (Aug 12 to Sep 2):
ওরা self-serve সাইনআপের জন্য $49 রাখে, কিন্তু যারা প্রাইসিং ক্যালকুলেটরে “10+ seats” চয়ন করে তাদেরকে কেবল $59 দেখায়। কপি বদলে হয়: “Pro for teams of 10+ seats. Includes onboarding and priority support.”
এইবার, 10+ সেগমেন্টের পেইড কনভার্সন ঠিক থাকে (5.8% থেকে 5.9%), এবং রেভিনিউ পার একাউন্ট 14% বাড়ে। দল সেগমেন্টেড প্রাইস রুল শিপ করে এবং ছোট টিমদের জন্য নিম্ন এন্ট্রি মূল্য রাখে।
পুনঃব্যবহারযোগ্য টেকঅওয়ে: কেবল লিখে রাখবেন “দাম বাড়ল/নামল” নয়—লিখুন কে দেখেছিল, সঠিক ওয়ার্ডিং কি ছিল, এবং কোথায় প্রভাব দেখা গেছে, যাতে পরের পরীক্ষা শুরুতেই স্মার্ট হয়, পুনরায় শুরু না করে।
একটি মূল্য পরীক্ষার লগ সবচেয়ে ভালো কাজ করে যখন এটা আর “কেউ যে ডক আপডেট করে” না হয়ে একটি ছোট অভ্যন্তরীণ টুলে পরিণত হয় যার একটি পরিষ্কার ওয়ার্কফ্লো আছে। এভাবেই এন্ট্রিগুলো সম্পূর্ণ, ধারাবাহিক, এবং সহজে বিশ্বাসযোগ্য থাকে।
একটি ফর্ম-ভিত্তিক সেটআপ সহায়ক। এটি লোকদের মৌলিকগুলো (অনুমান, ভ্যারিয়েন্ট, শুরু/স্টপ তারিখ) যোগ করতে উস্কে দেয় এবং খালি ফিল্ড কমায়। একটি হালকা ওজনের অনুমোদন ধারা কাউকে পরীক্ষা লাইভ হওয়ার আগে স্যানিটি-চেক করতে সাহায্য করে।
সাধারণত কয়েকটি ভিউ যথেষ্ট: স্ট্যাটাস অনুযায়ী (ড্রাফট, চলমান, শেষ), প্ল্যান বা অ্যাড-অন অনুযায়ী, সারফেস (pricing page, checkout, in-app) অনুযায়ী, এবং মালিক অনুযায়ী।
যদি আপনি এভাবে তৈরি করতে চান ইঞ্জিনিয়ারিং অপেক্ষা না করেই, AppMaster (appmaster.io) একটি অপশন। এটি একটি নো-কোড প্ল্যাটফর্ম যা প্রোডাকশন-রেডি অভ্যন্তরীণ টুল তৈরি করতে দেয়, PostgreSQL ডাটা মডেল, ওয়েব UI ফর্ম ও ফিল্টার করা ভিউ, এবং বাধ্যতামূলক ফিল্ড যাতে পরীক্ষাগুলো অর্ধেক-সম্পন্ন না saved হয়।
What is a pricing experiment log?একটি মূল্য পরীক্ষার লগ হচ্ছে প্রতিটি মূল্য-সংক্রান্ত পরিবর্তনের একটি শেয়ার্ড রেকর্ড — অনুমান, কি বদল হয়েছে, কে দেখেছে, কখন চলেছে, কী মাপা হয়েছিল, এবং ফলাফল কী ছিল। এটি দলকে স্লাইড, চ্যাট এবং স্ক্রীনশটের ভেতর হারিয়ে যাওয়া তথ্যের কারণে একই পরীক্ষা পুনরায় করার হাত থেকে রক্ষা করে।
Why do pricing tests get repeated or misremembered so often?মনে রাখার ভুল ও পর্যাপ্ত রেকর্ড না থাকা মিলিয়ে পরীক্ষাগুলো বারবার করা বা ভুলভাবে মনে রাখার প্রধান কারণ। যদি একখানা জায়গায় খুঁটিনাটি ভ্যারিয়েন্ট ও সময় সংরক্ষণ না থাকে, আপনি পুরনো পরীক্ষা পুনরায় চালাবেন বা অর্ধেক তথ্যের ওপর ভিত্তি করে সিদ্ধান্ত নেবেন।
What changes should be logged as a pricing test?যে কোনো কন্ট্রোলড পরিবর্তন যা মানুষের কত দিচ্ছে, কোন প্ল্যান বেছে নিচ্ছে, বা কখন আপগ্রেড করে—এসব প্রভাব ফেলতে পারে—সেগুলো লগ করা উচিত। এর মধ্যে আছে মূল্যবিন্দু, ছাড়, ট্রায়াল, প্যাকেজিং, ফিচার গেট, ব্যবহার সীমা, অ্যাড-অন এবং আপগ্রেড প্রম্পট।
What doesn’t count as a pricing experiment?যদি পরিবর্তনটি গ্রাহকের কি পরিশোধ করে বা প্ল্যানে কি পাওয়া যায় তা না বদলে, সাধারণত সেটা মূল্য পরীক্ষা নয়। চেকআউট বাগ ঠিক করা বা পেজের টাইপো straightening করা অনেক সময় প্রোডাক্ট/মার্কেটিং কাজ — কেবল তখনই এটি প্রাইসিং লগে আসে যদি তা মূল্যযোগ্যতা বা প্ল্যান সামগ্রীর যোগ্যতাকে বদলে দেয়।
How do I tell a plan test from a feature test?প্ল্যান টেস্ট বোঝায় কিভাবে আপনি অফার সাজান ও উপস্থাপন করেন: টিয়ার, বান্ডেল, প্ল্যান নাম, এবং প্রতিটি টিয়ারে কি আছে। ফিচার টেস্ট হচ্ছে কোনো বিশেষ ক্ষমতায় অ্যাক্সেস বদলানো—একটি ফিচারকে উচ্চতর টিয়ারে রাখা, ব্যবহার সীমা যোগ করা, পেইওয়াল দেখানো ইত্যাদি।
How do I write a useful hypothesis for a pricing experiment?একটি বাক্যে লিখুন কিভাবে পরিবর্তন আচরণ বদলাবে এবং সেটা কী পরিমাপযোগ্য ফলাফল দিবে। উদাহরণ: “যদি আমরা ফিচার X কে Pro থেকে Business-এ সরাই, বেশি দল Business বেছে নেবে কারণ তাদের শুরুতেই X দরকার, ফলে Business আপগ্রেড বাড়বে এবং রিফান্ড বাড়বে না।”
What metrics should we track for pricing experiments?একটি প্রধান মেট্রিক বেছে নিন যা ‘এটা কাজ করেছে কি না’ বলে—উদাহরণ: পেইড কনভার্সন, আপগ্রেড রেট, বা রেভিনিউ পার ভিজিটর। তার সাথে ১–২টি গার্ডরেইল রাখুন যেন আপনি মেট্রিক জিতেই ব্যবসাকে ক্ষতি না করেন—চর্ন, রিফান্ড, সাপোর্ট টিকিট ইত্যাদি।
What fields are essential in each log entry?সর্বনিম্ন: টেস্ট নাম, মালিক, স্ট্যাটাস, শুরু ও বন্ধের সময়, দর্শক ও কোথায় দেখানো হলো, ট্রাফিক স্প্লিট, কন্ট্রোল ও প্রতিটি ভ্যারিয়েন্টের স্পষ্ট বর্ণনা, প্রধান ও গার্ডরেইল মেট্রিকগুলো সংখ্যাসহ, সিদ্ধান্ত, এবং সংক্ষিপ্ত টেকঅওয়ে। প্রসঙ্গ হিসেবে প্রচার, আউটেজ, সিজনালিটি ইত্যাদি লিখে রাখুন।
How do we make the log easy to search and maintain?একটি একরকম নামকরণ প্যাটার্ন ব্যবহার করুন যাতে মানুষ সহজে মিলে খুঁজে পায়—স্ক্রিন, পরিবর্তন, এবং কে প্রভাবিত হলো তা নিয়ে। ছোট ও পূর্বনির্ধারিত ট্যাগ সেট রাখুন (টাইপ, রিজিওন, সারফেস) এবং প্রতিটি এন্ট্রির জন্য একজন মালিক রাখুন যিনি দায়বদ্ধ থাকবেন।
Can we run the log as a simple internal tool instead of a document?হ্যাঁ—যদি আপনি এটাকে হালকা রাখেন এবং কিছু অভ্যাস জোরদার করেন। এক অনুশীলন হচ্ছে: লঞ্চের আগে এন্ট্রি বাধ্যতামূলক করা এবং স্টপের ৪৮ ঘণ্টার মধ্যে ফলাফল আপডেট বাধ্যত করা; এরপর একটি ফর্ম-ভিত্তিক ইন্টারনাল টুল ব্যবহার করুন যাতে গুরুত্বপূর্ণ ফিল্ড খালি না থাকে; অনেক দল AppMaster-এ (appmaster.io) একটা ছোট ইন্টারনাল অ্যাপ বানায় যাতে ধারাবাহিকতা থাকে।
১০ মার্চ, ২০২৬
10 মিনিট
০৮ মার্চ, ২০২৬11 মিনিট
০৭ মার্চ, ২০২৬8 মিনিটবিনামূল্যের পরিকল্পনা সহ অ্যাপমাস্টারের সাথে পরীক্ষা করুন।
আপনি যখন প্রস্তুত হবেন তখন আপনি সঠিক সদস্যতা বেছে নিতে পারেন৷
