57 ข้อผิดพลาดในการทดสอบ A/B ทั่วไป & วิธีหลีกเลี่ยง

เผยแพร่แล้ว: 2021-06-15
57 ข้อผิดพลาดในการทดสอบ A/B ทั่วไป & วิธีหลีกเลี่ยง

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

คุณต้องการเรียนรู้ข้อผิดพลาดทั่วไปเมื่อทำการทดสอบ A/B เพื่อไม่ให้เสียเวลาอันมีค่าไปกับแคมเปญที่เสียหายหรือไม่

ข่าวดี! ในบทความนี้ เราจะแนะนำคุณเกี่ยวกับข้อผิดพลาดในการทดสอบ A/B ทั่วไป 57 ข้อ (และบางครั้งไม่ปกติ) ที่เราเห็น เพื่อให้คุณสามารถหลีกเลี่ยงข้อผิดพลาดเหล่านี้หรือตระหนักได้ว่าเกิดขึ้นเมื่อใด และแก้ไขปัญหาอย่างรวดเร็ว

เราได้แบ่งสิ่งเหล่านี้ออกเป็น 3 ส่วนหลัก:

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

คุณสามารถอ่านและดูว่าคุณกำลังสร้างสิ่งเหล่านี้เองหรือไม่

และจำไว้ว่า:

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

เลยดำดิ่งลงไป…

ซ่อน
  • ข้อผิดพลาดในการทดสอบ A/B ทั่วไปที่สามารถทำได้ก่อนที่คุณจะทำการทดสอบด้วยซ้ำ
    • #1. ดันของสดก่อนทดสอบ!
    • #2. ไม่ได้ทำการทดสอบ A/B จริง
    • #3. ไม่ทดสอบเพื่อดูว่าเครื่องมือใช้งานได้หรือไม่
    • #4. การใช้เครื่องมือคุณภาพต่ำและการกะพริบของเนื้อหา
    • #5. ไม่มีการทดสอบ QA
    • #6. การรักษา/รูปแบบใหม่นี้ใช้ได้ผลหรือไม่?
    • #7. ไม่ทำตามสมมุติฐาน แค่ทดสอบของเก่า
    • #8. มีสมมติฐานที่พิสูจน์ไม่ได้
    • #9. ไม่ได้กำหนดเป้าหมายที่ชัดเจนสำหรับการทดสอบของคุณล่วงหน้า
    • #10. มุ่งเน้นไปที่เมตริกผิวเผิน
    • #11. ใช้ข้อมูลเชิงปริมาณเพื่อสร้างแนวคิดการทดสอบเท่านั้น
    • #12. ลอกเลียนคู่แข่ง
    • #13. การทดสอบเฉพาะ 'แนวทางปฏิบัติที่ดีที่สุดสำหรับอุตสาหกรรม'
    • #14. มุ่งเน้นไปที่งานที่มีแรงกระแทกน้อยก่อน เมื่อมีผลกระทบสูงรางวัลใหญ่/ผลห้อยต่ำมีอยู่
    • #15. ทดสอบหลายๆ อย่างพร้อมกันและไม่รู้ว่าการเปลี่ยนแปลงใดทำให้เกิดผลลัพธ์
    • #16. ไม่ใช้การวิเคราะห์ก่อนการทดสอบที่เหมาะสม
    • #17. การติดฉลากการทดสอบผิด
    • #18. เรียกใช้การทดสอบไปยัง URL ที่ไม่ถูกต้อง
    • #19. การเพิ่มกฎการแสดงผลตามอำเภอใจให้กับการทดสอบของคุณ
    • #20. การทดสอบการเข้าชมที่ไม่ถูกต้องสำหรับเป้าหมายของคุณ
    • #21. ล้มเหลวในการยกเว้นผู้เข้าชมที่กลับมาในการทดสอบและบิดเบือนผลลัพธ์
    • #22. ไม่ลบ IP ของคุณออกจากการทดสอบ
    • #23. ไม่แบ่งกลุ่มรูปแบบกลุ่มควบคุม (ผลกระทบจากเครือข่าย)
    • #24. ดำเนินการทดสอบระหว่างกิจกรรมตามฤดูกาลหรือเหตุการณ์สำคัญในไซต์/แพลตฟอร์ม
    • #25. ละเลยความแตกต่างทางวัฒนธรรม
    • #26. ใช้งานแคมเปญที่เชื่อมต่อหลายรายการพร้อมกัน
    • #27. น้ำหนักจราจรไม่เท่ากัน
  • ข้อผิดพลาดในการทดสอบ A/B ทั่วไปที่คุณสามารถทำได้ระหว่างการทดสอบ
    • #28. ไม่วิ่งนานพอที่จะได้ผลลัพธ์ที่แม่นยำ
    • #29. การตรวจสอบ / แอบดูเฮลิคอปเตอร์
    • #30. ไม่ติดตามความคิดเห็นของผู้ใช้ (สำคัญอย่างยิ่งหากการทดสอบส่งผลกระทบโดยตรงต่อการดำเนินการในทันที)
    • #31. การเปลี่ยนแปลงระหว่างการทดสอบ
    • #32. การเปลี่ยน % ของการจัดสรรการรับส่งข้อมูลระหว่างการทดสอบหรือการเอาผลงานที่ไม่ดีออก
    • #33. ไม่หยุดการทดสอบเมื่อคุณได้ผลลัพธ์ที่แม่นยำ
    • #34. การลงทุนทางอารมณ์ในการสูญเสียความหลากหลาย
    • #35. ดำเนินการทดสอบนานเกินไปและการติดตามลดลง
    • #36. ไม่ใช้เครื่องมือที่ให้คุณหยุด/ดำเนินการทดสอบได้!
  • ข้อผิดพลาดในการทดสอบ A/B ทั่วไปที่คุณสามารถทำได้หลังจากการทดสอบเสร็จสิ้น
    • #37. ยอมแพ้หลังสอบครั้งเดียว!
    • #38. เลิกตั้งสมมติฐานดีๆ ก่อนทดสอบทุกเวอร์ชั่น
    • #39. คาดหวังชัยชนะครั้งใหญ่ตลอดเวลา
    • #40. ไม่ตรวจสอบความถูกต้องหลังการทดสอบ
    • #41. อ่านผลลัพธ์ไม่ถูกต้อง
    • #42. ไม่ดูผลลัพธ์ตามเซกเมนต์
    • #43. ไม่ได้เรียนรู้จากผลลัพธ์
    • #44. รับผู้แพ้
    • #45. ไม่ดำเนินการกับผลลัพธ์
    • #46. ไม่ทำซ้ำและปรับปรุงในการชนะ
    • #47. ไม่แชร์ผลงานที่ชนะในด้านหรือแผนกอื่น
    • #48. ไม่ได้ทดสอบการเปลี่ยนแปลงเหล่านั้นในแผนกอื่น
    • #49. ซ้ำมากเกินไปในหน้าเดียว
    • #50. สอบไม่พอ!
    • #51. ไม่บันทึกการทดสอบ
    • #52. ลืมเกี่ยวกับผลบวกที่ผิดพลาดและไม่ตรวจสอบแคมเปญที่เพิ่มขึ้นอย่างมาก
    • #53. ไม่ติดตามผลดาวน์ไลน์
    • #54. ล้มเหลวในการคำนึงถึงความเป็นอันดับหนึ่งและความแปลกใหม่ซึ่งอาจทำให้ผลการรักษามีอคติ
    • #55. ดำเนินการเปลี่ยนแปลงระยะเวลาการพิจารณา
    • #56. ไม่ทำการทดสอบซ้ำหลังจาก X time
    • #57. ทดสอบเส้นทางเท่านั้นไม่ใช่ผลิตภัณฑ์
  • บทสรุป

ข้อผิดพลาดในการทดสอบ A/B ทั่วไปที่สามารถทำได้ก่อนที่คุณจะทำการทดสอบด้วยซ้ำ

#1. ดันของสดก่อนทดสอบ!

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

ออกจาก!

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

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

#2. ไม่ได้ทำการทดสอบ A/B จริง

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

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

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

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

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

#3. ไม่ทดสอบเพื่อดูว่าเครื่องมือใช้งานได้หรือไม่

ไม่มีเครื่องมือทดสอบใดที่แม่นยำ 100% สิ่งที่ดีที่สุดที่คุณสามารถทำได้เมื่อเริ่มต้นคือเรียกใช้การทดสอบ A/A เพื่อดูว่าเครื่องมือของคุณแม่นยำเพียงใด

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

แปลงประสบการณ์การทดสอบ A/A
วิธีเรียกใช้ A/A Experiments

ทำไม

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

บางครั้งก็ไม่ใช่ ซึ่งหมายความว่าเครื่องมือของคุณอาจได้รับการตั้งค่าอย่างไม่ถูกต้อง ดังนั้น โปรดตรวจสอบเครื่องมือทดสอบของคุณก่อนใช้งานแคมเปญใดๆ

#4. การใช้เครื่องมือคุณภาพต่ำและการกะพริบของเนื้อหา

เครื่องมือบางอย่างไม่ดีเท่าเครื่องมืออื่น พวกเขาทำงานแต่ต้องดิ้นรนภายใต้สภาพการจราจรหรือ 'กะพริบ' และกะพริบ

แปลงประสบการณ์ SmartInsert ลบการสั่นไหว
เราสร้างวิธีการที่เป็นกรรมสิทธิ์ของเราเองเพื่อหยุดการทดสอบที่ส่งผลต่อการกะพริบตา

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

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

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

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

ตรวจสอบให้แน่ใจว่าคุณมีเครื่องมือที่ดีพอที่จะทดสอบด้วย

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

#5. ไม่มีการทดสอบ QA

ข้อผิดพลาดที่ง่ายสุด ๆ แต่คุณได้ตรวจสอบแล้วว่าทุกอย่างใช้งานได้หรือไม่?

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

ทั้งหมดนี้เป็นสิ่งที่ควรค่าแก่การตรวจสอบ ก่อนที่คุณจะเริ่มแสดงการเข้าชมไปยังแคมเปญใดๆ

PRO-TIP

รับรายการตรวจสอบการรับประกันคุณภาพสำหรับการทดสอบ A/B เป็น PDF ที่กรอกได้ ซึ่งคุณจะต้องกลับไปทุกครั้งที่ทำการทดสอบ QA

#6. การรักษา/รูปแบบใหม่นี้ใช้ได้ผลหรือไม่?

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

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

#7. ไม่ทำตามสมมุติฐาน แค่ทดสอบของเก่า

บางคนแค่ทดสอบอะไรโดยไม่ได้ไตร่ตรองจริงๆ

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

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

สมมติฐานคืออะไร?
คุณสามารถสร้างสมมติฐานโดยใช้โปรแกรมสร้างฟรีของเราที่นี่

#8. มีสมมติฐานที่พิสูจน์ไม่ได้

ไม่ใช่ทุกสมมติฐานที่ถูกต้อง นี้เป็นเรื่องปกติ อันที่จริง คำนี้หมายถึง 'ฉันมีแนวคิดจากข้อมูล X และฉันคิดว่า Y อาจเกิดขึ้นในสถานการณ์ Z'

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

#9. ไม่ได้กำหนดเป้าหมายที่ชัดเจนสำหรับการทดสอบของคุณล่วงหน้า

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

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

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

ที่พูดถึง…

#10. มุ่งเน้นไปที่เมตริกผิวเผิน

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

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

ต่อไปนี้คือรายการเมตริกรั้วทั่วไปของ Ben Labay สำหรับโปรแกรมการทดลอง:

#11. ใช้ข้อมูลเชิงปริมาณเพื่อสร้างแนวคิดการทดสอบเท่านั้น

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

ทำไม

เราสามารถทราบได้จากข้อมูลของเราว่า X จำนวนคนไม่ได้คลิก แต่เราอาจไม่รู้ว่าทำไม

  • ปุ่มอยู่ต่ำเกินไปในหน้า?
  • ไม่ชัดเจน?
  • สอดคล้องกับสิ่งที่ผู้ชมต้องการหรือไม่?
  • มันทำงานได้หรือยัง?

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

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

#12. ลอกเลียนคู่แข่ง

พร้อมสำหรับความลับ?

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

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

#13. การทดสอบเฉพาะ 'แนวทางปฏิบัติที่ดีที่สุดสำหรับอุตสาหกรรม'

อีกครั้ง สิ่งที่ใช้ได้ผลกับคนคนหนึ่งไม่ใช่สิ่งที่ได้ผลเสมอไป

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

#14. มุ่งเน้นไปที่งานที่มีแรงกระแทกน้อยก่อน เมื่อมีผลกระทบสูงรางวัลใหญ่/ผลห้อยต่ำมีอยู่

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

ประเด็นก็คือ ตอนนี้อาจมีหน้าที่สำคัญกว่าที่คุณจะทดสอบได้

จัดลำดับความสำคัญของผลกระทบมากที่สุด:

  • เพจนี้จะส่งผลโดยตรงต่อยอดขายหรือไม่?
  • มีหน้าอื่นในกระบวนการขายที่มีประสิทธิภาพต่ำกว่ามาตรฐานหรือไม่?

ถ้าใช่ ให้เน้นที่สิ่งเหล่านั้นก่อน

การเพิ่มขึ้น 1% ในหน้าการขายนั้นยอดเยี่ยม แต่การเพิ่มขึ้น 20% บนหน้าที่ทำให้พวกเขาอยู่ที่นั่นอาจมีความสำคัญมากกว่านั้นมาก (โดยเฉพาะอย่างยิ่งถ้าหน้านั้นเป็นที่ที่คุณสูญเสียผู้ชมส่วนใหญ่)

บางครั้งเราไม่เพียงแต่มองหาการยกระดับที่มากขึ้น แต่ยังเพื่อแก้ไขสิ่งที่เป็นคอขวดแทน

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

#15. ทดสอบหลายๆ อย่างพร้อมกันและไม่รู้ว่าการเปลี่ยนแปลงใดทำให้เกิดผลลัพธ์

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

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

แต่อย่าลืมว่า ไม่ใช่ทุกการทดสอบ A/B ที่ควรมีไว้เพื่อการเปลี่ยนแปลงที่รุนแรงเช่นนี้ 99% ของเวลาที่เราแค่ทดสอบการเปลี่ยนแปลงของสิ่งเดียว เช่น

  • พาดหัวข่าวใหม่
  • ภาพใหม่
  • เค้าโครงใหม่ของเนื้อหาเดียวกัน
  • ราคาใหม่ ฯลฯ

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

#16. ไม่ใช้การวิเคราะห์ก่อนการทดสอบที่เหมาะสม

คุณมีผู้เข้าชมในกลุ่มทดสอบเพียงพอหรือไม่ การทดสอบนั้นคุ้มค่ากับเวลาของคุณหรือไม่?

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

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

#17. การติดฉลากการทดสอบผิด

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

ตรวจสอบซ้ำเสมอ!

#18. เรียกใช้การทดสอบไปยัง URL ที่ไม่ถูกต้อง

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

อาจดูโอเคสำหรับคุณ แต่จริงๆ แล้วจะไม่โหลดสำหรับผู้ชมของคุณ

#19. การเพิ่มกฎการแสดงผลตามอำเภอใจให้กับการทดสอบของคุณ

อีกครั้ง คุณต้องทดสอบสิ่งหนึ่งกับการรักษาของคุณและไม่ต้องทำอย่างอื่น

ถ้าเป็นภาพก็ทดสอบภาพครับ อย่างอื่นควรเหมือนกันหมด รวมถึงเวลาที่คนดูทั้งสองหน้าได้!

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

ตัวอย่างเช่น การเข้าชมบล็อกของเราลดลงในช่วงสุดสัปดาห์ (เช่น บล็อกธุรกิจส่วนใหญ่)

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

#20. การทดสอบการเข้าชมที่ไม่ถูกต้องสำหรับเป้าหมายของคุณ

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

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

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

#21. ล้มเหลวในการยกเว้นผู้เข้าชมที่กลับมาในการทดสอบและบิดเบือนผลลัพธ์

เราเรียกสิ่งนี้ว่ามลภาวะตัวอย่าง

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

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

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

#22. ไม่ลบ IP ของคุณออกจากการทดสอบ

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

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

#23. ไม่แบ่งกลุ่มรูปแบบกลุ่มควบคุม (ผลกระทบจากเครือข่าย)

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

นี่คือตัวอย่าง

สมมติว่าคุณมีแพลตฟอร์มที่ผู้ชมสามารถสื่อสารได้ บางทีหน้า Facebook หรือส่วนความคิดเห็น แต่ทุกคนสามารถเข้าถึงได้

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

ตามหลักการแล้ว คุณต้องการแยกการสื่อสารระหว่างกลุ่มทดสอบ 2 กลุ่ม จนกว่าการทดสอบจะเสร็จสิ้น

#24. ดำเนินการทดสอบระหว่างกิจกรรมตามฤดูกาลหรือเหตุการณ์สำคัญในไซต์/แพลตฟอร์ม

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

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

สิ่งที่ดีที่สุดที่ควรทำคือเรียกใช้ซ้ำหลังจากนั้นทุกอย่างก็ดับลง

#25. ละเลยความแตกต่างทางวัฒนธรรม

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

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

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

Netflix ดำเนินการนี้โดยใช้ภาพขนาดย่อของรายการทั้งหมด ทดสอบองค์ประกอบต่างๆ ที่อาจดึงดูดผู้ชมที่แตกต่างกัน (นำเสนอนักแสดงที่มีชื่อเสียงในประเทศนั้นๆ แทน)

ข้อผิดพลาดในการทดสอบ A/B ของการทดสอบทางวัฒนธรรมของ Netflix
ที่มา: บล็อกทดสอบ Netflix

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

#26. ใช้งานแคมเปญที่เชื่อมต่อหลายรายการพร้อมกัน

ตื่นเต้นได้ง่ายและต้องการทำการทดสอบหลายรายการพร้อมกัน

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

นี่คือสิ่งที่ฉันหมายถึง

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

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

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

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

ไซด์โน้ต:

การแปลงทำให้คุณสามารถแยกผู้คนในการทดสอบหนึ่งออกจากการเห็นคนอื่น ๆ ในทางทฤษฎี คุณสามารถทดสอบวงจรการขายทั้งหมด แล้วดูเฉพาะการควบคุมของหน้าอื่นๆ เท่านั้น

แปลงประสบการณ์รวมถึงและไม่รวมผู้เยี่ยมชมทดสอบ
คุณเพียงแค่ลบออกจากกลุ่มทดสอบอื่นๆ

#27. น้ำหนักจราจรไม่เท่ากัน

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

ตั้งค่าให้เท่ากันตั้งแต่เริ่มต้น เครื่องมือส่วนใหญ่จะให้คุณทำสิ่งนี้ได้

แปลงประสบการณ์ A/B การทดสอบการกระจายการรับส่งข้อมูล
ตรวจสอบให้แน่ใจว่าคุณกระจายการกระจายอย่างเท่าเทียมกัน

ข้อผิดพลาดในการทดสอบ A/B ทั่วไปที่คุณสามารถทำได้ ระหว่าง การทดสอบ

#28. ไม่วิ่งนานพอที่จะได้ผลลัพธ์ที่แม่นยำ

มีปัจจัยสำคัญ 3 ประการที่ควรพิจารณาเมื่อต้องการทดสอบและได้ผลลัพธ์ที่แม่นยำ:

  • นัยสำคัญทางสถิติ,
  • วงจรการขาย และ
  • ขนาดตัวอย่าง.

เรามาทำลายมันกันเถอะ

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

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

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

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

ในที่สุด คุณได้ขนาดตัวอย่าง

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

ดังนั้นตามหลักธรรมที่ว่า

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

#29. การตรวจสอบ / แอบดูเฮลิคอปเตอร์

Peeking เป็นคำที่ใช้อธิบายเมื่อผู้ทดสอบดูการทดสอบของตนเพื่อดูว่ามีประสิทธิภาพเป็นอย่างไร

ตามหลักการแล้ว เราไม่ต้องการดูการทดสอบของเราทันทีที่ดำเนินการ และเราไม่เคยตัดสินใจเกี่ยวกับการทดสอบจนกว่าการทดสอบจะเสร็จสิ้นด้วยขนาดตัวอย่างที่ถูกต้องและมีนัยสำคัญทางสถิติ

อย่างไรก็ตาม… จะเกิดอะไรขึ้นถ้าการทดสอบไม่ทำงาน

เกิดอะไรขึ้นถ้ามีอะไรเสีย?

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

หากฉันเห็นว่าทั้งคู่ได้รับการเข้าชมและได้รับคลิก/Conversion ฉันก็เดินจากไปและปล่อยให้มันทำหน้าที่ของมัน ฉันไม่ตัดสินใจใดๆ จนกว่าการทดสอบจะดำเนินไป

#30. ไม่ติดตามความคิดเห็นของผู้ใช้ (สำคัญอย่างยิ่งหากการทดสอบส่งผลกระทบโดยตรงต่อการดำเนินการในทันที)

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

ถ้าอย่างนั้น ความคิดแรกของคุณควรมีบางอย่างเสีย

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

ถ้ามันเสียให้แก้ไขและเริ่มต้นใหม่

#31. การเปลี่ยนแปลงระหว่างการทดสอบ

มันอาจจะชัดเจนในสองสามประเด็นที่ผ่านมา แต่เราไม่ต้องการทำการเปลี่ยนแปลงใดๆ กับการทดสอบเมื่อเผยแพร่แล้ว

แน่นอนว่ามีบางอย่างที่อาจพังได้ แต่นั่นเป็นการเปลี่ยนแปลงเดียวที่เราควรทำ เราไม่เปลี่ยนการออกแบบ คัดลอก หรืออะไรก็ตาม

หากการทดสอบได้ผล ให้เรียกใช้และให้ข้อมูลตัดสินว่าสิ่งใดใช้ได้ผล

#32. การเปลี่ยน % ของการจัดสรรการรับส่งข้อมูลระหว่างการทดสอบหรือการเอาผลงานที่ไม่ดีออก

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

ทำไม

สมมติว่าคุณกำลังเรียกใช้การทดสอบ A/B/n ที่มีตัวควบคุมและรูปแบบต่างๆ 3 แบบ คุณเริ่มการทดสอบและหลังจากผ่านไปหนึ่งสัปดาห์คุณแอบดูและสังเกตว่า 2 เวอร์ชันทำงานได้ดีและเวอร์ชันหนึ่งทำได้ไม่ดี

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

ทำไม

การแจกจ่ายซ้ำนี้ไม่เพียงแต่จะส่งผลต่อประสิทธิภาพการทดสอบเท่านั้น แต่ยังส่งผลโดยตรงต่อผลลัพธ์และลักษณะที่ปรากฏบนเครื่องมือการรายงาน

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

นั่นคือเหตุผลที่คุณไม่เคยเปลี่ยนการเข้าชมหรือปิดรูปแบบต่างๆ ระหว่างทาง (และทำไมคุณไม่ควรแอบดู!)

#33. ไม่หยุดการทดสอบเมื่อคุณได้ผลลัพธ์ที่แม่นยำ

บางครั้งคุณก็ลืมหยุดการทดสอบ!

มันยังคงทำงานต่อไปและป้อน 50% ของผู้ชมของคุณไปยังหน้าที่อ่อนแอกว่าและ 50% ให้กับผู้ชนะ อ๊ะ!

โชคดีที่เครื่องมืออย่าง Convert Experiences สามารถตั้งค่าให้หยุดแคมเปญและแสดงผู้ชนะโดยอัตโนมัติเมื่อถึงเกณฑ์ที่กำหนด (เช่น ขนาดตัวอย่าง สถิติ คอนเวอร์ชั่น และกรอบเวลา)

Convert Experiences จุดหยุดอัตโนมัติ
คุณลองใช้แอพของเราแล้วหรือยัง?

#34. การลงทุนทางอารมณ์ในการสูญเสียความหลากหลาย

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

ดึงผ้าพันแผลออก

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

#35. ดำเนินการทดสอบนานเกินไปและการติดตามลดลง

นี่เป็นปัญหามลพิษตัวอย่างที่อาจเกิดขึ้นอีกประการหนึ่ง

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

#36. ไม่ใช้เครื่องมือที่ให้คุณหยุด/ดำเนินการทดสอบได้!

อีกเรื่องที่หายาก

โปรแกรมทดสอบบางโปรแกรมยืนยันในการสร้างการทดสอบแบบฮาร์ดโค้ด คือนักพัฒนาและวิศวกรสร้างแคมเปญตั้งแต่เริ่มต้น

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

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

#37. ยอมแพ้หลังสอบครั้งเดียว!

การทดสอบ 9 ใน 10 ครั้งมักจะล้มเหลว

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

#38. เลิกตั้งสมมติฐานดีๆ ก่อนทดสอบทุกเวอร์ชั่น

ความล้มเหลวอาจหมายถึงสมมติฐานของคุณถูกต้อง แต่ต้องดำเนินการให้ดีขึ้น

ลองวิธีใหม่ การออกแบบใหม่ เลย์เอาต์ใหม่ ภาพใหม่ อวตารใหม่ ภาษาใหม่ คุณมีความคิดและดูว่าคุณสามารถดำเนินการได้ดีขึ้นหรือไม่

ต้องใช้ CXL 21 ซ้ำเพื่อปรับปรุงหน้าของลูกค้า แต่ใช้อัตรา Conversion จาก 12.1% เป็น 79.3%

กรณีศึกษา CXL การทดสอบ A/B
อย่าละทิ้งสมมติฐานที่ดี!

#39. คาดหวังชัยชนะครั้งใหญ่ตลอดเวลา

ความจริงในเรื่องนี้คือคุณอาจได้รับชัยชนะครั้งใหญ่เพียง 1 ครั้งจากทุกๆ 10 แคมเปญหรือมากกว่าที่ชนะ

นี้ก็โอเค เรายังคงทดสอบและปรับปรุงอย่างต่อเนื่อง เพราะแม้แต่สารประกอบก็เพิ่มขึ้น 1% เมื่อเวลาผ่านไป ปรับปรุงให้ดีขึ้นเป็น 2% และตอนนี้คุณเพิ่มประสิทธิภาพเป็นสองเท่าแล้ว

การทดสอบประเภทใดให้ผลลัพธ์ที่ดีที่สุด

ความจริงก็คือ การทดลองต่างๆ มีผลต่างกัน จากการวิจัยของ Jakub Linowski จากการทดสอบกว่า 300 รายการ การทดลองเลย์เอาต์มักจะนำไปสู่ผลลัพธ์ที่ดีกว่า

หน้าจอประเภทใดที่ปรับให้เหมาะสมได้ยากที่สุด การวิจัยเดียวกันเผยให้เห็นว่าเป็นหน้าจอชำระเงิน (มีผลมัธยฐาน +0.4% จากการทดสอบ 25 ครั้ง)

#40. ไม่ตรวจสอบความถูกต้องหลังการทดสอบ

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

อาจเป็นไปได้ว่ามีบางอย่างเสียระหว่างการทดสอบ ไม่เคยเจ็บที่จะตรวจสอบ

#41. อ่านผลลัพธ์ไม่ถูกต้อง

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

  • เจาะลึกการวิเคราะห์ของคุณ
  • ดูข้อมูลเชิงคุณภาพที่คุณมี

อะไรได้ผลและอะไรไม่ได้ผล? ทำไมมันเกิดขึ้น?

ยิ่งคุณเข้าใจผลลัพธ์ของคุณมากเท่าไหร่ก็ยิ่งดีเท่านั้น

#42. ไม่ดูผลลัพธ์ตามเซกเมนต์

การดำน้ำลึกขึ้นเล็กน้อยนั้นคุ้มค่าเสมอ

ตัวอย่างเช่น รูปแบบใหม่อาจดูเหมือนทำ Conversion ได้ไม่ดี แต่บนอุปกรณ์เคลื่อนที่ มี Conversion เพิ่มขึ้น 40%!

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

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

#43. ไม่ได้เรียนรู้จากผลลัพธ์

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

#44. รับผู้แพ้

หรือแย่กว่านั้นคือพวกเขาใช้รูปแบบที่สูญเสียไป

บางทีพวกเขาอาจชอบการออกแบบและอัตราการแปลงต่างกันเพียง 1% แต่เมื่อเวลาผ่านไปผลกระทบเหล่านั้นก็รวมกัน รับชัยชนะเล็ก ๆ เหล่านั้น!

#45. ไม่ดำเนินการกับผลลัพธ์

เลวร้ายยิ่งกว่าเดิมอีก?

ชนะแต่ไม่ลงมือทำ! พวกเขามีข้อมูลและไม่ต้องทำอะไรกับมัน ไม่มีการเปลี่ยนแปลง ไม่มีข้อมูลเชิงลึก และไม่มีการทดสอบใหม่

#46. ไม่ทำซ้ำและปรับปรุงในการชนะ

บางครั้งคุณสามารถขึ้นลิฟต์ได้ แต่ยังมีอีกมากที่จะให้ได้ Like we said earlier, it's very rare that every win will give you a double-digit lift.

But that doesn't mean that you can't get there by running new iterations and improvements and clawing your way up 1% at a time.

It all adds up so keep on improving!

#47. Not sharing winning findings in other areas or departments

One of the biggest things we see with hyper-successful/mature CRO teams is that they share their winnings and findings with other departments in the company.

This gives other departments insights into how they can also improve.

  • Find some winning sales page copy? Preframe it in your adverts that get them to the page!
  • Find a style of lead magnet that works great? Test it across the entire site.

#48. Not testing those changes in other departments

And that's the key here. Even if you share insights with other departments, you should still test to see how it works.

A style design that gives lift in one area might give a drop in others, so always test!

#49. Too much iteration on a single page

We call this hitting the 'local maximum'.

The page you're running tests on has plateaued and you just can't seem to get any more lift from it.

You can try radical redesigns, but what next?

Simply move onto another page in the sales process and improve on that. (Ironically this can actually prove to give a higher ROI anyway.)

Taking a sales page from a 10% to 11% conversion can be less important than taking the page that drives traffic to it from 2% to 5%, as you will essentially more than double the traffic on that previous page.

If in doubt, find the next most important test on your list and start improving there. You may even find it helps conversion on that stuck page anyway, simply by feeding better prospects to it.

#50. Not testing enough!

Tests take time and there's just only so many that we can run at once.

So what can we do?

Simply reduce the downtime between tests!

Complete a test, analyze the result, and either iterate or run a different test. (Ideally, have them queued up and ready to go).

This way you'll see a much higher return for your time investment.

#51. Not documenting tests

Another habit mature CRO teams have is creating an internal database of tests, which includes data about the page, the hypothesis, what worked, what didn't, the lift, etc.

Not only can you then learn from older tests, but it can also stop you from re-running a test by accident.

#52. Forgetting about false positives and not double-checking huge lift campaigns

Sometimes a result is just too good to be true. Either something was set up or recording wrong, or this just happens to be that 1 in 20 tests that gives a false positive.

So what can you do?

Simply re-run the test, set a high confidence level, and make sure you run them for long enough.

#53. Not tracking downline results

When tracking your test results, it's also important to remember your end goal and track downline metrics before deciding on a winner.

A new variant might technically get fewer clicks through but drives more sales from the people who do click.

In this instance, this page would actually be more profitable to run, assuming the traffic that clicks continues to convert as well…

#54. Fail to account for primacy and novelty effects, which may bias the treatment results

Let's say you're not just targeting new visitors with a change, but all traffic.

We're still segmenting them so 50% see the original and 50% see the new version, but we're allowing past visitors into the campaign. This means people who've seen your site before, read your content, seen your calls to action, etc.

Also, for the duration of the campaign, they only see their specific test version.

When you make a new change, it can actually have a novelty effect on your past audience.

Maybe they see the same CTA all the time and now just ignore it, right? In this case, a new CTA button or design can actually see a lift from past visitors, not because they want it more now, but because it's new and interesting.

Sometimes, you might even get more clicks because the layout has changed and they're exploring the design.

Because of this, you will usually get an initial lift in response, but which dies back down over time.

The key when running your test is to segment the audience after and see if the new visitors are responding as well as the old ones.

If it's much lower, then it could be a novelty effect with the old users clicking around. If it's on a similar level, you might have a new winner on your hands.

Either way, let it run for the full cycle and balance out.

#55. ดำเนินการเปลี่ยนแปลงระยะเวลาการพิจารณา

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

ฉันหมายถึงอะไร

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

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

ตัวอย่างการเปลี่ยนแปลงระยะเวลาการพิจารณาดำเนินการ
ที่มา: Adobe

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

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

#56. ไม่ทำการทดสอบซ้ำหลังจาก X time

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

ใช่ คุณอาจมีหน้าที่ยอดเยี่ยม และใช่ คุณอาจทำมาแล้ว 20 ครั้งบนหน้านั้นเพื่อไปยังที่ที่เป็นอยู่ในปัจจุบัน

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

พร้อมเสมอที่จะกลับไปใช้แคมเปญเก่าและทดสอบซ้ำ (อีกเหตุผลหนึ่งที่ทำให้พื้นที่เก็บข้อมูลการทดสอบใช้งานได้ดี)

#57. ทดสอบเส้นทางเท่านั้นไม่ใช่ผลิตภัณฑ์

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

คิดถึงไอโฟน.

iphone วิวัฒนาการ
แหล่งที่มา

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

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

บทสรุป

ดังนั้นคุณมีมัน ข้อผิดพลาดในการทดสอบ A/B ทั่วไปและผิดปกติ 57 ข้อที่เราเห็นและวิธีที่คุณสามารถหลีกเลี่ยงได้

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

เริ่มการทดลองใช้ฟรีอย่างน่าเชื่อถือ
เริ่มการทดลองใช้ฟรีอย่างน่าเชื่อถือ