خانه / دسته‌بندی نشده / فرآیند آزمون AB

فرآیند آزمون AB

AB Testing Approach

مقدمه

بی شک یکی از سخت ترین و مشکل ترین فعالیت های هر توسعه سیستمی مربوط می شود به UX و تجربه ی کاربری. شاید به جرات بتوان گفت این خود action و reaction کاربر در زمان واقعی در مواجه با interaction ها عناصر سیستم طراحی شده توسط ما می باشد که ux واقعی است و پیش بینی کردن و به سمت این تجربه ی دلخواه کاربر رفتن کاری است بسیار سخت. Approach های مختلفی جهت مواجه با مسائل UX مطرح شده و وجود دارد. یکی از این Approach های بسیار مهم فرآیند تست AB هست. هرچند این رویکرد رو در گروه Deploy Strategy ها در نظر می گیرند. به شخصه اما این رویکرد رو UX metric approach بسیار مهم در نظر می گیرم. که تقریبا اکثر کسب و کارهایی که بصورت آنلاین چه از طریق وب سایت و چه از طریق Application موبایل و … با کاربران بسیار زیادی در تعامل هستند و در آنها UX بهتر و برتر یک مزیت رقابتی بسیار مهم برای آنها محسوب میشه از رویکردهای شبیه AB Testing در فرآیند UX خود حتما استفاده می کنند.

A/B test چیست؟

آزمون A/B (که به عنوان Split testing و هم چنین bucket testing  نیز شناخته میشه) فرآیند مقایسه دو نسخه ی از یک صفحه ی وب با هم هست به این جهت که مشخص شود کدام یک عملکرد بهتری خواهد داشت. آزمون AB یک فرآیند بر اساس تجربه ی کاربران است که در طی آن دو نسخه ی متفاوت از صفحه ی وب بصورت تصادفی به کاربران نمایش داده می شود؛ و سپس بررسی و تحلیل های آماری روی این مشاهدات انجام می شود و نتایج بر اساس یک هدف goal از قبل تعیین شده مشخص خواهد شد.


فرآیند آزمون عملی خارج از فرآیندهای بهبود عملکرد وب سایت-website optimization- هست؛ که باعث می شود که تصممیات بر پایه داده و اطلاعات-data-informed decision- گرفته شود و تصمیمات business از مرحله ی “we think” به “we know” تغییر کند. با اندازه گیری تاثیراتی که این تغییرات بر روی متریک های شما خواهند داشت؛ مطمین خواهید شد که هر تغییری تاثیر مثبت در پی خواهد داشت.
در آزمون AB دو نسخه ی متفاوت از وب سایت یا App شما با هم مقایسه می شود؛ به شما اجازه می دهد که بر روی تغییرات وب سایت یا اپلیکشن خود متمرکز باشید؛ و سپس داده هایی را درباره اثرات این تغییرت جمع آوری کنید.

 

اما A/B testing به چه صورت عمل می کند؟

در یک آزمون A/B شما صفحه ای از یک وب سایت و یا اپلیکشن رو تغییر داده تا نسخه ی جدیدی از آن بدست بیاورید. این تغییر می تونه به سادگی یک headline یا button ساده باشد؛ و یا اینکه بطور کلی موجب طراحی مجدد صفحه بشود.

سپس در نصفی از ترافیک نسخه ی اصلی(که به عنوان control معروف است) و در نیمه ی دیگر نسخه ی تغییر داده شده(به عنوان variation) در معرض دید قرار خواهد گرفت.


به محض اینکه کاربران نسخه های control یا variation رو مشاهده و با آنها تعامل کردند؛ اطلاعات درباره نحوه ی رفتار  و تجربه کاربران به درون داشبورد تجزیه و تحلیل جمع آوری شده و سپس از طریق یک engine آماری مورد آنالیز قرار می گیرد. و بعد از اون می شه تشخیص داد که تغییر مورد نظر دارای تاثیر مثبت؛ منفی؛ و یا اصولا بی تاثیر است؟

 

 

خوب حالا چه نیازی به آزمون A/B وجود دارد؟

این آزمون به افراد و تیم ها و شرکت این امکان را می دهد که با جمع آوری داده ها؛ نسبت به تغییرات تجربه ی کاربری-user experiences ( دقیق باشند. و این مورد به آنها اجازه می دهد که فرضیات مفید و درستی را ایجاد کنند و بهتر متوجه شوند که چرا و چگونه یک element مشخص بر روی رفتار کاربران تاثیر خواهد گذاشت. به عبارت دیگر؛ تفکر و عقیده ی آنها در باب بهترین تجارب best practice برای یک هدف خاص می تواند از طریق آزمون A/B ثابت شود که کاملا اشتباه است.

مضاف بر اینکه آزمون A/B قادر به یافتن پاسخ سوالات و یا تشخیص عدم توافق می باشد و مورد استفاده قرار می گیرد؛ جهت بهبود مستمر یک تجربه خاص و بهبود یک هدف شبیه نرخ محاوره می توان از آزمون A/B نیز استفاده نمود.

به عنوان مثال؛ یک شرکت B2B ممکن است تصمیم به بهبود و افزایش کمی و کیفی خود از طریق landing pageهای خود بکند. جهت دستیابی به این هدف؛ تیم باید تغییرات headline؛ visual imagery از فیلدها و تماس ها تا عملیات و سراسر layout صفحه را مورد آزمون A/B قرار دهد.

در صورتی که در هر لحظه فقط یک تغییر مورد آزمون واقع شود؛ به تیم امکان می دهد که با دقت بیشتر مشخص کند که کدام تغییر تاثیر بیشتر بر روی رفتار بازدید کنندگان دارد. با گذشت زمان؛ می توان نتایج چند تغییر موفق را با هم ترکیب نمود تا میزان بهبود تغییرات نسبت به نسخه ی قدیمی تر به چه میزان می باشد.

 

این شیوه ی معرفی تغییرات به تجربه ی کاربری همچنین اجازه می دهد که خروجی کار برای یک نتیجه مورد پسند نیز بهینه شود؛ و می تواند گام و قدم مثبت و موثری در بازار باشد.
با آزمون و کپی کردن؛ فروشندگان می توانند بفهمند که کدام نسخه جاذبه ی کلیک بیشتری داشته است. همچنین با آزمون صفحات بعدی می توانند متوجه بشوند که کدام layout بازدیدکنندگان را به بهترین شکل به بهترین مشتریان مبدل می کند.

آزمون A/B همچنین می تواند بوسلیه توسعه دهندگان و طراحان نرم افزار جهت تعیین میزان تاثیر ویژگی و تغییرات جدید به تجربه ی کاربری مورد استفاده واقع شود.

فرآیند آزمون A/B

آنچه در ادامه خواهد آمد فریمورک آزمون AB هست که می توان جهت شروع آزمون استفاده نمود:

  • جمع آوری داده: آنالیز معمولا این بینش را می دهد که فرآیند بهینه سازی از کجا شروع شود. و می تواند با محل هایی از سایت یا اپلیکشن شروع شود که دارای بالاترین ترافیک می باشد, و یا اینکه به شما اجازه می دهد که سریعتر داده ها را جمع آوری نمائید. به صفحاتی که دارای نرخ مشاهده کم و یا نرخ عدم فعالیت بالا هستند بیشتر تمرکز نموده و آن را سعی در بهبود آنها داشته باشید.
  • اهداف را تعیین نمائید: اهداف؛ متریک هایی هستند جهت تعیین اینکه آیا variation نسبت به نسخه ی control بهتر است یا خیر. و اهداف می توانند هر چیزی از کلیک کردن یک دکمه تا لینک خرید محصول و وارد شدان از طریق ایمیل باشد.
  • فرضیه ها را بوجود آورید: استفاده کردن از نرم افزار آزمون کننده ی A/B(از جمله Optimizely)؛ تغییرات مورد انتظاری را به یک element به تجربه ی وب سایت یا اپلیکشن موبایل اعمال می کند. و این مورد می تونه شامل تغییر رنگ یک دکمه؛ تغییر اولویت عناصر یک صفحه؛ داشتن navigation elements و یا یک چیز کاملا دلخواه باشد. اکثر سیستم های نرم افزاری A/B testing پیشرو؛ شامل یک editor تصویری هستند که ایجاد و اعمال این تغییرات را آسان می کنند. و به QA تجربه ی کاربری این اطمینان را می دهد که تغییرات همانطور که انتظار می رود عمل خواهند کرد.
  • اجرای تجربه های(نتایج) بدست آمده: تجربه های بدست آمده را اعمال و منتظر مشارک بازدید کنندگان باشید! در این نقطه در این لحظه بازدید کنندگان بصورت تصادفی به نسخه ی control و یا variation تخصیص داده می شوند. تعاملات آنها با هر کدام از آنها اندازه گیری و مقایسه شده و تعیین می شود که هر کدام به چه صورت عمل خواهند کرد.
  • نتایج را آنالیز نمایید: بمحض اینکه آزمایش ها به اتمام رسید؛ زمان آنالیز نتایج می باشد. نرم افزار آزمون A/B دیتا را به شما نشان می دهند و تفاوت های میان دو نسخه از صفحه را ارائه می دهند.

در صورتی که  variation موفق تر باشد؛ باید تبریک گفت! بررسی کنید که آیا می توان از تغییرات انجام گرفت آموخت و این تغییرات را به سایر بخش ها جهت رسیدن به نتیجه بهتر و عملکرد بالاتر اعمال نمود. اما در صورتی که آزمایش نتایج منفی نشان دهد کج خلق نشوید. از آزمایش های به مثابه تجارب فراگیرنده یاد کنید و فرضیات جدیدی که می شود آنها را آزمون نمود را ایجاد کنید.


صرفظر از اینکه خروجی آزمایش و آزمون چه بوده؛ از آنها جهت داشتن ویژگی های آزمون مطلع و تکرارهای مداوم در جهت بهبود تجربه ی کاربری سایت یا اپلیکشن خود استفاده نمائید.

آزمون A/B و SEO

گوگل آزمون A/B را مجاز دانسته و تشویق می کند. هر چند که ممکن است رتبه جستجو –search rank- با استفاده نامناسب از یک ابزار آزمون A/B برای اهدافی نظیر cloaking به خطر بیافتد. گوگل یکسری best practice هایی جهت اطمینان از اینکه این اتفاق نخواهد افتاد را بر شمرده:

  • No Cloaking: cloaking عمل نمایش و ارائه ی محتوایی متفاوت از آنکه بازدید کنندگان باید ببیند به Search engine ها می باشد. و این می تواند منجر به تنزل رتبه یا حتی پاک شدن از نتایج جستجوها شود. برای جلوگیری از این عمل؛ از بخش بندی جهت نمایش محتوایی متفاوت از آن چیزی که Googlebot بر اساس user-agent یا IP Address دارد سوئ استفاده نکنید.
  • Use rel=” canonical”: در صورتی که split testای را با چند url اجرا نمودید؛ باید از rel=” canonical” جهت برگشت variationها به نسخه ی اصلی صفحه استفاده کنید. این عمل موجب می شود که Googlebot نسبت به داشتن چند نسخه ی متفاوت از یک صفحه قاطی نکند.
  • Use 302 redirect instead of 3.1s: در صورت اجرای آزمونی که موجب redirect از original url به variation url می شود؛ از 302(temporary) بجای 301(permanent) استفاده کنید. این مورد به search engine ها از جمله گوگل می گوید که redirect موقت است و آنها باید همان original url ایندکس شده را نگه داری کنند.
  • Run Experiments Only As Long As Necessary: اجرای آزمونها برای مدت طولانی بخصوص هنگامی که بخش قابل توجهی از ترافیک را به variation اختصاص داده باشید منجر می شود به اینکه search engineها فریب بخورند. گوگل پیشنهاد می دهد که تمامی آزمون ها را به محض اینکه به نتیجه مورد نظر دست یافتید حذف و سایت رو بروز رسانی نمائید و اجرای غیر ضروری آزمون ها برای مدت طولانی اجتناب ورزید.

تصورات آزمون A/B

در زیر لیستی از ایده تصوراتی که می توان به عنوان نقطه ی شروع برای آزمون A/B استفاده نمود آورده شده است.

 

  • A media company ممکن است بخواهد تعداد خوانندگان خود را افزایش دهد؛ یا میزان زمانی که خوانندگان بر روی سایت آنها صرف می کنند را افزایش دهد و هم چنین مقالات خود را از طریق اشتراک گذاری اجتماعی بالا ببرند. جهت دست یابی به این اهداف شما باید variationهایی را بر روی موارد زیر آزمون کنید:
    • مدال های signup ایمیلی
    • مطالب توصیه شده
    • دکمه های اشتراک گذاری اجتماعی
  • A travel company ممکن است در نظر داشته باشد میزان رزروهای تکمیل شده ی وب سایت یا اپلیکشن خود را افزایش دهد؛ یا منافع خریدهای فرعی را افزایش دهد. جهت بهبود این متریک ها؛ باید variationهای زیر را آزمون نمود:
    • مدال های صفحات خانگی
    • صفحات نتایج جستجو
    • نمایش محصولات فرعی
  • An e-commerce company شاید تمایل داشته باشد که تصفیه حساب های اتمام شده را افزایش دهد؛ یا میانگین ارزش سفارش با بیشتر کند؛ و یا خرید های روز تعطیل را افزایش دهد. جت دستیابی به این موارد باید موارد زیر را مورد آزمون قرار داد:
    • تبلیغ های صفحات خانگی
    • عناصر ناوبری
    • کامپوننت های Checkout funnel
  • A technical company ممکن است بخواهد برا ی تیم فروش؛ تعداد پیش روهای با کیفیت بالا را افزایش دهد؛ یا تعداد کابران رایگان را بیشتر کند؛ و یا نوع خاصی از خریداران را مجذوب کند. آنها باید:
    • در کامپوننت پیش رو شوند
    • جریان signup آزمایش مجانی
    • پیام رسانی صفحه خانگی و call-to-action

 

درباره ی masoud@admin

همچنین ببینید

بررسی Promiseها در AngularJs بر اساس کارتون

بررسی Promiseها  در Angular Js بر اساس کارتون متن زیر بر گرفته از مقاله ای …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن