Erweiterte Streaming- und Social-Analytics: Alle meldenden Stores in einem Dashboard

Ein leeres Diagramm und ein Diagramm voller Nullen sagen zwei verschiedene Dinge aus, und nur eines davon kann stimmen. Boomplay meldet Streams und Streams nach Land. Saves meldet der Store nicht. Ein Saves-Diagramm für Boomplay sollte deshalb ausweisen, dass der Store diese Zahl nicht liefert, statt eine flache Linie bei null zu zeichnen, aus der man schließen könnte, niemand habe den Release gespeichert.

Diese Unterscheidung zieht sich durch das Analytics-Update, das wir im Juli ausgeliefert haben. LabelGrid Analytics deckt jetzt jeden Store ab, der uns einen Analytics-Feed schickt: Spotify, Apple Music, Deezer, Audiomack, Boomplay, AWA und die drei Tencent-Dienste Kugou, Kuwo und QQ Music. Daneben steht die Social- und UGC-Aktivität rund um Ihren Katalog, von SoundCloud über Snapchat bis zu den Meta-Apps. Die Streaming-Daten lassen sich jetzt außerdem programmatisch abrufen, über die öffentliche API und den Open-Source-MCP-Server.

Welche Stores Daten melden und was sie jeweils liefern

Der Vertrieb geht über diese Liste hinaus. Hier stehen die Stores, deren Analytics-Feeds wir einlesen, und der Unterschied ist wichtig: Die Aktivität eines Stores landet in Ihren Abrechnungen, ganz gleich, ob er einen Analytics-Feed veröffentlicht oder nicht, denn Abrechnungen und Analytics laufen über getrennte Pipelines.

Store	Meldefrequenz	Gemeldete Daten
Spotify	Täglich	Der umfangreichste Datensatz: Streams, Hörer, Saves, Skips, Shares, Engagement-Raten, Stream-Quellen, Geräte, Demografie
Apple Music	Täglich	Streams, Hörer, Aufnahmen in die Mediathek, Aufnahmen in redaktionelle Playlists, Shazams sowie Aufschlüsselungen nach Stadt und Storefront
Deezer	Täglich	Streams, geografische Verteilung, Geräte, Demografie der Hörer, durchschnittliche Hördauer, Platzierungen
Audiomack	Täglich	Streams, Hörer, Saves, geografische Verteilung
Boomplay	Täglich	Streams, Streams nach Land
AWA	Täglich	Streams
Kugou, Kuwo, QQ Music	Wöchentlich	Streams

Die Tabelle zeigt vor allem eines: Skips, Shares, Stream-Quellen, Tageszeit und Audioformat liefert allein Spotify. Shazams, Aufnahmen in die Mediathek und Aufnahmen in redaktionelle Playlists stammen allein von Apple Music, denn Shazam ist ein Apple-Signal ohne Entsprechung anderswo. Die Demografie der Hörer, die Personen statt Wiedergaben zählt, kommt von Spotify und Deezer. Streams nach Land gibt es für Spotify, Apple Music, Deezer, Boomplay und Audiomack, nicht aber für AWA, dessen Feed statt ISO-Ländercodes subnationale japanische Regionalcodes enthält. Das alles müssen Sie sich nicht merken: Das Dashboard zeigt, was jeder Store unterstützt, und die API veröffentlicht dieselbe Matrix als Daten.

Für Playlist-Platzierungen gilt dasselbe. In den Spotify-Zeilen stehen Name und Inhaber der Playlist samt Stream-Zahlen. Bei Apple Music erscheinen redaktionelle Playlists mit Namen und der besten Position, die der Titel erreicht hat; manche dieser Zeilen haben gar keine Wiedergabezahl, was als „nicht gemeldet“ angezeigt wird. Deezer-Zeilen verlinken auf die öffentliche Playlist, sofern sich die ID auflösen lässt.

Stores kombinieren, vergleichen oder einzeln betrachten

Drei Ansichtsmodi decken das meiste ab, was man mit diesen Daten tut. „Kombiniert“ fasst alle Stores zu einer Zahl zusammen. „Vergleich“ stellt sie nebeneinander, und „Alle vergleichen“ nimmt neu hinzugekommene Stores automatisch auf, sodass Sie einen neuen Store nie eigens in einen bestehenden Vergleich einbinden müssen. „Einzeln“ öffnet die vollständige Detailansicht eines Stores. Die Diagramme lassen sich nach Tag, Woche oder Monat auflösen, wahlweise auch automatisch. Die Top-Performer stehen pro Kennzahl in Tabs, und die Platzierungen lassen sich nach Store filtern.

Ein Datenpunkt pro Woche von den Tencent-Stores

Kugou, Kuwo und QQ Music melden wöchentlich. Jede Woche ergibt einen Datenpunkt pro Titel. Er ist auf den Tag datiert, den der Bericht abdeckt, und enthält die Werte der gesamten Woche. Wochensummen verteilen wir nie auf erfundene Tageswerte. Im Tagesdiagramm zeigen diese drei Stores deshalb pro Woche nur einen Tag mit Werten und dazwischen Lücken.

Die Lücken sind korrekt, es fehlen keine Daten. Die Summen über einen Zeitraum stimmen weiterhin, und die Meldefrequenz ist im Dashboard und in der API-Antwort ausgewiesen, sodass eine Integration einen wöchentlich meldenden Store von einem ruhigen unterscheiden kann.

Wenn bei einer Kennzahl „nicht verfügbar“ steht

Meldet ein Store eine Kennzahl nicht, wird sie im Dashboard pro Plattform entsprechend gekennzeichnet; in der API liefert die Verfügbarkeitsmatrix die Zelle als not_available_for_platform statt einer Reihe von Nullen. Am deutlichsten wird das in der Platzierungsansicht: Eine redaktionelle Apple-Music-Zeile kann die Playlist und die erreichte Position nennen, ohne dass daneben eine Wiedergabezahl steht. Das bedeutet „nicht gemeldet“. Macht man daraus eine Null, ändert man die Aussage der Zahl und zieht jedem daraus berechneten Durchschnitt eine künstliche Untergrenze ein.

Die Datenschutzschwellen folgen derselben Logik, nur aus der anderen Richtung. Demografische und geografische Aufschlüsselungen sind k-anonymisiert: Zellen unterhalb einer Mindestzahl an Hörern werden komplett verworfen, ohne Restkategorie und ohne veröffentlichte Gesamtsumme, aus der sich der unterdrückte Wert errechnen ließe. Bei kleineren Katalogen fällt das meist zuerst bei den Apple-Aufschlüsselungen nach Stadt und bei den Shazams pro Stadt auf: solide Streams, aber ein leeres Städtediagramm. Das ist so gewollt und lässt sich nicht umgehen, denn die Alternative wäre, etwas über eine Handvoll identifizierbarer Hörer zu veröffentlichen.

Wie aktuell die Zahlen sind und warum sie sich ändern

Stores melden mit Verzögerung, und unterschiedliche Feeds erscheinen zu unterschiedlichen Zeiten. An einem beliebigen Tag kann eine Kennzahl daher bis zu einem späteren Datum reichen als eine andere. Jede Kennzahl trägt deshalb zwei Datumsangaben: ein Gemeldet-bis-Datum, das jüngste Datum, für das Daten vorliegen, und ein Vollständig-bis-Datum, das jüngste Datum, das als final gelten kann. Alles dazwischen füllt sich noch, und das Dashboard markiert diese Zeiträume als unvollständig, damit ein halb gemeldeter Tag nicht wie ein Einbruch aussieht. Rechnen Sie damit, dass das rechte Ende eines Diagramms beim nächsten Aufruf höher liegt. Läuft ein Diagramm am Gemeldet-bis-Datum aus, hat der Store spätere Tage noch nicht gemeldet.

Wie weit die Historie zurückreicht, hängt ebenfalls vom Feed ab. Bei Spotify und Apple Music sind es mehrere Jahre. Für die Stores, die mit diesem Update hinzugekommen sind (Deezer, Boomplay, AWA, Audiomack und die drei Tencent-Dienste), reicht die Historie bis etwa Ende Januar 2026 zurück, als ihre Feeds einzutreffen begannen.

Social- und UGC-Aktivität rund um Ihren Katalog

Die Social-Bereiche erfassen, was Menschen außerhalb der DSPs mit Ihrer Musik machen. Jede Plattform meldet ihren eigenen Ausschnitt:

• SoundCloud-Plays sowie Reposts und Favoriten, samt den zugehörigen Territorien
• Snapchat: Content-Creates, also Verwendungen der Musik, sowie Aufrufe und Reichweite nach Territorium
• Instagram und Facebook: Creates und Aufrufe nach Territorium sowie Follower- und Engagement-Wachstum des Künstlerkontos
• WhatsApp und Messenger: Creates und Aufrufe nach Territorium, ohne zugehörigen Konto-Feed
• Threads: nur Aufrufe und Reichweite, weil der Feed Konsum statt Creates meldet

Diese Daten sind eine eigene Kategorie neben dem Streaming, mit anderen Feeds und einer anderen Plattformachse, und sie bleiben getrennt: Ein UGC-Aufruf oder ein Content-Create fließt nie in die Stream-Summe eines DSP ein. Sie stehen nur im Dashboard und bewusst nicht in der öffentlichen API. Eine Integration, die /analytics/* abfragt, findet dort also keine SoundCloud- oder Meta-Zahlen.

37 Section-Keys und ein Endpoint, der sie abbildet

Die Streaming-Daten stehen in der öffentlichen API bereit, begrenzt auf Ihre eigenen Labels und per ISRC im Feld identifier adressiert. GET /analytics/summary ist der Sammelabruf: Mit dem Pflichtparameter metrics[] wählen Sie zwischen einem und zwölf von 37 Section-Keys. Fehlt er, kommt absichtlich ein 422 zurück, und eine Auswahl von mehr als zwölf wird abgelehnt. Sie teilen die Auswahl dann auf mehrere Anfragen auf, die unabhängig voneinander zwischengespeichert werden. Fünfzehn eigenständige Endpoints decken die einzelnen Reihen ab, von Streams und Hörern über Saves, Skips, Abschlussrate, Geräte- und Quellenaufteilung bis zu den demografischen und geografischen Auswertungen. Leaderboards liefern Top-N-Rankings, gefiltert nach Label, Künstler, Release oder Track, und die Platzierungen lassen sich nach Plattform filtern.

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] akzeptiert SPOTIFY, APPLE_MUSIC, DEEZER, BOOMPLAY, AWA, AUDIOMACK, KUGOU, KUWO und QQMUSIC. Ohne Angabe liefert die API jede Plattform, für die Ihr Konto Daten hat. Jede Summary-Antwort enthält die Meldefrequenz der Plattform in meta.platform_cadence und pro Section die beiden Datumsangaben zur Aktualität als meta.sections_as_of und meta.sections_complete_through, sodass ein Client noch nicht abgeschlossene Tage als vorläufig darstellen und aus den Periodensummen heraushalten kann.

Zeiträume reichen bei Summary und den fünfzehn Serien-Endpoints bis zu 400 Tage, also ein volles Jahr plus Vergleichszeitraum in einem Aufruf. Leaderboards und Platzierungen bleiben bei 180 Tagen, weil sich ein Ranking über eine längere Spanne nicht ehrlich aus kürzeren Fenstern zusammensetzen lässt. Anfragen über mehr als 90 Tage werden zusätzlich zum regulären Analytics-Limit auf ein zweites, engeres Rate-Limit angerechnet; Anfragen mit 90 Tagen oder weniger sind davon nicht betroffen.

Bevor Sie etwas von den Details pro Store fest in Ihren Code schreiben, rufen Sie GET /analytics/availability auf. Der Endpoint braucht keine Parameter, ist statisch und zwischenspeicherbar und liefert die komplette Matrix aus Sections und Plattformen samt der Map der Meldefrequenzen in einer Antwort. Bauen Sie darauf auf, dann ist ein neuer Store im Feed eine Datenänderung und keine Codeänderung.

Oder fragen Sie Ihren Assistenten

Der LabelGrid MCP-Server ist ein schlanker, typisierter Wrapper um dieselbe öffentliche API. Jeder Model-Context-Protocol-Client, etwa Claude Desktop, Claude Code oder Cursor, kann die Performance Ihres Katalogs deshalb direkt auslesen. „Welche meiner Tracks sind letzten Monat in Deutschland gewachsen, und auf welchem Store?“ ist damit eine Frage, die Sie stellen, statt vier Exporten, die Sie abgleichen müssen. Der Wrapper übernimmt alles oben Beschriebene, darunter die Verfügbarkeitsregeln, die wöchentliche Meldefrequenz und die Angaben zur Aktualität, und er übernimmt auch die Auslassungen: Die Social-Zahlen stehen nicht in der API und damit auch nicht im MCP-Server. Einrichtung und Berechtigungsmodell behandelt der Launch-Beitrag zum MCP-Server.

Alles ist jetzt im Dashboard live. Analytics, einschließlich des erweiterten Funktionsumfangs, ist in jedem Standardtarif enthalten; API- und MCP-Zugang laufen über die API-Tarife von LabelGrid. Auf der Analytics-Seite stehen die Details pro Store, auf der Preisseite die Übersicht der Tarife.

Häufig gestellte Fragen