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
Co-founder, Backline · 7 July 2026 · 3 min read
In short
- An ISRC identifies a recording, a UPC identifies a release, and every platform additionally has its own internal id for both. Four identities for one track.
- The ISRC is the join key that makes cross-platform analytics possible, and everything downstream degrades when it is wrong, missing or duplicated.
- A recording re-released with a new ISRC splits its own history in two, and no analytics tool can put it back together without being told.
- Track-level endpoints at some data providers require an artist identifier alongside the ISRC, so a project with no resolved artist cannot resolve its first track.
- Check identifiers at delivery, not when a report looks wrong. Retrospective fixes rarely recover the data that was mis-attributed.
Every cross-platform music analytics system rests on one assumption: that the thing you are counting on Spotify is the same thing you are counting on YouTube. That assumption is carried by identifiers, and identifiers in music are messier than they look.
The four identities
ISRC. The International Standard Recording Code identifies a specific recording. Twelve characters: country, registrant, year, designation. The same song recorded live and in a studio has two ISRCs, correctly, because they are two recordings.
UPC or EAN. A barcode identifying a release, meaning the album, EP or single as a product. One UPC contains several ISRCs.
Platform recording ids. Every service has its own internal identifier for the recording, which is what its own API speaks natively.
Provider ids. Data providers assign their own track and artist ids on top, which is what their endpoints usually key on.
Four identifiers for one track
Illustrative| Identifies | Assigned by | Used for | |
|---|---|---|---|
| ISRC | One recording | The registrant, via national agencies | Joining the same recording across platforms |
| UPC or EAN | One release as a product | The distributor or label | Album and EP level reporting, retail |
| Platform recording id | The recording, per service | Each platform | That platform's own API |
| Provider track and artist id | The recording and the act | The data provider | Most third-party analytics endpoints |
The ISRC is the one that crosses systems, which makes it load bearing for anything comparing platforms.
Where it breaks
Missing at delivery. A track delivered without a usable ISRC is invisible to any tool keyed on it. It exists on the platform, it accrues streams, and no cross-platform system can attach them to your catalogue.
Duplicated. The same recording delivered twice with different ISRCs, usually a re-release, a distributor change or a compilation. Now one recording has two histories and every total is split. Nothing about this is detectable from the data alone: two ISRCs is what two recordings look like.
Reused. Rarer and worse, where an ISRC gets applied to a different recording, so two things merge into one.
Right but unmatched. The identifier is correct and the provider has not indexed it yet. A newly released track can be genuinely unknown to a data provider for days, which looks identical to a broken identifier from the outside.
The bootstrapping problem
One practical trap worth knowing about, because it bites at exactly the wrong moment.
Some providers require an artist identifier alongside the track identifier on track-level endpoints. That is reasonable for disambiguation, and it creates a chicken and egg problem: to resolve a track you need the artist id, and the artist id usually arrives with an already-resolved track.
A newly onboarded project with nothing resolved cannot resolve its first track. The workable answer is to borrow a known artist identifier from any already-resolved track on the same project, and to make sure the onboarding path that adds a catalogue sets the artist id on every row it writes, so the project is never in the empty state to begin with.
We learned this the hard way, twice: once when a provider began enforcing the requirement on an endpoint that had not needed it, which silently killed track snapshots for two days.
A bare barcode is not a lookup
A related, smaller trap. Users paste what they have, and sometimes that is a twelve to fourteen digit barcode.
A UPC is not an ISRC and generally cannot be looked up as one. Detect the shape and reject it with an explanation rather than attempting a lookup that will silently fail or, worse, match something unrelated. Telling somebody a barcode is not supported is a better experience than an empty result.
Identifier checks that pay for themselves
Illustrative- 1Before deliveryEvery recording has the intended ISRC. Re-releases either keep the original or are recorded as new. UPC and track order correct.
- 2Day oneConfirm each track resolved with your data provider. A track that has not resolved after a few days is an identifier problem, not a delay.
- 3Week oneCross-platform totals plausible against each other. One platform at zero while others report is a matching failure.
- 4On catalogue importWrite the artist identifier on every track row, so the project can never reach the state where it cannot resolve its first track.
- 5On user inputDetect a bare barcode and refuse it with an explanation rather than attempting an ISRC lookup that will fail or mismatch.
What to check, and when
At delivery, before release:
- Every recording has an ISRC, and it is the one you intended.
- A re-release either keeps the original ISRC, if the recording is unchanged, or the fact that it is new is recorded somewhere your analytics can read.
- The UPC is right on the release, and the track order matches.
- Featured artists and the primary artist are consistent, since artist resolution depends on them.
After release, in the first week:
- Every track resolved with your data provider. If one has not after a few days, that is an identifier problem rather than a provider delay.
- Totals across platforms are plausible relative to each other. One platform reading zero while others report normally is usually a matching failure rather than a performance story.
When history is already split
If a recording has two ISRCs with two histories, you have three options and none is perfect.
Sum them in reporting, and document the pairing so it survives the person who noticed. Pick one as canonical and treat the other as a separate item, which is honest and understates the recording. Or ask the distributor to consolidate, which sometimes works and rarely recovers historical data.
The general rule with identifiers is that the cheap fix happens at delivery and the expensive one happens in reporting, forever.
Common questions
- What is the difference between an ISRC and a UPC?
- An ISRC identifies a single recording and is the identifier that lets analytics tools join the same track across platforms. A UPC or EAN identifies a release as a product, so one UPC contains several ISRCs. Platforms and data providers additionally hold their own internal identifiers for both.
- What happens if a track is released twice with different ISRCs?
- Its history splits in two and every cross-platform total is understated, with nothing in the data to reveal it, because two ISRCs is exactly what two different recordings look like. The options are to sum them in reporting and document the pairing, to pick one as canonical, or to ask the distributor to consolidate, which rarely recovers historical data.
- Why can't I look up a track by its barcode?
- A UPC identifies a release rather than a recording, and the analytics endpoints that matter key on recordings. A bare barcode should be detected and refused with an explanation, because attempting it as an ISRC either fails silently or matches something unrelated.
Sources
- 1IFPI, Reviewed August 2026. International Standard Recording Code
- 2DDEX, Reviewed August 2026. DDEX standards for digital music supply chain metadata
- 3Music Business Worldwide, 2026. Music streaming platforms now host a quarter of a billion tracks
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
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
Data engineering
Backfilling history you were never given
A new analytics connection starts counting today, and public streaming counters expose no dated past. What can actually be recovered, from where, and how to show it honestly.
Danny Starr · 3 min read
Streaming
Comparing releases properly: align on day zero, not the calendar
How is the new single doing compared to the last one? Answering that requires re-anchoring each track to its own release date, and being honest about the tracks that cannot be compared at all.
Danny Starr · 4 min read
