Analytics di streaming e social ampliate: tutti gli store che inviano dati in un’unica dashboard

Un grafico vuoto e un grafico pieno di zeri significano due cose diverse, e solo una delle due può essere vera. Boomplay riporta gli stream e gli stream per paese. Non riporta i salvataggi. Il grafico dei salvataggi di Boomplay dovrebbe quindi dire che lo store non fornisce quel dato, invece di tracciare una linea piatta sullo zero e lasciarti concludere che nessuno ha salvato il disco.

Questa distinzione è il filo conduttore di tutte le novità sulle analytics che abbiamo rilasciato a luglio. Le analytics di LabelGrid coprono ora ogni store che ci invia un feed di analytics: Spotify, Apple Music, Deezer, Audiomack, Boomplay, AWA e i tre servizi Tencent, Kugou, Kuwo e QQ Music. Accanto a questi trovi l'attività social e UGC intorno al tuo catalogo, da SoundCloud a Snapchat fino alle app di Meta. Anche i dati di streaming sono ora accessibili via codice, attraverso l'API pubblica e il server MCP open source.

La distribuzione va molto oltre questo elenco. Qui trovi gli store di cui acquisiamo i feed di analytics, e la differenza conta: l'attività di uno store finisce nei tuoi rendiconti royalty anche se non pubblica un feed di analytics, perché rendiconti e analytics seguono flussi distinti.

Il punto sta nella forma di quella tabella. Skip, condivisioni, fonti di stream, fascia oraria e formato audio arrivano solo da Spotify. Shazam, aggiunte alla libreria e aggiunte alle playlist editoriali arrivano solo da Apple Music, perché Shazam è un segnale di Apple senza equivalenti altrove. I dati demografici degli ascoltatori, che contano le persone e non gli ascolti, arrivano da Spotify e Deezer. Gli stream per paese coprono Spotify, Apple Music, Deezer, Boomplay e Audiomack, ma non AWA, il cui feed riporta codici di regioni giapponesi, sotto il livello nazionale, invece dei paesi ISO. Non devi memorizzare niente di tutto questo: la dashboard mostra che cosa supporta ogni store, e l'API espone la stessa matrice sotto forma di dati.

I posizionamenti nelle playlist funzionano allo stesso modo. Le righe di Spotify riportano nome e proprietario della playlist insieme al numero di stream. Quelle di Apple Music includono le playlist editoriali per nome, con la posizione migliore raggiunta dal brano, e alcune di queste righe non hanno alcun conteggio di ascolti: in quel caso compare «non riportato». Le righe di Deezer rimandano alla playlist pubblica quando l'id viene risolto.

Tre modalità di visualizzazione coprono la maggior parte di ciò che si fa con questi dati. Combinata riunisce tutti gli store in un unico numero. Confronto li mette uno accanto all'altro, e il confronto totale include automaticamente gli store aggiunti di recente, quindi non devi mai attivare un nuovo store in un confronto già esistente. Singolo ti porta nel dettaglio completo di un solo store. I grafici funzionano con granularità giornaliera, settimanale o mensile, oppure automatica. I migliori risultati sono raccolti in schede separate, una per metrica, e i posizionamenti hanno un filtro per store.

Kugou, Kuwo e QQ Music riportano con frequenza settimanale. Ogni settimana produce un solo dato per brano, con la data del giorno coperto dal report e il valore dell'intera settimana. Non dividiamo mai un totale settimanale in valori giornalieri inventati: su un grafico giornaliero questi tre mostrano quindi una sola data valorizzata a settimana, con dei vuoti in mezzo.

I vuoti sono corretti, non sono dati mancanti. I totali sull'intervallo tornano comunque, e la frequenza è indicata sia nella dashboard sia nella risposta dell'API, così un'integrazione può distinguere uno store settimanale da uno poco attivo.

Nella dashboard, una metrica che uno store non riporta è indicata così, piattaforma per piattaforma; sull'API, la matrice di disponibilità restituisce la cella come not_available_for_platform invece di una serie di zeri. Il caso più evidente è la vista dei posizionamenti, dove una riga editoriale di Apple Music può indicare la playlist e la posizione raggiunta dal brano senza alcun conteggio di ascolti accanto. Va letto come dato non riportato. Se lo trasformi in zero, cambi il significato del numero e metti un falso minimo sotto ogni media calcolata su quel dato.

Le soglie di privacy seguono la stessa logica, vista dall'altro lato. Le suddivisioni demografiche e geografiche sono anonimizzate con k-anonimato: le celle sotto una soglia minima di pubblico vengono eliminate del tutto, senza una categoria «altro» e senza un totale pubblicato da cui ricavare il valore soppresso. I dettagli per città di Apple e gli Shazam per città sono di solito il punto in cui un catalogo più piccolo se ne accorge per primo: stream regolari, grafico delle città vuoto. È voluto e non esiste alcuna deroga, perché l'alternativa sarebbe pubblicare informazioni su una manciata di ascoltatori identificabili.

Gli store riportano con un certo ritardo e feed diversi pubblicano con tempi diversi, quindi in un dato giorno una metrica può essere aggiornata fino a una data più recente di un'altra. Per questo ogni metrica ha due date: una data di ultimo aggiornamento, cioè l'ultima data per cui ha dati, e una data di consolidamento, cioè l'ultima data che si può considerare definitiva. Tutto ciò che sta in mezzo è ancora in completamento, e la dashboard segna quei periodi come parziali, così una giornata riportata a metà non sembra un crollo. Aspettati che la parte finale del grafico salga quando ci torni. Un grafico che cala alla data di ultimo aggiornamento significa che lo store non ha ancora riportato le date successive.

La profondità dello storico segue le stesse linee dei feed. Con Spotify e Apple Music si torna indietro di anni. Gli store aggiunti con le novità di luglio (Deezer, Boomplay, AWA, Audiomack e i tre servizi Tencent) hanno uno storico che parte più o meno da fine gennaio 2026, quando i loro feed hanno cominciato ad arrivare.

I dati social registrano ciò che le persone fanno con la tua musica fuori dai DSP, e ogni piattaforma riporta la sua parte:

• Ascolti su SoundCloud, più repost e preferiti, con i territori corrispondenti
• Creazioni di contenuti su Snapchat, cioè gli utilizzi della musica, più visualizzazioni e copertura per territorio
• Creazioni e visualizzazioni per territorio su Instagram e Facebook, più la crescita di follower e di engagement sull'account dell'artista
• Creazioni e visualizzazioni per territorio su WhatsApp e Messenger, senza un feed dell'account alle spalle
• Su Threads solo visualizzazioni e copertura, perché il suo feed riporta il consumo e non le creazioni

Sono un insieme a parte rispetto allo streaming, con feed diversi e un asse di piattaforme diverso, e restano separati: una visualizzazione UGC o una creazione di contenuto non finisce mai nel totale degli stream dei DSP. Si vedono solo nella dashboard e di proposito non sono esposti sull'API pubblica, quindi un'integrazione che legge /analytics/* non troverà mai lì numeri di SoundCloud o di Meta.

I dati di streaming sono sull'API pubblica, limitati alle tue etichette, con l'ISRC come chiave nel campo identificatore. GET /analytics/summary è l'endpoint composito: scegli da una a dodici delle 37 chiavi di sezione con il parametro obbligatorio metrics[]. Se lo ometti ottieni un 422, volutamente, e una selezione di più di dodici chiavi viene rifiutata: la dividi quindi su più richieste, che vanno in cache in modo indipendente. Quindici endpoint autonomi coprono le singole serie, da stream e ascoltatori a salvataggi, skip, tasso di completamento, ripartizione per dispositivo e per fonte, più i tagli demografici e geografici. Le classifiche restituiscono i primi N risultati, filtrabili per etichetta, artista, release o brano, e i posizionamenti si filtrano per piattaforma.

filter[platform] accetta SPOTIFY, APPLE_MUSIC, DEEZER, BOOMPLAY, AWA, AUDIOMACK, KUGOU, KUWO e QQMUSIC, e se lo ometti restituisce tutte le piattaforme per cui il tuo account ha dati. Ogni risposta di summary riporta la frequenza della piattaforma in meta.platform_cadence e, per ogni sezione, le due date di riferimento in meta.sections_as_of e meta.sections_complete_through, così un client può mostrare come provvisorie le date ancora in completamento ed escluderle dai totali del periodo.

Gli intervalli arrivano a 400 giorni su summary e sui quindici endpoint di serie, cioè un anno intero più un periodo di confronto in una sola chiamata. Classifiche e posizionamenti restano a 180 giorni, perché una classifica su un arco più lungo non si può ricostruire in modo onesto unendo finestre più brevi. Le richieste che coprono più di 90 giorni vengono conteggiate su un secondo limite di frequenza, più stretto, in aggiunta al limite standard delle analytics; le richieste di 90 giorni o meno non ne sono toccate.

Prima di scrivere nel codice uno qualsiasi dei dettagli per store visti sopra, chiama GET /analytics/availability. Non ha parametri, è statico e cacheabile, e restituisce in una sola risposta l'intera matrice sezione per piattaforma più la mappa delle frequenze. Se costruisci su quella, un nuovo store che compare nel feed diventa una modifica ai dati e non al codice.

Il server MCP di LabelGrid è un wrapper leggero e tipizzato sulla stessa API pubblica, quindi qualsiasi client Model Context Protocol (Claude Desktop, Claude Code o Cursor) può leggere direttamente l'andamento del tuo catalogo. «Quali dei miei brani sono cresciuti in Germania il mese scorso, e su quale store» diventa una domanda che fai, invece di quattro export da riconciliare. Il wrapper eredita tutto quanto descritto sopra, comprese le regole di disponibilità, la frequenza settimanale e le date di aggiornamento, e ne eredita anche le omissioni: i numeri social non sono sull'API, quindi non ci sono nemmeno lì. Il post di lancio dell'MCP spiega configurazione e modello dei permessi.

Tutto questo è già attivo nella dashboard. Le analytics, set avanzato incluso, sono comprese in ogni piano standard; l'accesso ad API e MCP rientra nei piani API di LabelGrid. La pagina delle analytics ha il dettaglio per store e la pagina dei prezzi la mappa dei piani.