ส่งข้อมูลฟอร์มใน LIFF ผ่าน Client Event กับผ่าน Webhook หลังบ้าน ต่างกันตรงไหน

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

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

บทความนี้จะพาเทียบสองวิธีวัดฟอร์ม submit ใน LIFF คือแบบยิงจาก Client Event กับแบบรับผ่าน Webhook หลังบ้าน ให้เห็นว่าแต่ละแบบพลาดตรงไหนได้บ้าง แล้วควรใช้แบบไหนตามลักษณะธุรกิจ

วัดแบบ Client Event ตอนกดปุ่มส่งฟอร์ม

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

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

วัดแบบรับผ่าน Webhook หลังบ้าน

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

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

เทียบสองวิธีแบบเห็นภาพ

ตารางนี้สรุปจุดต่างหลักที่ควรใช้ประกอบการตัดสินใจเลือกวิธีวัดฟอร์มใน LIFF

ทำไมหลายทีมเลือกใช้ทั้งสองแบบร่วมกัน

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

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

รับมือกรณี Webhook ล้มเหลวไม่ให้ข้อมูลหาย

ระบบที่รับ Webhook ควรมีกลไก Retry เมื่อการส่งครั้งแรกล้มเหลว และควรมี Log เก็บไว้ว่าคำขอไหนสำเร็จหรือไม่สำเร็จ เพื่อให้ตรวจย้อนหลังได้ว่าข้อมูลหายไปช่วงไหนบ้าง ไม่ใช่รู้แค่ว่า ‘ยอดน้อยกว่าที่ควรจะเป็น’ โดยไม่รู้สาเหตุ หลักการนี้ใกล้เคียงกับการออกแบบระบบแบบServer-to-serverทั่วไปที่ต้องมีการยืนยันสองทางเสมอ

ถ้าเกิดเหตุการณ์ Webhook ล้มเหลวเป็นวงกว้าง เช่น เซิร์ฟเวอร์ปลายทางล่มชั่วคราว ควรมีกระบวนการดึงข้อมูลที่ตกหล่นกลับมาซ่อมภายหลัง ไม่ปล่อยผ่านไปเฉย ๆ เพราะจะกระทบทั้งตัวเลขฟอร์มและ Conversion ที่ส่งกลับไปยังแพลตฟอร์มโฆษณาด้วย

ขั้นตอนตั้งค่าให้วัดฟอร์มได้แม่นยำขึ้น

ลำดับต่อไปนี้ช่วยให้เริ่มวางระบบวัดฟอร์มใน LIFF ได้ครบทั้งสองฝั่ง

1. ยิง Client Event ตอนกดปุ่มส่งฟอร์ม พร้อมแนบ Identifier ต้นทางไปด้วยเสมอ
2. ตั้ง Webhook รับผลจากระบบหลังบ้านหลังจากข้อมูลถูกบันทึกสำเร็จจริง
3. ทำ Deduplication ระหว่างสองแหล่งข้อมูล เพื่อไม่ให้นับซ้ำเวลานำไปใช้สรุปผล
4. ทดสอบกรณีเน็ตหลุดระหว่างส่งฟอร์ม เพื่อดูว่า Client Event กับ Webhook ให้ผลต่างกันตามที่คาดไว้หรือไม่

เชื่อตัวเลขไหนตอนตัดสินใจเรื่องงบ

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

ถ้าธุรกิจใช้ระบบที่เชื่อม Lead จาก LIFF เข้ากับKey Event ฝั่ง GA4 ด้วย ก็ควรยึดหลักเดียวกัน คือใช้ข้อมูลที่ยืนยันจากหลังบ้านเป็นแหล่งอ้างอิงหลัก ไม่ใช่ข้อมูลจากฝั่งหน้าจอที่ยังไม่ผ่านการยืนยัน

ฟิลด์จริงที่ต้องผูกตอนยิง Client Event จากฟอร์มใน LIFF

ก่อนยิง Client Event ตอนกดปุ่มส่งฟอร์ม โค้ดฝั่ง Client ต้องเรียก `liff.init({ liffId: "xxxx-xxxxxxxx" })` ให้เสร็จก่อนเสมอ แล้วเรียก `liff.getProfile()` เพื่อดึง `userId` ของผู้ใช้คนนั้นออกมาผูกไว้กับข้อมูลฟอร์มที่จะส่ง เพราะ `userId` ตัวนี้คือ Key เดียวกับที่ Messaging API จะใช้อ้างถึงผู้ใช้คนนี้ในอนาคต ถ้าไม่ผูก userId ไว้ตั้งแต่ตอนยิง Client Event จะไม่มีทางเชื่อมข้อมูลฟอร์มกับแชทที่เกิดขึ้นภายหลังได้เลย

ฝั่ง Webhook หลังบ้านที่รับผลจากการประมวลผลฟอร์ม ควรออกแบบ Payload ยืนยันให้มีอย่างน้อยสามฟิลด์ คือ `formId` ระบุว่าเป็นฟอร์มไหนของหน้าไหน `submissionId` เป็นรหัสเฉพาะของการส่งครั้งนั้นเพื่อกันนับซ้ำ และ `userId` ที่ผูกมาจากฝั่ง LIFF ตั้งแต่ต้น ถ้าระบบหลังบ้านไม่ส่ง `userId` กลับมาด้วย ฝั่งที่รับ Webhook จะไม่มีทางรู้ว่าการส่งฟอร์มที่สำเร็จจริงนี้เป็นของผู้ใช้คนไหนในระบบแชท ทำให้เชื่อม Conversion กลับไปยังแพลตฟอร์มโฆษณาไม่ได้ทั้งที่ข้อมูลเข้าระบบจริงแล้ว

ตัวอย่างเดินระบบจริง จากกดปุ่มส่งฟอร์มถึงยืนยันผ่าน Webhook

สมมติผู้ใช้กรอกฟอร์มสมัครทดลองใช้ใน LIFF แล้วกดปุ่มส่ง โค้ดฝั่ง Client จะเรียก `liff.getProfile()` ได้ `userId` เป็น `U4af4980629...` แล้วยิง Client Event ทันทีพร้อมแนบ `userId` และ `formId: "trial-signup"` ไปด้วย นี่คือจุดที่นับเป็น ‘ความตั้งใจส่ง’ ตามที่อธิบายไว้ก่อนหน้า

ระบบหลังบ้านรับข้อมูลฟอร์มไปประมวลผล ตรวจสอบความถูกต้อง บันทึกลงฐานข้อมูล แล้วสร้าง `submissionId` เฉพาะให้รายการนี้ ก่อนยิง Webhook กลับมายืนยันพร้อมฟิลด์ `formId`, `submissionId` และ `userId` เดียวกับที่ได้จาก LIFF ฝั่งระบบ Tracking ที่รับ Webhook นี้จึงรู้ได้ทันทีว่าการส่งฟอร์มของผู้ใช้ `U4af4980629...` สำเร็จจริง ไม่ใช่แค่กดปุ่มแล้วเน็ตหลุดกลางทาง และสามารถส่ง Conversion กลับไปยังแพลตฟอร์มโฆษณาได้อย่างมั่นใจ

ทำแบบนี้แล้วพัง เพราะ… Webhook ยืนยันฟอร์มแต่ไม่มี userId ติดมา

ทีมพัฒนาที่ทำระบบหลังบ้านออกแบบ Webhook ยืนยันการส่งฟอร์มไว้อย่างดี มี `formId` และ `submissionId` ครบ แต่ลืมส่ง `userId` กลับมาด้วย เพราะมองว่าฐานข้อมูลหลังบ้านมีข้อมูลผู้ใช้ครบอยู่แล้วไม่จำเป็นต้องส่งซ้ำ ผลคือฝั่งระบบ Tracking ได้รับการยืนยันว่ามีฟอร์มสำเร็จจริงหลายร้อยรายการต่อวัน แต่ไม่มีทางรู้เลยว่าแต่ละรายการเป็นของผู้ใช้ LINE คนไหน จึงส่ง Conversion กลับไปยังแพลตฟอร์มโฆษณาแบบผูกกับตัวบุคคลไม่ได้สักรายการ

กว่าจะรู้ปัญหาคือตอนที่ทีมการตลาดถามว่าทำไมยอด Conversion ที่ส่งกลับไป Facebook Ads ต่ำกว่ายอดฟอร์มที่ระบบหลังบ้านยืนยันมากเกือบครึ่ง ทั้งที่ทั้งสองระบบนับตรงกันทุกตัวเลข การแก้คือย้อนกลับไปแก้ Payload ของ Webhook ให้ส่ง `userId` กลับมาด้วยเสมอ และสำหรับข้อมูลเก่าที่ตกหล่นไปแล้ว ก็ต้องยอมรับว่าส่วนนั้นไม่มีทางผูกย้อนหลังได้อีก เพราะไม่มีอะไรเชื่อมกับ `userId` เดิมเหลืออยู่เลย

สรุป

การวัดฟอร์ม submit ใน LIFF ด้วย Client Event บอกความตั้งใจของผู้ใช้ได้เร็ว แต่ไม่ยืนยันว่าข้อมูลเข้าระบบจริง ส่วน Webhook หลังบ้านยืนยันความถูกต้องได้มากกว่าแต่มี Delay และเสี่ยงตกหล่นถ้าไม่มี Retry ที่ดี

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

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

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