একটি পণ্যের মালিক হিসাবে, বিকল্প A বা বিকল্প B নিয়ে এগিয়ে যেতে হবে কিনা এমন প্রশ্নের মুখোমুখি হওয়া সাধারণ। এই ধরনের সিদ্ধান্ত নেওয়া চ্যালেঞ্জিং হতে পারে, বিশেষ করে যখন আপনি সীমিত সংস্থান সহ কঠোর সময়সীমার অধীনে থাকেন। তদুপরি, এই জাতীয় সিদ্ধান্তগুলি ব্যক্তিগত রায় বা প্রতিযোগীর পদ্ধতির অনুলিপি করার উপর ভিত্তি করে নেওয়া হয়, যা সাবঅপ্টিমাল ফলাফলের দিকে নিয়ে যেতে পারে।
ভাল খবর হল যে কেউ একটি সাধারণ পরীক্ষার পরিবেশ স্থাপন করে এই ধরনের সমস্যাগুলি এড়াতে পারে যার জন্য অপেক্ষাকৃত কম প্রচেষ্টা প্রয়োজন। এই নিবন্ধে, আমরা বর্ণনা করব কিভাবে আপনি এটি অর্জন করতে পারেন।
একটি পরীক্ষার পরিবেশ সেট আপ করা দুটি কারণে গুরুত্বপূর্ণ:
প্রথমত, এটি আপনাকে নিশ্চিত করতে দেয় যে আপনি একবার নতুন কার্যকারিতা প্রয়োগ করলে, আপনি ডেটা-চালিত পদ্ধতির উপর ভিত্তি করে সেরা বিকল্পটি বেছে নিন।
দ্বিতীয়ত, এটি আপনাকে অনুমানমূলক 'যথা-থাকতে' বিকল্পগুলির সাথে তুলনা করে এবং 'যদি হলে' বিশ্লেষণ করে আপনার পণ্যের বিদ্যমান কার্যকারিতা ক্রমাগত উন্নত করতে দেয়।
আমরা পদ্ধতিতে এগিয়ে যাওয়ার আগে, আসুন আমরা কিছু পৌরাণিক কাহিনী উড়িয়ে দেই যা সাধারণত পণ্যের মালিকদের বিভ্রান্ত করে:
একটি জটিল পরিবেশ সেট আপ করার জন্য আমার প্রচুর সংস্থান দরকার যা পরীক্ষা এবং A/B পরীক্ষা করার অনুমতি দেয়
ভুল : বর্ণিত পদ্ধতিতে আপনার সফ্টওয়্যার ইঞ্জিনিয়ারের সংস্থানগুলির এক সপ্তাহেরও কম সময় লাগে৷
আমার একটি সু-প্রতিষ্ঠিত তথ্য সংগ্রহ প্রক্রিয়া এবং বিস্তারিত ইভেন্ট ট্র্যাকিং প্রয়োজন
ভুল : আপনি একটি বিদ্যমান ডাটাবেসের উপর নির্ভর করতে পারেন যা আপনার পণ্যের প্রধান সত্তার জীবনচক্র সম্পর্কে তথ্য সঞ্চয় করে। উদাহরণস্বরূপ, আপনি একটি ডেলিভারি পরিষেবা হলে স্ট্যাটাস অর্ডার করুন।
আমার বিশ্লেষকদের একটি নিবেদিত দল দরকার যারা প্রতিদিনের ভিত্তিতে আমার অনুরোধগুলি পরিচালনা করবে
ভুল : একবার আপনি আপনার পরীক্ষার পদ্ধতি এবং মেট্রিক্স বুঝতে পারলে, আপনি একটি সাধারণ SQL ক্যোয়ারী ব্যবহার করে নিয়মিতভাবে ডেটা টানতে পারেন।
আপনার পরীক্ষার পরিবেশ সেট আপ করতে, একজনকে এই পদক্ষেপগুলি অনুসরণ করার পরামর্শ দেওয়া হচ্ছে:
আপনি আপনার পণ্য ডিজাইনারের সাথে যোগাযোগ করার আগে, আপনার পরীক্ষার অংশ হিসাবে পরিমাপ করা লক্ষ্য এবং মেট্রিক্স সংজ্ঞায়িত করুন। একটি ক্লাসিক 'বিকল্প A বা বিকল্প B' প্রশ্নের ক্ষেত্রে, আপনি একটি পরিবর্তন বাস্তবায়নের মাধ্যমে কী অর্জন করতে চান তা সাধারণত সোজা। উদাহরণস্বরূপ, আপনি ফানেলের একটি নির্দিষ্ট অংশকে সম্বোধন করতে পারেন।
দৃষ্টান্তমূলক উদ্দেশ্যে ধরা যাক আপনি একটি ডেলিভারি কোম্পানিতে কাজ করছেন এবং বর্তমানে অর্ডার তৈরির ফর্মের উপর দৃষ্টি নিবদ্ধ করছেন। আপনি তুলনামূলকভাবে কম শতাংশ ব্যবহারকারীদের সম্বোধন করতে চান যারা তাদের শিপিং ঠিকানা প্রদান করে এবং তারপর একটি শিপিং পদ্ধতি নির্বাচন করে। এছাড়াও, কল্পনা করুন আপনার যাত্রার দুটি নতুন সংস্করণ রয়েছে:
বর্তমান সংস্করণ : একটি স্ক্রিনে ঠিকানা ইনপুট করা এবং প্রদত্ত ঠিকানার উপর ভিত্তি করে একটি পিন সহ মানচিত্র দেখানো প্রয়োজন। পরবর্তী স্ক্রীন প্রদত্ত ঠিকানার উপর ভিত্তি করে একটি শিপিং পদ্ধতি নির্বাচন করার অনুমতি দেয়।
নতুন সংস্করণ : একক পর্দার জন্য ঠিকানা ইনপুট করতে হবে এবং সেখানে শিপিং পদ্ধতি নির্বাচন করতে হবে।
লক্ষ্য হল কোন বিকল্পগুলি তাদের ঠিকানা প্রদান করে এবং একটি শিপিং পদ্ধতি বেছে নেওয়া ব্যবহারকারীদের বেশি ভাগের দিকে নিয়ে যায় তা নির্ধারণ করা। মেট্রিক্স বরং সহজবোধ্য: ব্যবহারকারীদের % যারা তাদের ঠিকানা প্রদান করেছে এবং একটি শিপিং পদ্ধতি নির্বাচন করেছে৷
আসলে, এই ধরনের তথ্য পরিমাপ করার 2 টি উপায় আছে :
আপনার ব্যাকএন্ডের ডিজাইন দ্বারা ইতিমধ্যে উপলব্ধ ডেটার উপর ভিত্তি করে। উদাহরণস্বরূপ, একটি ডাটাবেস বিবেচনা করুন যাতে অর্ডারের জীবনচক্রের তথ্য রয়েছে। আপনার অর্ডারের স্টেট বা স্ট্যাটাস থাকতে পারে যেমন:
খসড়া তৈরি করা হয়েছে
শিপিং পদ্ধতি খুঁজে বের করার চেষ্টা
শিপিং বিকল্প পাওয়া গেছে/ শিপিং বিকল্প পাওয়া যায়নি
ইভেন্ট ট্র্যাকিং - এটি এমন কিছু নয় যা বাক্সের বাইরে কাজ করবে এবং তাই বাস্তবায়নের জন্য অতিরিক্ত প্রচেষ্টার প্রয়োজন৷ যাইহোক, ইভেন্ট ট্র্যাকিং আপনার জন্য আরও দানাদার বিশ্লেষণ সক্ষম করবে, যেমন ডিভাইসের ধরন এবং ব্রাউজারের নাম আপনার ইভেন্টের প্যারামিটার হিসাবে পাস করা যেতে পারে।
এই নিবন্ধের পরবর্তী বিভাগগুলিতে, আমরা ইভেন্ট ট্র্যাকিং ছাড়াই প্রথম পদ্ধতির, অর্থাৎ বিদ্যমান ডেটা আর্কিটেকচারের উপর দৃষ্টি নিবদ্ধ করব।
পরীক্ষার প্রবাহের মধ্যে 2টি প্রধান ধাপ সম্পন্ন করা উচিত:
ধারণাটি হল একটি হালকা ওজনের A/B টেস্টিং ফ্রেমওয়ার্ক নিয়ে আসা যা যতটা সম্ভব সহজ হওয়া উচিত এবং আপনাকে নিম্নলিখিত পরামিতিগুলির সাথে পরীক্ষাগুলি তৈরি করার অনুমতি দেওয়া উচিত:
এই পরামিতিগুলি কনফিগার করতে সক্ষম হওয়া আপনাকে একটি নমুনা সীমা সেট করতে এবং পছন্দসই নমুনার আকারে না পৌঁছানো পর্যন্ত এলোমেলোভাবে পরীক্ষার জন্য প্রার্থীদের বেছে নিতে দেয়।
ক্লায়েন্ট এবং সার্ভার উভয়েরই এর জন্য পরিবর্তন প্রয়োজন: সার্ভারের উচিত পরীক্ষা প্রতি প্রার্থীর সংখ্যা ট্র্যাক করা এবং ব্যাকএন্ড সিদ্ধান্ত নেবে যে বর্তমান ব্যবহারকারী একটি পরীক্ষার অংশ হওয়া উচিত কিনা। বর্তমান নমুনা আকার এবং একটি নির্দিষ্ট সম্ভাবনার উপর ভিত্তি করে প্রমাণীকৃত ব্যবহারকারী পরীক্ষার অংশ হওয়া উচিত কিনা তা ব্যাকএন্ড সিদ্ধান্ত নেবে। অধিকন্তু, ব্যাকএন্ড ব্যবহারকারীদের সামঞ্জস্যপূর্ণ অভিজ্ঞতা প্রদান করতে এবং পরীক্ষার ফলাফলগুলি সঠিকভাবে গণনা করতে একটি প্রদত্ত পরীক্ষার অংশ হিসাবে ব্যবহারকারীদের একটি সংগ্রহ বজায় রাখা উচিত।
এইভাবে পরীক্ষার কনফিগারেশনের জন্য শেষ পয়েন্টটি দেখতে কেমন হতে পারে:
পোস্ট /api/your-service/experiment-create
অনুরোধ:
{ experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}
প্রতিক্রিয়া:
{
200,
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
আপনার একটি পৃথক এন্ডপয়েন্টের প্রয়োজন হবে যা পরীক্ষা এবং সংশ্লিষ্ট গোষ্ঠীতে একটি নির্দিষ্ট ব্যবহারকারীকে বরাদ্দ করার জন্য দায়ী হবে। একে experiment-enrollments
বলা যাক।
পুরো পরিবেশটি ডিজাইন করার সময় ব্যবহারকারীর যাত্রা experiment-enrollments
শেষপয়েন্টের কোন পর্যায়ে কল করা উচিত তা আপনার একটি পরিষ্কার বোঝা উচিত। উপরন্তু, এটি এমন হতে পারে যে সমস্ত ব্যবহারকারীর পরীক্ষায় অংশগ্রহণ করা উচিত নয়। এই কারণেই এটি একটি ব্যবহারকারী-প্রমাণপত্রের টোকেনও একটি শেষ পয়েন্টে প্রদান করা উপযোগী হবে।
আমাদের উদাহরণে, যদি আমরা শুধুমাত্র নতুন ব্যবহারকারীদের উপর ফোকাস করতে চাই যারা তাদের প্রথম অর্ডার করছেন, ব্যবহারকারী-প্রমাণকরণ আমাদের নির্ধারণ করতে দেয় যে এটি কোন ধরনের ব্যবহারকারী এবং একজনকে পরীক্ষায় নথিভুক্ত করা উচিত কিনা। এছাড়াও, নিশ্চিত করুন যে একবার এন্ডপয়েন্ট বলা হলে সমস্ত প্রয়োজনীয় তথ্য পাওয়া যায় এবং আপনার যাত্রা এবং জীবনচক্রের সুনির্দিষ্ট বিষয়গুলি বিবেচনা করে।
experiment-enrollments
শেষ বিন্দু নীচে বর্ণনা করা হয়েছে. এটি নির্দিষ্ট ধরণের ব্যবহারকারীদের জন্য যাত্রার একটি নির্দিষ্ট পর্যায়ে (যেমন শিপিং ঠিকানা প্রয়োজন স্ক্রিনে অবতরণের আগে) কল করা যেতে পারে (যেমন শুধুমাত্র নতুন ব্যবহারকারী যারা এখনও ঠিকানা প্রদান করেনি) এবং বর্তমান ব্যবহারকারীর অংশগ্রহণ করা উচিত কিনা তা গণনা করা হবে। একটি প্রদত্ত পরীক্ষায় বা না:
POST /api/your-service/experiment-enrollments
, user-auth টোকেন প্রয়োজন
অনুরোধ:
\ {
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
প্রতিক্রিয়া:
{200, enrolled: true/false, group_name: group_1,}
তাত্ত্বিক ডেটা প্রবাহ কেমন হবে তা বোঝাতে, ডেলিভারি কোম্পানিতে অর্ডার তৈরির প্রবাহের একই উদাহরণ অনুমান করুন। আপনি অর্ডার তৈরির পর্দার 2টি বিকল্পের মধ্যে নির্বাচন করছেন।
নীচের চিত্রে নিম্নলিখিত শেষ পয়েন্টগুলি উল্লেখ করা হয়েছে, যেমন:
/create-order-draft (ধাপ 3)
/ফাইন্ড-শিপিং-পদ্ধতি (ধাপ 16)
/সাবমিট-অর্ডার (ধাপ 20)
দৃষ্টান্তমূলক উদাহরণ সমর্থন করার জন্য প্রদান করা হয় এবং পরীক্ষার পরিবেশের প্রয়োজনীয় অংশ নয়
এছাড়াও, ডাটাবেসগুলির উদাহরণমূলক এবং সরলীকৃত আর্কিটেকচার নীচে সরবরাহ করা হয়েছে।
3টি প্রধান টেবিল রয়েছে:
Experiments set
- এতে আপনার আগে তৈরি করা সমস্ত পরীক্ষা রয়েছে। আপনি যখনই /experiment-create
endpoint কল করেন তখন ডাটাবেস আপডেট হয়।
Experiments database
- এটিতে একটি নির্দিষ্ট ব্যবহারকারীর প্রতিটি তালিকাভুক্তির সাথে সম্পর্কিত সমস্ত রেকর্ড রয়েছে। যখনই আপনি experiment-enrollments
এন্ডপয়েন্টে কল করেন তখন ডাটাবেস আপডেট হয়
Order lifecycle database
- এটি পরীক্ষা-সম্পর্কিত ডেটা কীভাবে সংরক্ষণ করা যায় তার চিত্রিত উদাহরণ সমর্থন করার জন্য সরবরাহ করা হয়েছে। মোদ্দা কথা হল এই টেবিলটি (অথবা আপনার পণ্যের সুনির্দিষ্টতার সাথে মিলে যায় এমন যেকোন সারণি) আপনাকে দেখতে দেবে যে এন্ট্রিটি সফল হয়েছে কিনা (যেমন অর্ডার তৈরি করা) আপনার পরীক্ষামূলক গ্রুপগুলির মধ্যে একটিতে নথিভুক্ত নির্দিষ্ট ব্যবহারকারীর জন্য নয় সেট করেছি। আমাদের উদাহরণে, আমরা শিপিং পদ্ধতির নির্বাচিত স্থিতির উপর নির্ভর করতে পারি যা এই উপসংহারে পৌঁছাতে দেয় যে ব্যবহারকারী সফলভাবে শিপিংয়ের বিশদ প্রদান করেছেন এবং তারপর প্রস্তাবিত শিপিং পদ্ধতিগুলির মধ্যে একটি নির্বাচন করেছেন।
সুবিধা:
অসুবিধা:
কার্য এবং সূচক অনুমান:
একবার আপনি আপনার ব্যাকএন্ড ডিজাইন করে নিলে, আপনার ফ্রন্টএন্ড টিমের সাথে তাদের তথ্য পাওয়ার সর্বোত্তম উপায় এবং প্রবাহের কোন পর্যায়ে সারিবদ্ধ করুন।
মনে রাখবেন এবং প্রধান নির্ভরতা হ্রাস করুন:
একবার আপনার পরীক্ষাটি পর্যাপ্ত সময়ের জন্য চলমান হলে, অর্থপূর্ণ সিদ্ধান্তে পৌঁছাতে ফলাফলগুলি বিশ্লেষণ এবং ব্যাখ্যা করা গুরুত্বপূর্ণ।
আপনি আগে ফোকাস করার সিদ্ধান্ত নিয়েছেন মেট্রিক্সের উপর প্রভাব গণনা করার জন্য আপনার প্রয়োজনীয় ক্ষেত্রগুলির তালিকা নির্ধারণ করুন।
উপরের চিত্রিত উদাহরণ থেকে ডেটা উত্স 2টি টেবিল হবে:
Experiments database
:ইনপুট : পরীক্ষা আইডি আপনি ফলাফল খুঁজছেন
আউটপুট : নির্দিষ্ট পরীক্ষার অংশগ্রহণকারী সমস্ত ব্যবহারকারী আইডির তালিকা, প্রতিটি ব্যবহারকারীকে যে গোষ্ঠীতে নিয়োগ করা হয়েছিল এবং যখন ব্যবহারকারীকে নিয়োগ করা হয়েছিল তখন টাইমস্ট্যাম্প
Order lifecycle database
এই ডেটার উপর ভিত্তি করে আপনি প্রতিটি পরীক্ষা গোষ্ঠীর জন্য % সফলভাবে তৈরি অর্ডার গণনা করতে পারেন।
আপনার ফলাফল বিশ্লেষণ করার সময়, শুধুমাত্র কাঁচা সংখ্যার বাইরে তাকানো গুরুত্বপূর্ণ। আপনি পরিসংখ্যানগত তাত্পর্যও দেখতে চাইবেন তা নিশ্চিত করার জন্য যে আপনার পরীক্ষার গ্রুপগুলির মধ্যে আপনি যে কোনও পার্থক্য লক্ষ্য করেন তা কেবল এলোমেলো সুযোগের কারণে নয়। আমি এই অংশে খুব বেশি ফোকাস করব না কারণ আমি ইতিমধ্যে এই এবং অন্যান্য অনলাইন সংস্থানগুলির সাথে এই বিষয়ের সাথে সম্পর্কিত প্রচুর নিবন্ধ দেখতে পাচ্ছি। যাইহোক, এখানে অত্যধিক জ্ঞানের প্রয়োজন নেই: আমার মতে, 2টি গোষ্ঠীর মধ্যে পার্থক্যের তাত্পর্য পরীক্ষা করার জন্য Z-Test বা T-Test প্রয়োগ করতে সক্ষম হওয়াই যথেষ্ট হবে।
তবুও, একবার আপনি নির্ধারণ করেছেন যে আপনার ফলাফলগুলি পরিসংখ্যানগতভাবে তাৎপর্যপূর্ণ, আপনি আপনার পণ্যের কোন বিকল্পটি ভাল পারফর্ম করেছে সে সম্পর্কে সিদ্ধান্ত নিতে শুরু করতে পারেন।
আপনি সফলভাবে একটি পরীক্ষা চালানোর পরে এবং সর্বোত্তম বিকল্প সম্পর্কে যথেষ্ট পরিমাণে আত্মবিশ্বাস অর্জন করার পরে, পরবর্তী পদক্ষেপটি হল আপনার পণ্য জুড়ে আপনার পরিবর্তনগুলিকে স্কেল করা। বিভিন্ন পন্থা হতে পারে:
সবচেয়ে সহজ হল আপনার পরীক্ষার কনফিগারেশন সামঞ্জস্য করা যাতে 100% ব্যবহারকারী সেই গোষ্ঠীর অধীনে পড়ে যা আরও ভাল ফলাফল দেখায় ৷ ভবিষ্যতে কোডটি পরিষ্কার করার জন্য আপনাকে কিছু সময় সংরক্ষণ করতে হবে যাতে UI এর এই নির্দিষ্ট অংশটি প্রদর্শন করা পরীক্ষার পরিবেশ থেকে স্বাধীন হয়
আপনার পণ্য একাধিক প্ল্যাটফর্মে উপলব্ধ হলে কম সোজা। ওয়েব ফ্লোতে পরীক্ষা-নিরীক্ষার ফলাফল মোবাইল অ্যাপ ফ্লোতে প্রযোজ্য (এবং এর বিপরীতে) অনুমানে অতিরিক্ত সতর্কতা অবলম্বন করুন । কখনও কখনও দুঃখিত হওয়ার চেয়ে নিরাপদ থাকা এবং একইভাবে একটি পৃথক পরীক্ষা চালানো ভাল, তবে অন্য প্ল্যাটফর্মে৷
আপনার নিজস্ব পরীক্ষার পরিবেশ থাকা যেকোনো পণ্য পরিচালকের জন্য একটি খুব সহজ টুল। আপনার বর্তমান পণ্য পরিপক্কতার কোন পর্যায়ে থাকুক না কেন, একটি পরীক্ষামূলক পরিবেশ তৈরি করতে খুব বেশি সময় নেওয়া উচিত নয়। এটিকে কাজ করার জন্য মোটামুটি কম এক-অফ খরচ প্রদান করা আপনাকে মোটামুটি দ্রুত বিনিয়োগের উপর রিটার্ন দেখাবে।
পরিশেষে, পরীক্ষার ফলাফলগুলি অর্থপূর্ণ কিনা তা নিশ্চিত করার জন্য এখানে কয়েকটি টিপস রয়েছে:
এই সর্বোত্তম অনুশীলনগুলি অনুসরণ করে, আপনি একটি কার্যকর পরীক্ষামূলক পরিবেশ সেট আপ করতে পারেন যা আপনাকে ডেটা-চালিত সিদ্ধান্ত নিতে এবং সময়ের সাথে সাথে আপনার রূপান্তর হার চালাতে সহায়তা করতে পারে।