LINE Rich Menu Insights 係分析工具，唔係入站路由器
7 月 1 日，LINE 宣布經 Messaging API 建立嘅 rich menu 已經可以讀取統計資料，包括顯示次數、點擊次數同按日彙整嘅洞察資料。再早一個月，LINE 亦確認咗同一個產品表面上另一項變更：由 2026 年 5 月 26 日起，Get rich menu list 端點限流由每秒 2000 次調整至每秒 10 次。
如果將呢兩件事視為分析同設定更新，兩者都合理。產品團隊想知道邊個 rich menu 區塊多人撳，營運團隊需要審計而家發佈緊邊套 menu。呢啲流程都唔應該跑喺客服訊息處理嘅關鍵路徑入面。真正風險係，小團隊將 LINE 官方 Messaging API 當成即時路由層，然後圍繞唔適合逐條訊息決策嘅端點寫輪詢。
如果你嘅目標係接收 LINE 訊息，送入 Slack、CRM 或客服 queue，之後仲要接 WhatsApp 或 Zalo，架構上應該拆成兩個循環：一個慢速嘅 LINE 官方分析循環，一個事件驅動嘅入站會話循環。
LINE 具體改咗咩
7 月 1 日更新新增兩個官方 rich menu 洞察端點：Get rich menu insight totals 同 Get rich menu insight by day。以前，經 Messaging API 建立嘅 rich menu 唔能夠用同樣方式讀取呢啲統計，只可以喺 LINE Official Account Manager 入面睇。依家，使用 Messaging API 建立 menu 嘅團隊可以直接拉取報表資料。
5 月 26 日更新更偏工程維運。LINE 將 Get rich menu list 限流由每秒 2000 次改為每秒 10 次，並說明今次通知無調整其他端點限流。
重點唔係每秒 10 次夠唔夠你個後台頁面用。多數情況下係夠嘅。重點係 rich menu metadata 已經好明確屬於可快取設定，而唔係高頻依賴。如果你個應用每收到一條用戶訊息都去檢查 rich menu 狀態，設計方向就調轉咗。
三個循環，三種速度
LINE 客服系統好容易將三類問題混埋一齊，但佢哋唔應該共用同一個時鐘。
分析循環。 產品同市場團隊讀取 rich menu 顯示量同每日點擊量。佢可以每小時或每日跑一次，可以失敗後重試，亦可以接受延遲，因為佢回答嘅係「昨日邊個 menu 入口多人撳」。
設定循環。 工程側讀取目前 rich menu list，保存 menu ID，喺 menu 變更時更新內部狀態。呢個流程應該被快取。新嘅 10 rps 限流提醒我哋，設定讀取唔應該出現喺訊息熱路徑。
入站路由循環。 客服側需要即刻知道客戶啱啱發咗訊息、邊個帳號收到、發送者係邊個、文字或媒體係咩、應該路由去邊。呢個循環應該由事件驅動，唔應該等 rich menu list、insight 或報表刷新。
UnifyPort 放喺第三個循環。佢唔取代 LINE 官方分析端點，而係為 LINE、WhatsApp、Telegram、TikTok、Zalo 同 X 提供 webhook-first 入站層，並喺多個平台之間使用同一套標準事件結構。
入站路徑應該點走
使用 UnifyPort 時，一條 LINE 訊息會作為 message.received webhook 事件送到你嘅服務端。投遞方式係對你嘅端點發起 HTTP POST。事件信封喺支援平台之間保持一致：id、type、provider、account_id、occurred_at 同 data。
一條 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 端點可以訂閱 message.received，亦可以用 ["*"] 訂閱完整標準事件目錄。如果啟用簽名，每次投遞都會帶上 X-Device-Timestamp 同 X-Device-Signature。簽名係使用該端點嘅 signing_secret，對時間戳、一個點號同原始 request body 做 HMAC-SHA256 後得到嘅十六進制值。
咁路由服務嘅規則就好清楚：先驗證簽名，再按事件 ID 去重，保存需要嘅 payload，然後路由訊息。rich menu insight 呼叫唔應該入呢條路徑。
LINE 官方洞察應該放喺邊
新嘅 insight 端點有價值，但佢回答嘅係另一個問題。
你可以用佢統計 rich menu 入面「客服」區塊係咪比「價格」區塊多人撳，亦可以比較平日同週末互動差異，仲可以判斷季節性 menu 係咪值得繼續上線。排程頻率應該保持低速：商業報表每日一次，活動期間最多每小時一次。
唔好用佢推斷用戶係咪等緊客服。rich menu 點擊唔係訊息。按日彙總嘅洞察報表唔係 queue。帶有 10 rps 限流嘅設定端點亦唔係路由原語。
最簡單拆分方式係：
| 關注點 | 最合適資料源 | 時機 |
|---|---|---|
| rich menu 顯示和點擊報表 | LINE rich menu insight 端點 | 每小時或每日 |
| 目前 rich menu 設定 | LINE rich menu list 端點 | 快取，遠離熱路徑 |
| 即時客戶訊息 | UnifyPort message.received webhook | 即時事件 |
| 跨平台路由 | UnifyPort 標準 webhook 信封 | 每個平台共用同一 handler |
呢種拆分亦令團隊更穩定。分析任務失敗時，客服 queue 仍然收到訊息。rich menu 報表延遲時，CRM 仍然記錄每一條入站會話。之後加 WhatsApp 或 Zalo，路由循環唔需要重寫，只有分析循環仍然係 LINE 專屬。
小團隊可落地嘅架構
小團隊唔需要複雜架構。
先註冊一個 UnifyPort webhook 端點，設定 signing_secret，訂閱 message.received。喺 handler 入面驗證 X-Device-Signature，保存原始事件，並按 provider、account_id、data.sender.id 同 data.message.type 路由。
再單獨跑一個排程任務處理 LINE 官方 rich menu 報表。呢個任務呼叫 insight 端點，將指標寫入數據倉或試算表，絕不阻塞入站路由。佢亦可以刷新 rich menu list 快取，但呢個快取對客服 handler 應該係唯讀資訊。
當客服團隊需要回覆時，出站路徑仍然明確：透過 POST /v1/messages 發送目標帳號同訊息內容。入站事件則繼續作為「邊個喺幾時講咗咩」嘅事實來源。
最終模型好清楚：
- LINE 官方 API 負責 LINE 專屬分析。
- UnifyPort 負責多平台標準化入站投遞。
- 客服後端唔喺訊息路徑入面輪詢官方設定端點。
- 增加另一個聊天 app 時，變嘅係資料，唔係架構。
真正嘅提醒
LINE 7 月 1 日 insight 更新，對關心 rich menu 表現嘅團隊係好消息。5 月 26 日限流變更就劃出一條邊界：唔好將 rich menu 設定當成即時訊息基礎設施。
如果你嘅 LINE 工作主要係市場分析，就用新嘅官方 insight 端點。如果你嘅工作係客戶營運，就讓入站訊息走事件驅動。如果團隊已經同時接收 LINE、WhatsApp、Zalo、Telegram、TikTok 或 X 上嘅客戶訊息，就使用同一種 webhook 結構，令所有平台入同一套路由管道。
分析可以輪詢，客戶訊息應該直接到達。