ストリーミングとソーシャル分析を拡張：レポートを送るすべてのストアを1つのダッシュボードに

空のチャートと、ゼロが並ぶチャートは、意味がまったく違います。正しいのは、どちらか一方だけです。Boomplayが報告するのは、ストリーム数と国別ストリーム数です。保存数は報告していません。だからBoomplayの保存数チャートは、ゼロの横線を引いて「この作品を保存した人はいない」と受け取らせるのではなく、「このストアは保存数を報告していません」と伝えるべきです。

この区別は、7月にリリースしたアナリティクスの大型アップデート全体を貫いています。LabelGridのアナリティクスは、分析フィードを送ってくるすべてのストアに対応しました。Spotify、Apple Music、Deezer、Audiomack、Boomplay、AWA、そしてTencentの3サービスであるKugou、Kuwo、QQ Musicです。SoundCloudからSnapchat、Metaのアプリまで、カタログをめぐるソーシャルやUGCの動きも、その隣に並びます。ストリーミング側は、公開APIとオープンソースのMCPサーバーから、プログラムでも取得できるようになりました。

どのストアが、何を報告するのか

配信先は、この一覧にとどまりません。ここに挙げたのは、分析フィードを取り込んでいるストアだけです。この違いは知っておく価値があります。ストアが分析フィードを公開しているかどうかにかかわらず、そのストアでの動きはロイヤリティ明細に反映されます。明細とアナリティクスは、別のパイプラインで動いているためです。

ストア	更新頻度	報告内容
Spotify	毎日	最も充実した内容。ストリーム数、リスナー数、保存数、スキップ数、シェア数、エンゲージメント率、ストリームソース、デバイス、リスナー属性
Apple Music	毎日	ストリーム数、リスナー数、ライブラリ追加数、エディトリアルプレイリストへの追加数、Shazam数、都市別・ストアフロント別の内訳
Deezer	毎日	ストリーム数、地域別、デバイス、リスナー属性、平均再生時間、プレイスメント（プレイリスト掲載）
Audiomack	毎日	ストリーム数、リスナー数、保存数、地域別
Boomplay	毎日	ストリーム数、国別ストリーム数
AWA	毎日	ストリーム数
Kugou、Kuwo、QQ Music	毎週	ストリーム数

この表の形そのものが要点です。スキップ、シェア、ストリームソース、時間帯、音声フォーマットを報告するのはSpotifyだけです。Shazam、ライブラリ追加、エディトリアルプレイリストへの追加はApple Musicだけです。ShazamはAppleのシグナルで、他に相当するものがないためです。再生回数ではなく人数を数えるリスナー属性は、SpotifyとDeezerが報告します。国別ストリーム数の対象はSpotify、Apple Music、Deezer、Boomplay、Audiomackで、AWAは含まれません。AWAのフィードはISOの国コードではなく、日本国内の地域コードを使っているためです。こうした違いを覚えておく必要はありません。ダッシュボードには各ストアが対応している項目が表示され、APIも同じ対応表をデータとして公開しています。

プレイスメントも同じ考え方です。Spotifyの行には、プレイリスト名とオーナー、ストリーム数が入ります。Apple Musicの行には、エディトリアルプレイリストの名称と、その曲が到達した最高順位が入ります。再生回数がまったく入っていない行もあり、その場合は「未報告」と表示されます。Deezerの行は、IDが解決できるときに公開プレイリストへリンクします。

ストアを合算する、比較する、1つずつ見る

このデータの使い方は、おおむね3つの表示モードでカバーできます。「合算」は全ストアを1つの数値にまとめます。「比較」は各ストアを並べて表示し、「すべて比較」は新しく追加されたストアを自動で取り込むため、既存の比較に新しいストアを加え直す必要はありません。「単体」は1つのストアの詳細画面を開きます。チャートの粒度は日・週・月、または自動から選べます。トップパフォーマーは指標ごとのタブに並び、プレイスメントにはストア別のフィルターがあります。

Tencent系ストアは、週に1ポイント

Kugou、Kuwo、QQ Musicは週次で報告します。1週間につき1曲あたり1つのデータポイントが届き、日付はレポートの対象日、値はその1週間分です。週次の合計を、こちらで作り出した日次の値に分割することは一切ありません。そのため日次チャートでは、この3つは週に1日だけ値が入り、その間は空白になります。

この空白は欠損ではなく、正しい表示です。期間の合計はきちんと合いますし、更新頻度はダッシュボードでもAPIレスポンスでも明示されます。連携システム側で、週次のストアと動きのないストアを区別できます。

指標が「利用不可」と表示されるとき

ダッシュボードでは、ストアが報告していない指標には、プラットフォームごとにその旨のラベルが付きます。APIでは、可用性マトリクスが該当セルをゼロの系列ではなく not_available_for_platform として返します。いちばん際立つのは、プレイスメントビューです。Apple Musicのエディトリアル行には、プレイリスト名と曲の到達順位は載っていても、再生回数が載っていないことがあります。それは「未報告」という意味です。これをゼロに置き換えると、数値の意味が変わってしまううえ、そこから計算するすべての平均値に偽の下限を敷くことになります。

プライバシーの下限値は、同じ考え方を逆の方向から適用したものです。リスナー属性と地域の内訳はk-匿名化されており、最小オーディエンス数の下限に満たないセルは完全に除外されます。「その他」の区分も、除外した数値を逆算できるような合計値も公開しません。Appleの都市別内訳や都市別Shazamは、規模の小さいカタログで最初に気づかれやすい項目です。ストリームは好調なのに、都市別チャートは空というケースです。これは設計どおりの動作で、上書きする手段はありません。ごく少数の特定可能なリスナーに関する情報を公開してしまうことになるからです。

数値の鮮度と、数値が動く理由

ストアの報告にはタイムラグがあり、フィードごとに公開のタイミングも異なります。そのため、同じ日でも、指標によって最新の日付が違うことがあります。そこで各指標には、2つの日付があります。データが存在する最新の日付である「報告済み日(reported-through)」と、確定値として扱える最新の日付である「確定済み日(complete-through)」です。両者の間にある期間はまだデータが入りつつある状態で、ダッシュボードでは「暫定」として表示します。一部しか届いていない日が急落に見えてしまうのを防ぐためです。チャートの右端は、あとで見たときに伸びているものと考えてください。チャートが報告済み日で途切れている場合は、ストアがそれ以降の日付をまだ報告していないという意味です。

履歴の長さも、フィードと同じように分かれます。SpotifyとApple Musicは、数年前までさかのぼれます。今回追加したストア、つまりDeezer、Boomplay、AWA、Audiomack、Tencentの3サービスは、フィードが届き始めた2026年1月下旬ごろからの履歴があります。

カタログをめぐるソーシャルとUGCの動き

ソーシャル系の画面では、DSPの外であなたの音楽がどう使われているかを追えます。プラットフォームごとに、報告される項目は異なります。

• SoundCloud：再生数、リポスト、お気に入り、それぞれの地域別内訳
• Snapchat：コンテンツ作成数（音楽が使われた回数）、地域別のビュー数とリーチ
• InstagramとFacebook：地域別の作成数とビュー数、アーティストアカウントのフォロワー数とエンゲージメントの伸び
• WhatsAppとMessenger：地域別の作成数とビュー数。アカウント単位のフィードはありません
• Threads：ビュー数とリーチのみ。フィードが報告するのは、作成ではなく閲覧だからです

これらはストリーミングとは別系統です。フィードもプラットフォームの軸も異なるため、データは分けて扱います。UGCのビューやコンテンツ作成が、DSPのストリーム合計に加算されることはありません。ダッシュボード専用で、公開APIでは意図的に提供していません。/analytics/* を読み込む連携システムが、SoundCloudやMetaの数値を見つけることはありません。

37のセクションキーと、それを対応表で返す1本のエンドポイント

ストリーミングデータは公開APIで取得できます。対象は自分のレーベルに限られ、識別子フィールドにはISRCが使われます。GET /analytics/summary は複合エンドポイントで、必須の metrics[] パラメーターを使い、37のセクションキーから1〜12個を選びます。指定を省略すると意図的に422を返し、12個を超える指定は拒否されます。その場合は複数のリクエストに分けてください。リクエストごとに個別にキャッシュされます。個別の系列には15本の単独エンドポイントがあり、ストリーム数やリスナー数から、保存数、スキップ数、完聴率、デバイス別・ソース別の内訳、さらにリスナー属性や地域別の切り口までを網羅しています。リーダーボードはレーベル、アーティスト、リリース、トラックで絞り込んだ上位N件のランキングを返し、プレイスメントはプラットフォームで絞り込めます。

GET /api/public/analytics/summary
  ?metrics[]=streams
  &metrics[]=listeners
  &metrics[]=streams-by-country
  &filter[platform]=SPOTIFY
  &filter[start_date]=2026-01-01
  &filter[end_date]=2026-07-01

filter[platform] には、SPOTIFY、APPLE_MUSIC、DEEZER、BOOMPLAY、AWA、AUDIOMACK、KUGOU、KUWO、QQMUSICを指定できます。省略すると、アカウントにデータがあるすべてのプラットフォームが返されます。summaryの各レスポンスには、プラットフォームの更新頻度が meta.platform_cadence に、セクションごとの2つの鮮度日付が meta.sections_as_of と meta.sections_complete_through に入っています。クライアント側で、まだデータが入りつつある日付を暫定として表示し、期間合計から除外できます。

範囲は、summaryと15本の系列エンドポイントで最大400日です。1年分と比較期間を1回の呼び出しで取得できる長さです。リーダーボードとプレイスメントは180日までです。短い期間をつなぎ合わせても、長い期間のランキングを正しく組み立てることはできないためです。90日を超えるリクエストは、標準のアナリティクス制限に加えて、さらに厳しい2つ目のレート制限の対象になります。90日以内のリクエストには影響しません。

ここまでのストア別の詳細をコードに直接書き込む前に、GET /analytics/availability を呼び出してください。パラメーターは不要で、内容は静的でキャッシュも効きます。セクションとプラットフォームの対応表全体と、更新頻度のマップを、1回のレスポンスで返します。これを基準に作っておけば、新しいストアがフィードに加わっても、コードの修正ではなくデータの更新だけで済みます。

アシスタントに聞くこともできます

LabelGrid MCPサーバーは、この同じ公開APIを型付きで薄くラップしたものです。そのため、Claude Desktop、Claude Code、CursorといったModel Context Protocolクライアントなら、どれでもカタログの成績を直接読み取れます。「先月ドイツで伸びた自分の曲はどれで、どのストアか」を、4つのエクスポートを突き合わせることなく、そのまま質問できます。ラッパーは上記の内容をすべて引き継ぎます。可用性のルール、週次の更新頻度、鮮度日付も同じです。省かれている点も同様で、ソーシャルの数値はAPIにないため、ここにもありません。セットアップと権限モデルは、MCPのリリース記事で解説しています。

すべて、すでにダッシュボードで利用できます。アナリティクスは、アドバンスト機能も含めて、すべての標準プランに付属します。APIとMCPのアクセスは、LabelGridのAPIプランでご利用いただけます。アナリティクスのページにストア別の詳細が、料金ページにプランの一覧があります。

よくある質問