รับดีไซน์ฟรีของคุณ
· Optimization · อ่าน 4 นาที

A/B testing ภาพหน้าจอด้วย Product Page Experiments

A/B testing ภาพหน้าจอด้วย Product Page Experiments
TL;DR. Product Page Experiments คือเครื่องมือ A/B testing ฟรีของ Apple สำหรับภาพหน้าจอ App Store ใช้งานได้ดีแต่จะช้าถ้าทำไม่ถูกวิธีทดสอบด้วยสมมติฐานที่ชัดเจนครั้งละหนึ่งตัวแปรให้ขนาดตัวอย่างที่เพียงพอแล้วจะได้ผลลัพธ์ที่ชัดเจนภายในสองสัปดาห์แต่ถ้าทดสอบห้าตัวแปรพร้อมกันและแบ่งทราฟฟิก 50% ต่อตัวจะได้แค่ข้อมูลรบกวนตลอดหกสัปดาห์

Product Page Experiments (PPE) เปิดตัวใน iOS 15 และกลายเป็นวิธีมาตรฐานในการ A/B test เมทาดาตาบน App Store ตั้งแต่นั้นมาคุณตั้งค่า control พร้อม treatment สูงสุดสามตัวกำหนดสัดส่วนทราฟฟิกเลือกระดับความเชื่อมั่นแล้ว Apple จะบอกว่าแบบไหนชนะโครงสร้างพื้นฐานมีความแข็งแกร่งแต่วินัยในการใช้งานยังขาดอยู่เสมอ

PPE วัดอะไรได้จริง

PPE วัด impressions และ conversions บนหน้า product page โดยเฉพาะ:

  • Impressions: ผู้ใช้ที่เข้ามายังหน้า product page ของคุณ
  • Conversions: ผู้ใช้ที่แตะ Get/Buy หลังจากเข้ามา

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

สิ่งนี้สำคัญเพราะการเปลี่ยนแปลง panel 4-10 ส่งผลต่อ conversion บน product page เท่านั้นขณะที่การเปลี่ยน panel 1-3 ส่งผลทั้งต่ออัตราการแตะในรายการค้นหาและ conversion บน product page PPE วัดอย่างหลังไม่ใช่อย่างแรก

กฎ "ทดสอบทีละตัวแปร"

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

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

ขนาดตัวอย่าง: ส่วนที่ทีมส่วนใหญ่ประเมินต่ำเกินไป

PPE ใช้การทดสอบสมมติฐานแบบ frequentist มาตรฐานขนาดตัวอย่างที่ต้องการขึ้นอยู่กับ:

  • อัตรา conversion พื้นฐานของคุณ (โดยทั่วไป 1-5% สำหรับแอปฟรีต่ำกว่าสำหรับแอปมีค่าใช้จ่าย)
  • ผลกระทบขั้นต่ำที่คุณสนใจ (lift สัมพัทธ์ 5%, 10%, 20%?)
  • ทราฟฟิกยังหน้า product page ของคุณ

ในระดับ order-of-magnitude: การตรวจจับ lift สัมพัทธ์ 10% บน baseline conversion 3% ต้องการ impressions ประมาณ 20,000 ต่อ variant เพื่อความเชื่อมั่น 95% ถ้าแอปของคุณได้รับ impressions บน product page 2,000 ต่อสัปดาห์นั่นคือ 10 สัปดาห์ต่อการทดสอบแอป indie ส่วนใหญ่ไม่มีทราฟฟิกพอสำหรับการทดสอบที่สะอาดทางสถิติที่ effect size เล็กตัวเลือกที่ซื่อสัตย์:

  • ทดสอบเฉพาะการเปลี่ยนแปลงครั้งใหญ่ — การเปลี่ยนสีลำดับ panel โทน caption ที่แตกต่างอย่างพื้นฐานการทดสอบเหล่านั้นถึง significance เร็วกว่าเพราะ effect size ใหญ่กว่า
  • ลดการแบ่งทราฟฟิกเป็นหนึ่งหรือสอง variant แทนที่จะเป็นสาม
  • ยอมรับผลเชิงทิศทางไม่ใช่ significant ถ้า variant ชนะต่อเนื่องตลอด 4 สัปดาห์ที่ความเชื่อมั่น 70% ให้ ship และรันการทดสอบอื่นต่อไป

การออกแบบการทดสอบที่ได้ผล

  1. เลือกสมมติฐานเดียว. "คำบรรยายที่ใหญ่ขึ้นบน panel 1 จะเพิ่ม conversion เพราะ thumbnail บีบอัดคำบรรยายเล็กๆจนอ่านไม่ออก" เป็นการเดาที่ชัดเจนไม่ใช่ 'ลองดูว่าอะไรได้ผล'
  2. ออกแบบ variant A: เปลี่ยนแค่อย่างเดียว. คารูเซลเหมือนเดิมเปลี่ยนแค่คำบรรยายบน panel 1 ส่วนอื่นเหมือนเดิมทุกประการ
  3. แบ่ง 50% ให้ control และ 50% ให้ variant. การทดสอบแบบ two-arm ถึง significance เร็วกว่า three-arm หรือ four-arm
  4. กำหนดระยะเวลาการทดสอบล่วงหน้า. "จะรันนี้ 4 สัปดาห์หรือจนถึง significance 95% อย่างใดก็ตามที่มาก่อน" ต้านทานการดูผลก่อนกำหนดและหยุดก่อนเวลา
  5. บันทึกผลลัพธ์. ไม่ว่าจะชนะแพ้หรือไม่ชัดเจน — เขียนไว้คุณในอนาคตจะรันการทดสอบเดิมซ้ำหกเดือนต่อมาถ้าไม่ทำเช่นนั้น

สิ่งที่ควรทดสอบเรียงตามลำดับความสำคัญ

  1. คำบรรยายบน panel 1. ผลกระทบสูงสุดเพราะ panel 1 ครอบงำทั้ง thumbnail ในการค้นหาและความประทับใจแรกบน product page
  2. ลำดับ panel. โดยเฉพาะ: คุณนำด้วยฟีเจอร์ไหน?
  3. สีคารูเซล / dark vs light. ผลกระทบใหญ่ทดสอบเร็ว
  4. มุมเอียง / การวางแนวอุปกรณ์. ผลกระทบเล็กกว่าแต่ตั้งค่าง่าย
  5. โทนคำบรรยาย (imperative vs descriptive). "ติดตามการวิ่ง" กับ "การวิ่งของคุณถูกติดตาม" ผลกระทบเล็กกว่าอ่านสัญญาณชัดได้ยากกว่า

หยุดทดสอบฟอนต์การเปลี่ยนสีเล็กน้อยหรือเนื้อหา panel 8-10 การทดสอบเหล่านั้นแทบจะไม่ถึง significance เลยและผลกระทบพื้นฐานเล็กน้อยพอที่ชัยชนะนั้นไม่คุ้มกับงบการทดสอบ

การแปลภาษาใน PPE

PPE รองรับ variants ต่อ locale ถ้าคุณรันการทดสอบใน locale ค่าเริ่มต้นและ ship ตัวที่ชนะคุณยังต้องใช้การเปลี่ยนแปลงนั้นกับทุก variant ที่แปลแล้วด้วยตนเองเลือก locale ที่มีทราฟฟิกพอสำหรับถึง significance (โดยปกติคือ en-US) และใช้ผลลัพธ์เป็นแนวทางเชิงทิศทางสากลสำหรับ locale อื่นๆไม่ต้องรัน 39 การทดลองแยกกัน

ข้อผิดพลาดที่พบบ่อย

  • การดูผลก่อนกำหนดและหยุดก่อนเวลา. Significance ผันผวนแบบสุ่มระหว่างการทดสอบการหยุดทันทีที่ variant ดูเหมือนชนะนำไปสู่ข้อสรุปที่ผิดพลาดกำหนดระยะเวลาขั้นต่ำและปฏิบัติตาม
  • การทดสอบตัวแปรมากเกินไป. การออกแบบใหม่ทั้งหมดไม่สามารถ A/B test ได้อย่างสะอาดคุณต้องการการทดสอบแยกสำหรับการออกแบบใหม่โดยรวม (หลายตัวแปรยอมรับความสับสนบ้าง) ตามด้วยการทดสอบแบบ single-variable บนตัวที่ชนะ
  • การรันการทดสอบในช่วงที่มีสัญญาณรบกวนตามฤดูกาล. Black Friday การแนะนำใน App Store แคมเปญการตลาดล้วนเพิ่มทราฟฟิกและสัญญาณรบกวนหลีกเลี่ยงการทดสอบในช่วงนี้ยกเว้นจะควบคุมค่าผิดปกติได้
  • การเพิกเฉยต่อ locale. ผลการทดสอบในสหรัฐฯไม่ได้ใช้ได้เสมอกับ JP ใช้เป็นสมมติฐานตั้งต้นไม่ใช่คำตอบสุดท้าย

สิ่งที่ควรทำในเดือนนี้

  1. ประเมินขนาดตัวอย่างที่ต้องการใส่ทราฟฟิกและ baseline conversion ของคุณในเครื่องคำนวณขนาดตัวอย่างก่อนตั้งค่าการทดสอบ
  2. เลือกสมมติฐานเดียวเขียนให้อยู่ในประโยคเดียว
  3. ออกแบบ A กับ B โดยเปลี่ยนตัวแปรเดียวตั้งค่าใน App Store Connect
  4. กำหนดระยะเวลาการรันและใส่วันสิ้นสุดในปฏิทิน
  5. บันทึกผลลัพธ์ไม่ว่าจะออกมาอย่างไร

อ่านต่อ

เปิดเครื่องมือแก้ไข →