ยอดขายที่นับได้จาก LINE สูงกว่าจำนวนออเดอร์จริงในระบบร้านเกือบสองเท่า

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

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

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

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

ทำไมยอด Purchase ถึงนับซ้ำได้ขนาดนี้

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

อีกจุดที่พบบ่อยคือการยิง Event ทั้งจากฝั่ง Client-side ผ่าน Pixel บนหน้าเว็บ และจากฝั่ง Server-side ผ่าน Conversion API พร้อมกัน โดยไม่มีการตั้งค่า Event ID ให้ตรงกัน ซึ่งตรงกับปัญหาที่อธิบายไว้ในการยิง Event Purchase ตอนปิดการขายในแชท ทำให้แพลตฟอร์มโฆษณานับเป็นสอง Event แยกกันแม้จะเป็นการซื้อครั้งเดียวกันจริง ๆ

ยิ่งไปกว่านั้น หากร้านค้ามีการใช้หลายเครื่องมือ Tracking พร้อมกัน เช่น ทั้ง Pixel ของ Meta, Google Tag Manager และปลั๊กอินร้านค้าที่มีระบบ Tracking ในตัว โอกาสที่ Event เดียวกันจะถูกยิงจากหลายจุดพร้อมกันก็ยิ่งสูงขึ้นตามจำนวนเครื่องมือที่ใช้งาน โดยเฉพาะเมื่อทีมงานที่ติดตั้งแต่ละเครื่องมือเป็นคนละคนกันและไม่ได้ประสานงานกันว่าใครติดตั้ง Event อะไรไปแล้วบ้าง

จุดที่มักทำให้ Event ยิงซ้ำโดยไม่ตั้งใจ

• หน้าขอบคุณ (Thank You Page) ที่ไม่มีการป้องกันการโหลดซ้ำ เช่น ลูกค้ากดรีเฟรชหรือแชร์ลิงก์หน้านี้ให้เพื่อน
• การยิง Event พร้อมกันทั้งจาก Client-side Pixel และ Server-side CAPI โดยไม่มี Event ID ที่ตรงกันเพื่อบอกระบบว่าเป็นเหตุการณ์เดียวกัน
• ระบบตะกร้าสินค้าที่มีการเรียก API ยืนยันคำสั่งซื้อมากกว่าหนึ่งครั้งเนื่องจากปัญหาเครือข่ายชั่วคราว ทำให้เกิดการยิง Event Purchase ซ้ำตามจำนวนครั้งที่เรียก
• สคริปต์ Tracking ถูกฝังซ้ำสองครั้งในหน้าเว็บเดียวกัน เช่น ทั้งจากการติดตั้งตรงในโค้ดและผ่าน Tag Manager พร้อมกันโดยไม่มีใครสังเกต

กลไก Event ID ที่ช่วยตัดข้อมูลซ้ำ

แพลตฟอร์มโฆษณาส่วนใหญ่รองรับกลไก Event ID หรือ Deduplication Key ตามหลักการป้องกัน Conversion ซ้ำฝั่งเซิร์ฟเวอร์ที่ช่วยให้ระบบรู้ว่า Event สองรายการที่ส่งเข้ามาเป็นเหตุการณ์เดียวกัน โดยกำหนดให้ทุก Event ที่เกี่ยวกับการซื้อครั้งเดียวกันมี Event ID เดียวกัน ไม่ว่าจะยิงมาจาก Client-side หรือ Server-side

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

วิธีตรวจสอบว่าเกิดการนับซ้ำจริงหรือไม่

1. เปรียบเทียบจำนวน Event Purchase ที่แพลตฟอร์มโฆษณารายงานกับจำนวนออเดอร์จริงในระบบหลังบ้านในช่วงเวลาเดียวกัน
2. ตรวจสอบว่าหน้าขอบคุณมีการยิง Event ทุกครั้งที่โหลดหน้าหรือมีการป้องกันการยิงซ้ำเมื่อรีเฟรชแล้วหรือยัง
3. ตรวจสอบว่ามีการยิง Event ทั้งจาก Client-side และ Server-side พร้อมกันหรือไม่ และถ้ามี ตรวจสอบว่าใช้ Event ID เดียวกันแล้วหรือยัง
4. ตรวจสอบโค้ดหน้าเว็บว่ามีสคริปต์ Tracking ซ้ำซ้อนติดตั้งมากกว่าหนึ่งจุดหรือไม่

ตัวอย่างสมมติ: ไล่หาสาเหตุยอด Purchase ซ้ำ

มุมมองจากทีมที่ตรวจสอบร้านค้าออนไลน์หลายราย

ทีมที่ตรวจสอบระบบ Tracking ให้ร้านค้าออนไลน์หลายรายมักพบว่าสาเหตุอันดับหนึ่งของยอด Purchase ที่สูงผิดปกติคือการยิง Event ทั้งจาก Client-side และ Server-side พร้อมกันโดยไม่มี Event ID ที่ตรงกัน ซึ่งเป็นปัญหาที่เกิดขึ้นบ่อยเมื่อทีมเพิ่งเริ่มติดตั้ง Conversion API เพิ่มเติมจากระบบ Pixel เดิมที่มีอยู่แล้ว

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

ผลกระทบต่อการตัดสินใจงบประมาณเมื่อยอดถูกนับซ้ำ

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

• ตรวจสอบยอด Purchase เทียบกับระบบหลังบ้านก่อนตัดสินใจปรับงบประมาณทุกครั้ง ไม่ควรเชื่อตัวเลขจาก Dashboard เพียงอย่างเดียว
• ตั้งค่า Event ID ให้สอดคล้องกันทุกช่องทางก่อนเริ่มใช้ตัวเลข ROAS ประกอบการตัดสินใจจริง

การตรวจสอบเมื่อใช้หลายเครื่องมือ Tracking พร้อมกัน

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

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

แยกให้ออกระหว่างปัญหาการนับซ้ำกับปัญหาการคืนสินค้า

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

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

ทำแบบนี้แล้วพัง เพราะ… บทเรียนจากทีมที่เจอปัญหาซ้ำ

• ยิง Event ทั้งจาก Client-side และ Server-side โดยไม่ตั้ง Event ID ให้ตรงกัน — พังเพราะทุกออเดอร์ถูกนับเป็นสอง Event แยกกันตลอดเวลา
• ไม่ป้องกันการยิง Event ซ้ำเมื่อลูกค้ารีเฟรชหน้าขอบคุณ — พังเพราะยอดถูกนับเพิ่มทุกครั้งที่มีการโหลดหน้าซ้ำ
• ติดตั้งสคริปต์ Tracking ซ้ำซ้อนโดยไม่รู้ตัว — พังเพราะ Event ยิงซ้ำสองเท่าในทุกการซื้อโดยไม่มีใครสังเกตจนยอด ROAS ผิดเพี้ยนไปมาก
• ไม่ทำ Audit เครื่องมือ Tracking หลังเปลี่ยนทีมงานหรือเพิ่มเครื่องมือใหม่ — พังเพราะเครื่องมือเก่าที่ไม่มีใครใช้แล้วยังคงยิง Event ซ้ำซ้อนต่อไปเรื่อย ๆ โดยไม่มีใครรู้ตัว
• ไม่แยกแยะระหว่างปัญหาการนับซ้ำทางเทคนิคกับความต่างจากการคืนสินค้า — พังเพราะแก้ปัญหาผิดจุด เช่น ไล่หาบั๊กในโค้ด Tracking ทั้งที่ความต่างจริงมาจากการคืนเงินที่ยังไม่ได้ส่ง Event ยกเลิกกลับไป

สรุป

ยอด Purchase ที่นับซ้ำจาก LINE ส่วนใหญ่เกิดจากการยิง Event มากกว่าหนึ่งครั้งต่อการซื้อหนึ่งครั้ง ไม่ว่าจะจากหน้าขอบคุณที่ไม่ป้องกันการรีเฟรช หรือการยิง Event ทั้งจาก Client-side และ Server-side โดยไม่มี Event ID ที่ตรงกัน

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

• ยอด Purchase นับซ้ำมักเกิดจากการยิง Event มากกว่าหนึ่งครั้งต่อการซื้อหนึ่งครั้งจากหลายจุด
• กลไก Event ID ช่วยให้แพลตฟอร์มโฆษณานับ Conversion ที่ซ้ำกันเป็นครั้งเดียว
• ควรตรวจสอบยอด Purchase เทียบกับระบบหลังบ้านก่อนตัดสินใจปรับงบประมาณทุกครั้ง

คำถามที่พบบ่อย