← Tất cả bài viết
Cẩm nang

LINE Rich Menu Insights là công cụ phân tích, không phải bộ định tuyến tin nhắn đến

Ngày 1 tháng 7, LINE thông báo rằng các rich menu được tạo bằng Messaging API giờ có thể truy xuất thống kê: tổng lượt hiển thị, tổng lượt nhấp và dữ liệu insight theo ngày. Trước đó khoảng một tháng, LINE cũng xác nhận một thay đổi khác trên cùng bề mặt sản phẩm: từ ngày 26 tháng 5 năm 2026, giới hạn của endpoint Get rich menu list giảm từ 2.000 request mỗi giây xuống 10 request mỗi giây.

Nếu đọc hai thay đổi này như cập nhật cho phân tích và cấu hình, chúng hoàn toàn hợp lý. Đội product muốn biết khu vực nào trên rich menu được nhấp nhiều hơn. Đội vận hành muốn kiểm tra menu nào đang được xuất bản. Nhưng không luồng nào trong số đó nên nằm trong đường xử lý quan trọng của chăm sóc khách hàng. Rủi ro xuất hiện khi một đội nhỏ coi LINE Messaging API chính thức là lớp định tuyến live và xây polling quanh những endpoint vốn không được thiết kế để quyết định từng tin nhắn đến.

Nếu mục tiêu của bạn là nhận tin nhắn LINE, đưa chúng vào Slack, CRM hoặc hàng đợi hỗ trợ, rồi sau đó thêm WhatsApp hoặc Zalo, kiến trúc nên tách thành hai vòng lặp: một vòng phân tích LINE chính thức chạy chậm và một vòng hội thoại đến chạy bằng sự kiện.

LINE đã thay đổi điều gì

Cập nhật ngày 1 tháng 7 thêm hai endpoint insight chính thức cho rich menu: Get rich menu insight totals và Get rich menu insight by day. Trước đây, các thống kê tương tự chủ yếu được xem trong LINE Official Account Manager cho rich menu được tạo tại đó. Với phần bổ sung mới, đội tạo rich menu bằng Messaging API có thể lấy dữ liệu báo cáo mà không cần mở dashboard thủ công.

Cập nhật ngày 26 tháng 5 mang tính vận hành hơn. LINE đổi giới hạn của Get rich menu list từ 2.000 request mỗi giây xuống 10 request mỗi giây. Trong thông báo này, LINE nói rằng giới hạn của các endpoint khác không thay đổi.

Điểm quan trọng không phải là 10 request mỗi giây có đủ cho trang quản trị hay không. Phần lớn trường hợp là đủ. Điểm quan trọng là metadata của rich menu rõ ràng thuộc về lớp cấu hình có thể cache, không phải phụ thuộc tần suất cao. Nếu ứng dụng của bạn kiểm tra trạng thái rich menu mỗi khi người dùng gửi tin nhắn, thiết kế đó đang đi sai hướng.

Ba vòng lặp, ba tốc độ

Một hệ thống hỗ trợ trên LINE thường trộn ba mối quan tâm khác nhau, nhưng chúng không nên dùng chung một nhịp chạy.

Vòng phân tích. Đội product và marketing đọc số lượt hiển thị rich menu và số click theo ngày. Vòng này có thể chạy mỗi giờ hoặc mỗi ngày. Nếu lỗi, có thể retry sau. Độ trễ chấp nhận được vì nó trả lời câu hỏi như “hôm qua tab nào được nhấp nhiều hơn?”

Vòng cấu hình. Engineering đọc rich menu list hiện tại, lưu menu ID và cập nhật trạng thái nội bộ khi menu thay đổi. Vòng này nên được cache. Giới hạn 10 rps mới là lời nhắc rằng đọc cấu hình không thuộc hot path của tin nhắn.

Vòng định tuyến tin nhắn đến. Support cần biết ngay rằng khách hàng vừa gửi tin nhắn, tài khoản nào nhận được, người gửi là ai, văn bản hoặc media là gì và cần chuyển đi đâu. Vòng này nên chạy bằng sự kiện. Nó không nên đợi rich menu list, insight hoặc báo cáo refresh.

UnifyPort nằm trong vòng thứ ba. Nó không thay thế các endpoint phân tích chính thức của LINE. Nó cung cấp lớp inbound webhook-first cho LINE, WhatsApp, Telegram, TikTok, Zalo và X, với cùng một dạng sự kiện chuẩn giữa các nền tảng. Với các đội ở Việt Nam, việc đặt LINE cạnh Zalo và WhatsApp trong cùng pipeline thường thực tế hơn là tạo ba tích hợp riêng.

Đường đi của tin nhắn đến

Với UnifyPort, một tin nhắn LINE đến dưới dạng sự kiện webhook message.received. Delivery là một HTTP POST tới endpoint của bạn. Envelope dùng cùng các trường trên những provider được hỗ trợ: id, type, provider, account_id, occurred_at và data.

Một tin nhắn text đến từ LINE có thể được xử lý như sau:

{
  "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 của bạn có thể subscribe message.received hoặc dùng ["*"] cho toàn bộ danh mục sự kiện chuẩn. Nếu bật signing, mỗi delivery có X-Device-Timestamp và X-Device-Signature. Chữ ký là HMAC-SHA256 dạng hex trên timestamp, dấu chấm và raw request body, được ký bằng signing_secret của endpoint.

Như vậy routing service có quy tắc rõ ràng: xác minh chữ ký, chống trùng bằng event ID, lưu payload cần thiết, rồi định tuyến tin nhắn. Lời gọi rich menu insight không thuộc đường này.

LINE insight chính thức nên nằm ở đâu

Các endpoint insight mới hữu ích, nhưng chúng trả lời câu hỏi khác.

Dùng chúng để báo cáo liệu vùng “Support” trên rich menu có được nhấp nhiều hơn vùng “Pricing” hay không. Dùng chúng để so sánh ngày thường với cuối tuần. Dùng chúng để quyết định một menu theo mùa có nên tiếp tục chạy không. Lịch chạy nên chậm: hằng ngày cho báo cáo kinh doanh, có thể hằng giờ trong chiến dịch.

Đừng dùng chúng để suy đoán người dùng có đang chờ hỗ trợ hay không. Một click trên rich menu không phải tin nhắn. Báo cáo insight theo ngày không phải hàng đợi. Một endpoint cấu hình có giới hạn 10 rps không phải primitive định tuyến.

Cách tách đơn giản là:

Mối quan tâmNguồn tốt nhấtThời điểm
Báo cáo hiển thị và click rich menuLINE rich menu insight endpointsMỗi giờ hoặc mỗi ngày
Cấu hình rich menu hiện tạiLINE rich menu list endpointCache, ngoài hot path
Tin nhắn khách hàng liveUnifyPort message.received webhookSự kiện tức thì
Định tuyến đa nền tảngEnvelope webhook chuẩn của UnifyPortMột handler cho từng provider

Sự tách này cũng làm hệ thống bền hơn. Nếu job phân tích lỗi, hàng đợi hỗ trợ vẫn nhận tin nhắn. Nếu báo cáo rich menu bị trễ, CRM vẫn ghi lại mọi hội thoại đến. Nếu sau này thêm WhatsApp hoặc Zalo, vòng định tuyến giữ nguyên và chỉ vòng phân tích còn riêng cho LINE.

Kiến trúc thực tế

Một đội support nhỏ không cần kiến trúc phức tạp.

Đăng ký webhook endpoint trong UnifyPort, đặt signing_secret và subscribe message.received. Trong handler, xác minh X-Device-Signature, lưu raw event, rồi định tuyến theo provider, account_id, data.sender.id và data.message.type.

Chạy một scheduled job riêng cho báo cáo rich menu chính thức của LINE. Job đó gọi các endpoint insight, ghi metrics vào warehouse hoặc spreadsheet và không bao giờ chặn inbound routing. Nó cũng có thể refresh cache của rich menu list, nhưng cache đó nên là thông tin read-only đối với support handler.

Khi đội support cần trả lời, đường outbound vẫn rõ ràng: gửi qua POST /v1/messages với tài khoản đích và nội dung tin nhắn. Sự kiện inbound vẫn là nguồn sự thật cho việc ai nói gì và khi nào.

Mô hình cuối cùng gọn hơn:

  1. LINE official APIs giữ phần phân tích riêng của LINE.
  2. UnifyPort xử lý delivery inbound chuẩn hóa trên nhiều provider.
  3. Backend support không poll endpoint cấu hình chính thức trong đường tin nhắn.
  4. Thêm một ứng dụng nhắn tin khác chỉ đổi dữ liệu, không đổi kiến trúc.

Bài học thật sự

Cập nhật insight ngày 1 tháng 7 của LINE là tin tốt cho các đội quan tâm hiệu quả rich menu. Thay đổi giới hạn ngày 26 tháng 5 cũng vạch ra một ranh giới: đừng coi cấu hình rich menu là hạ tầng tin nhắn live.

Nếu công việc LINE của bạn chủ yếu là marketing analytics, hãy dùng các endpoint insight chính thức mới. Nếu công việc là vận hành khách hàng, hãy để tin nhắn đến chạy bằng sự kiện. Và nếu đội của bạn đã nhận tin nhắn khách hàng trên LINE, WhatsApp, Zalo, Telegram, TikTok hoặc X, hãy dùng một dạng webhook chung để mọi nền tảng đi vào cùng một pipeline định tuyến.

Phân tích có thể polling. Tin nhắn khách hàng nên đến trực tiếp.