แนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบ A/B บนแอปพลิเคชันหน้าเดียว (SPA)

บทความนี้เป็นส่วนที่ 2 ของชุด การทดสอบ A/B สำหรับแอปพลิเคชันหน้าเดียว

ในตอนที่ 1 เราได้แนะนำแนวคิดของแอปพลิเคชันหน้าเดียว (SPA) แสดงให้เห็นว่าเหตุใดจึงได้รับความนิยมเพิ่มขึ้น และดู 10 แพลตฟอร์มการทดสอบ A/B ที่ดีที่สุดที่คุณสามารถใช้กับแอปหน้าเดียว

แต่การเรียกใช้การทดสอบ A/B บน SPA อาจเป็นเรื่องยุ่งยากเล็กน้อยเนื่องจากวิธีการทำงาน ในบทความนี้ เราจะให้คำแนะนำแบบลงมือปฏิบัติเกี่ยวกับวิธีเรียกใช้การทดสอบ SPA และแนวทางปฏิบัติที่ดีที่สุดบางประการที่ควรปฏิบัติตาม

วิวัฒนาการของกรอบงานสปา

สปาไม่ใช่แนวคิดใหม่

สิทธิบัตรจากปี 2545 อธิบายถึงเทคโนโลยีที่คล้ายกับ SPA เวอร์ชันร่วมสมัย

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

ในทางกลับกัน การเปิดตัว AJAX ไม่ใช่ช่วงเวลาสำคัญของการนำ SPA มาใช้

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

SPA ถูกสร้างขึ้นครั้งแรกโดยใช้แอปเพล็ต Java หรือโปรแกรม Flash รวมถึง JavaScript หรือไลบรารี jQuery ที่ "บริสุทธิ์"

อย่างไรก็ตาม เฟรมเวิร์กส่วนหน้าเช่น Angular.js, React.js และ Vue.js ซึ่งทั้งหมดนี้เป็นเฟรมเวิร์ก JavaScript ที่ค่อนข้างใหม่ ได้ช่วยในการพัฒนาของพวกเขา

เทคโนโลยีเบื้องหลังสถาปัตยกรรมสปาคืออะไร?

SPA เป็นเฟรมเวิร์ก JavaScript ที่รองรับ HTML5 และ CSS3 โดยพื้นฐานแล้ว

อย่างไรก็ตาม ด้วยการใช้ส่วนประกอบเหล่านี้ ไลบรารีและเฟรมเวิร์กที่แตกต่างกันสองสามตัวได้เกิดขึ้นและนำไปใช้ในโลกของการพัฒนา:

1. เชิงมุม

พัฒนาโดย Google Angular เป็นเฟรมเวิร์กที่ครบกำหนดที่สุดและเก่าแก่ที่สุดใน 3 เฟรมเวิร์กพร้อมเอกสารประกอบโดยละเอียดที่จะใช้ แต่มีช่วงการเรียนรู้ที่สูงชัน

มันถูกฝังด้วยสถาปัตยกรรม Model View Controller (MVC) ดั้งเดิม แต่ส่วนใหญ่ใช้ MVVM (Model-View-ViewModel) ที่อนุญาตให้นักพัฒนาหลายคนทำงานแยกกันในส่วนแอพเดียวกัน อาจมีปัญหาในการย้ายข้อมูลในการอัปเดตเป็นเวอร์ชันใหม่ แต่ Angular มีความน่าเชื่อถือมากที่สุดเมื่อขยายขนาดขึ้น และเหมาะสำหรับโครงการขนาดใหญ่และซับซ้อน

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

บน GitHub เป็นเฟรมเวิร์กที่เป็นที่ยอมรับและเติบโตเต็มที่ โดยมีผู้มีส่วนร่วมจำนวนมาก

Google และผลิตภัณฑ์ต่างๆ เช่น Google Drive และ Gmail รวมถึง Wix เป็นหนึ่งในผู้ใช้ Angular สำหรับ SPA

2. React.js

React ได้รับการพัฒนาโดย Facebook และสร้างโอเพ่นซอร์ส ส่วนใหญ่ใช้สำหรับสร้างอินเทอร์เฟซผู้ใช้ (Facebook, WhatsApp และ Instagram)

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

มักใช้ร่วมกับ Redux เพื่อจัดการสถานะของส่วนประกอบแอปพลิเคชัน Uber ยังใช้เทคโนโลยี React.js ในผลิตภัณฑ์ของตนอีกด้วย

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

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

3. Vue.js

Vue.js ไม่ได้เป็นเจ้าของโดยบริษัทใหญ่ๆ เช่น Facebook หรือ Google แต่ก็ยังคงก้าวไปพร้อมกับผู้ใช้ใหม่ๆ โดยเฉพาะในเอเชีย เป็นเฟรมเวิร์ก SPA ใหม่ล่าสุดที่ก่อตั้งในปี 2014 โดย Evan You ซึ่งเป็นอดีตพนักงานของ Google เอกสารจำนวนมากมักเป็นภาษาจีน แต่ก็ยังมีแหล่งการฝึกอบรมอยู่

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

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

ปัจจุบัน Vue.js ถูกใช้โดยองค์กรต่างๆ เช่น Baidu, GitLab และ Alibaba เพื่อตอบสนองความต้องการของพวกเขา

แอปหน้าเดียวทำงานอย่างไร

สปามีการออกแบบที่ตรงไปตรงมา ใช้เทคโนโลยีการแสดงผลทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์

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

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

สรุป SPA ทำงานดังนี้:

1. ขั้นแรกไคลเอนต์สร้างการเชื่อมต่อกับเซิร์ฟเวอร์และรับเนื้อหาของหน้า ซึ่งประกอบด้วยโค้ด HTML, CSS และชุด JavaScript ที่ประกอบด้วยสคริปต์ทั้งหมดที่จำเป็นในการรันตรรกะของแอปพลิเคชันเป็นหลัก
2. การกระทำของผู้ใช้จะเปิดใช้งานการทำงานของ JavaScript ที่เกี่ยวข้อง จากนั้นจึงส่งคำขอ AJAX ไปยังเซิร์ฟเวอร์ ข้อมูลมักจะอยู่ในรูปแบบ JSON และไม่ต้องการการรีเฟรชหน้าเว็บแบบเต็ม

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

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

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

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

สปาเหมาะกับใครมากที่สุด?

เนื่องจากประโยชน์ของ SPA จึงเป็นทางออกที่ดีในหลายสถานการณ์

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

มีผู้เล่นรายใหญ่จำนวนมากที่ใช้ SPA Facebook, Gmail, Google Maps, Netflix และ Paypal เป็นตัวอย่างที่โดดเด่นที่สุดของเทคโนโลยีประเภทนี้ (ดูด้านล่าง)

เหตุใดการทดสอบ A/B จึงยากใน SPA

ทั้งสามเฟรมเวิร์ก ได้แก่ React.js, Angular.js และ Vue.js เป็นที่นิยมมากในหมู่นักพัฒนา JavaScript เนื่องจากช่วยให้สามารถพัฒนาอินเทอร์เฟซผู้ใช้ที่ซับซ้อนซึ่งสร้างประสบการณ์ผู้ใช้ที่ดีขึ้นและอัตรา Conversion ที่สูงขึ้น

เป็นที่ต้องการของนักพัฒนามากเพราะ

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

พวกเขายังเป็นแหล่งข้อมูลสำหรับทุกคนที่เริ่มต้น SPA ใหม่

อย่างไรก็ตาม มีข้อเสียประการสำคัญประการหนึ่งคือ เนื่องจากวิธีการทำงานของเฟรมเวิร์ ก เครื่องมือทดสอบ A/B ฝั่งไคลเอ็นต์จึงไม่สามารถทำงานได้อย่างถูกต้อง

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

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

ต่อไปนี้คือสถานการณ์ทั่วไปสองสถานการณ์:

1. หากคุณเปิดใช้งานการเปิด ดูหน้าเว็บ ใน SPA ของคุณ คุณจะได้รับการดูหน้าเว็บเมื่อมีผู้เยี่ยมชม URL แต่จะไม่มีการเปิดดูหน้าที่สองหากพวกเขาเรียกดูในหน้าอื่นที่เปิดใช้งานการเปิดดูหน้าเว็บ เนื่องจากมีการโหลดเนื้อหาลงในหน้าปัจจุบันแทนที่จะเป็นหน้าใหม่
2. หากคุณพยายามจำกัด เหตุการณ์ไว้ที่ URL เฉพาะ คุณจะพบปัญหาเดียวกัน เครื่องมือทดสอบ A/B จะ "เชื่อ" ว่ามันอยู่ในหน้าเดียวกับที่โหลดครั้งแรก แม้ว่าผู้ใช้จะคิดว่าอยู่ในหน้าอื่น เนื่องจากชิ้นส่วนต่างๆ ถูกย้ายเข้าและออกจากไซต์ จึงอาจมีปัญหาในการตรวจสอบการคลิกหรือเหตุการณ์อื่นๆ

ในการแสดงประสบการณ์ ซอฟต์แวร์ทดสอบ A/B ฝั่งไคลเอ็นต์และแพลตฟอร์มการตั้งค่าส่วนบุคคลต้องอาศัยการโหลดหน้าเว็บทั้งหมด

เนื่องจากแนวคิดนี้หายไปเมื่อใช้เฟรมเวิร์ก SPA เช่น React, Angular หรือ Vue การพิจารณาว่าเนื้อหาใหม่ถูกเพิ่มลงในเพจหรือสถานะของเนื้อหาที่มีอยู่เปลี่ยนไป และที่สำคัญกว่านั้นคือ เมื่อใดที่จะฉีดเนื้อหาที่ปรับแต่งให้เหมาะสม กลายเป็นเรื่องยากขึ้น

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

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

ตัวอย่างเช่น การโต้ตอบของผู้ใช้แต่ละครั้งใน React.js ทำให้องค์ประกอบ UI หนึ่งองค์ประกอบขึ้นไปรีเฟรช โดยจะลบการเปลี่ยนแปลงที่ทำโดยโซลูชันการทดสอบ A/B

การทดสอบฝั่งไคลเอ็นต์กับการทดสอบฝั่งเซิร์ฟเวอร์บน SPA

เมื่อพูดถึงการทดสอบ A/B บน SPA มีสองตัวเลือก:

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

ตัวอย่าง "สถานะ" ได้แก่ การแสดงแบบฟอร์มการสมัคร การโหลดรายการผลการค้นหา และอื่นๆ

2. ฮาร์ดโค้ดการแก้ไข ที่ ฝั่งเซิร์ฟเวอร์ หรือการปรับใช้แบบกำหนดเองสำหรับประสบการณ์ใหม่แต่ละรายการ

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

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

การเปิดใช้งานแบบมีเงื่อนไขในฝั่งไคลเอ็นต์

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

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

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

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

สามารถทำได้โดยการเขียน JavaScript เล็กน้อย มีสองวิธีในการทำเช่นนั้น

1. ฟังก์ชั่นการเลือกตั้ง

ฟังก์ชันโพลเป็นวิธีพื้นฐานที่สุดในการใช้การเปิดใช้งานแบบมีเงื่อนไข ฟังก์ชันจะสแกนหน้าทุกๆ 50ms จนกว่าองค์ประกอบที่ระบุจะปรากฏขึ้น ซึ่งอาจเป็นแบบโมดอล div หรือแม้แต่ทั้งหน้า

การทดสอบเริ่มต้นเมื่อองค์ประกอบปรากฏขึ้น

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

การทดสอบจะเปิดใช้งานเมื่อฟังก์ชันประเมินเป็น TRUE

2. ฟังก์ชั่นการโทรกลับ

การดำเนินการของฟังก์ชันเรียกกลับคล้ายกับฟังก์ชันการหยั่งเสียง แต่เพิ่มความยืดหยุ่นบางอย่าง

ฟังก์ชันนี้ให้คุณป้อนเงื่อนไข JavaScript ที่คุณต้องการ และหากประเมินเป็น TRUE เพื่อเริ่มการทดสอบ

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

การทดสอบฝั่งเซิร์ฟเวอร์

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

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

ตัวอย่างการทดสอบ A/B บน SPAs

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

การเปลี่ยนรูปภาพบนแลนดิ้งเพจ

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

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

ปัญหานี้สามารถหลีกเลี่ยงได้ทั้งหมดโดยเรียกใช้การสำรวจเมื่อโหลดหน้า Landing Page ที่เฉพาะเจาะจง

การทดสอบสำเนาเพิ่มเติมด้านล่าง CTA

การทดลองอื่นบนไซต์ SPA ที่สร้างด้วย Angular.js อาจเกี่ยวข้องกับการแสดงบรรทัดเพิ่มเติมของสำเนาด้านล่าง CTA หลักถึง 30% ของผู้ชมเป้าหมาย

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

เนื่องจากเว็บไซต์สร้างด้วย Angular.js องค์ประกอบจึงมีการเปลี่ยนแปลงเป็นประจำ เหตุการณ์การโทรกลับที่นี่สามารถช่วยเราในการแสดงการเปลี่ยนแปลงตัวแปร

การแสดงบัตรกำนัล

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

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

กำลังแสดงสโลแกนด้านล่าง 'ซื้อเลย' CTA

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

เนื่องจากหน้าที่มีปุ่ม 'ซื้อเลย' CTA จะไม่โหลดในตอนแรก

วิธีที่ Convert ข้ามปัญหาการทดสอบบน SPAs

การทดลองเกี่ยวกับ SPA จะต้องได้รับการจัดการที่แตกต่างจากการทดลองอื่นๆ เนื่องจากสคริปต์การแปลงไม่สามารถอ่าน URL ที่ผู้เยี่ยมชมเว็บไซต์กำลังนำทางอยู่ จึงไม่สามารถทริกเกอร์การทดสอบด้วยวิธีมาตรฐานได้

นี่คือวิธีการทำแทน

เริ่มต้นด้วยการติดตั้งโค้ดติดตามการแปลงตามที่อธิบายไว้ในบทความนี้

จากนั้น ใช้หนึ่งใน 3 วิธีด้านล่าง:

1. การกระตุ้นการเลือกตั้ง

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

ซึ่งรวมถึงการตรวจสอบ URL ของผู้เข้าชม เงื่อนไขของผู้ชม หรือเงื่อนไข JavaScript เพื่อเรียกใช้การทดสอบ

การทำโพลมักจะถูกเรียกโดย Convert เมื่อโหลดหน้าใหม่ ใน SPA มักจะไม่มีการโหลดหน้าใหม่บนเว็บแอป

ในกรณีนั้น คุณจะต้องใช้รหัสต่อไปนี้เพื่อเริ่มการสำรวจ:

 window._conv_q = _conv_q || [];
window._conv_q.push(["run","จริง"]);

คุณควรกำหนดว่าเหตุการณ์ใดดีที่สุดใน SPA ของคุณเพื่อเรียกใช้โค้ดด้านบน โค้ดตัวอย่างที่ควรเพิ่มในการตั้งค่าโปรเจ็กต์ > ส่วน Global Project JavaScript

 console.log('SPA/Convert Code ใน Global Project Javascript ดำเนินการแล้ว');
ถ้า (!window.globalExecutedTs) {
window.globalExecutedTs = จริง;
var oldPushState = window.history.pushState;
window.history.pushState = ฟังก์ชั่น (ข้อมูล) {
ลอง {
setTimeout (ฟังก์ชัน () {
ส่งคืน oldPushState.apply (นี่ อาร์กิวเมนต์);
console.log('แปลงที่เปิดใช้งานจาก pushstate');
window._conv_q = _conv_q || [];
window._conv_q.push(["รัน", "จริง"]);
}, 0);
} จับ (จ) {
console.log(จ);
}
};
window.onpopstate = ฟังก์ชั่น (เหตุการณ์) {
setTimeout (ฟังก์ชัน () {
console.log('แปลงที่เปิดใช้งานจาก popstate');
window._conv_q = _conv_q || [];
window._conv_q.push(["รัน", "จริง"]);
}, 0);
};
}

2. ใช้เงื่อนไข JavaScript ในพื้นที่ไซต์

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

ค้นหาคำอธิบายเชิงลึกเกี่ยวกับวิธีการทำเช่นนี้ในบทความต่อไปนี้

3. เปิดใช้งานการทดสอบด้วยตนเอง

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

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

Convert เพิ่มความเสี่ยงต่อการกะพริบบน SPA หรือไม่?

ตอบสั้น ๆ ไม่

เฟรมเวิร์ก SPA ทั้งหมดเข้ากันได้กับเทคโนโลยีป้องกันการสั่นไหวของ Convert Convert ใช้ประโยชน์จากเทคโนโลยี SmartInsert ^TM เบื้องหลังเพื่อให้แน่ใจว่าการปรับเปลี่ยนการทดสอบจะถูกนำไปใช้หรือนำมาใช้ใหม่ในเวลาที่เหมาะสมบน SPA ของคุณ แม้ในระหว่างการโหลดหน้าแบบไดนามิก

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

ปัญหาทั่วไปเมื่อทำการทดสอบ A/B บนไซต์แอปพลิเคชันหน้าเดียว

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

อาจเกิดจากบางสิ่ง:

1. ทดสอบการเปลี่ยนแปลงที่ปรากฏในการดูหน้าแรกแต่ไม่ปรากฏบนหน้าถัดไป

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

2. การเปลี่ยนแปลงที่ปรากฏใน Visual Editor ไม่ปรากฏขึ้นเมื่อแสดงตัวอย่างภายนอก

ในบางครั้ง การเปลี่ยนแปลงที่ทำกับ Visual Editor ไม่แสดงนอกหน้าตัวอย่างเอดิเตอร์ในบางครั้ง

เฟรมเวิร์ก SPA ส่วนใหญ่ไม่ได้ใช้ DOM API และใช้วิธีการของตนเองในการปรับใช้การเปลี่ยนแปลงในหน้าแทน ซึ่งทำให้ DOM ไม่ซิงค์เมื่ออัปเดตโดย SPA นี่เป็นเรื่องปกติใน React และ Angular ทำให้ตัวเลือก CSS ที่พบในโค้ด Jquery ไม่ทำงาน

3. การเปลี่ยนแปลงจะปรากฏต่อ 'การดู' ที่ตามมา

ในสถานการณ์นี้ การเปลี่ยนแปลงการทดสอบจะแสดงในมุมมอง (หน้า) ที่ถูกต้อง แต่เมื่อไปที่มุมมองใหม่ (หน้า) การเปลี่ยนแปลงจะไม่หายไป สิ่งนี้เกิดขึ้นเนื่องจากในไซต์ SPA การเปลี่ยนแปลงจะไม่ถูกลบออกเมื่อโหลดหน้าใหม่ซ้ำ

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

คุณจะต้องรันโค้ดที่คืนค่าการเปลี่ยนแปลงที่เกิดจากการทดสอบ

ตาคุณ: หลีกเลี่ยงข้อผิดพลาดเหล่านี้เมื่อเพิ่มประสิทธิภาพสปาของคุณ

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

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

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