หลักคิดสำคัญในการทำ A/B Test ที่ Product Manager ควรรู้

หลังจากที่ผมสวมหมวก Product Manager มาหลายปี เครื่องมือนึงที่ผมมีโอกาสได้ลองศึกษาเอง ลองใช้เอง จนถึงตอนนี้ที่ต้องใช้เป็นส่วนหนึ่งของการ launch product คือ A/B Test ครับ

สำหรับโพสต์นี้ผมเอาสิ่งที่ผมเรียนรู้ตลอดการทำ A/B Test ระหว่างที่เป็น Product Manager ทั้งที่ลงคอร์สเรียนมา อ่านหนังสือ และทำจริง มารวบตึงเป็นหลักความรู้สำคัญ ๆ ที่ผมใช้ และคิดว่าไหนๆ เขียนสรุปในบทความส่วนตัวแล้ว ก็อยากเอามาแบ่งปันให้กับชาว PM คนอื่นเช่นกัน (ติดตามบทความต้นฉบับ ที่นี่)

หวังว่าจะเป็นประโยชน์สำหรับชาว Product Manager เพื่อไว้เป็น Checklist ตรวจสอบวิธีการทำ A/B Test ของเราให้ผลลัพธ์ออกมาน่าเชื่อถือมากยิ่งขึ้นครับ

A/B Test คืออะไร ใช่เรื่องของ Marketing รึเปล่า?

A/B Test ไม่ใช่เรื่องใหม่ที่ใช้ใน Product Management แต่เป็นกระบวนการทางวิทยาศาสตร์ปกติ ที่ใช้ได้ในทุกแขนง แล้วแต่ว่าเรากำลังจะพิสูจน์เรื่องอะไร

A/B Test มีอีกชื่อว่า Split test โดยทั่วไปชาว PM จะใช้วิธีนี้เพื่อวัดความสำเร็จของ Feature หรือ Product ด้วยการแบ่ง User เป็นสองกลุ่ม โดยกลุ่ม A ไม่ได้เห็น Feature ใหม่ (หรือเรียกว่า Control group) ส่วนกลุ่ม B ได้เห็น Feature ใหม่ (หรือ Test group)

จากนั้น เราจะวัดผลผ่านตัวชี้วัดที่เราคาดหวัง (หรือ Metric) จากการที่ User ในกลุ่ม B ได้รับ Feature ใหม่ไป ว่าตัวชี้วัดนี้มีการเปลี่ยนแปลงในทางที่เราคาดคิดหรือไม่

ซึ่ง A/B Test สามารถใช้ได้ ทั้งในสถานการณ์ที่ต้องการ Optimize Feature ที่มีอยู่แล้ว (เช่น เปลี่ยน Layout หน้า Website, เปลี่ยนวิธีการแสดงผล, เปลี่ยนข้อมูลที่แสดงผล) หรือ พิสูจน์ประสิทธิผลของ Product Feature ที่ออกใหม่ว่าตอบโจทย์ User และ Business KPI จริงๆ หรือไม่ก็ได้ครับ

วิธีการพิสูจน์ ไม่ได้มีแค่ A/B Test

วิธีการพิสูจน์สาเหตุของการเปลี่ยนแปลงมีหลายวิธี ซึ่งความน่าเชื่อถือจะต่างกันตามรูปด้านล่าง

A/B Test ที่ทำอย่างถูกต้องจะจัดเป็น Randomized Experiment โดยทฤษฎีแล้วเป็นวิธีที่ความน่าเชื่อถือสูงสุดในการหาสาเหตุ (Causation) วิธีที่ความน่าเชื่อถือรองลงมาก็จะอยู่ที่ฐานรูปสามเหลี่ยมตามภาพ

ตัวอย่างการนำ A/B Test มาใช้ เช่น

• Problem: เราพบว่า user บางส่วนไม่สามารถเริ่มกระบวนการ Search ได้
• Pain point: หลังจากทำการ Qualitative Research มา พบว่า user แค่คิดไม่ออกว่าต้องพิมพ์ว่าอะไร
• Assumption: “ถ้าระบบเราเสนอ Keyword ให้ User ระหว่างพิมพ์ จะทำให้ User เริ่ม Search มากขึ้น และจะส่งผลให้ User เข้ามาซื้อของบนเว็บของเรามากขึ้น”

พอตั้งสมมติฐาน (Assumption) แบบนี้ ก็จะชัดเจนว่าสิ่งที่ B ต้องต่างจาก A คืออะไร และต้องใช้ตัวชี้วัดไหนเพื่อดูว่าประสบความสำเร็จหรือไม่ เช่น ในตัวอย่างข้างต้น

• ในกลุ่ม B จะต้องมีระบบเสนอ Keyword ให้ User
• ตัวชี้วัดก็จะเป็น อัตราส่วน User ที่เริ่ม Search หรือ จำนวนการ Search ต่อ User โดยเฉลี่ยก็ได้เช่นกัน

จากนั้น Implement ในระบบให้เกิดการ Random User เข้ากลุ่ม A หรือ B และใส่เงื่อนไขของ Feature ลงไปให้เห็นเฉพาะกลุ่ม B

หลังจากปล่อยการทดลองออกไปจนได้ Traffic ครบตามเงื่อนไขการสรุปผลการทดลอง ก็สามารถนำ Data มาคำนวณตัวชี้วัดที่ตั้งไว้ มาเปรียบเทียบระหว่างกลุ่ม A กับ B ได้

A/B Test ฟังดูง่าย แต่มีขั้นตอนเพื่อทำให้น่าเชื่อถือ

ถึงแม้จะฟังดูง่าย แต่ A/B Test นั้นจะไร้ความหมายเกือบทันที ถ้าวิธีการทำไม่น่าเชื่อถือ หรือก็คือวิทยาศาสตร์ไม่พอ

กล่าวคือ ไม่ได้คำนวณว่า จำนวน user ที่ต้องใช้ในแต่ละกลุ่มใช้เท่าไร ไม่ได้ตั้งตัวชี้วัด หรือตัวชี้วัดไม่เหมาะสม ตัวชี้วัดฝั่ง A กับ B ต่างกันเท่าไรถึงเรียกว่าดีพอ ต้องแบ่ง User สองกลุ่มนานเท่าไร ถึงจะสรุปผลได้

คลาสสิคเคสที่ทำให้การทดลองไม่น่าเชื่อถือ เช่น

• เปิดการทดลองไป 3 วันเห็น Metrics B ขยับสูงกว่า A 1% จบการสรุปผล (แล้วถ้าปกติ Metrics ตัวนี้มันแกว่งได้ +/- 3% เลยล่ะ?)
• ต้องเปิดการทดลองกี่วันก็ไม่รู้ เอาฤกษ์มงคลสักอาทิตย์นึงละกัน แล้วดูเลยว่า A หรือ B มากกว่า (แล้วถ้าเปิดนานกว่านั้น ผลมันจะเปลี่ยนมั้ย? B อาจมากขึ้น น้อยลง หรือไม่เปลี่ยนก็ได้)
• เปิดการทดลองมาสองอาทิตย์แล้ว Metrics ฝั่ง B ไม่ขยับ ไม่อยากสรุปผลแบบ fail เปิดมันต่อยาว ๆ เลยละกันจนกว่า B จะชนะ (แบบนี้ก็ชนะทุกการทดลองเลยสิ)

ซึ่งทั้งหมดนี้ สามารถแก้ไขได้ด้วยการวางแผนออกแบบการทดลองแบบอิงหลักสถิติก่อนจะเอาไป Implement จริง

---

จับมือทำแบบ Step by Step

ขั้นตอนที่ 1 – เขียนสมมติฐานของการทดลองให้เรียบร้อย

อาจใช้ Format เป็น ปัญหา วิธีแก้ วิธีวัดผล ก็ได้ เช่น

• ปัญหา: User ส่วนหนึ่งหยุดและออกจากกรอกฟอร์มหน้าสมัคร User ใหม่เพราะมี Required Field ที่ต้องไปหาเอกสารมาเพื่อกรอกฟอร์มให้เสร็จ
• วิธีแก้: ตัด field ดังกล่าวออกจากฟอร์มหน้าสมัคร แล้วไปขออีกครั้งเมื่อต้องใช้ข้อมูลดังกล่าว
• วิธีวัดผล: ดูว่าจะทำให้อัตราการสมัครสำเร็จต่อ session มากขึ้นหรือไม่

ขั้นตอนที่ 2 – ตั้ง Metrics

หลักๆ จะมี Metric อยู่ 2 กลุ่ม ได้แก่

กลุ่มแรก: Metrics สำหรับวัดผลการทดลอง

ในที่นี้ก็ควรจะเป็น “อัตราการสมัครสำเร็จต่อ Session”

โดยในการตั้ง metrics มีรายละเอียดที่จำเป็นต้องพิจารณาเพิ่มเติม คือ Metrics ที่ตั้งควรสามารถนำมาคำนวณไปสู่ Business KPI ที่องค์กรเราให้ความสำคัญได้ ถ้าในกรณีนี้ เราต้องการ New user ก็สามารถคำนวณได้อย่างตรงไปตรงมา

จุดที่สำคัญคือ ต้องทำการตกลงชุด Metrics นี้ให้เรียบร้อยก่อน เพื่อให้ผลจากการทดลองมีความหมายทั้งกับ User และธุรกิจ

กลุ่มที่ 2: Guardrails Metrics

หน้าที่ของมันคือเอาไว้คอยตรวจว่าการทดลองของเราว่า Implement มาถูกต้องหรือไม่

ตัวหลักๆ ที่มักจะต้องตรวจคือ Random Traffic ออกมาประมาณ 50% เท่าๆกันจริงมั้ย (ภาษาเทคนิคเรียกว่า Sample Ratio Mismatch)

นอกจากนั้นจะเป็นพวก Metrics อื่นๆที่เราไม่อยากให้มันเปลี่ยนแปลงอันเนื่องมาจากการทดลอง เช่น ถ้าเป็น Flow สมัครการใช้งาน เราน่าจะไม่อยากให้อัตราการเริ่มใช้งานลดลง หรือตัวชี้วัดพวกเหตุการณ์ตาม Funnel ที่เกิดก่อนจะถึงจุดที่เราทำการทดลอง (Upstream metrics) ที่ถ้าเปลี่ยนอาจส่งผลกับการทดลองได้ เช่น Click through rate ของ Funnel ก่อนหน้า ก็ควรวางแผนเพื่อคำนวณไว้ Monitor ระหว่างทำ รวมถึงพิจารณาหลังจบการทดลองด้วย

จะเห็นว่าเมื่อเราตั้ง Metrics ได้ เราจะต้องคำนึงวิธีการคำนวณ รวมไปถึงวิธีการเก็บข้อมูลด้วยว่า Metrics ดังกล่าวควรคำนวณโดยอิง Unit อะไร เช่น จำนวน User หรือ Session หรือ Device ID

นอกจากนี้ เรายังแตกย่อยได้อีกว่า มันคือ User ทั้งหมด หรือแค่ Segment เฉพาะกลุ่มที่ใช้ Feature นี้ หรือเฉพาะระบบปฏิบัติการ เช่น iOS ไม่เอา Android หรือ Web

ทั้งหมดนี้จะเป็นรายละเอียดที่ต้องเอาไป Implement จริง ในระบบ เพื่อนำ Random Unit เข้า A/B ตาม Metrics ที่เราต้องการวัด ตาม Trigger condition ที่เหมาะสม เช่น อยากวัด Register rate ตาม User จริงๆ ว่าเข้ามา 100 คนสมัครสำเร็จกี่คน แต่ตอน Register ข้อมูล User ยังไม่มีในระบบ ก็อาจต้องถอยไปตั้ง Metrics ใหม่ เช่น ใช้ Device ID หรือ Session ID แทน

ขั้นตอนที่ 3 – ตั้ง Sample Size, MDE, Experiment length

ขั้นตอนนี้ จะเริ่มมีการนำเรื่อง Statistical Significance และ Hypothesis Testing จากหลักการสถิติมาใช้ สำหรับใครที่ไม่คุ้นเคยหรือไม่มีพื้นฐานมาก่อน สามารถลองศึกษาก่อนได้ ที่นี่

โดยเราจะเอา Data ในอดีต และจำนวน User traffic ที่เรามี มาคำนวณหา

• Sample size (ต้องมี sample ในแต่ละกลุ่มเท่าไร)
• Minimum Detectable Effect (MDE) (การเปลี่ยนแปลงขั้นต่ำของ metrics วัดผลเป็นเท่าไร)
• Experiment Length (ต้องเปิดการทดลองทั้งหมดกี่วัน)

จึงจะถือว่ามีการเปลี่ยนแปลงอย่างมีนัยสำคัญทางสถิติ (Statistical Significance หรือสั้นๆ เขานิยมเรียกกันว่า Stat-Sig) ไม่ได้เกิดแบบบังเอิญ แต่เปลี่ยนแบบของแทร่

เริ่มจากหาตัวเลขปัจจุบันของ Metrics วัดผล ว่าตอนนี้ประมาณเท่าไร จากนั้นจะมีวิธีคำนวณต่อ อีกสองแบบ

• ท่าที่ 1 คือแบบที่มี % change ของ Metrics ที่เราเชื่อว่าจะทำได้ เราสามารถใช้เป็นตัวเลข MDE เพื่อดูว่าต้องใช้ Sample ของแต่ละกลุ่มเท่าไร
• ท่าที่ 2 แบบที่ไม่แน่ใจว่า Metrics จะไปได้ไกลขนาดไหน แต่โดยทั่วไปเรามักจะรู้จำนวณ Traffic ตาม Unit จาก Data ในอดีต ดังนั้น เราจะรู้ข้อจำกัดแต่แรกว่า Sample size ที่ระบบเราทำได้คือเท่าไร เช่น ปกติใน สองอาทิตย์มี Device ID ประมาณ 100,000 ID ที่เข้ามาในระบบ ถ้าทำ A/B Test แบบมีแค่ 1 Treatment ดังนั้น A กับ B ก็ได้ไปคนฝั่งละ 50,000 ID เท่านั้น จาก Sample Size นี้เราสามารถเอามาคำนวณหา MDE ได้

ในขั้นตอนนี้ ถ้ามีทีม BI หรือ Data Scientist ผู้เชี่ยวชาญสถิติ ก็คิดว่าน่าจะขอคำปรึกษาได้ แต่เพื่อความเข้าใจ PM ก็สามารถลองเองได้ เพราะเรามี tool สำเร็จรูปให้ลองใช้งานทาง Link นี้ https://www.evanmiller.org/ab-testing/sample-size.html

มาดูตัวอย่างกัน

ถ้าเราเลือกท่าที่ 1

1. กรอก Baseline และ MDE ที่คิดว่าสามารถทำได้ลงไป เราจะพบว่าต้องใช้ Traffic เท่าไรจากเครื่องคิดเลขนี้
2. เอามาเทียบกับ Traffic ปกติที่เราได้ต่อวัน ว่าต้องใช้เวลาทั้งหมดในการทำการทดลองกี่วัน ถึงจะได้ Sample size ครบตามที่ควรจะเป็น เช่น ในรูปบอกต้องการ 1,030 Sample ต่อกลุ่ม สองกลุ่มก็จะรวมเป็น 2,060
3. จากนั้นเราก็ไปดู Unit ของ metrics ว่าเป็น Per session หรือ User หรือ Device หรืออื่นๆ
4. แล้วเราก็ไปดู Data จริงๆ ของ App/ Website เราต่อ ว่าวันนึงเราได้ Traffic มาเท่าไร ต้องใช้เวลากี่วันถึงจะได้ 2,060 Unit

ถ้าเลือกท่าที่ 2

1. ลองเอา baseline ไปกรอกในนี้ แล้วเปลี่ยนเลข Minimum Detectable Effect (MDE) จนกระทั่งจำนวน Traffic ที่ต้องการน้อยกว่าที่แอปเราทำได้จริงๆ ในระยะการทดลองสองอาทิตย์ (ระยะเวลาตรงนี้ เราสามารถเลือกเองได้เลยตามความเหมาะสม)
2. เราก็จะทราบว่า ด้วย Baseline ของ Metrics ที่เราเลือก และจำนวน Traffic ที่เป็นไปได้ตามระยะเวลาการทดลองที่เราเลือกนั้น Metrics จะต้องเปลี่ยนไปเท่าไรเป็นอย่างน้อยจึงจะถือว่าเปลี่ยนไปอย่างมีนัยสำคัญทางสถิติ

ในทางปฏิบัติแล้วจะมีคำแนะนำกว้างๆ สำหรับระยะเวลาการเปิดการทดลอง โดยทั่วไปควรจะประมาณ 2 อาทิตย์ เพื่อให้ Capture และ Normalize พวก Seasonal effect ได้ (เช่น วันหยุดจะมี User มาใช้มากกว่าวันธรรมดา) แต่ไม่ได้แปลว่าต้อง 2 อาทิตย์เสมอ แล้วแต่บริบทของการทดลอง ทั้งตัว metrics เอง และพฤติกรรมการใช้งานด้วย

ขั้นตอนที่ 4 – Implement เข้าระบบ ตัดริบบิ้นเริ่มการทดลองได้

พอรู้แล้วว่า Metrics คืออะไร ต้องเปลี่ยนอย่างน้อยเท่าไร และต้องใช้เวลากี่วัน
ดังนั้นจากตรงนี้เราก็สามารถไป Implement ในระบบจริง และเปิดการทดลองได้เลย!

ขั้นตอนที่ 5 – คำนวณผล

หลังจากเก็บข้อมูลจากทดลอง ให้นำข้อมูลจาก A และ B มากรอกใน t-test tool เครื่องมือตัวนี้จะช่วยคำนวณให้ว่าจาก Data ของ Metrics ที่เราวัดได้จาก A และ B ควรสรุปผลว่าอย่างไร

ทดลองเล่นได้จาก Link นี้: https://www.evanmiller.org/ab-testing/t-test.html

พอกรอก Metrics จาก A และ B เสร็จ จะได้รูปกราฟสีส้มด้านล่าง ซึ่งถูกคำนวณจากการเอา Sample Mean ของ A มาลบกับ B จะออกมาเป็นกราฟการกระจายข้อมูลของผลต่าง

โดยปกติแล้ว เรามักจะอยากได้ Confidence level ประมาณ 95% (Confidence level คือ % ความมั่นใจว่าผลต่างนี้มีนัยสำคัญจริง ยิ่งสูงมาก ยิ่งมั่นใจมาก) ซึ่ง p-value คิดมาจาก 1 – Confidence level ใน t-test tool

ในตัวอย่างนี้ เราจึงใช้ p-value = 0.05 (1-95%)

ถ้าเลข 0 ในกราฟสีส้ม (ก็คือ mean A เท่ากับ B) กินพื้นที่อยู่ในกราฟมากเกิน p-value (0.05) นั่นแปลว่ามีโอกาสที่จะพบ Mean A = Mean B มากกว่า 5% แสดงว่ามีโอกาสสูงที่ A อาจไม่ได้ต่างกับ B อย่างมีนัยสำคัญทางสถิติ

แต่ถ้า อยู่ขอบนอกของกราฟมากๆ หรือ p-value น้อยกว่า 0.05 แสดงว่า A ต่างกับ B อย่างมีนัยสำคัญทางสถิติ เพราะมีโอกาสต่ำมากที่จะพบ A = B

จากตัวอย่างนี้

• 0 จะกินพื้นที่ในกราฟ Diff of mean เยอะ
• หรือค่า p-value ของกลุ่ม sample นี้ คำนวณออกมาได้ 0.61 (มากกว่า p-value = 0.05 ที่เราตั้งไว้)

ดังนั้นจึงสรุปได้ว่า A กับ B ไม่ได้ต่างกันอย่างมีนัยสำคัญทางสถิติ (ที่ Confidence Level = 95%) แปลว่า Feature หรือการเปลี่ยนแปลงที่ปล่อยไป ไม่ได้ให้ผลต่างกับปัจจุบันอย่างมีนัยสำคัญนั่นเอง

ขั้นตอนที่ 6 – ได้ผลการทดลองแล้ว ตกลงว่า Launch ได้ไหม?

ช้าก่อนอานนท์…

เริ่มจากตรวจสอบ Guardrails Metrics (จากขั้นตอนที่ 2) ก่อนว่ามีอะไรผิดปกติมั้ย ถ้ามี อาจต้องตรวจสอบก่อนว่าเกิดจากอะไร ในบางกรณีอาจต้องพิจารณาทำการทดลองใหม่

กรณีที่ได้ launch แน่ๆ:

ถ้า treatment ให้ผลที่ต่างกันอย่างมีนัยสำคัญทางสถิติ (ย่อ = stat-sig) และผลต่างเยอะเท่าที่คาดหวัง (practical significance) อันนี้ก็น่าจะ launch ได้ทันที

กรณีที่อาจ launch:

ถ้า treatment ให้ผลที่ต่างกันอย่างมีนัยสำคัญทางสถิติ แต่ผลต่างไม่เยอะเท่าที่คาดหวัง กรณีนี้ต้องหารือกันเพิ่มเติม ว่าคุ้มในการ Launch หรือไม่ เพราะเราสามารถสังเกตการเปลี่ยนแปลงตามหลักทางสถิติได้แล้ว แต่อาจไม่ถึงจุดคุ้มทางธุรกิจ หรือในมุม Cost อาจต้องเอาไปปรับปรุงมาใหม่

กรณีที่เอาไปปรับปรุงมาใหม่ หรือเปิดการทดลองอีกรอบ:

ถ้า Treatment ไม่ให้ผลที่ต่างกันอย่างมีนัยสำคัญทางสถิติ อันนี้ก็ตัดสินใจง่ายคือต้องไปวิเคราะห์และปรับปรุงตัว Solution มาใหม่

ถ้าเจอ Variance ของ Diff mean สูงๆ (ฐานของกราฟสีส้มกว้างมาก) คร่อม MDE และ/หรือ จุด Practical Significance ควรลองเปิดการทดลองใหม่อีกที หรือ อาจต้องไปวิเคราะห์และซ่อมมาใหม่เพราะ Treatment อาจส่งผลทั้งดีทั้งไม่ดีกับ User segment ที่ต่างกัน ที่ปนกันอยู่ในกลุ่ม Sample ก็ได้

---

ข้อเสีย ข้อควรระวัง และข้อจำกัดของ A/B Test

#1 – แพง เปลืองค่าสร้าง ใช้ data เยอะ และใช้เวลามากกว่าทำแล้ว Launch ไปเลย

พูดกันแบบตรงๆ เท่าที่ผ่านมา 3-4 องค์กร แล้วแต่ผู้นำของเราเลยว่า เขาเข้าใจและให้ค่าความสำคัญกับมันขนาดไหน รวมถึง Stage ของ Product และทีมด้วย ว่าพร้อมทำมั้ย พร้อมที่ scale ขนาดไหน

ซึ่งก็เป็น trade-off ว่าองค์กรพร้อมที่จะลงทุนกับการวัดผลในการสร้างและปรับปรุง product ขนาดไหน ถ้าไม่ทำ A/B Test แล้วองค์กรเลือกวิธีใดในการวัดผล

#2 – ความยากลำบากในการตั้ง metrics เพื่อชี้วัดความสำเร็จ

เพราะองค์กรที่ต้องการวัดผลอย่างจริงจัง จำเป็นที่จะต้องเอาชุด Metrics ตั้งแต่ Business KPI → Product Metrics → Evaluation Metrics มาผ่านการวิเคราะห์เพื่อดูว่ามันเชื่อมโยงกันหรือไม่ ส่งผลกันมากน้อยอย่างไร และควรที่จะต้องผ่านการยอมรับโดยผู้บริหารและผู้มีส่วนได้ส่วนเสียทั้งหมด

เช่น ถ้า Business KPI คือ Revenue per user การที่เราทำ A/B Test เพื่อให้ได้ New Registered User มากขึ้น มันส่งผลถึง Revenue per user จริงหรือไม่? ซึ่งอาจลามไปถึงเรื่องอื่นๆ อย่าง Performance Review ของแต่ละคน ทำให้แทนที่ A/B Test ที่เป็นเรื่องที่ควรทำ อาจกลายเป็นเรื่องที่คนไม่กล้าทำเพราะผลข้างเคียงเหล่านี้แทน

ทั้งนี้ทั้งนั้น สิ่งที่ PM ควรทำคือ ตรวจสอบความเชื่อมโยงของ Metrics ชุดนั้นโดยทำ Qualitative Research กับ User บ้าง เพื่อดูว่า User รู้สึกได้ถึงการเปลี่ยนแปลงในทางที่ดีขึ้นจริงหรือไม่ บางครั้งการเปลี่ยนแปลงทางสถิติมันเล็กจน User อาจไม่ได้รู้สึกสิ่งนั้นจริงๆ รวมถึงพฤติกรรมของ User ที่เปลี่ยนไป ก็อาจทำให้ความสัมพันธ์ของ Metrics ข้างต้นอาจเปลี่ยนได้

#3 – ไม่ใช่ทุกเคสที่ทำ A/B Test ได้

• บางครั้งทำ A/B Test แล้ว B มัน effect A เช่น กรณีอย่าง Social Network ที่ กลุ่ม B ได้ฟีเจอร์ใหม่ไปเล่นอวดเพื่อน อาจส่งผลต่อพฤติกรรมของ A ได้ หรือเคสของ Two-sided marketplace (e-commerce) ที่ทำฟีเจอร์บางอย่างให้ผู้ขาย แต่อาจส่งผลเสียต่อผู้ซื้อด้วย
• หากในหน้าจอเดียวกันต้องการปรับปรุงหลายๆ อย่าง ถ้าต้อง Test ด้วย change หลายอย่างพร้อมๆ กันจะทำให้ไม่รู้ว่าผลมันเกิดจาก Change อันไหน บางอันในนั้นอาจมีผลในแง่ลบแฝงอยู่ก็ได้ ทำให้ถ้าจะทำจริงๆ ก็ต้องเรียง Change ทีละอย่าง เสียเวลายิ่งกว่าเดิม หรือต้องใช้ท่ายาก เช่น Multi-Bandit test เป็นต้น

#4 – A/B Test ไม่ได้บอกว่าทำไม

อย่าลืมไปทำ Qualitative Research ด้วย เพื่อให้เราเข้าใจผู้ใช้ในเชิงลึกมากขึ้น เพราะ A/B ไม่ได้บอกว่าทำไม เพราะอะไร รู้แค่มันได้ผลเนื่องจากเราเปลี่ยนหรือเพิ่มอะไรเข้าไป

#5 – Novelty Effect & Primacy Effect

พอเราใส่ของใหม่เข้าไปใน UI ก็จะมีทั้ง User ที่กระโดดเข้าไปใช้แล้วก็เลิกใช้ไปเลย กับ user ที่ไม่กล้าลองใช้ ทำให้สรุปผลการทดลองยากขึ้น อาจต้องใช้เวลานานกว่าปกติเพื่อให้ Metrics นิ่งก่อน

#6 – Simpson Paradox

ข้อนี้ผมเจอกับตัวคือไปเอา Underlying metrics มาดูแล้วเจอว่าผลมันขัดแย้งกับ Evaluation metrics พากันงงไปทั้งทีม ซึ่งจริง ๆ แล้วไม่ควรทำ เพราะ Sample size และ Variance ต่าง ๆ ที่เราใช้ออกแบบการทดลองเป็นของ Evaluation metrics ดูตัวเลขคร่าวๆได้แต่อาจไม่สามารถมองในระดับ Stat-Sig ได้

ถ้าทำ A/B Test ไม่ได้จริงๆ ตัวเลือกมีอะไรบ้าง?

ท่ามาตรฐานในทางสถิติคือ ใช้เทคนิคทางสถิติในการคาดว่า Before change จะวิ่งไปในทิศทางไหน แล้วเอามาเปรียบเทียบกับ After change เข่น Interrupted time series, Difference in Difference ซึ่งแน่นอนว่าความน่าเชื่อถือจะน้อยกว่า A/B Test แต่ก็ดีกว่าไม่วัดผลอะไรเลยแล้วไปนั่งสังเกตเอาอย่างเดียว

แน่ใจได้อย่างไรว่า Feature / Change / Enhancement ที่ทำไป จะมีผลที่ดีในระยะยาว

มีหลายวิธี แต่วิธีที่ส่วนตัวคิดว่าสมเหตุสมผล ความเสี่ยงต่ำ (แต่ยังเสี่ยงอยู่)

• วิธีแรก Cohort analysis ตาม Timeframe ที่ Feature Launch ออกไป เปรียบเทียบกับทีละ Cohort เพื่อดู Stability ของ Metrics วิธีนี้ก็จะค่อนไปทาง Observation Study มากกว่าที่จะพิสูจน์ด้วยการทดลอง
• อีกวิธีคือ Hold out experiment คร่าวๆคือกัน 10% ออกจากการทดลอง กล่าวคือเราจะทดลองกับ Traffic แค่ 90% แล้วเวลา Release จะ Release Feature ให้ 90% นี้เท่านั้น ทีนี้ก็จะกลุ่ม Hold out 10% ที่ไม่เคยได้ feature ใหม่ ทำให้เราสามารถเปรียบเทียบกับกลุ่มนี้ได้เสมอ…แน่นอนครับข้อเสียก็คือ User ที่ถูกเลือกผู้น่าสงสาร กว่าจะได้ของใหม่ไปใช้ เผลอๆ อาจมีโวยมาทาง CS แล้ว

บทเรียนสำคัญส่วนตัวของผม

แต่ละองค์กรให้ค่า A/B Test ของ Product ไม่เหมือนกัน และ Organization Alignment สำคัญมาก

• ถ้า metrics และวิธีทำดีแค่ไหน แต่ไม่ได้ Align กับ Strategy หรือสิ่งที่องค์กรพยายามทำอยู่ ก็แทบจะสูญเปล่าเช่นกัน ดังนั้น การตั้ง metrics ที่สะท้อนตรงทั้งสิ่งองค์กรให้ความสำคัญ และตอบโจทย์ผู้ใช้งานจึงเป็นเรื่องที่สำคัญมาก
• นอกจาก Evaluation Metrics แล้ว Guardrail Metrics ก็ควรตกลงกันให้เรียบร้อยด้วย
• ประเด็นอื่นๆ ที่เจอไม่บ่อยแต่รู้ไว้ก็ดี อาทิ ทำยังไงถ้าอยากใช้ Sample น้อยลง แต่ MDE เท่าเดิม หรือข้อผิดพลาดที่ควรระวังในการวิเคราะห์ผล ไปอ่านเอาในหนังสือฮิปโปได้เลย

หลักสำคัญ ๆ สำหรับผมก็ประมาณนี้ครับ ในบล็อกนี้ผมตั้งใจไม่ได้ใส่รายละเอียดทางสถิติลงไปมากนัก และเน้นใช้เครื่องคิดเลขสำเร็จรูปเพื่อไม่ให้มันดูเข้าใจยากมากเกินไป (ตอนทำงานจริงส่วนใหญ่ผมก็ต้องขอความช่วยเหลือผู้เชี่ยวชาญจากทีม Data เป็นปกติครับสำหรับเคสยากๆ)

ซึ่งจริง ๆ แล้วมีรายละเอียดและเครื่องมือทางสถิติอีกค่อนข้างหลายประเด็นสำหรับผู้ที่สนใจแนวลึกเพิ่มเติม ขอแนะนำหนังสือฮิปโปเล่มนี้ครับ หลาย ๆ อย่างที่ผมพูดถึงในบทความนี้ในหนังสือจะมีตัวอย่างแบบละเอียดยิบให้อ่านอีกมากมายเลย

ขอบคุณที่อ่านจนจบครับ หวังว่าจะได้ประโยชน์บ้างไม่มากก็น้อย หากท่านใดมีคำถามหรือผมจุดที่ผมอาจเข้าใจคลาดเคลื่อนก็ฝากข้อความทาง Comment ได้เลยครับ

---

เกี่ยวกับผู้เขียน

ชื่อเล่นเอ็มครับ อยู่สายงาน IT มาเกิน 10 ปี มีประสบการณ์ทำงานตั้งแต่เป็น Software engineer เขียน Code เอง ทำ Agile ทำ Scrum Master เคยทำ UX มี Product เล็กๆ ส่วนตัวเป็นของตัวเอง และปัจจุบันเป็น Product Manager อยากพาทีมทำ Product ดีๆให้ user ได้ใช้และตอบโจทย์ธุรกิจ ตอนนี้มาหาประสบการณ์ทำ Product ที่เน้น Machine Learning อยู่ต่างประเทศครับ 🙂

---

และหากคุณชอบคอนเทนต์นี้ และอยากฟังเรื่องราวจาก Product People คนอื่น ๆ เพิ่มเติม อย่าลืมกดติดตาม PM Corner ผ่านช่องทางดังต่อไปนี้ได้เลย 

• Facebook Page: PM Corner Thailand
• Website: PM Corner
• Youtube: https://www.youtube.com/@pmcornerthailand (สำหรับรับชม live ย้อนหลัง)