LINE Rich Menu Insights нужны для аналитики, а не для маршрутизации входящих
1 июля LINE объявила, что для rich menu, созданных через Messaging API, теперь можно получать статистику: показы, клики и дневные показатели. Примерно месяцем раньше LINE подтвердила другое изменение в той же области продукта: с 26 мая 2026 года лимит для endpoint Get rich menu list изменился с 2000 запросов в секунду до 10 запросов в секунду.
Если смотреть на эти изменения как на аналитику и конфигурацию, они логичны. Продуктовой команде нужно понимать, какая зона rich menu получает больше кликов. Операционной команде нужно проверять, какое меню опубликовано. Но ни один из этих процессов не должен находиться в критическом пути обработки клиентских сообщений. Риск появляется тогда, когда небольшая команда начинает использовать официальный LINE Messaging API как live-слой маршрутизации и строит polling вокруг endpoints, которые не предназначены для принятия решений по каждому входящему сообщению.
Если ваша задача — принимать LINE-сообщения, отправлять их в Slack, CRM или очередь поддержки, а позже добавить WhatsApp или Zalo, архитектуру лучше разделить на два цикла: медленный цикл официальной LINE-аналитики и событийный цикл входящих разговоров.
Что изменилось в LINE
Обновление от 1 июля добавило два официальных endpoint для rich menu insights: Get rich menu insight totals и Get rich menu insight by day. Раньше такая статистика была в основном доступна в LINE Official Account Manager для rich menu, созданных там. Теперь команды, которые создают rich menu через Messaging API, могут получать отчетные данные без ручного dashboard.
Обновление от 26 мая более операционное. LINE изменила лимит Get rich menu list с 2000 запросов в секунду до 10 запросов в секунду. В этом объявлении LINE указала, что лимиты других endpoints не менялись.
Главный вопрос не в том, хватит ли 10 запросов в секунду для вашей админки. Скорее всего, хватит. Главное в другом: metadata rich menu — это кэшируемая конфигурационная поверхность, а не высокочастотная зависимость. Если приложение проверяет состояние rich menu каждый раз, когда пользователь отправляет сообщение, дизайн идет не в ту сторону.
Три цикла, три скорости
В LINE support stack часто смешиваются три разные задачи, но у них не должен быть один и тот же таймер.
Аналитический цикл. Продукт и маркетинг читают показы rich menu и дневные клики. Это может работать раз в час или раз в день. Ошибку можно повторить позже. Задержка допустима, потому что вопрос звучит так: «Какая вкладка меню получила больше кликов вчера?»
Конфигурационный цикл. Engineering читает текущий rich menu list, сохраняет menu IDs и обновляет внутреннее состояние при изменениях. Это должно кэшироваться. Новый лимит 10 rps напоминает, что чтение конфигурации не относится к hot path сообщений.
Цикл входящей маршрутизации. Support должен сразу знать, что клиент отправил сообщение, какой аккаунт его получил, кто отправитель, какой текст или media пришли и куда это нужно направить. Этот цикл должен быть событийным. Он не должен ждать rich menu list, insight или обновления отчета.
UnifyPort находится в третьем цикле. Он не заменяет официальные endpoints LINE для аналитики. Он дает webhook-first слой для входящих сообщений из LINE, WhatsApp, Telegram, TikTok, Zalo и X с одинаковой стандартной формой событий.
Как должен выглядеть входящий путь
В UnifyPort LINE-сообщение приходит как webhook-событие message.received. Доставка выполняется HTTP POST на ваш endpoint. Envelope использует одинаковые поля для поддерживаемых провайдеров: 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 endpoint может подписаться на message.received или использовать ["*"] для полного стандартного каталога событий. Если включена подпись, каждая доставка содержит X-Device-Timestamp и X-Device-Signature. Подпись — это hex-encoded HMAC-SHA256 от timestamp, точки и raw request body, подписанный signing_secret конкретного endpoint.
Правило для routing service становится простым: проверить подпись, дедуплицировать по event ID, сохранить нужный payload и затем маршрутизировать сообщение. Вызовы rich menu insight не должны попадать в этот путь.
Где остаются официальные LINE insights
Новые insight endpoints полезны. Но они отвечают на другой вопрос.
Используйте их, чтобы понять, кликают ли пользователи по зоне «Support» чаще, чем по зоне «Pricing». Используйте их для сравнения будней и выходных. Используйте их, чтобы решить, стоит ли оставлять сезонное меню. Расписание должно быть медленным: ежедневно для бизнес-отчетности, возможно каждый час во время кампании.
Не используйте их, чтобы понять, ждет ли пользователь поддержки. Клик по rich menu — не сообщение. Дневной отчет insight — не очередь. Конфигурационный endpoint с лимитом 10 rps — не примитив маршрутизации.
Самое простое разделение выглядит так:
| Задача | Лучший источник | Тайминг |
|---|---|---|
| Отчеты по показам и кликам rich menu | LINE rich menu insight endpoints | Раз в час или раз в день |
| Текущая конфигурация rich menu | LINE rich menu list endpoint | Кэш, вне hot path |
| Живое клиентское сообщение | UnifyPort message.received webhook | Немедленное событие |
| Cross-platform routing | Стандартный webhook envelope UnifyPort | Один handler для каждого провайдера |
Такое разделение снижает хрупкость. Если аналитическая job падает, очередь поддержки все равно получает сообщения. Если отчет rich menu задерживается, CRM все равно записывает каждый входящий разговор. Если позже вы добавите WhatsApp или Zalo, routing loop останется тем же, а аналитический loop останется LINE-specific.
Практичная архитектура
Небольшой support team не нужна сложная архитектура.
Зарегистрируйте webhook endpoint в UnifyPort, задайте signing_secret и подпишитесь на message.received. В handler проверьте X-Device-Signature, сохраните raw event и маршрутизируйте по provider, account_id, data.sender.id и data.message.type.
Отдельно запустите scheduled job для официальных rich menu reports LINE. Эта job вызывает insight endpoints, пишет метрики в warehouse или spreadsheet и никогда не блокирует inbound routing. Она также может обновлять cached rich menu list, но для support handler этот кэш должен быть read-only.
Когда support team отвечает, исходящий путь остается явным: отправить сообщение через POST /v1/messages с целевым аккаунтом и телом сообщения. Входящее событие остается источником правды о том, кто что сказал и когда.
Итоговая модель:
- Официальные LINE API отвечают за LINE-specific analytics.
- UnifyPort отвечает за нормализованную доставку входящих событий по провайдерам.
- Support backend не poll-ит официальные конфигурационные endpoints в message path.
- При добавлении нового мессенджера меняются данные, а не архитектура.
Главный вывод
LINE update от 1 июля — хорошая новость для команд, которым важна эффективность rich menu. Изменение лимита от 26 мая также проводит границу: rich menu configuration не стоит воспринимать как live message infrastructure.
Если ваша LINE-работа — в основном marketing analytics, используйте новые официальные insight endpoints. Если ваша работа — customer operations, сделайте inbound messages событийными. А если команда уже принимает клиентские сообщения из LINE, WhatsApp, Zalo, Telegram, TikTok или X, используйте одну webhook-форму, чтобы все платформы попадали в один routing pipeline.
Аналитику можно poll-ить. Клиентские сообщения должны приходить.