リッチメニューを数字で改善する。統計APIの範囲と指標の読み方

リッチメニューの改善では、「どのボタンが押されたか」だけでなく、「何人に表示され、その先の用事が完了したか」を見ます。予約ボタンのクリックが多くても、予約画面で迷って戻っているなら、色や配置だけを変えても解決しません。

2026年7月1日には、Messaging APIで作ったリッチメニューの統計を取得するAPIが追加されました。本記事では2026年9月8日時点の公式資料を確認し、取得範囲と数字の読み方を整理します。計算例は架空の値で、実配信の分析結果ではありません。統計APIの公式リリース

最初に、どのツールで作ったメニューか確認する

管理画面で作成したリッチメニューには、管理画面側の分析機能があります。APIが追加されたことで、両方式の統計をどこからでも取れるようになったわけではありません。

メニューの作成元	統計の確認先	運用時の注意
LINE Official Account Manager	同管理画面の分析	管理画面の指標・集計条件に従う
Messaging API	Messaging APIの統計エンドポイント	対象IDの管理と取得処理が必要

それぞれ作成したツールでのみ統計を参照できることが公式に示されています。リッチメニューの公式比較と管理画面の分析マニュアル

制作会社に「分析APIを付けてほしい」と依頼する前に、現在のメニューID、作成方法、変更担当者を確認してください。管理画面で十分に評価できるなら、統計を取得するためだけに作成方法を変える必要があるかを比較します。

回数と人数を混ぜず、領域ごとに見る

APIでは指定期間の合計と日別の統計を取得できます。表示回数・表示人数と、クリック領域ごとのクリック回数・人数を使い分けます。合計の公式仕様と日別の公式仕様

指標	答えたいこと	読み違いの例
表示回数	メニューが何回表示されたか	同じ人の再表示を別人として扱う
表示人数	何人がメニューを見たか	友だち全体が見たと考える
領域別クリック回数	その領域が何回使われたか	繰り返し操作を成果件数にする
領域別クリック人数	その領域を何人が使ったか	複数領域の人数を単純合算する
自社側の完了件数	予約・申込などが何件成立したか	LINEのクリックだけで成立と判断する

同じ人が予約と問い合わせの両方を押す場合、二つの領域の人数を足すと重複します。日別の人数も、同じ人が別の日に使えば重複するため、合計して期間の実人数とはしません。

計算例：予約領域の利用を二つの比率で読む

架空の一週間で、メニューの表示回数が1,000、表示人数が500、予約領域のクリック回数が120、クリック人数が90だったとします。

計算	値	何を表すか
120回 ÷ 1,000回	12％	表示回数に対する予約領域のクリック回数の比
90人 ÷ 500人	18％	表示した人のうち予約領域を押した人の割合

二つとも使えますが、同じ「クリック率」という列名にしません。回数の比は繰り返し操作の影響を受けるため、利用者の割合として読めない場合があります。表示後に同じ領域を複数回押すこともあるため、回数の比を確率とは扱いません。

予約完了が何件だったかは別に自社側で確認します。クリックした人と予約した人を個人単位で対応づけられない場合は、90人をそのまま予約の母集団とみなして精密な離脱率を出さないようにします。

統計がない場合を、ゼロとして描かない

APIの統計は通常翌日中に集計されます。また、指定した期間全体でクリックした実人数が20人未満の場合、リッチメニューIDのみが返り、統計値が含まれません。数値には誤差を含む場合もあります。公式の集計条件

この場合、ダッシュボードで表示回数やクリックをゼロに変換すると、「誰も使っていないメニュー」という誤った評価になります。未取得、集計待ち、少人数等で取得できない状態と、取得できたゼロを分けます。

取得した状態	画面での扱いの案
数値が取得できた	値と実際の集計期間を表示
IDだけ返った	統計取得条件を満たさない可能性を表示
APIが失敗した	取得失敗と再取得予定を表示
対象期間に不足がある	要求期間と取得できた期間を分ける

取得APIにはレート制限があるため、担当者が画面を開くたびに全メニューを再取得する構成は避け、取得結果を保存する方式を検討します。対象数、取得間隔、再試行を現在の公式上限に合わせます。

ボタンの意味とメニューの版を保存する

クリック統計の領域情報だけでは、その場所に当時何が表示されていたかを後から説明できません。左上のボタンが先月は「営業時間」、今月は「予約」なら、同じ場所のクリックを一つの推移へ足すと意味が変わります。

設計案として、メニューIDごとに画像、公開期間、領域と表示名、遷移先、適用対象を保存します。画面やボタンを変更した際は、変更日と仮説も記録します。

例えば「予約の文言を『空き状況を見る』へ変更し、予約画面へ進む前の不安を減らす」という仮説なら、予約領域の利用と画面到達、その後の申込状況を比較します。色、文言、配置、リンク先を同時に変えた場合は、特定の一要素が原因とは断定しません。

実務例：クリックの多さが迷いを示していた場合

架空の施設予約サービスで、予約領域のクリック回数が増えたのに申込件数が変わらない状況を考えます。調べると、遷移先が長い施設紹介ページで、空き状況へ進む入口が下部にありました。

改善案は、リッチメニューの文言と遷移先を対応させ、空き状況を確認しやすいページへ案内することです。同時に、利用者が予約確認と新規申込を取り違えないようにします。

変更後は同じ期間の長さだけでなく、配信キャンペーン、施設の休業日、予約可能枠を記録して比較します。利用者が増えただけでクリック数が上がったのか、導線が改善したのかを分けて判断するためです。

分析機能の受入確認表

確認する場面	合格の判断
管理画面作成のメニュー	対応する取得先で確認し、API取得可能と誤表示しない
同じ人が複数日使う	日別人数を期間の実人数として合算しない
少人数で統計が欠ける	ゼロで埋めず、取得できない状態を示す
メニューを変更する	画像・領域・表示名・公開期間が追える
APIが失敗する	過去値と失敗状態を区別し、再取得できる
予約が取り消される	クリックと取引の状態を別に確認できる
数値を共有する	分母、分子、期間、比較条件を説明できる

リッチメニューの改善を依頼する場合は、画像制作と分析の定義、遷移先の使いやすさを同じ課題として扱うと、変更の目的が明確になります。

よくある質問

管理画面で作ったメニューもAPIで分析できますか？

管理画面とMessaging APIで作ったメニューは、それぞれ作成したツールで統計を確認します。現在の作成元を調べてから、分析画面や取得処理を選びます。

日別の利用人数を足すと月間の利用人数になりますか？

同じ人が別の日に利用している可能性があるため、期間の実人数にはなりません。日別の推移と期間全体の人数を分けて確認します。

統計値が返らない場合はクリックゼロですか？

ゼロとは限りません。指定期間全体でクリックした実人数が20人未満の場合は、IDだけが返る仕様があります。取得失敗や集計条件も含めて、欠測とゼロを区別します。

予約ボタンのクリック数が増えれば改善成功ですか？

予約画面へ進んだ後に迷っている可能性もあります。予約完了などの目的と比較し、メニューの表示条件、リンク先、配信や営業日の違いも確認して判断します。

この記事に関連するサービス

リッチメニューの見た目、統計の取得、予約・申込画面までの導線を合わせて改善したい方は、LINEアプリ開発のサービスをご覧ください。

LINEアプリ開発のサービス・相談窓口を見る