ปุ่ม 'ยืนยันคำสั่งซื้อ' ถูกกดสองครั้งในหนึ่งวินาที: ไล่ audit รอยรั่วที่ทำให้ event ยิงซ้ำ
สรุปสั้น ๆ
การยิง event ซ้ำมีต้นตอได้หลายจุดกว่าที่คิด ตั้งแต่ผู้ใช้กดปุ่มซ้ำเพราะหน้าเว็บโหลดช้า ไปจนถึง trigger ใน tag manager ที่ยิงซ้ำเองโดยไม่มีใครสังเกต การ audit ที่ตรงจุดต้องไล่ทดสอบจริงในเบราว์เซอร์ ไม่ใช่แค่ดู log ปลายทาง
ร้านขายตั๋วกิจกรรมออนไลน์สมมติชื่อ 'อีเวนต์โก' สังเกตว่ายอด purchase event ในระบบโฆษณาสูงกว่าจำนวนตั๋วที่ขายได้จริงอยู่เสมอ ราว 8-12% ทุกเดือน ทีมงานเริ่มสงสัยว่ามีคนแฮกระบบหรือเปล่า แต่พอไล่เช็กจริงกลับพบว่าสาเหตุง่ายกว่านั้นมาก คือหน้ายืนยันคำสั่งซื้อโหลดช้าเล็กน้อยในบางเครือข่าย ทำให้ลูกค้าบางส่วนกดปุ่ม 'ยืนยัน' ซ้ำสองครั้งเพราะคิดว่าปุ่มแรกกดไม่ติด
ทุกครั้งที่กดซ้ำ หน้าเว็บก็ยิง event purchase ซ้ำไปด้วย ทั้งที่เป็นออเดอร์เดียวกัน ปัญหานี้ไม่เกี่ยวกับระบบหลังบ้านหรือ CAPI เลยสักนิด แต่เกิดจากพฤติกรรมผู้ใช้บวกกับหน้าเว็บที่ไม่ได้ป้องกันการกดซ้ำ
บทความนี้จะพา audit จุดที่ event ยิงซ้ำได้ ตั้งแต่ฝั่งหน้าเว็บ ไปจนถึง trigger ใน tag manager ซึ่งเป็นจุดที่มักถูกมองข้ามเพราะทุกคนสงสัยระบบหลังบ้านก่อนเสมอ
ต้นตอที่ 1: ฝั่งหน้าเว็บที่ไม่ได้ป้องกันการกดซ้ำ
ปุ่มสำคัญอย่าง 'ยืนยันคำสั่งซื้อ' หรือ 'ส่งฟอร์ม' ถ้าไม่ได้ตั้งค่าให้ปิดใช้งานทันทีหลังกดครั้งแรก (disable on click) ผู้ใช้ที่รอผลลัพธ์นานเกินไปมักกดซ้ำโดยไม่รู้ตัว โดยเฉพาะบนมือถือที่สัญญาณเน็ตไม่เสถียร แต่ละครั้งที่กดคือ event หนึ่งตัวที่ถูกยิงออกไปใหม่
วิธีทดสอบง่ายที่สุดคือลองจำลองเน็ตช้าผ่านเครื่องมือนักพัฒนาในเบราว์เซอร์ (throttling) แล้วกดปุ่มซ้ำ ๆ ดูว่าระบบยอมให้ event ยิงออกไปกี่ครั้ง ถ้ายิงได้มากกว่าหนึ่งครั้งต่อการทำรายการเดียว นี่คือจุดที่ต้องแก้ก่อนอย่างอื่น
ต้นตอที่ 2: trigger ใน tag manager ที่ตั้งเงื่อนไขกว้างเกินไป
อีกจุดที่พบบ่อยคือ trigger ที่ตั้งให้ยิง event ทุกครั้งที่หน้า thank-you page ถูกโหลด โดยไม่ได้แยกว่าเป็นการโหลดครั้งแรกหรือการรีเฟรชซ้ำ ถ้าลูกค้ากดปุ่มย้อนกลับแล้วกดไปข้างหน้าใหม่ หรือแค่กด F5 หน้าเดิมก็ยิง event ซ้ำได้ทันทีโดยไม่มีการทำรายการซื้อใหม่เกิดขึ้นจริงเลย
วิธีป้องกันที่ใช้ได้ผลคือตั้งเงื่อนไขให้ trigger ยิงเฉพาะครั้งแรกที่หน้านั้นถูกเข้าถึงในเซสชันเดียว โดยอาศัยตัวแปรที่บันทึกไว้ใน session storage แทนที่จะยิงทุกครั้งที่หน้าโหลดแบบไม่มีเงื่อนไข
วิธียืนยันว่า event ซ้ำเกิดจากจุดไหนกันแน่
- เปิดโหมดตัวอย่าง (preview mode) ของ tag manager แล้วทำรายการซื้อจริงหนึ่งครั้งบนหน้าเว็บ ดูว่า tag ที่เกี่ยวข้องถูกยิงกี่ครั้งในรอบเดียว
- ลองกดปุ่มซ้ำด้วยมือหลังทำรายการเสร็จ ดูว่าระบบอนุญาตให้ยิง event ซ้ำหรือไม่
- ลองกดปุ่มย้อนกลับของเบราว์เซอร์แล้วกดไปข้างหน้าใหม่บนหน้า thank-you page ดูว่า tag ยิงซ้ำหรือไม่
- เทียบผลทั้งสามการทดสอบกับจำนวน event จริงที่บันทึกในระบบโฆษณาช่วงเวลาเดียวกัน เพื่อยืนยันว่าปัญหาที่เห็นในรายงานตรงกับสิ่งที่ทดสอบเจอจริง
ถ้าป้องกันต้นทางไม่ได้ทั้งหมด ให้พึ่ง dedup key เป็นเกราะชั้นสอง
แม้จะแก้ต้นตอที่หน้าเว็บและ tag manager ได้ดีแค่ไหน ก็ยังควรมีกลไก dedup key ที่ผูกกับ order ID เป็นเกราะป้องกันชั้นสุดท้าย เพราะบางสถานการณ์ เช่น ผู้ใช้เปิดสองแท็บพร้อมกันโดยตั้งใจ ก็อาจหลุดผ่านการป้องกันฝั่งหน้าเว็บได้อยู่ดี
การผูก event ID เดียวกันสำหรับ event ที่มาจาก pixel และ CAPI ของออเดอร์เดียวกัน ช่วยให้แพลตฟอร์มโฆษณาแยกแยะและไม่นับซ้ำแม้ต้นทางจะยิงมาสองครั้งจริง ๆ ก็ตาม
ตารางสรุปจุดตรวจ เรียงจากต้นทางไปปลายทาง
| จุดตรวจ | อาการที่บ่งชี้ปัญหา | วิธีแก้เบื้องต้น |
|---|---|---|
| ปุ่มกดซ้ำฝั่งหน้าเว็บ | event ยิงมากกว่า 1 ครั้งต่อการกดจริง 1 ครั้ง | ปิดปุ่มทันทีหลังกดครั้งแรก |
| Trigger ใน tag manager | ยิงซ้ำเมื่อรีเฟรชหรือย้อนกลับหน้าเดิม | ยิงเฉพาะครั้งแรกต่อเซสชันด้วย session storage |
| หลายแท็บเปิดพร้อมกัน | event ซ้ำที่มี order ID เดียวกัน | ใช้ dedup key ผูกกับ order ID เป็นเกราะสุดท้าย |
สรุป
event ที่ยิงซ้ำไม่ได้มาจากจุดเดียวเสมอไป และหลายครั้งต้นตอไม่ได้อยู่ที่ระบบหลังบ้านอย่างที่คนส่วนใหญ่สงสัยก่อน แต่อยู่ที่พฤติกรรมผู้ใช้บวกกับหน้าเว็บที่ไม่ได้ออกแบบมาป้องกันการกดซ้ำ
การไล่ทดสอบจริงในเบราว์เซอร์ทีละขั้นตอน ตั้งแต่กดปุ่มซ้ำไปจนถึงลองรีเฟรชหน้า ให้คำตอบที่ชัดเจนกว่าการนั่งเดาจาก log ปลายทางเพียงอย่างเดียว
- ทดสอบกดปุ่มซ้ำและรีเฟรชหน้า thank-you page ด้วยมือก่อนสงสัยระบบหลังบ้าน
- ตั้ง trigger ให้ยิงเฉพาะครั้งแรกต่อเซสชัน ไม่ใช่ทุกครั้งที่หน้าโหลด
- ใช้ dedup key ผูกกับ order ID เป็นเกราะป้องกันชั้นสุดท้ายเสมอ
คำถามที่พบบ่อย
ป้องกันที่หน้าเว็บอย่างเดียวพอไหมไม่ต้องมี dedup key
ไม่พอเสมอไป เพราะยังมีสถานการณ์ที่ควบคุมไม่ได้ เช่น ผู้ใช้เปิดหลายแท็บเอง หรือ browser cache ทำงานผิดปกติ ควรมี dedup key เป็นเกราะชั้นสองเสมอ
ทำไม throttling เน็ตช้าถึงช่วยจับปัญหานี้ได้ดี
เพราะอาการกดซ้ำมักเกิดตอนผู้ใช้รอนานผิดปกติ การจำลองเน็ตช้าในเครื่องมือนักพัฒนาช่วยสร้างสถานการณ์นั้นซ้ำได้โดยไม่ต้องรอเจอปัญหาจริงบนมือถือ
trigger ที่ยิงตามการโหลดหน้าเว็บ อันตรายกว่า trigger แบบอื่นไหม
อันตรายกว่าในแง่ที่ผู้ใช้ไม่ต้องทำอะไรเลยก็ยิงซ้ำได้ แค่กดปุ่มย้อนกลับหรือรีเฟรช ต่างจาก trigger ที่ผูกกับการคลิกปุ่มเฉพาะซึ่งต้องมีการกระทำเพิ่มเติมถึงจะยิงซ้ำ
ตรวจแล้วไม่เจอปัญหาที่หน้าเว็บเลย ควรดูจุดไหนต่อ
ให้ไล่ดูฝั่งระบบหลังบ้านว่ามีการยิง event จากหลายช่องทางพร้อมกันหรือไม่ เช่น ทั้ง webhook อัตโนมัติและแอดมินกดยืนยันด้วยมือสำหรับออเดอร์เดียวกัน
การใช้ session storage ป้องกันการยิงซ้ำ มีข้อจำกัดอะไรบ้าง
ข้อจำกัดคือถ้าผู้ใช้ปิดเบราว์เซอร์แล้วเปิดใหม่ ค่าที่เก็บใน session storage จะหายไป ถ้าผู้ใช้ทำรายการซ้ำจริงในเซสชันใหม่ก็จะยิง event ได้อีกครั้ง ซึ่งเป็นพฤติกรรมที่ถูกต้องตามการออกแบบ
ปัญหาแบบนี้ตรวจสอบเองได้โดยไม่ต้องมีทีมพัฒนาไหม
การทดสอบเบื้องต้นด้วยโหมด preview ของ tag manager และการลองกดปุ่มซ้ำด้วยมือ เจ้าของธุรกิจที่ไม่มีพื้นฐานเทคนิคก็ทำตามขั้นตอนได้ แต่การแก้โค้ดจริงมักต้องอาศัยทีมพัฒนาหรือเอเจนซี่ช่วย
บทความที่เกี่ยวข้อง
