تغییر بدون ترس: با Feature Flag برو، با A/B Test ببین!

یه بار داشتم توی Doulingo یه درس انجام میدادم، یهو بعد از ۵ تا تمرین اول یه انیمیشن رعد و برق برام زد، تا حالا ندیده بودم اونو با وجودی که هر روز تمرینامو انجام میدادم. بنابراین هر روز داشتم از اپلیکیشن استفاده می‌کردم و نسخه قدیمی ای نبود. از دوستم پرسیدم که باهم داشتیم کوئست انجام میدادیم و اون گفت که نه این چیز جدیدی نیست و برای من خیلی وقته اینطوریه!

اتفاقی که داشت برای ما میوفتاد یه مدلی از A/B Testing بود. اگه من از دوستم نمی‌پرسیدم متوجه نمیشدم که این قابلیت از قبل هم بوده و من اونو نمیدیدم ولی اون قبلا هم اونجا بود! این موضوع توی بیزنس خیلی مهمه مخصوصا برای تصمیم گیری در مورد اینکه یک قابلیتی که بهش اطمینان نداریم رو بتونیم تست و بررسی کنیم و اگر نتیجه تست ها مثبت بود اضافه اش کنیم وگرنه بیخیالش بشیم.

تجربه ای که براتون تعریف کردم یه مفهوم ساده و در عین حال خیلی کارآمده به اسم A/B Testing. نحوه کارش اینطوریه که شما یک فیچر یا UI یا فرایند یا هرچیزی رو به دو یا چند شکل مختلف پیاده سازی می‌کنید و بعد هر کدوم از اون نسخه ها رو در اختیار دسته ای از کاربراتون قرار میدین، فیدبک می‌گیرید و تصمیم گیری ‌می‌کنید. این قابلیت میتونه یک تغییر ساده در ظاهر (UI) باشه مثل این که کاربر ها با کدوم رنگ یا کدوم شکل بیشتر راحت بودن یا حتی یک Flow کاملا مستقل.

سناریو: کدوم شکل؟

سه تا دکمه با حالت های مختلف داریم. ببینیم کاربر بیشتر با کدوم ارتباط می‌گیره. هدف اینه که کاربر روی این دکمه کلیک کنه. حالا پارامتر های مختلفی وجود داره که این جذابیت رو براش ایجاد کنیم، میتونیم از شکل شروع کنیم:

تو این حالت چیزی که داریم کنترل می‌کنیم شکل دکمه است. و بله من میدونم که این شکل ها توی Context و خیلی پارامتر های دیگه تعریف ‌میشن و معنا پیدا میکنن ولی بیاید ساده بهش نگاه کنیم.

یا میتونیم روی رنگ بازی کنیم:

در هر حالت، ما میخوایم ببینیم که کاربر در هر کدوم از این مدل ها با کدوم بیشتر ارتباط برقرار میکنه. در هر حالت کاربر متوجه این موضوع نیست که سناریو های دیگه ای هم وجود داره. کاربری که داره رنگ نارنجی رو میبینه، فقط همون رو میبینه و کاربری که شکل دکمه های با لبه های تیز، باز هم همون. بعد از مدتی وقتی اطلاعات جمع آوری شد تصمیم گیری صورت می‌گیره.

سناریو: تکمیل اطلاعات پروفایل

این سناریو برای کاربر ها اختیاری هست ولی برای بیزنس داشتن اون اطلاعات ارزشمنده. چرا ارزشمنده؟ چون بیزنس میتونه بر اساس اطلاعات اختیاری مثل سن و جنسیت و یا علایق کاربر ها، پیشنهاد های بهتری بهشون بده. پس برای بیزنس و مارکتینگ مهمه که این اطلاعات رو داشته باشه ولی از طرفی هم نمیخوایم کاربر رو مجبور کنیم که این اطلاعات رو وارد کنه چون خیلی ها قطعا دوست ندارند!

پس اینجا میخوایم یک سیاستی رو پیاده سازی کنیم که بالاترین نرخ ورود اطلاعات رو داشته باشیم در عین حال همچنان این فرایند اختیاری بمونه. خب بنابراین اگر ما این فرایند رو پیچیده طراحی کنیم ممکنه کاربر همون اول کار بیخیال بشه و بره ولی اگه فرایند رو براش راحت یا جذاب کنیم، احتمالا تمایل بیشتری برای ادامه دادنش داشته باشه.

دو تا سناریو در نظر می‌گیریم:

• دسته اول کاربر ها بعد از اینکه توی سایت ثبت نام می‌کنن، میخوایم که وارد پروفایل شون بشن و اطلاعات رو تکمیل کنن.
• دسته دوم کاربر ها برای تکمیل این اطلاعات یه امتیازی میدیم! مثلا فلان کد تخفیف رو میگیری بعد اینکه اطلاعات پروفایلت رو وارد کنی.

در هر دو حالت کاربرا آگاهی ندارن که دارن مورد آزمایش قرار می‌گیرن. ممکنه دسته اول چون دقیقا بعد از ثبت نام ازشون درخواست میشه، اطلاعات رو تکمیل کنن. ممکن هم هست دسته دوم برای دریافت کد تخفیف، بیشتر تمایل داشته باشن که اطلاعات پروفایل رو وارد کنن. شاید هم هیچکدوم کار نکنه یا هر دو به یه اندازه اوکی باشن! ما نمیدونیم!

نکته مهم توی بحث A/B Testing ایده آل هست که کاربر ها دقیقا به طور برابری هر دو نسخه رو ببینن، یعنی اگر ۱۰۰۰ تا کاربر دارن نسخه A رو میبینن، ۱۰۰۰ تا کاربر دیگه نسخه B رو ببینن. اینطوری راحت تر میتونیم اندازه گیری کنیم.

این که چطور بفهمیم کاربر ها با کدوم مدل پیاده سازی بیشتر ارتباط برقرار کردن، بر اساس Log هایی هست که در زمان تعامل با اون قابلیت خاص ازشون جمع‌‌آوری می‌کنیم. این لاگ ها میتونن بر اساس نیاز های ما تعیین بشن، مثلا نرخ کلیک، مدت زمانی که کاربر تو صفحه مونده، نرخ تبدیل و ...

تا نخوایم نشون نمیدیم: Feature Flag

این یه تکنیکه که به توسعه‌دهنده‌ها اجازه می‌ده قابلیت‌های جدید رو بدون اینکه بلافاصله برای همه کاربران فعال بشن، در کد اضافه کنن. این یعنی می‌تونی یه فیچر رو با خیال راحت بنویسی و حتی Deploy کنی، ولی فقط برای بخشی از کاربران (یا حتی فقط تیم خودت) فعالش کنی.

از Feature Flag می‌شه برای موارد مختلفی استفاده کرد: تست تو محیط واقعی، اجرای rollout تدریجی، فعال‌سازی قابلیت‌ها فقط برای کاربران خاص (مثلاً کاربران Premium یا بتا تسترها یا تیم خودمون)، یا حتی خاموش کردن سریع یه قابلیت مشکل‌دار بدون نیاز به deploy جدید. تصور کن یه فیچر باعث خطا شده، ولی به‌جای rollback کل نسخه روی گیت، فقط اون فیچر رو غیرفعال می‌کنی و بقیه‌ی سیستم به کارش ادامه می‌ده.

در عمل، پیاده‌سازی Feature Flag می‌تونه ساده یا پیچیده باشه. می‌تونی با یه شرط ساده مثل if (showNewFeature) توی کدت داشته باشیش، یا از سرویس‌های داخلی رو سرور خودت یا حتی ابزار های third-party استفاده کنی که کنترل خیلی دقیق‌تری روی فلگ‌ها دارن (مثلاً فعال‌سازی براساس درصد، کشور، نقش کاربر، زمان‌بندی و غیره). اما ایده اصلی اینه که کنترل کامل دست خودته، در نهایت همون مفهوم فیوزباکس هست که انگار چندتا چیز رو خاموش و روشن میکنی. مهم‌ترین مزیتش اینه که توسعه و انتشار رو چابک‌تر، امن‌تر و قابل کنترل‌تر می‌کنه.

فرق A/B Test با Feature Flag و ترکیب شون باهم

اگه مخاطب باهوشی که شما باشی، اینجا یه لامپی باید بالا سرت روشن شده باشه.

• توی A/B Test یعنی دو یا چند نسخه از یه قابلیت یا طراحی رو به کاربرها نشون بدی و ببینی کدومش بهتر عمل می‌کنه
• تو Feature Flag مثل یک سوییچه: روشن یا خاموش. قابلیتت رو پشتش مخفی می‌کنی و فقط برای بعضی کاربرها روشنش می‌کنی.

حالا که فرق شون رو میدونیم بریم چندتا مثال دنیای واقعی رو باهم بررسی کنیم:

فرض کن تیم محصول Spotify می‌خواد یک طراحی جدید برای صفحه‌ی “Now Playing” رو تست کنه. اون‌ها این طراحی جدید رو پشت یک Feature Flag قرار می‌دن، تا فقط برای ۵٪ از کاربران فعال باشه. اما در همین ۵٪، دو نسخه‌ی متفاوت از طراحی (مثلاً با کنترل‌های پخش در بالا یا پایین صفحه) به‌صورت A/B بین کاربران پخش می‌شه. اینجوری اگر کل طراحی مشکل داشت، می‌تونن فلگ رو خاموش کنن، و اگر فقط یکی از نسخه‌ها عملکرد ضعیفی داشت، اون رو در تست حذف کنن.

یا مثلاً LinkedIn زمانی که قابلیت “Open to Work” رو معرفی کرد، نمی‌دونست دقیقاً چه نوع نمایش یا phrasing برای کاربران جذاب‌تره. پس این قابلیت پشت یک Feature Flag قرار گرفت و تنها برای بخشی از کاربران فعال شد. در همین حال، تیم UX دو نسخه مختلف از عبارت یا نمایش اون رو. توی پروفایل کاربرا تست کرد. مثلا عبارت ”Open to Opportunities” یا ”Actively looking”. این ترکیب بهشون اجازه داد هم feature رو مرحله‌ای rollout کنن، هم بهترین پیام رو پیدا کنن.

یا توی فروشگاه های بزرگ، مثل Zalando یا Amazon، این روش خیلی مرسومه. مثلاً وقتی بخوان یک الگوریتم جدید مرتب‌سازی محصولات رو تست کنن یا سیستم پیشنهاد محصولات مشابه، اول اون الگوریتم رو پشت Feature Flag پیاده‌سازی می‌کنن تا اگر سیستم دچار افت شد، بشه به‌راحتی غیر فعالش کرد و فاجعه نشه. ولی در همین حال، الگوریتم جدید در نسخه A و قدیمی در نسخه B به کاربران مختلف نمایش داده می‌شه تا نرخ کلیک و خرید مقایسه بشه.

ترکیب A/B Testing با Feature Flag به ما این توانایی رو می‌ده که هم با اطمینان تغییرات مهم رو منتشر کنیم، و هم با داده و تست واقعی تصمیم بگیریم که چه چیزی واقعاً بهتر عمل می‌کنه. این ترکیب، قلب فرآیند Continuous delivery در شرکت‌های بزرگه.

امیدوارم ایده رو تونسته باشم به طور کلی براتون توضیح داده باشم، نمونه کدی نذاشتم چون روش های پیاده سازی همه یه کار انجام میدن که ایده بزرگ پشتش همون جعبه فیوز هست. یه تعداد boolean داخل یه Object یا لیست و چک کردن شون با شرط و ... پس خیلی چیز عجیبی نداشت. مطمئنم که خودتونم میتونین پیاده سازیش کنین.

اگه دوست داشتین میتونید از طریق لینکدین باهام در ارتباط باشین.