ตั้ง LINE Webhook จับเหตุการณ์ Add Friend ให้ทัน ไม่ต้องเช็กมือ

ทีมแอดมินของร้านค้าปลีกออนไลน์แห่งหนึ่งเคยเปิดแอป LINE Official Account Manager ทุกเช้าเพื่อเช็กว่าเมื่อคืนมีคนเพิ่มเพื่อนกี่คน แล้วพิมพ์ตัวเลขลงชีตด้วยมือ พอธุรกิจโตขึ้นจนมีหลายแคมเปญพร้อมกัน งานเช็กมือแบบนี้เริ่มตามไม่ทัน เพราะไม่รู้เลยว่าคนที่เพิ่มเพื่อนแต่ละคนมาจากแคมเปญไหน และก็ไม่มีทางรู้แบบทันทีว่ามีคนเพิ่มเพื่อนตอนกี่โมง

LINE Webhook คือคำตอบของปัญหานี้ ตัว Webhook Add Friend ทำหน้าที่ส่งข้อมูลจากฝั่ง LINE มาหาระบบหลังบ้านของธุรกิจทันทีที่มีเหตุการณ์เพิ่มเพื่อนเกิดขึ้น แทนที่จะต้องเปิดแอปไล่เช็กเอง แต่หลายทีมที่เริ่มตั้งค่าครั้งแรกมักเจอปัญหาว่า Event ไม่มาตามที่คาด หรือมาไม่ครบ เพราะยังไม่เข้าใจกลไกเบื้องหลังดีพอ

บทความนี้จะอธิบายว่า Webhook Add Friend ทำงานยังไงจริง ๆ ต้องตั้งค่าอะไรบ้างก่อนใช้งาน แล้วมีข้อจำกัดอะไรที่ต้องรู้ไว้ก่อนจะเชื่อว่าระบบทำงานสมบูรณ์แบบ

Follow Event คืออะไร แล้วต่างจาก Add Friend ทั่วไปยังไง

Follow Event คือชื่อเหตุการณ์ที่ LINE ส่งมาให้ระบบหลังบ้านทราบทุกครั้งที่มีผู้ใช้เพิ่ม LINE OA เป็นเพื่อนสำเร็จ ข้อมูลที่ส่งมาจะมี User ID ของคนที่เพิ่มเพื่อนและเวลาที่เกิดเหตุการณ์ ซึ่งเป็นข้อมูลพื้นฐานที่ระบบต้องใช้ต่อในการผูกกับ Identifier ต้นทางหรือสร้าง Lead ใหม่

จุดที่ต้องเข้าใจให้ชัดคือ Follow Event เกิดเฉพาะตอนที่ผู้ใช้ ‘เพิ่มเพื่อนใหม่’ เท่านั้น ถ้าผู้ใช้เคยบล็อกแล้วยกเลิกบล็อก หรือเคยเป็นเพื่อนอยู่แล้ว พฤติกรรมการส่ง Event อาจต่างกันไปตามสถานะเดิมของบัญชีนั้น ธุรกิจจึงไม่ควรสมมติว่าทุกครั้งที่มีคนโผล่มาในแชทคือ Follow Event ใหม่เสมอ

Webhook ส่งข้อมูลมาหาระบบธุรกิจได้ยังไง

หลักการคือธุรกิจต้องมี Endpoint หนึ่งจุดที่เป็น URL รับข้อมูลจาก LINE โดยตั้งค่าไว้ในหน้า LINE Developers Console แล้ว LINE จะส่งคำขอ HTTP มาที่ Endpoint นี้ทุกครั้งที่มีเหตุการณ์เกิดขึ้นในช่องทางนั้น ระบบฝั่งธุรกิจต้องรับคำขอนี้ ตรวจสอบความถูกต้อง แล้วประมวลผลต่อว่าเป็น Follow Event หรือเหตุการณ์ประเภทอื่น

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

ต้องเตรียมอะไรก่อนเปิดใช้ Webhook Add Friend

ก่อนเริ่มต้องมี Channel ของ Messaging API ที่เปิดใช้งาน Webhook ไว้ในการตั้งค่า พร้อม Channel Secret และ Access Token ที่ใช้ยืนยันตัวตนระหว่างระบบธุรกิจกับ LINE ถ้าเป็นตัวธุรกิจเองที่ยังไม่มีทีมเทคนิคดูแลเรื่องนี้ มักต้องพึ่งนักพัฒนาหรือระบบสำเร็จรูปที่รองรับการเชื่อมต่อแบบนี้อยู่แล้ว

อีกจุดที่สำคัญคือการตรวจสอบลายเซ็นของคำขอที่ส่งมา (Signature Verification) เพื่อยืนยันว่าคำขอนั้นมาจาก LINE จริง ไม่ใช่คำขอปลอมที่ส่งมาแอบอ้าง ถ้าข้ามขั้นตอนนี้ไปจะเสี่ยงต่อการรับข้อมูลที่ไม่น่าเชื่อถือเข้ามาปนกับข้อมูล Lead จริงของธุรกิจ

ผูก Follow Event เข้ากับ Identifier ต้นทางให้รู้ที่มา

ตัว Follow Event เองมีแค่ User ID กับเวลา ไม่ได้บอกว่าคนคนนี้มาจากแคมเปญไหน ถ้าธุรกิจต้องการรู้ที่มา ต้องมีกลไกผูก Identifier ที่ส่งมาจากตอนเปิด LIFF หรือ Landing Page เข้ากับ User ID ที่ได้จาก Follow Event อีกที ซึ่งเป็นคนละขั้นตอนกับตัว Webhook เอง ต้องออกแบบร่วมกับฝั่งเว็บไซต์ตามแนวทางที่ใกล้เคียงกับการวางระบบ Tracking ให้รองรับหลายแคมเปญใน LIFF

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

ปัญหาในทางปฏิบัติคือปุ่มเพิ่มเพื่อนของ LINE ไม่มีช่องให้แนบพารามิเตอร์แคมเปญติดไปกับ Follow Event เลย วิธีที่ทีมส่วนใหญ่ใช้จริงคือให้ Landing Page เปิดผ่าน LIFF ก่อน เรียก liff.getProfile() เพื่อได้ userId มาผูกกับ utm_source และ utm_campaign ที่อ่านจาก query string ตั้งแต่ตอนนั้น แล้วค่อยปล่อยให้ผู้ใช้กดเพิ่มเพื่อนต่อ เมื่อ Follow Event เดินทางมาถึงพร้อม source.userId ตัวเดียวกัน ระบบก็จับคู่กับ Identifier ที่บันทึกไว้ก่อนหน้าได้ทันที ไม่ต้องเดาจากช่วงเวลาหรือ IP ซึ่งแม่นยำน้อยกว่ามาก

โครงสร้าง JSON ที่ LINE ส่งมาจริง มีฟิลด์อะไรบ้าง

คำขอที่ LINE ส่งมาที่ Endpoint เป็น JSON ที่มี key หลักคือ destination กับ events ซึ่ง events เป็น array เพราะบางครั้ง LINE รวมหลายเหตุการณ์มาในคำขอเดียว แต่ละ event ในกรณี Follow จะมี type เป็น "follow", mode เป็น "active", timestamp เป็นตัวเลข Unix time เป็นมิลลิวินาที, replyToken สำหรับตอบกลับผู้ใช้ทันทีถ้าต้องการ, และ source ที่มี type เป็น "user" พร้อม userId ซึ่งเป็นตัวเดียวกับที่ได้จาก liff.getProfile() ฝั่งหน้าเว็บ

อีกฟิลด์ที่มักถูกมองข้ามคือ webhookEventId ซึ่งเป็น ID เฉพาะของแต่ละคำขอ ใช้เป็นกุญแจกันข้อมูลซ้ำเวลา LINE ส่งคำขอเดิมมาอีกรอบ และ deliveryContext.isRedelivery ที่บอกว่าเหตุการณ์นี้เป็นการส่งซ้ำหรือเป็นครั้งแรก ถ้าระบบหลังบ้านไม่เช็กสองฟิลด์นี้ก่อนบันทึก Lead ใหม่ มีโอกาสสูงที่จะเจอ Follow Event ซ้ำซ้อนกันเป็นแถวเดียวกันในฐานข้อมูล โดยเฉพาะช่วงที่เซิร์ฟเวอร์ตอบช้าเป็นระยะ

ข้อผิดพลาดที่พบบ่อยตอนตั้งค่า Webhook

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

อีกข้อผิดพลาดคือทดสอบด้วยบัญชีที่เคยเพิ่มเพื่อนไปแล้ว ซึ่งจะไม่สร้าง Follow Event ใหม่ ทำให้ทีมเข้าใจผิดว่า Webhook ไม่ทำงาน ทั้งที่จริงแล้วปัญหาคือทดสอบผิดเงื่อนไข ควรทดสอบด้วยบัญชีใหม่ที่ยังไม่เคยเป็นเพื่อนกับ LINE OA นั้นเสมอ

ข้อผิดพลาดที่พบบ่อยไม่แพ้กันคือใส่ Logic หนัก ๆ เช่น เขียนลงฐานข้อมูลหลายตาราง เรียก API ภายนอก หรือคำนวณเยอะ ๆ ไว้ในตัว Handler ก่อนตอบกลับ HTTP 200 ให้ LINE ทำให้ Endpoint ตอบช้าเกินเวลาที่ LINE รอ พอเกิดแบบนี้บ่อยเข้า LINE จะเริ่มมองว่า Endpoint ไม่เสถียร แล้วอาจหยุดส่ง Event ชั่วคราวจนกว่าจะตอบกลับได้ปกติอีกครั้ง แนวทางที่ถูกต้องคือให้ Handler ตอบ 200 กลับไปก่อนทันทีที่ตรวจสอบ Signature ผ่าน แล้วค่อยส่งงานหนักไปประมวลผลต่อแบบ Asynchronous ผ่านคิวงาน

LINE พยายามส่งซ้ำยังไงเมื่อ Endpoint ไม่ตอบ

เมื่อ Endpoint ไม่ตอบกลับภายในเวลาที่กำหนดหรือตอบด้วยสถานะที่ไม่ใช่ 2xx LINE จะพยายามส่งคำขอเดิมซ้ำอีกหลายครั้งในลักษณะ Backoff คือเว้นระยะห่างขึ้นเรื่อย ๆ ก่อนจะหยุดพยายามไปเองถ้ายังไม่สำเร็จ คำขอที่ส่งซ้ำจะมี deliveryContext.isRedelivery เป็น true และ webhookEventId เดิม ทำให้ฝั่งรับสามารถเช็กได้ว่าเหตุการณ์นี้เคยประมวลผลไปแล้วหรือยัง

ทีมที่ไม่ได้ทำ Deduplication มักเจอปัญหาว่า Lead หนึ่งคนถูกสร้างซ้ำสองสามรายการในระบบ โดยเฉพาะช่วงที่มี Traffic Spike จากแคมเปญใหญ่ ทำให้เซิร์ฟเวอร์ตอบช้ากว่าปกติ วิธีแก้คือเก็บ webhookEventId ที่เคยประมวลผลไว้ในตารางแยก แล้วเช็กก่อนทุกครั้งว่าเคยเห็น ID นี้มาก่อนหรือไม่ ก่อนจะสร้าง Lead ใหม่หรืออัปเดตสถานะซ้ำ

ขั้นตอนยืนยันว่า Webhook ทำงานถูกต้องก่อนใช้จริง

ควรทำตามลำดับนี้ก่อนเริ่มพึ่งข้อมูลจาก Webhook ไปตัดสินใจเรื่องแคมเปญ

1. เปิด Verify ในหน้าตั้งค่า Webhook ของ LINE Developers Console เพื่อเช็กว่า Endpoint ตอบกลับสถานะถูกต้อง
2. ทดสอบเพิ่มเพื่อนด้วยบัญชีใหม่ที่ไม่เคยเป็นเพื่อนมาก่อน แล้วดูว่า Follow Event มาถึงระบบหลังบ้านภายในเวลาไม่กี่วินาที
3. ตรวจ Log ฝั่งรับข้อมูลว่ามีการตรวจสอบ Signature ผ่านจริง ไม่ใช่แค่รับข้อมูลโดยไม่ตรวจสอบที่มา
4. ทดสอบกรณีระบบหลังบ้านล่มชั่วคราว แล้วดูว่ามีกลไก Retry หรือ Log บันทึกไว้ให้ตรวจย้อนหลังได้หรือไม่

ข้อจำกัดของ Webhook Add Friend ที่ต้องรู้ไว้

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

สรุป

LINE Webhook Add Friend ช่วยให้ธุรกิจรู้ทันทีว่ามีคนเพิ่มเพื่อนใหม่โดยไม่ต้องเปิดแอปมาไล่เช็กเอง แต่ต้องตั้งค่า Channel, Endpoint และการยืนยันตัวตนให้ถูกต้องตั้งแต่แรก และเข้าใจว่า Follow Event เกิดเฉพาะกับคนที่เพิ่มเพื่อนใหม่จริงเท่านั้น

การผูก Identifier ต้นทางเข้ากับ Follow Event เป็นงานที่ต้องออกแบบเพิ่มเติมนอกเหนือจากตัว Webhook เอง ถ้าทำได้ครบ ธุรกิจจะรู้ไม่แค่ว่ามีคนเพิ่มเพื่อนกี่คน แต่รู้ด้วยว่าแคมเปญไหนสร้างผลลัพธ์นี้ได้จริง

• Webhook Add Friend ส่ง Follow Event มาทันทีที่มีคนเพิ่มเพื่อนใหม่ ไม่ใช่ทุกครั้งที่มีคนโผล่มาในแชท
• ต้องเปิด Use Webhook, ตั้ง Endpoint และตรวจ Signature ให้ครบก่อนเชื่อว่าระบบทำงานจริง
• ผูก Identifier ต้นทางเข้ากับ User ID จาก Follow Event เพื่อรู้ว่าแคมเปญไหนสร้างเพื่อนใหม่ได้จริง

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