Music analytics platforms compared by what they actually store
Feature lists in this category all look the same. The data model does not. A technical comparison of catalogue trackers, all-in-one suites and project data layers, and what each one can never tell you.
Danny Starr
Co-founder, Backline · 12 August 2026 · 4 min read
In short
- A tool's data model decides which questions it can answer, and no amount of interface work changes that. Compare models, not screenshots.
- Catalogue trackers key their data on the track and the artist, sourced by crawling public platforms. They can compare anyone, and they cannot see anything only you have access to.
- Project data layers key their data on the project and its own authorised connections. They can join ad spend to ticket sales, and they cannot tell you about an artist you do not work with.
- All-in-one management suites key their data on documents and money. They are strong on settlements and weak on daily performance measurement, and most of them integrate a catalogue tracker rather than building one.
- The join key is the real differentiator. Ask what identifier ties two different sources together in the tool, and what happens when it is missing.
If you put five music analytics products side by side, the marketing pages are close to interchangeable: real-time data, cross-platform coverage, alerts, audience insight, AI. The differences that matter sit one level down, in what each product stores and what it keys that storage on.
I build one of these, so treat what follows as an engineer's map of the category rather than a neutral review. The map is still useful, because the constraints are structural and apply to us as much as to anyone.
Three data models
What each model stores, and what it can never see
| Catalogue tracker | Operations suite | Project data layer | |
|---|---|---|---|
| Core record | Track or artist | Document or transaction | Project plus its connections |
| Primary key | ISRC, platform artist id | Entities you created | Project id plus date |
| How data arrives | Crawling and platform deals | Uploads and manual entry | Authorised account connections |
| Coverage | Every public artist | Whatever you enter | Only projects you work with |
| Can compare rivals | Yes | No | No |
| Can see your ad spend | No | Only as cost lines | Yes |
| Can see box office | No | From settlements | From ticketing sync |
| Can join spend to sales | No | Loosely, after the fact | Yes |
Crawl and key on the track
A catalogue tracker's core record is a track or an artist, identified by an ISRC or a platform id, with a time series of public counters attached: playlist placements, chart positions, follower counts, play totals. The data arrives by crawling and by platform partnerships, so coverage is the entire public catalogue.
What this model gives you is comparison. You can look up an artist you have never met, benchmark two acts in the same lane, and monitor a playlist you have no relationship with. Songstats, Chartmetric, Soundcharts and Viberate all sit here, with different depths of radio, chart and playlist history.
What it structurally cannot give you is anything private. Your Meta ad spend, your Dice settlement, your Mailchimp open rate, your Google Search Console impressions: none of that is public, so none of it is in a crawl-based model. Some vendors add it through a connected account, and at that point they are building the third model alongside the first.
Key on documents and money
An operations suite's core record is a document or a transaction: a contract, a settlement, a royalty statement, an invoice, a booking. Octve describes itself as a platform for booking, settlements, royalties and contracts, and lists a Soundcharts integration for discography data. Union AIA is built around release management, royalty tracking, rights administration and tour planning, and lists integrations with Viberate and Chartmetric.
Note what those integrations tell you. When a product's own model is documents and money, performance data is something it imports from someone else's model. That is a sensible engineering decision and it sets a ceiling: the analysis you get is whatever the imported feed exposes, joined loosely to your paperwork.
Key on the project and its connections
A project data layer's core record is a project, and everything hangs off authorised connections that project owns. Streaming and audience from a catalogue provider, social from Meta and TikTok, ad performance from Meta Ads and Google Ads, website behaviour from Google Analytics and Amplitude, search from Google Search Console, box office from a ticketing partner, campaign performance from Mailchimp, coverage from a news feed.
The strength is the join. Because every source lands under the same project with a date, you can put ad spend, streams and ticket sales on one axis and see whether they move together. The weakness is symmetrical: with no connection, there is no data, so this model can tell you nothing about an artist you do not work with.
Backline is this third model. It is why we do not sell A and R research, and why we can show a manager whether last month's spend showed up in the box office.
The question that reveals the model
Ask a vendor: what identifier joins two different sources in your system, and what happens when it is missing?
The answers are diagnostic.
- Catalogue trackers join on ISRC and platform artist ids. Missing or wrong ISRCs are their hardest problem, because a track with no ISRC delivered to the tracker simply does not exist. We wrote up the general version of this in ISRC, UPC and the identity problem.
- Operations suites join on entities you typed: an artist record, a release record, a deal. Duplicates are their hardest problem.
- Project data layers join on the project id and the date. Timezone and reporting-lag mismatches are their hardest problem, because a source that is two days behind will line up against yesterday's ad spend and quietly imply the wrong thing.
None of those problems is embarrassing. A vendor who cannot name theirs has either not run at scale or is not being straight with you.
What each model gets wrong in practice
Where each model breaks first
IllustrativeTwo of those deserve expanding, because they cost real decisions.
Weekly cadence sold as daily. Not every public counter refreshes every day. When a source only advances its cumulative total once a week and a tool computes a daily difference anyway, six days read as zero and the seventh carries the whole week. Charted naively, that is a spike, and spikes get attributed to whatever marketing happened nearby. We now treat those sources as genuinely weekly and bucket them accordingly, having first been fooled by exactly this.
Uncorrected reporting lag. Third-party Spotify figures tend to trail the real day by around two days. If nothing shifts the series back, a release-day surge appears mid-week and your correlation between spend and streams is out by 48 hours, which is enough to reverse a conclusion.
Choosing between them
You are not really choosing a vendor, you are choosing which question you want answered daily. Research and benchmarking points at a catalogue tracker. Paperwork and money points at an operations suite. Understanding and reporting on the projects you run points at a data layer.
Plenty of teams run two, and that is a reasonable outcome. What does not work is expecting one model to answer the other's question, then concluding the software is bad.
Common questions
- What is the difference between Chartmetric, Soundcharts, Songstats and a platform like Backline?
- The first three are catalogue trackers: their core record is a track or artist, built largely from public data, so they can compare any act in the world. Backline is a project data layer: its core record is a project and its own authorised connections, so it can join private sources such as ad spend, ticket sales, email and search to streaming, but it holds nothing about artists you do not work with.
- Can one platform do both?
- Partly. A crawl-based tool can add connected accounts, and a connection-based tool can license catalogue data. What does not merge is the coverage promise: comparison across the whole industry and depth on your own private sources are different data acquisition problems with different costs.
- Why do all-in-one music platforms integrate a third-party analytics provider?
- Because their own data model is documents and money. Performance time series are a separate acquisition problem, so it is cheaper and faster to import a feed from a catalogue provider than to build one. OCTVE lists a Soundcharts integration and Union AIA lists Viberate and Chartmetric.
Sources
- 1OCTVE, Reviewed August 2026. OCTVE product and pricing
- 2Union AIA, Reviewed August 2026. Union AIA platform overview
- 3Chartmetric, Reviewed August 2026. Chartmetric plans
- 4Soundcharts, Reviewed August 2026. Soundcharts pricing
- 5Songstats, Reviewed August 2026. Songstats pricing
Danny Starr
Co-founder, Backline
Danny Starr is a co-founder of Backline and builds the platform. He writes about the data engineering behind music analytics: ingestion, identity, honesty in charts, and the AI layer on top of it.
Backline does this for the projects you run
Streaming, audience, social, advertising, website, search, ticketing and press data in one dashboard per project, with an AI assistant that answers questions about your own connected data. Invite-only.
Keep reading
Choosing a platform
How to choose a music data analytics platform
A buying checklist for managers, labels and independent artists: the eight questions that separate a chart-tracking subscription from a platform you can actually run a project on.
Danny Angove · 4 min read
Data engineering
ISRC, UPC, and why your track has four identities
Every analytics platform in music runs on identifiers, and the identifiers disagree. What ISRCs and UPCs are for, where they break, and what to do when a track has none.
Danny Starr · 3 min read
Data engineering
Designing an API layer over a dozen music data vendors
Streaming, social, advertising, ticketing, email and search all speak differently, fail differently and rate limit differently. The patterns that keep an integration layer from becoming a liability.
Danny Starr · 3 min read
