Ett tomt diagram och ett diagram fullt av nollor betyder två olika saker, och bara det ena kan vara sant. Boomplay rapporterar streams och streams per land, men inte sparningar. Ett diagram över sparningar för Boomplay bör därför visa att tjänsten inte rapporterar det, i stället för att rita en platt linje på noll och låta dig dra slutsatsen att ingen har sparat skivan.

Den skillnaden går som en röd tråd genom analysuppdateringen vi släppte i juli. LabelGrids analys omfattar nu alla tjänster som skickar oss ett analysflöde: Spotify, Apple Music, Deezer, Audiomack, Boomplay, AWA och de tre Tencent-tjänsterna Kugou, Kuwo och QQ Music. Bredvid dem visas social aktivitet och UGC kring din katalog, från SoundCloud till Snapchat och Metas appar. Streamingdelen går nu också att nå programmatiskt, via det publika API:et och MCP-servern med öppen källkod.

Tjänsterna som rapporterar och vad var och en rapporterar

Distributionen når fler tjänster än så. Det här är de tjänster vars analysflöden vi läser in, och skillnaden är värd att känna till: en tjänsts aktivitet hamnar i dina royaltyredovisningar oavsett om den publicerar ett analysflöde eller inte, eftersom redovisning och analys hanteras i separata system.

TjänstFrekvensVad den rapporterar
SpotifyDagligenDen mest omfattande uppsättningen: streams, lyssnare, sparningar, skips, delningar, engagemangsgrad, streamkällor, enheter, demografi
Apple MusicDagligenStreams, lyssnare, tillägg i biblioteket, tillägg i redaktionella spellistor, Shazams samt uppdelning per stad och storefront
DeezerDagligenStreams, geografi, enheter, lyssnardemografi, genomsnittlig lyssningstid, placeringar
AudiomackDagligenStreams, lyssnare, sparningar, geografi
BoomplayDagligenStreams, streams per land
AWADagligenStreams
Kugou, Kuwo, QQ MusicVeckovisStreams

Det är tabellens form som är poängen. Skips, delningar, streamkällor, tid på dygnet och ljudformat kommer enbart från Spotify. Shazams, tillägg i biblioteket och tillägg i redaktionella spellistor kommer enbart från Apple Music, eftersom Shazam är en Apple-signal som inte har någon motsvarighet hos de andra. Lyssnardemografi, som räknar personer i stället för uppspelningar, kommer från Spotify och Deezer. Streams per land täcker Spotify, Apple Music, Deezer, Boomplay och Audiomack, men inte AWA, vars flöde innehåller japanska regionkoder under landsnivå i stället för ISO-landskoder. Du behöver inte kunna något av det utantill: dashboarden visar vad varje tjänst stöder, och API:et publicerar samma matris som data.

Spellisteplaceringar fungerar på samma sätt. Rader från Spotify innehåller spellistans namn och ägare tillsammans med antal streams. Rader från Apple Music omfattar redaktionella spellistor med namn och den bästa positionen låten nådde, och en del av de raderna saknar helt uppgift om antal uppspelningar, vilket visas som ”rapporteras inte”. Rader från Deezer länkar till den publika spellistan när id:t går att matcha.

Slå ihop tjänsterna, jämför dem eller ta en i taget

Tre visningslägen täcker det mesta du gör med datan. Kombinerat slår ihop alla tjänster till ett enda tal. Jämför ställer dem sida vid sida, och jämför-alla tar med nytillkomna tjänster automatiskt, så du behöver aldrig själv lägga till en ny tjänst i en befintlig jämförelse. Enskild tar dig till en tjänsts fullständiga detaljvy. Diagrammen visas per dag, vecka eller månad, eller automatiskt. Toppresultat ligger i flikar per mätvärde, och placeringar har ett filter per tjänst.

En datapunkt i veckan från Tencent-tjänsterna

Kugou, Kuwo och QQ Music rapporterar veckovis. Varje vecka ger en datapunkt per låt, daterad till den dag rapporten avser och med hela veckans värde. Vi delar aldrig upp ett veckototal i påhittade dagsvärden, så i ett dagsdiagram visar de tre ett ifyllt datum i veckan med luckor emellan.

Luckorna är korrekta, inte saknad data. Summorna för ett intervall stämmer ändå, och frekvensen anges i dashboarden och i API-svaret, så att en integration kan skilja en tjänst som rapporterar veckovis från en som bara är tyst.

När ett mätvärde visar ”ej tillgängligt”

Ett mätvärde som en tjänst inte rapporterar märks i dashboarden som ”ej tillgängligt” för just den plattformen. I API:et returnerar tillgänglighetsmatrisen cellen som not_available_for_platform i stället för en nollserie. Det tydligaste fallet finns i placeringsvyn, där en redaktionell rad från Apple Music kan ange spellistan och positionen låten nådde utan någon uppspelningssiffra bredvid. Det ska läsas som ”rapporteras inte”. Gör du om det till en nolla har du ändrat vad talet betyder och lagt en falsk golvnivå under varje medelvärde som beräknas utifrån det.

Integritetsgränser följer samma logik fast från andra hållet. Uppdelningar efter demografi och geografi är k-anonymiserade, så celler under en minimigräns för målgruppens storlek tas bort helt, utan någon ”övrigt”-grupp och utan någon publicerad totalsumma som gör det möjligt att räkna ut det borttagna värdet. Det är oftast i Apples uppdelning per stad och i Shazams per stad som en mindre katalog märker det först: fullt normala streams, men ett tomt stadsdiagram. Det är avsiktligt och går inte att åsidosätta, eftersom alternativet vore att publicera uppgifter om en handfull identifierbara lyssnare.

Hur färska siffrorna är och varför de ändras

Tjänsterna rapporterar med fördröjning och olika flöden publiceras enligt olika scheman, så en given dag kan ett mätvärde vara aktuellt till ett senare datum än ett annat. Därför har varje mätvärde två datum: ett ”rapporterat till och med”-datum, det senaste datum det har data för, och ett ”komplett till och med”-datum, det senaste datum som kan räknas som slutgiltigt. Allt däremellan fylls fortfarande på, och dashboarden markerar de dagarna som delvis rapporterade i stället för att låta en halvrapporterad dag se ut som ett ras. Räkna med att diagrammets sista del stiger när du tittar igen. Om ett diagram ebbar ut vid sitt sista rapporterade datum betyder det att tjänsten inte har rapporterat senare datum än så.

Hur långt tillbaka historiken når varierar på samma sätt som flödena. Spotify och Apple Music går flera år bakåt. De tjänster som tillkom i den här uppdateringen, Deezer, Boomplay, AWA, Audiomack och de tre Tencent-tjänsterna, har historik från ungefär slutet av januari 2026, när deras flöden började komma in.

Social aktivitet och UGC kring din katalog

De sociala kanalerna visar vad folk gör med din musik utanför DSP:erna, och varje plattform rapporterar sin egen del:

  • SoundCloud-uppspelningar samt reposts och favoriter, med territorierna bakom dem
  • Snapchat: skapat innehåll, alltså när musiken används, samt visningar och räckvidd per territorium
  • Instagram och Facebook: skapat innehåll och visningar per territorium, samt tillväxt i följare och engagemang på artistkontot
  • WhatsApp och Messenger: skapat innehåll och visningar per territorium, utan något kontoflöde bakom
  • Threads: bara visningar och räckvidd, eftersom flödet rapporterar konsumtion och inte skapande

De sociala siffrorna är en egen kategori, skild från streaming, med egna flöden och en annan plattformsaxel, och de två hålls isär: en UGC-visning eller ett skapat innehåll räknas aldrig in i en DSP:s streamingtotal. De finns bara i dashboarden och är medvetet inte tillgängliga i det publika API:et, så en integration som läser /analytics/* hittar aldrig SoundCloud- eller Meta-siffror där.

Se vad din katalog gör, tjänst för tjänst

Streaminganalys för alla tjänster som rapporterar, i dashboarden och via API:et. Sociala kanaler och UGC i dashboarden.

Utforska analysen

37 sektionsnycklar och en endpoint som kartlägger dem

Streamingdatan finns i det publika API:et, avgränsad till dina egna labels och med ISRC som identifierare i identifier-fältet. GET /analytics/summary är den sammansatta endpointen: med den obligatoriska parametern metrics[] väljer du mellan en och tolv av 37 sektionsnycklar. Utelämnar du den får du ett 422, helt avsiktligt, och ett urval på fler än tolv avvisas, så du delar upp det på flera anrop som cachas var för sig. Femton fristående endpoints täcker de enskilda serierna, från streams och lyssnare till sparningar, skips, genomlyssningsgrad, enhetsfördelning och källfördelning, samt de demografiska och geografiska uppdelningarna. Topplistor ger rangordningar av de N bästa, filtrerade på label, artist, release eller låt, och placeringar går att filtrera per plattform.

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] accepterar SPOTIFY, APPLE_MUSIC, DEEZER, BOOMPLAY, AWA, AUDIOMACK, KUGOU, KUWO och QQMUSIC, och om du utelämnar den returneras alla plattformar som ditt konto har data för. Varje summary-svar anger plattformens frekvens i meta.platform_cadence och, per sektion, de två färskhetsdatumen som meta.sections_as_of och meta.sections_complete_through, så att en klient kan visa ännu ofullständiga datum som preliminära och hålla dem utanför periodens totaler.

Intervall på upp till 400 dagar gäller för summary och de femton endpoints för enskilda serier, vilket motsvarar ett helt år plus en jämförelseperiod i ett enda anrop. Topplistor och placeringar stannar på 180 dagar, eftersom en rangordning över en längre period inte går att sätta ihop på ett ärligt sätt från kortare tidsfönster. Anrop som omfattar mer än 90 dagar räknas mot en andra, snävare anropsgräns utöver den vanliga analysgränsen. Anrop på högst 90 dagar påverkas inte.

Innan du hårdkodar något av tjänstedetaljerna ovan bör du anropa GET /analytics/availability. Den tar inga parametrar, är statisk och går att cacha, och returnerar hela matrisen över sektioner och plattformar plus frekvenskartan i ett enda svar. Bygg mot den, så blir en ny tjänst i flödet en dataändring i stället för en kodändring.

Eller fråga din assistent

LabelGrids MCP-server är ett tunt, typat lager ovanpå samma publika API, så alla klienter för Model Context Protocol, till exempel Claude Desktop, Claude Code eller Cursor, kan läsa din katalogs resultat direkt. ”Vilka av mina låtar växte i Tyskland förra månaden, och på vilken tjänst” blir en fråga du ställer i stället för fyra exporter du måste stämma av. Lagret ärver allt ovan, inklusive tillgänglighetsreglerna, veckofrekvensen och färskhetsdatumen, och det ärver även det som saknas: de sociala siffrorna finns inte i API:et, så de finns inte där heller. Lanseringsinlägget om MCP går igenom installation och behörighetsmodell.

Allt är live i dashboarden nu. Analys, inklusive den avancerade uppsättningen, ingår i varje standardplan. API- och MCP-åtkomst får du med LabelGrids API-planer. Analyssidan har detaljerna per tjänst och prissidan ger en översikt över planerna.

Vanliga frågor

Vilka tjänster visar LabelGrid streaminganalys för?

Spotify, Apple Music, Deezer, Audiomack, Boomplay och AWA rapporterar dagligen, och de tre Tencent-tjänsterna Kugou, Kuwo och QQ Music rapporterar veckovis. Det är de tjänster vars analysflöden LabelGrid läser in. Distributionen når fler tjänster än så, och aktiviteten på de övriga syns fortfarande i dina royaltyredovisningar, eftersom redovisning och analys hanteras i separata system.

Varför visar en tjänst ett mätvärde medan en annan säger att det inte är tillgängligt?

Därför att tjänsterna rapporterar olika saker. Spotify rapporterar skips och delningar samt streamkällor. Apple Music rapporterar Shazams, tillägg i biblioteket och tillägg i redaktionella spellistor. Deezer och Spotify rapporterar lyssnardemografi. Boomplay rapporterar streams och streams per land, och AWA rapporterar streams. När en tjänst inte rapporterar ett mätvärde markerar LabelGrid det som ej tillgängligt för den plattformen i stället för att rita en nolla. Uppdelningar efter demografi och geografi är dessutom k-anonymiserade, så en liten katalog kan visa fullt normala streams men ett tomt demografi- eller stadsdiagram. Celler under minimigränsen för målgruppens storlek tas bort helt, utan någon ”övrigt”-grupp och utan någon totalsumma som gör det möjligt att räkna ut det borttagna värdet.

Varför visar Kugou, Kuwo och QQ Music bara en datapunkt i veckan?

De tre rapporterar veckovis. Varje vecka ger en datapunkt per låt, daterad till den dag rapporten avser och med hela veckans värde för just den låten. LabelGrid delar aldrig upp ett veckototal i påhittade dagsvärden, så i ett dagsdiagram ser du ett ifyllt datum i veckan med luckor emellan. Luckorna är korrekta, inte saknad data, summorna för ett intervall stämmer ändå, och både dashboarden och API-svaret anger frekvensen.

Varför ökade förra veckans siffror efter att jag hade tittat på dem?

Tjänsterna rapporterar med fördröjning, och ett flöde kan leverera en del av en dag innan dagen är komplett. Varje mätvärde har ett eget ”rapporterat till och med”-datum, alltså det senaste datum det har data för, och ett ”komplett till och med”-datum, alltså det senaste datum som kan räknas som slutgiltigt. Datum däremellan fylls fortfarande på och markeras som delvis rapporterade, så räkna med att diagrammets sista del stiger när du tittar igen. Om ett diagram ebbar ut vid sitt sista rapporterade datum betyder det att tjänsten inte har rapporterat senare datum än så, inte att lyssningen har upphört.

Kan jag hämta analys via API:et eller en AI-assistent?

Ja, för streaming. Det publika API:et har en sammansatt summary-endpoint som täcker 37 sektionsnycklar, 15 fristående endpoints för enskilda serier och två till för topplistor och placeringar. En separat tillgänglighetsendpoint returnerar hela matrisen över sektioner och plattformar samt frekvenskartan i ett enda anrop. Summary och serierna accepterar intervall på upp till 400 dagar, medan topplistor och placeringar stannar på 180. MCP-servern med öppen källkod ligger ovanpå samma API, så en assistent som Claude eller Cursor läser exakt det som API:et exponerar. Sociala och UGC-siffror finns bara i dashboarden och är medvetet inte med i det publika API:et.

Table of contents:

Börja distribuera din musik idag

Alla stora DSP:er. Automatisk royaltyfördelning. Statistik per DSP. Gå med tusentals skivbolag och artister som redan använder LabelGrid.