คุณควรทำการทดสอบ A/B กี่ครั้งต่อเดือน

เป็นคำถามสำคัญที่ต้องพิจารณาเพื่อความสำเร็จของโปรแกรมการทดสอบของคุณ

เรียกใช้การทดสอบมากเกินไป และคุณอาจใช้ทรัพยากรโดยเปล่าประโยชน์โดยไม่ได้รับคุณค่ามากนักจากการทดสอบแต่ละครั้ง

แต่ทำการทดสอบน้อยเกินไป และคุณอาจพลาดโอกาสในการเพิ่มประสิทธิภาพที่สำคัญซึ่งอาจนำมาซึ่ง Conversion มากขึ้น

ดังนั้น จากปริศนานี้ จังหวะการทดสอบในอุดมคติคืออะไร

เพื่อช่วยตอบคำถามนี้ ทำให้ $en$e พิจารณาทีมทดลองที่ประสบความสำเร็จและก้าวหน้ามากที่สุดในโลก

Amazon เป็นชื่อหนึ่งที่อยู่ในใจ

ยักษ์ใหญ่ด้านอีคอมเมิร์ซยังเป็นยักษ์ใหญ่ด้านการทดลองอีกด้วย ในความเป็นจริง Amazon ได้รับการกล่าวขานว่าทำการทดลองมากกว่า 12,000 ครั้งต่อปี! จำนวนนี้แบ่งออกเป็นการทดสอบประมาณหนึ่งพันครั้งต่อเดือน

บริษัทต่างๆ เช่น Google และ Bing ของ Microsoft ได้รับการกล่าวขานว่าดำเนินไปในลักษณะเดียวกัน

จากข้อมูลของวิกิพีเดีย เครื่องมือค้นหายักษ์ใหญ่แต่ละแห่งทำการทดสอบ A/B มากกว่า 10,000 ครั้งต่อปี หรือประมาณ 800 ครั้งต่อเดือน

และไม่ใช่แค่เครื่องมือค้นหาเท่านั้นที่ทำงานในอัตรานี้

Booking.com เป็นอีกหนึ่งชื่อที่โดดเด่นในการทดลอง มีรายงานว่าเว็บไซต์จองการเดินทางทำการทดสอบมากกว่า 25,000 ครั้งต่อปี ซึ่งมีจำนวนมากกว่า 2,000 การทดสอบต่อเดือนหรือ 70 การทดสอบต่อวัน!

จากการศึกษาพบว่า บริษัทโดยเฉลี่ยทำการทดสอบเพียง 2-3 ครั้งต่อเดือน

ดังนั้น หากบริษัทส่วนใหญ่ทำการทดสอบเพียงไม่กี่ครั้งต่อเดือน แต่บางบริษัทที่ดีที่สุดในโลกทำการทดสอบเป็นพันครั้งต่อเดือน ตามหลักแล้วคุณควรทำการทดสอบกี่ครั้ง

ปัจจัย 6 ประการที่ต้องพิจารณาเมื่อรันการทดสอบ A/B

มีปัจจัยสำคัญ 6 ประการที่ต้องพิจารณาเมื่อตัดสินใจว่าจะทำการทดสอบกี่ครั้งต่อเดือน พวกเขารวมถึง

• ข้อกำหนดขนาดตัวอย่าง
• วุฒิภาวะขององค์กร
• ทรัพยากรที่มีอยู่
• ความซับซ้อนของแนวคิดการทดสอบ
• ระยะเวลาการทดสอบ
• ผลกระทบการโต้ตอบ

มาเจาะลึกกัน

ข้อกำหนดขนาดตัวอย่าง

ในการทดสอบ A/B ขนาดตัวอย่างจะอธิบายถึงปริมาณการเข้าชมที่คุณต้องการเพื่อเรียกใช้การทดสอบที่น่าเชื่อถือ

หากต้องการดำเนินการศึกษาที่ถูกต้องทางสถิติ คุณต้องมีตัวอย่างผู้ใช้จำนวนมากที่เป็นตัวแทน

แม้ว่าในทางทฤษฎีแล้ว คุณสามารถเรียกใช้การทดสอบกับผู้ใช้เพียงไม่กี่คน แต่คุณจะไม่ได้รับผลลัพธ์ที่มีความหมายมากนัก

ขนาดตัวอย่างต่ำยังสามารถให้ผลลัพธ์ที่มีนัยสำคัญทางสถิติ

ตัวอย่างเช่น ลองนึกภาพการทดสอบ A/B ที่มีผู้ใช้เพียง 10 คนเห็นเวอร์ชัน A และ 2 ที่แปลงแล้ว และมีผู้ใช้เพียง 8 รายที่เห็นเวอร์ชัน B โดยมี 6 รายที่แปลง

ดังที่แผนภูมินี้แสดงไว้ ผลลัพธ์มีนัยสำคัญทางสถิติ:

เวอร์ชัน B มีประสิทธิภาพดีกว่า 275% แต่การค้นพบนี้ไม่น่าเชื่อถือมากนัก ขนาดตัวอย่างต่ำเกินไปที่จะให้ผลลัพธ์ที่มีความหมาย

การศึกษามีน้อย ไม่มีตัวอย่างผู้ใช้จำนวนมากที่เป็นตัวแทน

เนื่องจากการทดสอบมีกำลังน้อย ผลลัพธ์จึงมีโอกาสเกิดข้อผิดพลาดได้ง่าย และยังไม่ชัดเจนว่าผลลัพธ์จะเกิดขึ้นโดยบังเอิญหรือเวอร์ชันใดเวอร์ชันหนึ่งดีกว่าจริงๆ

ด้วยตัวอย่างเล็กๆ นี้ ทำให้ง่ายต่อการสรุปผลที่ไม่ถูกต้อง

การทดสอบพลังงานอย่างเหมาะสม

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

ใหญ่แค่ไหนถึงจะพอ?

คำถามนี้สามารถตอบได้โดยการคำนวณขนาดตัวอย่างอย่างง่าย

เพื่อให้คำนวณข้อกำหนดด้านขนาดตัวอย่างของคุณได้ง่ายที่สุด ฉันขอแนะนำให้ใช้เครื่องคำนวณขนาดตัวอย่าง มีมากมายที่นั่น

สิ่งที่ฉันชอบคือของ Evan Miller เพราะมีความยืดหยุ่นและทั่วถึง นอกจากนี้ หากคุณเข้าใจวิธีใช้งาน คุณก็สามารถเข้าใจเครื่องคิดเลขได้เกือบทุกชนิด

นี่คือลักษณะของเครื่องคิดเลขของ Evan Miller:

แม้ว่าการคำนวณจะค่อนข้างง่าย แต่การทำความเข้าใจคำศัพท์ที่อยู่เบื้องหลังนั้นกลับไม่ใช่ ดังนั้นฉันจึงพยายามอธิบายความซับซ้อน:

อัตราการแปลงพื้นฐาน

อัตราการแปลงพื้นฐานคืออัตราการแปลงที่มีอยู่ของตัวควบคุมหรือรุ่นดั้งเดิม โดยปกติจะมีป้ายกำกับว่า "เวอร์ชัน A" เมื่อตั้งค่าการทดสอบ A/B

คุณควรจะพบอัตราการแปลงนี้ภายในแพลตฟอร์มการวิเคราะห์ของคุณ

หากคุณไม่เคยทำการทดสอบ A/B หรือไม่ทราบอัตรา Conversion พื้นฐาน ให้เดาอย่างมีการศึกษาดีที่สุด

อัตราการแปลงเฉลี่ยทั่วทั้งไซต์ ส่วนใหญ่ ประเภทอุตสาหกรรม และประเภทอุปกรณ์อยู่ระหว่าง 2 ถึง 5% ดังนั้น หากคุณไม่แน่ใจเกี่ยวกับอัตรา Conversion พื้นฐานของคุณจริงๆ ให้ลองระมัดระวังและเริ่มด้วยค่าพื้นฐาน 2%

ยิ่งอัตรา Conversion พื้นฐานต่ำ คุณก็ยิ่งต้องใช้ขนาดตัวอย่างมากเท่านั้น และในทางกลับกัน.

ผลการตรวจหาขั้นต่ำ (MDE)

เอฟเฟกต์ตรวจจับขั้นต่ำ (MDE) ฟังดูเหมือนเป็นแนวคิดที่ซับซ้อน แต่จะเข้าใจได้ง่ายกว่ามากหากคุณแบ่งคำศัพท์ออกเป็นสามส่วน:

• ต่ำสุด = น้อยที่สุด
• Detectable = ต้องการให้คุณพยายามตรวจจับหรือค้นหาโดยทำการทดสอบ
• ผลกระทบ = การเปลี่ยนแปลงความแตกต่างระหว่างการควบคุมและการรักษา

ดังนั้น ผลขั้นต่ำที่ตรวจพบได้คือการเพิ่ม Conversion ที่เล็กที่สุดที่คุณหวังว่าจะตรวจพบโดยเรียกใช้การทดสอบ

นักตรวจสอบข้อมูลบางคนจะโต้แย้งว่าคำจำกัดความนี้อธิบายถึงผลกระทบขั้นต่ำของดอกเบี้ย (MEI) ไม่ว่าคุณต้องการเรียกมันว่าอย่างไร เป้าหมายคือการคาดการณ์ว่า Conversion ที่เพิ่มขึ้นที่คุณคาดว่าจะได้รับจากการทดสอบนั้นมากเพียงใด

แม้ว่าแบบฝึกหัดนี้อาจดูเป็นการคาดเดา แต่คุณสามารถใช้เครื่องคำนวณขนาดตัวอย่างเช่นนี้หรือเครื่องคำนวณสถิติการทดสอบ A/B ของ Convert เพื่อคำนวณ MDE ที่คาดการณ์ไว้

ตามหลักการทั่วไปแล้ว MDE 2-5% ถือว่าสมเหตุสมผล สิ่งใดก็ตามที่สูงกว่ามักจะไม่สมจริงเมื่อใช้การทดสอบที่ใช้พลังงานอย่างเหมาะสมอย่างแท้จริง

ยิ่ง MDE มีขนาดเล็กเท่าใดก็ยิ่งต้องการขนาดตัวอย่างที่ใหญ่ขึ้นเท่านั้น และในทางกลับกัน.

MDE สามารถแสดงเป็นจำนวนสัมบูรณ์หรือสัมพัทธ์

แน่นอน

MDE สัมบูรณ์คือความแตกต่างของจำนวนดิบระหว่างอัตราการแปลงของการควบคุมและตัวแปร

ตัวอย่างเช่น หากอัตรา Conversion พื้นฐานคือ 2.77% และคุณคาดว่าตัวแปรจะได้รับ MDE สัมบูรณ์ +3% ความแตกต่างสัมบูรณ์คือ 5.77%

ญาติ

ในทางตรงกันข้าม เอฟเฟกต์สัมพัทธ์จะแสดงเปอร์เซ็นต์ความแตกต่างระหว่างตัวแปรต่างๆ

ตัวอย่างเช่น หากอัตรา Conversion พื้นฐานคือ 2.77% และคุณคาดว่าตัวแปรจะได้รับ MDE สัมพัทธ์ +3% ความแตกต่างสัมพัทธ์คือ 2.89%

โดยทั่วไป ผู้ทดสอบส่วนใหญ่ใช้การเพิ่มขึ้นเป็นเปอร์เซ็นต์สัมพัทธ์ ดังนั้น โดยทั่วไปแล้ว วิธีที่ดีที่สุดคือแสดงผลลัพธ์ด้วยวิธีนี้

กำลังทางสถิติ 1−β

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

ในการทดสอบ เป้าหมายของคุณคือเพื่อให้แน่ใจว่าคุณมีพลังมากพอที่จะตรวจหาความแตกต่างอย่างมีความหมาย หากมีอยู่ โดยไม่มีข้อผิดพลาด ดังนั้นพลังที่สูงกว่าย่อมดีกว่าเสมอ แต่ข้อเสียคือต้องใช้ขนาดตัวอย่างที่ใหญ่ขึ้น

ค่าพลัง 0.80 ถือเป็นแนวทางปฏิบัติที่ดีที่สุดมาตรฐาน ดังนั้น คุณสามารถปล่อยให้เป็นช่วงเริ่มต้นของเครื่องคิดเลขนี้

จำนวนนี้หมายความว่ามีโอกาส 80% ที่หากมีผลกระทบ คุณจะตรวจจับได้อย่างแม่นยำโดยไม่มีข้อผิดพลาด ด้วยเหตุนี้ จึงมีโอกาสเพียง 20% ที่คุณจะพลาดการตรวจหาเอฟเฟกต์อย่างถูกต้อง ความเสี่ยงที่คุ้มค่า

ระดับนัยสำคัญ α

ตามคำจำกัดความง่ายๆ ระดับนัยสำคัญอัลฟ่าคืออัตราผลบวกปลอม หรือเปอร์เซ็นต์ของเวลาที่ตรวจพบความแตกต่างของ Conversion แม้ว่าจะไม่มีอยู่จริงก็ตาม

ตามแนวทางปฏิบัติที่ดีที่สุดในการทดสอบ A/B ระดับนัยสำคัญของคุณควรเป็น 5% หรือต่ำกว่า ดังนั้นคุณสามารถปล่อยให้มันเป็นค่าเริ่มต้นของเครื่องคิดเลขนี้

ระดับนัยสำคัญ 5% α หมายความว่ามีโอกาส 5% ที่คุณจะพบความแตกต่างระหว่างส่วนควบคุมและตัวแปร — เมื่อไม่มีความแตกต่างอยู่จริง

อีกครั้งเป็นความเสี่ยงที่คุ้มค่า

การประเมินความต้องการขนาดตัวอย่างของคุณ

เมื่อเสียบตัวเลขเหล่านี้เข้ากับเครื่องคิดเลขแล้ว ตอนนี้คุณสามารถมั่นใจได้ว่าไซต์ของคุณมีปริมาณการเข้าชมเพียงพอที่จะเรียกใช้การทดสอบที่ขับเคลื่อนอย่างเหมาะสมในช่วงเวลาทดสอบมาตรฐาน 2 ถึง 6 สัปดาห์

หากต้องการยืนยัน ให้ไปที่แพลตฟอร์มการวิเคราะห์ที่คุณต้องการและดูอัตราการเข้าชมเฉลี่ยที่ผ่านมาของไซต์หรือหน้าที่คุณต้องการทดสอบในช่วงเวลาที่จำกัด

ตัวอย่างเช่น ในบัญชี Google Analytics 4 (GA4) นี้ เมื่อไปที่แท็บ วงจรชีวิต > การได้ผู้ใช้ใหม่ > ภาพรวมการได้ ผู้ใช้ใหม่ คุณจะเห็นว่ามีผู้ใช้ 365,000 คนในช่วงเวลาที่ผ่านมาล่าสุดระหว่างเดือนตุลาคมถึงพฤศจิกายน 2022:

อิงตามอัตราการแปลงพื้นฐานที่มีอยู่ 3.5% โดยมี MDE สัมพัทธ์ 5% ที่กำลังมาตรฐาน 80% และระดับนัยสำคัญมาตรฐาน 5% เครื่องคิดเลขแสดงขนาดตัวอย่างผู้เข้าชม 174,369 คนต่อรูปแบบที่จำเป็นเพื่อให้ทำงานอย่างถูกต้อง- ขับเคลื่อนการทดสอบ A/B:

สมมติว่าแนวโน้มการเข้าชมค่อนข้างคงที่ในเดือนต่อๆ ไป จึงมีเหตุผลที่จะคาดว่าไซต์จะมีผู้ใช้ประมาณ 365,000 คน หรือ (365,000/2 ตัวแปร) ผู้เข้าชม 182,000 คนต่อตัวแปรภายในกรอบเวลาทดสอบที่สมเหตุสมผล

บรรลุข้อกำหนดด้านขนาดตัวอย่างได้ ให้ไฟเขียวเพื่อดำเนินการทดสอบต่อไป

หมายเหตุสำคัญ ควรทำแบบฝึกหัดการตรวจสอบความต้องการขนาดตัวอย่างนี้ก่อนดำเนินการศึกษาใดๆ เสมอ เพื่อให้คุณทราบว่าคุณมีปริมาณการใช้งานเพียงพอที่จะเรียกใช้การทดสอบที่ขับเคลื่อนอย่างเหมาะสมหรือไม่

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

การประกาศผู้ชนะหรือผู้แพ้ก่อนเวลาอันควรก่อนที่จะบรรลุข้อกำหนดด้านขนาดตัวอย่างคือสิ่งที่เรียกว่า "การแอบดู" และเป็นวิธีการทดสอบที่เป็นอันตรายซึ่งอาจทำให้คุณโทรผิดก่อนที่ผลลัพธ์จะถูกล้างออกไปจนหมด

คุณสามารถเรียกใช้การทดสอบได้กี่ครั้งหากคุณมีปริมาณการใช้งานเพียงพอ

สมมติว่าไซต์หรือเพจที่คุณต้องการทดสอบตรงตามข้อกำหนดขนาดตัวอย่าง คุณสามารถเรียกใช้การทดสอบได้กี่ครั้ง

คำตอบคือ อีกครั้ง มันขึ้นอยู่กับ

จากการนำเสนอที่แบ่งปันโดย Ronny Kohavi อดีตรองประธานฝ่ายการทดลองที่ Bing ของ Microsoft โดยทั่วไปแล้ว Microsoft จะทำการทดลองมากกว่า 300 ครั้งต่อวัน

แต่พวกเขามีการจราจรที่ต้องทำ

การทดลองแต่ละครั้งจะเห็นผู้ใช้มากกว่า 100,000 คน:

ยิ่งปริมาณการใช้งานของคุณมีมากเท่าใด คุณก็ยิ่งสามารถเรียกใช้การทดสอบได้มากขึ้นเท่านั้น

ในการทดสอบใดๆ คุณต้องแน่ใจว่าคุณมีขนาดตัวอย่างที่ใหญ่พอที่จะเรียกใช้การทดสอบที่ขับเคลื่อนอย่างถูกต้อง

หากคุณเป็นองค์กรขนาดเล็กที่มีการรับส่งข้อมูลจำกัด ให้พิจารณาการทดสอบคุณภาพสูงน้อยลง

ท้ายที่สุดแล้ว มันไม่ได้เกี่ยวกับจำนวนการทดสอบที่คุณใช้ แต่เป็นผลลัพธ์ของการทดสอบของคุณ

ตัวเลือกหากคุณไม่สามารถปฏิบัติตามข้อกำหนดด้านขนาดตัวอย่างได้

หากคุณพบว่าไม่ตรงตามข้อกำหนดด้านขนาดตัวอย่าง ไม่ต้องกังวล การทดลองไม่ได้อยู่นอกตารางสำหรับคุณ คุณมีตัวเลือกการทดสอบที่เป็นไปได้ไม่กี่รายการ:

1. มุ่งเน้นไปที่การได้มาซึ่งทราฟฟิก

แม้แต่ไซต์ขนาดใหญ่ก็สามารถมีปริมาณการเข้าชมต่ำในบางหน้า

หากคุณพบว่าการเข้าชมไซต์หรือการเข้าชมในบางหน้าไม่เป็นไปตามข้อกำหนดด้านขนาดตัวอย่าง ให้พิจารณาเน้นความพยายามในการรับการเข้าชมให้มากขึ้น

ในการทำเช่นนั้น คุณสามารถใช้กลยุทธ์การปรับแต่งเว็บไซต์ให้ติดอันดับบนเครื่องมือการค้นหา (SEO) เชิงรุกเพื่อให้อันดับสูงขึ้นในเครื่องมือค้นหาและรวบรวมจำนวนคลิกมากขึ้น

คุณยังสามารถรับการเข้าชมที่เสียค่าใช้จ่ายผ่านช่องทางต่างๆ เช่น Google Ads, โฆษณา LinkedIn หรือแม้แต่โฆษณาแบนเนอร์

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

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

2. ประเมินว่าการทดสอบ A/B เป็นวิธีการทดสอบที่ดีที่สุดสำหรับคุณหรือไม่

แม้ว่าการทดสอบ A/B ถือเป็นมาตรฐานสูงสุดของการทดสอบ แต่ผลลัพธ์จะดีเท่ากับข้อมูลที่อยู่เบื้องหลังเท่านั้น

หากคุณพบว่ามีการเข้าชมไม่เพียงพอที่จะเรียกใช้การทดสอบที่เหมาะสม คุณอาจต้องพิจารณาว่าการทดสอบ A/B เป็นตัวเลือกการทดสอบที่ดีที่สุดสำหรับคุณจริงๆ หรือไม่

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

การทดสอบประสบการณ์ผู้ใช้ (UX) การสำรวจผู้บริโภค การสำรวจความคิดเห็น หรือการสัมภาษณ์ลูกค้าเป็นรูปแบบการทดสอบอื่นๆ อีกสองสามรูปแบบที่คุณสามารถลองใช้แทนการทดสอบ A/B

3. ผลลัพธ์ของ Realize อาจให้ข้อมูลทิศทางเท่านั้น

แต่ถ้าคุณยังคงตั้งใจทำการทดสอบ A/B คุณก็ยังสามารถเรียกใช้การทดสอบได้

เพิ่งตระหนักว่าผลลัพธ์อาจไม่ถูกต้องทั้งหมดและจะให้เพียง "ข้อมูลทิศทาง" ซึ่งบ่งชี้ถึงผลลัพธ์ที่น่าจะเป็นไปได้มากกว่าที่จะเชื่อถือได้ทั้งหมด

เนื่องจากผลลัพธ์ที่ได้อาจไม่เป็นจริงทั้งหมด คุณจึงต้องเฝ้าติดตามผลการแปลงอย่างใกล้ชิดเมื่อเวลาผ่านไป

อย่างไรก็ตาม สิ่งที่สำคัญกว่าตัวเลข Conversion ที่แม่นยำคือตัวเลขในบัญชีธนาคาร หากกำลังเพิ่มขึ้น คุณจะรู้ว่างานเพิ่มประสิทธิภาพที่คุณกำลังทำอยู่นั้นได้ผล

วุฒิภาวะการทดสอบ

นอกจากข้อกำหนดด้านขนาดตัวอย่างแล้ว ปัจจัยอีกประการหนึ่งที่มีอิทธิพลต่อจังหวะการทดสอบคือระดับวุฒิภาวะขององค์กรทดสอบ

วุฒิภาวะในการทดสอบเป็นคำที่ใช้เพื่ออธิบายว่าการทดลองที่ยึดมั่นอยู่ภายในวัฒนธรรมองค์กรเป็นอย่างไร และวิธีปฏิบัติในการทดลองขั้นสูงเป็นอย่างไร

องค์กรต่างๆ เช่น Amazon, Google, Bing และ Booking ซึ่งดำเนินการทดสอบหลายพันรายการต่อเดือน มีทีมทดสอบที่ก้าวหน้าและเป็นผู้ใหญ่

นั่นไม่ใช่เรื่องบังเอิญ

จังหวะการทดสอบมีแนวโน้มที่จะเชื่อมโยงอย่างใกล้ชิดกับระดับวุฒิภาวะขององค์กร

หากการทดลองนั้นฝังแน่นภายในองค์กร ฝ่ายบริหารก็มุ่งมั่นที่จะทำสิ่งนั้น เช่นเดียวกัน พนักงานทั่วทั้งองค์กรมักได้รับการสนับสนุนให้สนับสนุนและจัดลำดับความสำคัญของการทดลอง และอาจช่วยเสนอแนวคิดในการทดสอบด้วย

เมื่อปัจจัยเหล่านี้มารวมกัน การเรียกใช้โปรแกรมทดสอบที่เหมาะสมจะง่ายขึ้นมาก

หากคุณต้องการเพิ่มการทดสอบ การดูระดับวุฒิภาวะขององค์กรของคุณก่อนอาจเป็นประโยชน์

เริ่มต้นด้วยการประเมินคำถามเช่น

• การทดลองมีความสำคัญอย่างไรกับ C-Suite?
• มีแหล่งข้อมูลใดบ้างที่สนับสนุนการทดลอง
• มีช่องทางการสื่อสารอะไรบ้างในการสื่อสารการอัปเดตการทดสอบ

หากคำตอบคือ “ไม่มี” หรือใกล้เคียง ให้ลองสร้างวัฒนธรรมการทดสอบก่อน

เมื่อองค์กรของคุณรับเอาวัฒนธรรมการทดลองที่ก้าวหน้ามากขึ้น การเพิ่มจังหวะการทดสอบก็จะง่ายขึ้นโดยธรรมชาติ

สำหรับคำแนะนำเกี่ยวกับวิธีสร้างวัฒนธรรมแห่งการทดลอง โปรดดูแหล่งข้อมูลต่างๆ เช่น บทความนี้และบทความนี้

ข้อจำกัดด้านทรัพยากร

สมมติว่าคุณมีการซื้อในองค์กรในระดับหนึ่งแล้ว ปัญหาต่อไปที่ต้องต่อสู้คือข้อจำกัดด้านทรัพยากร

เวลา เงิน และกำลังคนล้วนเป็นข้อจำกัดที่อาจจำกัดความสามารถในการทดสอบของคุณ และทดสอบได้อย่างรวดเร็ว.

เพื่อเอาชนะข้อจำกัดด้านทรัพยากร การเริ่มต้นด้วยการประเมินความซับซ้อนของการทดสอบจะเป็นประโยชน์

ปรับสมดุลการทดสอบที่ง่ายและซับซ้อน

ในฐานะนักทดลอง คุณอาจเลือกทำการทดสอบที่มีตั้งแต่แบบง่ายๆ ไปจนถึงแบบซับซ้อนบ้าๆ

การทดสอบง่ายๆ อาจรวมถึงการเพิ่มประสิทธิภาพองค์ประกอบต่างๆ เช่น การคัดลอกหรือสี การอัปเดตรูปภาพ หรือการย้ายองค์ประกอบเดียวในหน้า

การทดสอบที่ซับซ้อนอาจเกี่ยวข้องกับการเปลี่ยนแปลงองค์ประกอบหลายอย่าง การเปลี่ยนแปลงโครงสร้างหน้า หรือการอัปเดตช่องทางการแปลง การทดสอบประเภทนี้มักต้องการการเขียนโค้ดเชิงลึก

จากการเรียกใช้การทดสอบ A/B นับพันครั้ง ฉันพบว่ามีประโยชน์ที่จะมีการทดสอบแบบผสมผสานระหว่าง ⅗ ที่ง่ายกว่าและ ⅖ ที่ซับซ้อนกว่า ซึ่งทำงานพร้อมกันตลอดเวลา

การทดสอบที่เรียบง่ายสามารถทำให้คุณชนะได้อย่างรวดเร็วและง่ายดาย

แต่การทดสอบที่ใหญ่กว่า การเปลี่ยนแปลงที่ใหญ่กว่า มักจะให้ผลลัพธ์ที่ใหญ่กว่า ในความเป็นจริง จากการวิจัยการเพิ่มประสิทธิภาพ ยิ่งคุณทำการทดสอบมากขึ้นและซับซ้อนมากเท่าไหร่ คุณก็ยิ่งมีโอกาสประสบความสำเร็จมากขึ้นเท่านั้น ดังนั้นอย่ากลัวที่จะทำการทดสอบวงสวิงใหญ่ๆ บ่อยๆ

โปรดทราบว่าข้อเสียคือคุณจะต้องใช้ทรัพยากรมากขึ้นในการออกแบบและสร้างแบบทดสอบ และไม่มีการรับประกันว่าจะชนะ

ทดสอบตามทรัพยากรบุคคลที่มีอยู่

หากคุณเป็นนักวางกลยุทธ์ CRO คนเดียวหรือทำงานกับทีมขนาดเล็ก ความสามารถของคุณมีจำกัด ไม่ว่าจะง่ายหรือซับซ้อน คุณอาจพบว่าการทดสอบ 2-5 ครั้งต่อเดือนทำให้คุณสนใจ

ในทางตรงกันข้าม หากคุณอยู่ในองค์กรที่มีทีมนักวิจัย นักวางกลยุทธ์ นักออกแบบ นักพัฒนา และผู้เชี่ยวชาญด้าน QA ที่ทุ่มเท คุณน่าจะมีความสามารถในการทำการทดสอบหลายสิบถึงหลายร้อยครั้งต่อเดือน

หากต้องการกำหนดจำนวนการทดสอบที่คุณควรทำ ให้ประเมินความพร้อมของทรัพยากรบุคคล

โดยเฉลี่ยแล้ว การทดสอบอย่างง่ายอาจใช้เวลา 3-6 ชั่วโมงในการคิด สร้าง Wireframe ออกแบบ พัฒนา นำไปใช้ QA และติดตามผล

ในทางกลับกัน การทดสอบที่ซับซ้อนมากอาจใช้เวลามากกว่า 15-20 ชั่วโมง

หนึ่งเดือนมีประมาณ 730 ชั่วโมง ดังนั้นคุณจะต้องมีการคำนวณอย่างมากเกี่ยวกับการทดสอบและจำนวนการทดสอบที่คุณกำลังดำเนินการในช่วงเวลาอันมีค่านี้

วางแผนและจัดลำดับความสำคัญของแนวคิดการทดสอบของคุณ

เพื่อช่วยคุณกำหนดโครงสร้างการทดสอบที่เหมาะสมที่สุด ให้ลองใช้กรอบการจัดลำดับความสำคัญของการทดสอบ เช่น PIE, ICE หรือ PXL

เฟรมเวิร์กเหล่านี้เป็นเทคนิคเชิงปริมาณสำหรับจัดอันดับแนวคิดการทดสอบยอดนิยมของคุณ ประเมินความง่ายในการใช้งาน และประเมินว่าการทดสอบใดมีแนวโน้มที่จะเพิ่ม Conversion ได้มากที่สุด

เมื่อทำการประเมินนี้ รายการแนวคิดการทดสอบที่จัดลำดับความสำคัญของคุณจะมีลักษณะดังนี้:

ด้วยการจัดอันดับแนวคิดการทดสอบยอดนิยมของคุณ ขอแนะนำให้คุณสร้างแผนการทดสอบเพื่อวางแผนไทม์ไลน์การทดสอบและขั้นตอนต่อไปด้วยภาพ

แผนงานของคุณอาจมีลักษณะดังนี้:

ควรรวมถึง:

• รายการแนวคิดที่คุณวางแผนจะทดสอบ แบ่งตามหน้า
• ระยะเวลาที่คุณคาดหวังในแต่ละขั้นตอนการทดสอบ (การออกแบบ การพัฒนา QA ฯลฯ) จะใช้เวลานานเท่าใด
• ระยะเวลาที่คุณวางแผนจะทำการทดสอบแต่ละครั้ง โดยอิงตามข้อกำหนดขนาดตัวอย่างที่คำนวณไว้ล่วงหน้า คุณสามารถคำนวณข้อกำหนดระยะเวลาการทดสอบได้โดยใช้เครื่องคำนวณระยะเวลาการทดสอบเช่นนี้

ด้วยการแมปแนวคิดการทดสอบของคุณ คุณจะสามารถกำหนดจังหวะการทดสอบและความสามารถได้แม่นยำยิ่งขึ้น

เมื่อคุณเติมแผนการทดสอบของคุณ อาจเห็นได้ชัดว่าจำนวนการทดสอบที่คุณเรียกใช้ได้นั้นขึ้นอยู่กับทรัพยากรที่คุณมี

คุณควรทำการทดสอบหลายครั้งพร้อมกันหรือไม่

แต่เพียงเพราะคุณสามารถทำบางสิ่งได้ ไม่ได้หมายความว่าคุณควรทำอย่างนั้นเสมอไป

เมื่อพูดถึงการทดสอบหลายรายการพร้อมกัน มีการถกเถียงกันอย่างมากเกี่ยวกับแนวทางที่ดีที่สุด

บทความ เช่น บทความนี้ โดยผู้นำประเทศแห่งการทดลอง Rommil Santiago นำเสนอคำถามที่ถกเถียงกัน: เป็นไปได้ไหมที่จะทำการทดสอบ A/B หลายรายการพร้อมกัน

นักทดลองบางคนจะบอกว่า ไม่เลย!

พวกเขาจะโต้แย้งว่าคุณควรทำการทดสอบเพียงครั้งเดียว ทีละหน้าเท่านั้น มิฉะนั้น คุณจะไม่สามารถแยกเอฟเฟกต์ใดๆ ได้อย่างถูกต้อง

ฉันเคยอยู่ในค่ายนี้เพราะเป็นวิธีที่ฉันได้รับการสอนเมื่อเกือบทศวรรษที่แล้ว

ฉันได้รับการบอกกล่าวอย่างเคร่งครัดว่าคุณควรจะทำการทดสอบเพียงครั้งเดียว โดยมีการเปลี่ยนแปลงเพียงครั้งเดียว ในหน้าเดียว ในคราวเดียว ฉันดำเนินการด้วยความคิดนี้มาหลายปี — สร้างความผิดหวังให้กับลูกค้าที่วิตกกังวลซึ่งต้องการผลลัพธ์ที่เร็วขึ้น

อย่างไรก็ตาม บทความนี้โดย Timothy Chan อดีตนักวิทยาศาสตร์ข้อมูลที่ Facebook และตอนนี้เป็นหัวหน้านักวิทยาศาสตร์ข้อมูลของ Statsig ทำให้ความคิดของฉันเปลี่ยนไปอย่างสิ้นเชิง

ในผลงานของเขา Chan ให้เหตุผลว่าเอฟเฟกต์การโต้ตอบนั้นเกินจริงไปมาก

ในความเป็นจริง การทดสอบหลายรายการพร้อมกันไม่ได้เป็นเพียงปัญหาเท่านั้น มันเป็นวิธีเดียวที่จะทดสอบ!

จุดยืนนี้ได้รับการสนับสนุนจากข้อมูลจากเวลาที่เขาอยู่ที่ Facebook ซึ่ง Chan ได้เห็นสื่อสังคมออนไลน์ยักษ์ใหญ่นี้ประสบความสำเร็จในการดำเนินการทดสอบหลายร้อยรายการพร้อมกัน หลายๆ การทดสอบทำได้ในหน้าเดียวกัน

ผู้เชี่ยวชาญด้านข้อมูลเช่น Ronny Kohavi และ Hazjier Pourkhalkhali เห็นพ้องกันว่า: ผลกระทบจากการโต้ตอบนั้นไม่น่าเป็นไปได้สูง และอันที่จริง วิธีทดสอบความสำเร็จที่ดีที่สุดคือทำการทดสอบหลายๆ ครั้งอย่างต่อเนื่อง

ดังนั้น เมื่อพิจารณาการทดสอบจังหวะ ไม่ต้องกังวลเกี่ยวกับผลของการโต้ตอบของการทดสอบที่ทับซ้อนกัน ทดสอบอย่างเสรี

สรุป

ในการทดสอบ A/B ไม่มีจำนวนการทดสอบ A/B ที่เหมาะสมที่สุดที่คุณควรทำ

หมายเลขในอุดมคติคือสิ่งที่เหมาะกับสถานการณ์เฉพาะของคุณ

ตัวเลขนี้ขึ้นอยู่กับปัจจัยหลายประการ รวมถึงข้อจำกัดของขนาดตัวอย่างไซต์ของคุณ ความซับซ้อนของแนวคิดในการทดสอบ และการสนับสนุนและทรัพยากรที่มี

ท้ายที่สุดแล้ว มันไม่ได้เกี่ยวกับจำนวนการทดสอบที่คุณเรียกใช้มากนัก แต่เป็นเรื่องของคุณภาพของการทดสอบและผลลัพธ์ที่คุณได้รับ การทดสอบเพียงครั้งเดียวที่ทำให้เกิดการยกขนาดใหญ่นั้นมีค่ามากกว่าการทดสอบที่สรุปไม่ได้ซึ่งไม่ได้ขยับเข็ม

การทดสอบนั้นเกี่ยวกับคุณภาพมากกว่าปริมาณอย่างแท้จริง!

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้โปรแกรมการทดสอบ A/B ให้เกิดประโยชน์สูงสุด โปรดดูบทความ Convert นี้