LINE Rich Menu Insights 是分析工具，不是入站路由器
7 月 1 日，LINE 宣布透過 Messaging API 建立的 rich menu 已可讀取統計資料，包括顯示次數、點擊次數，以及按日彙整的洞察資料。再往前一個月，LINE 也確認了同一個產品表面上的另一項變更：自 2026 年 5 月 26 日起，Get rich menu list 端點限流從每秒 2000 次調整為每秒 10 次。
如果把這兩件事視為分析和設定更新，它們都很合理。產品團隊想知道哪個 rich menu 區塊被點擊更多，營運團隊需要審計目前發布的是哪一組選單。這些流程都不應該跑在客服訊息處理的關鍵路徑裡。真正的風險，是小團隊把 LINE 官方 Messaging API 當作即時路由層，然後圍繞不適合逐則訊息決策的端點寫輪詢。
如果你的目標是接收 LINE 訊息，把它們送進 Slack、CRM 或客服佇列，之後還要接入 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 建立選單的團隊可以直接拉取報表資料。
5 月 26 日的更新更偏工程維運。LINE 將 Get rich menu list 的限流從每秒 2000 次改為每秒 10 次，並說明此次通知中沒有調整其他端點的限流。
重點不是每秒 10 次夠不夠你的後台頁面使用。多數情況下是夠的。重點是 rich menu metadata 已經很明確屬於可快取設定，而不是高頻依賴。如果你的應用程式每收到一則使用者訊息都去檢查 rich menu 狀態，設計方向就是反的。
三個循環，三種速度
LINE 客服系統常把三類問題混在一起，但它們不應該共用同一個時鐘。
分析循環。 產品和市場團隊讀取 rich menu 顯示量與每日點擊量。它可以每小時或每天執行一次，可以失敗後重試，也可以接受延遲，因為它回答的是「昨天哪個選單入口點擊更多」。
設定循環。 工程側讀取目前 rich menu list，保存選單 ID，並在選單變更時更新內部狀態。它應該被快取。新的 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，對時間戳、一個點號和原始請求體做 HMAC-SHA256 後得到的十六進位值。
這樣路由服務的規則就很清楚：先驗證簽名，再按事件 ID 去重，保存需要的 payload，然後路由訊息。rich menu insight 呼叫不應該進入這條路徑。
LINE 官方洞察應該放在哪裡
新的 insight 端點有價值，但它回答的是另一個問題。
你可以用它統計 rich menu 裡「客服」區塊是否比「價格」區塊點擊更多，也可以比較平日和週末的互動差異，還可以判斷季節性選單是否值得繼續上線。排程頻率應保持低速：商業報表每天一次，活動期間最多每小時一次。
不要用它推斷使用者是否正在等待客服。rich menu 點擊不是訊息。按日彙總的洞察報表不是佇列。帶有 10 rps 限流的設定端點也不是路由原語。
最簡單的拆分方式是：
| 關注點 | 最合適的資料來源 | 時機 |
|---|---|---|
| rich menu 顯示和點擊報表 | LINE rich menu insight 端點 | 每小時或每天 |
| 目前 rich menu 設定 | LINE rich menu list 端點 | 快取，遠離熱路徑 |
| 即時客戶訊息 | UnifyPort message.received webhook | 即時事件 |
| 跨平台路由 | UnifyPort 標準 webhook 信封 | 每個平台共用同一 handler |
這種拆分也讓團隊更穩定。分析任務失敗時，客服佇列仍能收到訊息。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 負責多平台標準化入站投遞。
- 客服後端不在訊息路徑裡輪詢官方設定端點。
- 增加另一個聊天應用時，變的是資料，不是架構。
真正的提醒
LINE 7 月 1 日的 insight 更新，對關心 rich menu 表現的團隊是好消息。5 月 26 日的限流變更則劃出一條邊界：不要把 rich menu 設定當成即時訊息基礎設施。
如果你的 LINE 工作主要是行銷分析，就使用新的官方 insight 端點。如果你的工作是客戶營運，就讓入站訊息走事件驅動。如果團隊已經同時接收 LINE、WhatsApp、Zalo、Telegram、TikTok 或 X 上的客戶訊息，就使用同一種 webhook 結構，讓所有平台進入同一套路由管道。
分析可以輪詢，客戶訊息應該直接到達。