เช็กความน่าเชื่อถือของ Webhook LINE ฟรี
ตอบคำถามเกี่ยวกับเวลาตอบสนองของ Endpoint, โค้ดสถานะ HTTP ที่ส่งกลับ และวิธีจัดการ Retry ของ LINE แล้วดูว่า Webhook ของคุณเสี่ยงต่อการทำให้ข้อความหรือ Event หายมากน้อยแค่ไหน
- ใช้ฟรี
- ไม่ต้องสมัคร
- ไม่ต้องกรอกอีเมล
- คำนวณในเบราว์เซอร์
รองรับ JSON array, Webhook Request Body เดียว หรือบรรทัดละ 1 JSON event
วางหรืออัปโหลด Log เพื่อเริ่มวิเคราะห์
รู้จุดเสี่ยงแล้ว ขั้นต่อไปคือไม่ต้องดูแล Endpoint เอง
linli ดูแล Endpoint ที่รับ Webhook จาก LINE OA ให้ ตอบกลับเร็วพอตามที่ LINE กำหนด และจัดการ Retry ให้ไม่มีข้อความหรือ Event ตกหล่น
เครื่องมือนี้ตรวจอะไร
ตอบคำถามเกี่ยวกับ Endpoint ที่รับ Webhook ของคุณ เช่น เวลาตอบสนองเฉลี่ยอยู่ที่กี่วินาที Endpoint ตอบกลับด้วยโค้ด 200 ก่อนเริ่มประมวลผล Event หรือประมวลผลเสร็จก่อนถึงตอบกลับ และมีการจัดการ Retry ที่ LINE ส่งซ้ำมาเมื่อไม่ได้รับคำตอบทันเวลาหรือไม่
เครื่องมือจะประเมินความเสี่ยงจากคำตอบที่ให้ เช่น ถ้า Endpoint ประมวลผลเสร็จก่อนค่อยตอบ 200 และการประมวลผลใช้เวลานาน ความเสี่ยงที่ LINE จะ Timeout แล้วส่ง Event เดิมซ้ำจะสูงขึ้น ซึ่งถ้าไม่มีระบบกัน Event ซ้ำ อาจนำไปสู่การนับ Conversion ซ้ำโดยไม่รู้ตัว
ทำไมถึงสำคัญ
LINE กำหนดเวลาที่ Endpoint ต้องตอบกลับภายในไม่กี่วินาที ถ้าตอบช้าเกินไปหรือไม่ตอบเลย LINE จะพยายามส่ง Event เดิมซ้ำตามกลไก Retry ของตัวเอง ถ้าระบบไม่ได้ออกแบบมาให้รับมือกับ Event ซ้ำ ผลลัพธ์ที่ตามมาคือข้อความซ้ำ การนับ Conversion ซ้ำ หรือ Lead ถูกสร้างซ้ำในระบบ CRM
แนวทางที่แนะนำคือให้ Endpoint ตอบกลับ 200 ทันทีที่รับ Event ได้ แล้วค่อยประมวลผลต่อแบบ Asynchronous เบื้องหลัง เพราะการตอบช้าเพื่อรอประมวลผลให้เสร็จก่อน มักเป็นสาเหตุอันดับหนึ่งของปัญหา Timeout ที่เกิดขึ้นเฉพาะตอนมีทราฟฟิกสูง เช่น ช่วงแคมเปญใหญ่
คำถามที่พบบ่อย
LINE กำหนดเวลาตอบกลับไว้กี่วินาที
LINE คาดหวังให้ Endpoint ตอบกลับอย่างรวดเร็วในหลักวินาที ถ้าช้ากว่านั้นถือว่าเสี่ยง Timeout แนวทางที่ปลอดภัยที่สุดคือออกแบบให้ Endpoint ตอบ 200 ทันทีโดยไม่ต้องรอประมวลผลเนื้อหาให้เสร็จก่อน
ถ้า Endpoint ตอบ 200 แล้วแต่ประมวลผล Error ทีหลังจะเกิดอะไรขึ้น
LINE จะไม่ทราบว่าเกิด Error ฝั่งเซิร์ฟเวอร์เพราะได้รับ 200 ไปแล้วและจะไม่ส่ง Event นั้นซ้ำ ดังนั้นระบบจึงต้องมี Log หรือ Alert ของตัวเองที่ตรวจจับ Error ในขั้นประมวลผลเบื้องหลัง ไม่พึ่งพากลไก Retry ของ LINE เป็นตัวจับ Error แทน
ป้องกัน Event ซ้ำจาก Retry ได้ยังไง
เก็บ Event ID หรือ Delivery Context ที่มากับแต่ละ Event ไว้ แล้วเช็กก่อนประมวลผลว่าเคยเห็น ID นี้มาก่อนหรือไม่ ถ้าเคยให้ข้ามการประมวลผลซ้ำ ดูรายละเอียดเพิ่มเติมได้ที่เครื่องมือ ดีบัก Event ซ้ำจาก Webhook
อ่านต่อ
คู่มือและ Labs ที่เกี่ยวข้อง
อยากให้ระบบเก็บและตรวจข้อมูลนี้ให้อัตโนมัติ
linli เก็บ Click ID, Webhook Event และ Journey ของลูกค้าตั้งแต่คลิกโฆษณาจนถึงยอดขายที่ปิดใน LINE ให้อัตโนมัติ ทดลองฟรี 14 วัน ไม่ต้องใช้บัตรเครดิต