An empty chart and a chart full of zeros mean two different things, and only one of them can be true. Boomplay reports streams and streams by country. It does not report saves. A saves chart for Boomplay should therefore say that the store does not report it, rather than draw a flat line at zero and let you conclude that nobody saved the record.
That distinction runs through the analytics wave we shipped in July. LabelGrid analytics now covers every store that sends us an analytics feed: Spotify, Apple Music, Deezer, Audiomack, Boomplay, AWA, and the three Tencent services, Kugou, Kuwo and QQ Music. Social and UGC activity around your catalog sits beside them, from SoundCloud through Snapchat and the Meta apps. The streaming side is also reachable programmatically now, through the public API and the open-source MCP server.
The stores that report, and what each one reports
Distribution reaches further than this list. These are the stores whose analytics feeds we ingest, and the difference is worth knowing: a store's activity lands in your royalty statements whether or not it publishes an analytics feed, because statements and analytics run on separate pipelines.
| Store | Cadence | What it reports |
|---|---|---|
| Spotify | Daily | The deepest set: streams, listeners, saves, skips, shares, engagement rates, stream sources, devices, demographics |
| Apple Music | Daily | Streams, listeners, library adds, editorial playlist adds, Shazams, plus city and storefront breakdowns |
| Deezer | Daily | Streams, geography, devices, listener demographics, average listen time, placements |
| Audiomack | Daily | Streams, listeners, saves, geography |
| Boomplay | Daily | Streams, streams by country |
| AWA | Daily | Streams |
| Kugou, Kuwo, QQ Music | Weekly | Streams |
The shape of that table is the point. Skips, shares, stream sources, hour of day and audio format come from Spotify alone. Shazams, library adds and editorial playlist adds come from Apple Music alone, because Shazam is an Apple signal with no equivalent elsewhere. Listener demographics, which count people rather than plays, come from Spotify and Deezer. Streams by country cover Spotify, Apple Music, Deezer, Boomplay and Audiomack, but not AWA, whose feed carries sub-national Japanese region codes instead of ISO countries. Nobody has to memorise any of that: the dashboard shows what each store supports, and the API publishes the same matrix as data.
Playlist placements work the same way. Spotify rows carry the playlist name and owner with stream counts. Apple Music rows include editorial playlists by name with the best position the track reached, and some of those rows carry no play count at all, which is shown as not reported. Deezer rows link out to the public playlist when the id resolves.
Combine the stores, compare them, or take one at a time
Three view modes cover most of what people do with this data. Combined rolls every store into one number. Compare puts them side by side, and compare-all picks up newly added stores on its own, so you never have to opt a new store into an existing comparison. Single drops you into one store's full detail. Charts run at day, week or month granularity, or auto. Top performers sit in tabs per metric, and placements carry a per-store filter.
One point a week from the Tencent stores
Kugou, Kuwo and QQ Music report weekly. Each week gives one data point per track, dated on the day the report covers and carrying that whole week. We never divide a weekly total into daily values we made up, so on a daily chart those three show one populated date a week with gaps in between.
The gaps are correct, not missing. Range totals still add up, and the cadence is labelled in the dashboard and in the API response, so an integration can tell a weekly store from a quiet one.
When a metric says "not available"
In the dashboard, a metric a store does not report is labelled that way per platform; on the API, the availability matrix returns the cell as not_available_for_platform instead of a zero series. The sharpest case sits in the placements view, where an Apple Music editorial row can name the playlist and the position the track reached with no play count beside it. That reads as not reported. Turn it into a zero and you have changed what the number means, and put a fake floor under every average calculated from it.
Privacy floors work on the same logic from the other direction. Demographic and geographic breakdowns are k-anonymised, so cells below a minimum-audience floor are dropped outright, with no other bucket and no published total that would let the suppressed figure be worked out. Apple city breakdowns and Shazams by city are usually where a smaller catalog notices it first: healthy streams, an empty city chart. That is by design and there is no override, because the alternative is publishing something about a handful of identifiable listeners.
How fresh the numbers are, and why they move
Stores report on a lag, and different feeds publish on different schedules, so on any given day one metric can be current through a later date than another. Each metric therefore carries two dates: a reported-through date, the latest date it has data for, and a complete-through date, the latest date that can be treated as final. Anything between the two is still filling, and the dashboard marks those buckets as partial instead of letting a half-reported day look like a collapse. Expect the trailing edge of a chart to rise when you come back to it. A chart that trails off at its reported-through date means the store has not reported later dates yet.
History depth splits along the same lines as the feeds. Spotify and Apple Music reach back years. The stores added in this wave, Deezer, Boomplay, AWA, Audiomack and the three Tencent services, have history from roughly late January 2026, when their feeds started landing.
Social and UGC activity around your catalog
The social surfaces track what people do with your music outside the DSPs, and each platform reports its own slice:
- SoundCloud plays, plus reposts and favorites, with the territories behind them
- Snapchat content creates, meaning uses of the music, plus views and reach by territory
- Instagram and Facebook creates and views by territory, plus follower and engagement growth on the artist account
- WhatsApp and Messenger creates and views by territory, with no account feed behind them
- Threads views and reach only, because its feed reports consumption rather than creations
These are a separate family from streaming, with different feeds and a different platform axis, and they stay separate: a UGC view or a content create never lands in a DSP stream total. They are dashboard-only, and they are deliberately not exposed on the public API, so an integration reading /analytics/* will never find SoundCloud or Meta numbers there.
37 section keys, and one endpoint that maps them
The streaming data is on the public API, scoped to your own labels and keyed by ISRC in the identifier field. GET /analytics/summary is the composite: you pick between one and twelve of 37 section keys with a required metrics[] parameter. Leaving it out returns a 422 on purpose, and a selection wider than twelve is rejected, so you split it across several requests, which cache independently. Fifteen standalone endpoints cover the individual series, from streams and listeners through saves, skips, completion rate, device split and source split, plus the demographic and geographic cuts. Leaderboards give top-N rankings filtered by label, artist, release or track, and placements are filterable by platform.
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-01filter[platform] takes SPOTIFY, APPLE_MUSIC, DEEZER, BOOMPLAY, AWA, AUDIOMACK, KUGOU, KUWO and QQMUSIC, and omitting it returns every platform your account has data for. Each summary response carries the cadence for the platform in meta.platform_cadence and, per section, the two freshness dates as meta.sections_as_of and meta.sections_complete_through, so a client can render still-filling dates as provisional and keep them out of period totals.
Ranges run to 400 days on summary and the fifteen series endpoints, which is a full year plus a comparison period in one call. Leaderboards and placements stay at 180 days, since a ranking over a longer span cannot be honestly stitched together from shorter windows. Requests spanning more than 90 days are metered against a second, tighter rate bucket on top of the standard analytics limit; requests of 90 days or less are unaffected.
Before you hardcode any of the per-store detail above, call GET /analytics/availability. It takes no parameters, it is static and cacheable, and it returns the entire section-by-platform matrix plus the cadence map in one response. Build against that and a new store showing up in the feed becomes a data change rather than a code change.
Or ask your assistant
The LabelGrid MCP server is a thin typed wrapper over that same public API, so any Model Context Protocol client, Claude Desktop, Claude Code or Cursor, can read your catalog's performance directly. "Which of my tracks grew in Germany last month, and on which store" becomes a question you ask rather than four exports you reconcile. The wrapper inherits everything above, including the availability rules, the weekly cadence and the freshness dates, and it inherits the omissions too: the social numbers are not on the API, so they are not there either. The MCP launch post covers setup and the permission model.
All of it is live in the dashboard now. Analytics, advanced set included, comes with every standard plan; API and MCP access run on LabelGrid's API plans. The analytics page has the per-store detail and the pricing page has the plan map.
