LINE Rich Menu Insights มีไว้สำหรับการวิเคราะห์ ไม่ใช่ตัวจัดเส้นทางข้อความเข้า
วันที่ 1 กรกฎาคม LINE ประกาศว่า rich menu ที่สร้างผ่าน Messaging API สามารถดึงสถิติได้แล้ว เช่น จำนวนครั้งที่แสดง จำนวนครั้งที่ถูกคลิก และข้อมูล insight รายวัน ก่อนหน้านั้นประมาณหนึ่งเดือน LINE ก็ยืนยันการเปลี่ยนแปลงอีกเรื่องในพื้นที่เดียวกัน: ตั้งแต่วันที่ 26 พฤษภาคม 2026 เป็นต้นไป endpoint Get rich menu list ถูกปรับ rate limit จาก 2,000 requests ต่อวินาที เหลือ 10 requests ต่อวินาที
ถ้ามองสองเรื่องนี้เป็นการอัปเดตด้าน analytics และ configuration ก็ถือว่าสมเหตุสมผล ทีม product ต้องรู้ว่าพื้นที่ไหนใน rich menu ถูกกดมากกว่า ทีม operations ต้องตรวจสอบว่าเมนูไหนถูก publish อยู่ แต่ไม่มี workflow ใดควรอยู่ใน critical path ของการจัดการข้อความลูกค้า ความเสี่ยงเริ่มขึ้นเมื่อทีมเล็กใช้ LINE Messaging API อย่างเป็นทางการเป็น live routing layer แล้วสร้าง polling รอบ endpoint ที่ไม่ได้ออกแบบมาเพื่อตัดสินใจทุกข้อความเข้า
ถ้างานของคุณคือรับข้อความ LINE ส่งต่อเข้า Slack, CRM หรือคิวซัพพอร์ต และต่อไปยังต้องเพิ่ม WhatsApp หรือ Zalo สถาปัตยกรรมควรแยกเป็นสอง loop: loop วิเคราะห์ LINE อย่างเป็นทางการที่ทำงานช้า และ loop ข้อความเข้าที่ขับเคลื่อนด้วย event
LINE เปลี่ยนอะไรบ้าง
อัปเดตวันที่ 1 กรกฎาคมเพิ่ม endpoint insight อย่างเป็นทางการสองตัวสำหรับ rich menu: Get rich menu insight totals และ Get rich menu insight by day ก่อนหน้านี้ สถิติแบบนี้มักดูได้ใน LINE Official Account Manager สำหรับ rich menu ที่สร้างจากที่นั่น ตอนนี้ทีมที่สร้าง rich menu ด้วย Messaging API สามารถดึงข้อมูลรายงานได้โดยไม่ต้องเปิด dashboard เอง
อัปเดตวันที่ 26 พฤษภาคมเป็นเรื่อง operations มากกว่า LINE เปลี่ยน rate limit ของ Get rich menu list จาก 2,000 requests ต่อวินาทีเป็น 10 requests ต่อวินาที และระบุว่า endpoint อื่นไม่ได้เปลี่ยน limit ในประกาศนี้
ประเด็นสำคัญไม่ใช่ว่า 10 requests ต่อวินาทีพอสำหรับหน้า admin หรือไม่ ส่วนใหญ่พออยู่แล้ว ประเด็นคือ metadata ของ rich menu เป็น configuration surface ที่ควรถูก cache ไม่ใช่ dependency ความถี่สูง ถ้าแอปของคุณตรวจสถานะ rich menu ทุกครั้งที่ผู้ใช้ส่งข้อความ ดีไซน์นั้นกำลังวางผิดทาง
สาม loop สามความเร็ว
ระบบซัพพอร์ตบน LINE มักรวมสามเรื่องที่ควรแยกกัน
Analytics loop. ทีม product และ marketing อ่านจำนวนแสดงผล rich menu และ click รายวัน งานนี้รันทุกชั่วโมงหรือทุกวันก็พอ ถ้าล้มเหลวก็ retry ทีหลังได้ เพราะคำถามคือ “เมื่อวาน tab ไหนถูกกดมากกว่า?”
Configuration loop. ทีม engineering อ่าน rich menu list ปัจจุบัน เก็บ menu IDs และอัปเดต state ภายในเมื่อ menu เปลี่ยน สิ่งนี้ควรถูก cache rate limit 10 rps ใหม่เตือนว่า configuration read ไม่ควรอยู่ใน hot path ของข้อความ
Inbound routing loop. ทีมซัพพอร์ตต้องรู้ทันทีว่าลูกค้าเพิ่งส่งข้อความ บัญชีไหนได้รับ ใครเป็นผู้ส่ง มีข้อความหรือสื่ออะไร และควรส่งต่อไปที่ไหน loop นี้ควรเป็น event-driven ไม่ควรรอ rich menu list, insight หรือรายงาน refresh
UnifyPort อยู่ใน loop ที่สาม ไม่ได้มาแทน endpoint analytics อย่างเป็นทางการของ LINE แต่ให้ inbound layer แบบ webhook-first สำหรับ LINE, WhatsApp, Telegram, TikTok, Zalo และ X โดยใช้รูปแบบ event มาตรฐานเดียวกันทุก provider สำหรับไทยที่ LINE เป็นช่องทางหลัก การมีเส้นทาง webhook เดียวและยังเพิ่ม WhatsApp หรือ Zalo ได้ภายหลังช่วยลดภาระ integration ได้มาก
เส้นทางของข้อความเข้า
เมื่อใช้ UnifyPort ข้อความ LINE จะมาถึงเป็น webhook event ชื่อ message.received การส่ง event เป็น HTTP POST มายัง endpoint ของคุณ envelope ใช้ field เดียวกันข้าม provider ที่รองรับ: id, type, provider, account_id, occurred_at และ data
ข้อความ text ที่เข้าจาก LINE สามารถถูกจัดการในรูปแบบนี้:
{
"id": "evt_4f1b9c2a70",
"type": "message.received",
"provider": "line",
"account_id": "acc_8c21d0",
"occurred_at": "2026-07-04T02:18:30Z",
"data": {
"conversation": { "id": "U4af2c891", "type": "user" },
"sender": { "id": "U4af2c891", "type": "user", "name": "Mika Tanaka" },
"message": {
"id": "msg_20260704_001",
"type": "text",
"text": "Can you check whether my appointment moved to Monday?",
"direction": "inbound",
"sent_at": "2026-07-04T02:18:29Z"
},
"event": { "kind": "message_received" }
}
}webhook endpoint ของคุณสามารถ subscribe message.received หรือใช้ ["*"] เพื่อรับ standard event catalogue ทั้งหมด ถ้าเปิด signing ทุก delivery จะมี X-Device-Timestamp และ X-Device-Signature signature คือ HMAC-SHA256 แบบ hex จาก timestamp จุด และ raw request body โดยใช้ signing_secret ของ endpoint นั้น
กฎของ routing service จึงชัดเจน: verify signature, deduplicate ด้วย event ID, เก็บ payload ที่ต้องใช้ แล้วค่อย route ข้อความ การเรียก rich menu insight ไม่ควรอยู่ใน path นี้
LINE official insights ควรอยู่ตรงไหน
endpoint insight ใหม่มีประโยชน์มาก แต่ตอบคำถามคนละชุด
ใช้มันเพื่อดูว่า area “Support” ใน rich menu ถูกคลิกมากกว่า area “Pricing” หรือไม่ ใช้เปรียบเทียบวันทำงานกับวันหยุด ใช้ตัดสินใจว่า seasonal menu ควรอยู่ต่อหรือไม่ schedule ควรช้า: รายวันสำหรับ business report หรือรายชั่วโมงในช่วง campaign
อย่าใช้มันเพื่อเดาว่าผู้ใช้กำลังรอซัพพอร์ตอยู่หรือไม่ การคลิก rich menu ไม่ใช่ข้อความ รายงาน insight รายวันไม่ใช่ queue และ configuration endpoint ที่มี limit 10 rps ไม่ใช่ primitive สำหรับ routing
การแยกที่ง่ายที่สุดคือ:
| เรื่องที่สนใจ | แหล่งข้อมูลที่เหมาะที่สุด | เวลา |
|---|---|---|
| รายงาน display และ click ของ rich menu | LINE rich menu insight endpoints | รายชั่วโมงหรือรายวัน |
| configuration ของ rich menu ปัจจุบัน | LINE rich menu list endpoint | cache และอยู่นอก hot path |
| ข้อความลูกค้าแบบ live | UnifyPort message.received webhook | event ทันที |
| routing ข้าม platform | standard webhook envelope ของ UnifyPort | handler เดียวต่อ provider |
การแยกนี้ทำให้ระบบเปราะบางน้อยลง ถ้า analytics job ล้มเหลว คิวซัพพอร์ตยังรับข้อความได้ ถ้า rich menu report ช้า CRM ยังบันทึกทุก conversation ที่เข้า ถ้าเพิ่ม WhatsApp หรือ Zalo ภายหลัง routing loop ยังเหมือนเดิม ส่วน analytics loop ยังเฉพาะ LINE
สถาปัตยกรรมที่ใช้ได้จริง
ทีมซัพพอร์ตขนาดเล็กไม่ต้องมีสถาปัตยกรรมซับซ้อน
ลงทะเบียน webhook endpoint ใน UnifyPort ตั้ง signing_secret และ subscribe message.received ใน handler ให้ verify X-Device-Signature เก็บ raw event แล้ว route ตาม provider, account_id, data.sender.id และ data.message.type
จากนั้นรัน scheduled job แยกสำหรับรายงาน rich menu อย่างเป็นทางการของ LINE job นี้เรียก insight endpoints เขียน metrics ลง warehouse หรือ spreadsheet และไม่ block inbound routing เด็ดขาด มันอาจ refresh cache ของ rich menu list ได้ แต่ cache นั้นควรเป็น read-only สำหรับ support handler
เมื่อทีมซัพพอร์ตต้องตอบกลับ เส้นทาง outbound ยังชัดเจน: ส่งผ่าน POST /v1/messages พร้อมบัญชีปลายทางและเนื้อหาข้อความ ส่วน inbound event ยังเป็นแหล่งข้อมูลจริงว่าใครพูดอะไรและเมื่อไร
ผลลัพธ์คือ operating model ที่สะอาดขึ้น:
- LINE official APIs ดูแล analytics เฉพาะของ LINE
- UnifyPort ดูแล inbound delivery ที่ normalize แล้วข้าม provider
- backend ซัพพอร์ตไม่ poll official configuration endpoints ใน message path
- เพิ่มแอปแชทอีกตัวแล้วเปลี่ยนข้อมูล ไม่ใช่สถาปัตยกรรม
บทเรียนที่แท้จริง
อัปเดต insight วันที่ 1 กรกฎาคมของ LINE เป็นข่าวดีสำหรับทีมที่สนใจประสิทธิภาพของ rich menu ส่วนการเปลี่ยน rate limit วันที่ 26 พฤษภาคมเป็นเส้นแบ่งที่สำคัญ: อย่าปฏิบัติต่อ rich menu configuration เหมือน live message infrastructure
ถ้างาน LINE ของคุณคือ marketing analytics เป็นหลัก ให้ใช้ insight endpoints อย่างเป็นทางการใหม่ ถ้างานของคุณคือ customer operations ให้ทำให้ข้อความเข้าเป็น event-driven และถ้าทีมของคุณรับข้อความลูกค้าจาก LINE, WhatsApp, Zalo, Telegram, TikTok หรือ X อยู่แล้ว ให้ใช้รูปแบบ webhook เดียวเพื่อให้ทุก platform เข้า routing pipeline เดียวกัน
Analytics polling ได้ แต่ข้อความลูกค้าควรมาถึงทันที