ส่ง Conversion ผ่าน CAPI กับผ่าน Webhook ของ LINE ต่างกันตรงไหนบ้าง

ทีมที่ดูแลระบบ LINE Official Account มักเจอสถานการณ์ที่ Webhook ซึ่งเคยรับข้อความจากลูกค้าเข้าระบบได้ปกติ จู่ ๆ ก็หยุดทำงาน ข้อความจากลูกค้าไม่ถูกส่งเข้าระบบหลังบ้านอีกต่อไป ทำให้ทีมแอดมินไม่เห็นข้อความใหม่และพลาดโอกาสในการตอบกลับลูกค้าในเวลาที่ควรจะตอบ

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

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

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

Webhook กับ CAPI ต่างกันตรงไหน

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

ในทางกลับกัน Conversion API เป็นกลไกที่ระบบของเราเป็นฝ่ายส่งข้อมูลออกไปหาแพลตฟอร์มโฆษณา เช่น ส่งข้อมูล Conversion ที่เกิดขึ้นไปยัง Meta หรือ Google Ads หลังจากมีการปิดการขายสำเร็จ ทั้งสองกลไกจึงมีทิศทางการไหลของข้อมูลตรงข้ามกัน แม้จะใช้หลักการทางเทคนิคที่คล้ายกันในแง่ของการส่งข้อมูลผ่าน HTTP Request

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

สาเหตุที่พบบ่อยเมื่อ Webhook หยุดทำงาน

• URL ปลายทางที่ตั้งไว้ใน LINE Developers Console ตอบสนองช้าเกินเวลาที่ LINE กำหนด ทำให้ LINE ถือว่าการส่งข้อมูลล้มเหลว
• SSL Certificate ของเซิร์ฟเวอร์หมดอายุหรือไม่ถูกต้อง เพราะ LINE กำหนดให้ Webhook URL ต้องใช้ HTTPS ที่มีใบรับรองถูกต้องเท่านั้น
• Verify Token หรือ Channel Secret ที่ใช้ตรวจสอบความถูกต้องของคำขอมีการเปลี่ยนแปลงในฝั่ง LINE Developers Console แต่ไม่ได้อัปเดตในระบบหลังบ้าน ซึ่งเป็นรูปแบบหนึ่งของความล้มเหลวของ Webhookที่พบบ่อย
• เซิร์ฟเวอร์ที่รับ Webhook มีปัญหาชั่วคราว เช่น ล่มหรือ Deploy โค้ดใหม่ระหว่างที่ LINE พยายามส่งข้อมูลเข้ามา

วิธีวินิจฉัยปัญหา Webhook ทีละขั้น

1. เข้าไปที่ LINE Developers Console แล้วใช้ปุ่ม Verify เพื่อทดสอบว่า URL ปลายทางตอบสนองถูกต้องหรือไม่
2. ตรวจสอบ Log ฝั่งเซิร์ฟเวอร์ว่ามีคำขอจาก LINE เข้ามาจริงหรือไม่ในช่วงเวลาที่คาดว่าจะมีข้อความ
3. ตรวจสอบสถานะ SSL Certificate ของโดเมนที่ใช้เป็น Webhook URL ว่ายังไม่หมดอายุและถูกต้องตามมาตรฐาน
4. ทดสอบส่งคำขอจำลองไปยัง Webhook URL ด้วยเครื่องมือภายนอกเพื่อวัดเวลาตอบสนองว่าอยู่ในเกณฑ์ที่ LINE กำหนดหรือไม่

ข้อกำหนดเรื่องเวลาตอบสนองที่มักถูกมองข้าม

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

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

ทีมที่เพิ่งเริ่มพัฒนาระบบมักออกแบบให้เซิร์ฟเวอร์ทำทุกอย่างในขั้นตอนเดียว เช่น รับข้อความ บันทึกลงฐานข้อมูล ส่งต่อไปยังระบบ CRM และตอบกลับลูกค้าอัตโนมัติ ทั้งหมดนี้ก่อนจะส่ง Response กลับไปหา LINE ซึ่งในสภาวะปกติอาจใช้เวลาไม่นาน แต่เมื่อฐานข้อมูลหรือระบบ CRM ปลายทางช้าลงจากภาระงานที่สูงขึ้น เวลาตอบสนองทั้งหมดอาจยืดออกไปเกินเกณฑ์ที่ LINE กำหนดได้ง่าย ๆ โดยที่ทีมงานไม่รู้ตัว

ตัวอย่างสมมติ: ไล่หาสาเหตุที่ Webhook หยุดทำงาน

มุมมองจากทีมที่ดูแลระบบ LINE OA ให้ลูกค้าหลายราย

ทีมที่ดูแลระบบ LINE Official Account ให้ลูกค้าหลายรายมักพบว่า SSL Certificate หมดอายุเป็นสาเหตุอันดับต้น ๆ ที่ทำให้ Webhook หยุดทำงานกะทันหัน โดยเฉพาะในกรณีที่ใบรับรองไม่ได้ตั้งค่าให้ต่ออายุอัตโนมัติ ทำให้เมื่อถึงวันหมดอายุ Webhook จะหยุดทำงานทันทีโดยไม่มีสัญญาณเตือนล่วงหน้าที่ชัดเจนจากฝั่ง LINE

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

อีกบทเรียนหนึ่งที่ทีมงานได้เรียนรู้จากการดูแลลูกค้าหลายราย คือควรมีเอกสารบันทึกโครงสร้าง Event Schema ของ Webhookของแต่ละบัญชีไว้อย่างละเอียด รวมถึง Channel Secret, URL ปลายทาง และวันที่ SSL Certificate หมดอายุ เพราะเมื่อมีการเปลี่ยนทีมงานผู้ดูแลหรือมีการปรับโครงสร้างระบบ หากไม่มีเอกสารอ้างอิงที่ชัดเจน การไล่หาสาเหตุเมื่อ Webhook มีปัญหาจะใช้เวลานานกว่าที่ควรจะเป็นมาก

เรื่องความปลอดภัยที่ต้องตรวจสอบควบคู่กันไป

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

การตรวจสอบลายเซ็นทำได้โดยใช้ Channel Secret คำนวณค่า HMAC-SHA256 จากเนื้อหาคำขอ แล้วเทียบกับค่าที่ LINE ส่งมาใน Header ของคำขอ หากค่าไม่ตรงกันควรปฏิเสธคำขอนั้นทันที การตั้งค่านี้มักถูกมองข้ามในช่วงพัฒนาระบบเร็ว ๆ แล้วลืมกลับมาเปิดใช้งานจริงตอน Deploy ขึ้นระบบ Production

การตั้งระบบเฝ้าระวังไม่ให้ปัญหาเกิดซ้ำ

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

• ตั้งการแจ้งเตือนล่วงหน้าก่อน SSL Certificate หมดอายุอย่างน้อยหนึ่งสัปดาห์
• บันทึก Log เวลาตอบสนองของเซิร์ฟเวอร์ต่อทุกคำขอ Webhook เพื่อสังเกตแนวโน้มที่ช้าลงก่อนจะพัง
• ตั้งค่าการแจ้งเตือนหากไม่มีคำขอ Webhook เข้ามาเลยเกินระยะเวลาที่กำหนดไว้ผิดปกติ เช่น เกินหนึ่งชั่วโมงในช่วงเวลาทำการที่ปกติมีลูกค้าทักเข้ามาต่อเนื่อง

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

• ไม่ตั้งระบบต่ออายุ SSL Certificate อัตโนมัติ — พังเพราะเมื่อใบรับรองหมดอายุ LINE จะปฏิเสธการเชื่อมต่อ Webhook ทั้งหมดทันที
• ประมวลผลข้อมูลซับซ้อนก่อนตอบกลับ LINE — พังเพราะเกินเวลาที่ LINE กำหนดให้ตอบสนอง ทำให้ LINE ถือว่าการส่งข้อมูลล้มเหลว
• เปลี่ยน Channel Secret ในคอนโซลโดยไม่อัปเดตในระบบหลังบ้าน — พังเพราะการตรวจสอบลายเซ็นไม่ผ่าน คำขอถูกปฏิเสธทั้งหมด
• ไม่ตั้งระบบเฝ้าระวังใด ๆ เลยหลังติดตั้งเสร็จ — พังเพราะเมื่อเกิดปัญหาจริง ไม่มีใครรู้ตัวจนกว่าลูกค้าจะร้องเรียนเข้ามาเอง ซึ่งอาจสายเกินไปสำหรับการปิดการขายในรอบนั้น

สรุป

LINE Webhook และ Conversion API เป็นกลไกที่มีทิศทางการไหลของข้อมูลตรงข้ามกัน Webhook คือ LINE ส่งข้อมูลเข้ามาหาเรา ในขณะที่ CAPI คือเราส่งข้อมูลออกไปหาแพลตฟอร์มโฆษณา การสับสนสองกลไกนี้มักทำให้ไล่หาสาเหตุผิดจุดเมื่อระบบมีปัญหา

เมื่อ Webhook หยุดทำงาน สาเหตุที่พบบ่อยที่สุดคือ SSL Certificate หมดอายุ เวลาตอบสนองเกินกำหนด และ Channel Secret ไม่ตรงกัน ควรตรวจสอบทั้งสามจุดนี้เป็นอันดับแรกก่อนไล่หาสาเหตุอื่น

• Webhook คือ LINE ส่งข้อมูลเข้าหาเรา ส่วน CAPI คือเราส่งข้อมูลออกไปหาแพลตฟอร์มโฆษณา ทิศทางตรงข้ามกัน
• สาเหตุที่พบบ่อยเมื่อ Webhook หยุดทำงานคือ SSL หมดอายุ, ตอบสนองช้าเกินกำหนด, และ Channel Secret ไม่ตรง
• ควรตั้งระบบต่ออายุ SSL อัตโนมัติและแจ้งเตือนล่วงหน้าก่อนหมดอายุเสมอ

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