ストリーミング・ソーシャル分析
レーベルのカタログ向けストリーミング分析
ある楽曲の再生数が、週末のうちにDeezerで伸び始めます。火曜日にはApple Musicのエディトリアルチームがこの曲を追加します。木曜日には、チームが一度もマーケティングをしたことのない国のSnapchat動画でBGMとして使われています。ダッシュボードもログインも別々で、フィードはそれぞれ異なるタイミングで届きます。
LabelGridならカタログ全体を1つの画面で確認できます。Spotify、Apple Music、Amazon Music、Deezer、Audiomack、Boomplay、AWA、KuGou、KuWo、QQ Musicが同じビューにレポートを送り、レーベルごとに絞り込んで表示されます。実際にリスナーが音楽を使っているソーシャルプラットフォームのデータも、すぐ隣に並びます。ダッシュボードで読み解くのはもちろん、自社のコードから取得したり、AIアシスタントに尋ねたりすることもできます。
統合・比較・単体表示
データを提供するすべてのストアを、ひとつのダッシュボードで
Spotify、Apple Music、Amazon Music、Deezer、Audiomack、Boomplay、AWAは毎日レポートを送り、KuGou、KuWo、QQ Musicは週に一度のペースでレポートを送りますが、すべて同じビューに反映されます。統合モードでは、すべてのストアを横断してカタログ全体を合算します。比較モードでは各ストアを並べて表示でき、自国では反応が薄いリリースが、他の地域では意外と好調だとわかるのはたいていこの画面です。単体モードは、1つのストアだけをじっくり分析したいときに使います。「全ストア比較」は新しいストアを自動的に取り込むため、来四半期に追加されるフィードも、数か月前に作った比較画面にそのまま表示されます。Amazon Musicも2026年8月にこの仕組みで加わりました。
LabelGridはすべての主要な音楽配信サービスに配信していますが、分析フィードを取り込んでいるのは上記のストアです。それ以外のストアでも収益は発生し、ロイヤリティの明細にはきちんと反映されます。明細と分析は別々のパイプラインで動いているため、ここにグラフが表示されないストアからも支払いを受けられます。
47の指標セクション
再生数の大きさより、データの深さ
再生数を見れば、何かが起きたことはわかります。残り46の指標セクションを見れば、それが何だったのかがわかります。47セクションのうち39がストリーミングストア向け、8がソーシャル向けで、すべてのストアがすべての指標を報告しているわけではありませんが、ダッシュボードは指標ごとにどのストアが対象かを明示するので、推測する必要はありません。
再生数、リスナー数、保存数
ストリーム数はリストにあるすべてのストアから得られます。リスナー数はSpotify、Apple Music、Amazon Music、Audiomackから提供され、SpotifyとAppleはトラックごとに重複を排除した実際の日次リスナー数を報告します。保存数はSpotifyとAudiomackから得られ、Spotifyはサブスクリプションのプラン別に保存数を分けて報告します。スキップとシェアはSpotify独自の指標です。
どこで聴かれているか
国別のストリーム数はSpotify、Apple Music、Amazon Music、Deezer、Boomplay、Audiomackで確認でき、Appleはさらに都市別・ストアフロント別の内訳も提供します。AWAのフィードには国ではなく日本国内の地域コードが含まれているため、AWAのストリーム数には国別の内訳がありません。KuGou、KuWo、QQ Musicにも国別の内訳はありません。
誰が聴いているか
年齢別・性別のストリーム数はSpotifyとApple Musicから得られます。SpotifyとDeezerのリスナー属性データは同じオーディエンスを別の角度から捉えたもので、再生回数ではなく人数を数えます。これには年齢、性別、地域、そして無料プランと有料プランの比率が含まれます。
どのように聴いているか
ここで最も深いデータを提供するのはSpotifyです。完了率やスキップ傾向、平均再生時間、シャッフル再生の割合に加えて、発見率やリピートリスナー率、プロモーション経由で始まったストリームの割合、歌詞表示やCanvas再生回数も確認できます。仕組みの部分では、デバイス、OS、音声フォーマット、時間帯、そしてその再生がプレイリスト、誰かのライブラリ、検索のどこから始まったのかまでわかります。Deezerは平均再生時間に加えてデバイスとOSを報告します。
プレイリストとエディトリアル
プレイスメントビューには、Spotify、Apple Music、Deezerでトラックが掲載されたプレイリストが一覧表示され、ストアごとに絞り込むこともできます。Spotifyの行にはプレイリスト名、作成者、ストリーム数が表示されます。Appleの行にはエディトリアルプレイリスト名とトラックが到達した最高順位が表示され、再生数が付いていない場合もありますが、これは数値が欠けているのではなく、そのストアが再生数を報告していないことを意味します。Deezerの行は、IDが解決できる場合、公開プレイリストへのリンクとなります。
ShazamとApple独自の指標
ライブラリへの追加数、エディトリアルプレイリストへの追加数、そしてShazam数（都市別・州別のShazam数を含む）はApple Musicから得られます。Appleはさらに、ある期間のオーディエンスのうち初めてその曲を聴いた人の割合を示す発見コホートも報告します。ShazamはAppleならではの指標で、Spotifyには相当するものがありません。
データの欠損を埋めない
正直な設計
分析ツールを完璧に見せかけるのは簡単です。週間合計を7日間に均等配分したり、ストアが一度も送っていない指標をゼロとして表示したり、まだ集計中の日をあたかも確定値であるかのようにこっそり描いたりすれば、どのグラフも美しく埋まります。LabelGridはそのどれもしません。つまり、数値の代わりに空白が表示されることもあるということです。
ストアが報告していない指標
ストアが指標を送っていない場合、ダッシュボードはそのプラットフォームについて「利用不可」と表示します。ゼロと表示することは決してありません。ゼロはそれ自体がひとつの実測値であり、「このストアはこれを公開していない」というのはまったく別の話だからです。Amazon Musicはその典型例です。ストリーム数、リスナー数、国だけを報告するため、スキップ数や属性データのチャートは平坦な線ではなく「利用不可」と表示されます。
週次のストアは週次のまま
KuGou、KuWo、QQ Musicは週に一度レポートを送ります。各レポートは1つのデータポイントとなり、対象の日付に紐づいてその週全体の合計を保持します。架空の日次数値7つに分割されることはありません。日次チャートでは、これらのストアのデータは週に1回、間隔を空けて並びますが、これは欠損ではなく正しい状態であり、期間合計もきちんと一致します。
直近数日はまだ集計中
すべての指標には、それぞれ「報告済み日」と「確定済み日」があり、この2つは必ずしも同じ日ではありません。その間にあるデータはまだ届いている途中のため、それらの区間は半端に報告された日が急落したように見えないよう「一部確定」として表示されます。チャートの末尾部分は、後で見直すと数値が上昇していることがあります。
オーディエンス詳細のプライバシー基準
属性別・地域別の内訳はk-匿名化されています。Appleの都市別内訳、都市・州別のShazam数、リスナー属性データはすべて、最小オーディエンス基準に達してはじめて表示され、これを下回るセルは完全に非表示になります。「その他」枠にまとめられることも、抑制されたオーディエンス数を逆算できてしまうような合計値が表示されることもありません。そのため、小規模なカタログでは、好調なストリーム数の隣に空の属性チャートや都市チャートが表示されることがあります。これはこの基準が正しく機能している証拠であり、その空白に架空の数値を入れて埋めることはありません。
意図的に含まれていないもの
ストリーミングの不正検知は顧客向け分析には一切含まれないため、これらのチャートの数値がアーティストへの判定を兼ねることはありません。その機能は、独立したアドオンであるStream Radarが専用の画面で担っています。
ソーシャルとUGC
ストアの外でも使われる楽曲
ある楽曲が、誰かのSnapchat動画の中で使われることがあります。この利用はストリーム数には一切反映されません。ソーシャルビューがカバーするのは、まさにこうしたカタログのもう一つの使われ方です。
SoundCloudは再生数、平均再生時間、リポスト数、お気に入り数、プレイリスト追加数、地域を報告します。Snapchatはコンテンツ作成数、つまりその楽曲を使って実際に作られたコンテンツの件数を、再生数と地域とともに報告します。Meta系アプリは1つの利用状況調査から得られ、アプリごとに内訳が分かれます。InstagramとFacebookはコンテンツ作成数、再生数、地域に加え、アーティストアカウントのフォロワー増加数とエンゲージメント増加数を報告し、WhatsAppとMessengerはコンテンツ作成数、再生数、地域を報告し、Threadsはこの調査にコンテンツ作成数のデータが一切含まれていないため、再生数とリーチのみを報告します。
これらはストア側とは別のプラットフォーム軸で動いています。コンテンツ作成数、視聴回数、再生数はそれぞれ別の数値であり、互いに合算されることも、ストリーム数の合計に加算されることもありません。
公式MCPサーバー
AIアシスタントにストリーミング統計を尋ねる
「ベルリンのリリースは先月Apple Musicでどうだったか、そしてどの国が最も伸びたか」。Claudeにそう入力すれば、クエリを書くこともエクスポートを開くこともなく、自社のカタログから直接答えが返ってきます。
LabelGridはこのための公式MCPサーバーを自社で公開しています。MITライセンスのオープンソースとして、npmから@labelgrid/mcpという名前でインストールできます。内部的には、以下で説明するパブリック分析APIを型付きでラップしたものであり、アシスタントが読み取れるのはダッシュボードと同じ範囲のデータだけです。Claude Desktop、Claude Code、Cursor、その他あらゆるModel Context Protocolクライアントが接続でき、MCPサーバーとAPIはどちらもLabelGridのAPIプランで利用できます。
MCPサーバーはダッシュボードと同じ対応マトリクスと鮮度情報もアシスタントに渡すため、ストアが一度も報告していない指標は空欄ではなく「利用不可」として返されます。わかりやすい例がAmazon Musicの属性データです。そもそも存在しないデータなので、マトリクスもそう答えます。数値を推測するアシスタントは、いないほうがましです。
パブリック分析API
自社のコードからカタログを取得する
上記のすべての指標はパブリックAPIの/api/public/analytics以下で取得でき、レーベル単位に限定されたうえで、すでに使い慣れたISRC、UPC、リリース、アーティストといった識別子で絞り込めます。サマリーエンドポイントは、8つのソーシャルセクションを含む47の指標セクションのうち最大12個を1回の呼び出しで返し、filter[ugc_platform]で特定のプラットフォームだけを指定することもできます。15個の単体シリーズエンドポイントは、個々の指標を単独でカバーします。リーダーボードは成績上位のものをランキング形式で返し、エンティティフィルターでレーベル、アーティスト、リリース、トラックの単位までランキングを限定できます。プレイスメントは、プラットフォームでフィルタリングしたプレイリストの行を返します。
とくに実装の土台として活用しやすいものが2つあります。availabilityエンドポイントに各プラットフォームが何をサポートしているかを問い合わせると、どのプラットフォームがどのセクションに対応しているかを示すストリーミングのマトリクス全体と、各ストアの報告頻度が、キャッシュ可能かつパラメータ不要の1回の呼び出しでまとめて返ってきます。これにより、実装側はストアが追加された週に前提が崩れるようなハードコードを避け、このマトリクスを読み取るだけで済みます。ソーシャルの対応状況は、ソーシャルセクションを要求するどのサマリーレスポンスにも含まれます。すべてのサマリーレスポンスにはセクションごとの鮮度情報が含まれているため、自社のレポートでもLabelGridのダッシュボードと同じように未確定の日をマークできます。
サマリーとシリーズの各エンドポイントは、1年分に比較期間を加えた最長400日間のウィンドウを1回のリクエストで受け付けます。リーダーボードとプレイスメントは180日までです。サマリーをリリース単位で絞り込むと、トラックごとのセクションはトラック1件につき1回の呼び出しではなく、日付・プラットフォーム・ISRCごとに1行ずつ、リリース内のすべてのトラックの日次シリーズをまとめて返します。
よくある質問