How to build a music monitoring dashboard for rights holders

Rights holders leave royalties uncollected every year, and the cause is usually incomplete tracking: music appears across thousands of radio stations and live streams, and following it by hand doesn’t scale.

A custom monitoring dashboard closes that gap. Instead of waiting on performance-rights-organization (PRO) reporting that arrives months later and misses smaller sources, you can track your catalog continuously and present the data the way your team needs it. This guide walks through the architecture and the recognition layer that makes it work.

Why rights holders need custom monitoring

PRO reporting has gaps. Stations submit incomplete logs, digital platforms report inconsistently, and international tracking varies by territory. A custom dashboard fills those gaps by:

Covering sources PROs miss — independent radio, internet radio, live streams.
Reporting in real time — know about airplay as it happens, not months later.
Surfacing unlicensed use — flag broadcasts in territories where you lack representation.
Centralizing the data — one interface instead of scattered reports.

The technical foundation is three parts: recognition, storage, and visualization. A recognition API handles the hard part — identifying songs — so you don’t build fingerprinting from scratch.

Architecture overview

Live streams → AudD streams API → your callback → database → dashboard

For continuous radio and live-stream monitoring, the right tool is AudD’s streams mode, not one-off recognition calls. You register each source once and AudD pushes matches to you as songs play, rather than you polling and sampling a feed yourself. AudD recognizes against a catalog of 160 million songs.

The streams flow uses methods on api.audd.io:

setCallbackUrl — register where results should be POSTed (set once).
addStream — add a source by url plus a radio_id integer you choose to identify the station.
Receive matches via callbacks (AudD POSTs to your URL) or longpoll (you pull events). Manage sources with getStreams, setStreamUrl, and deleteStream.

from audd import AudD

audd = AudD("your-api-token")  # get a token at dashboard.audd.io

audd.streams.set_callback_url("https://yourapp.example/audd-callback")
audd.streams.add(url="https://stream.example/community-fm", radio_id=4012)

By default a result callback fires after a song finishes and includes the total played time; set callbacks="before" on addStream to be notified the instant a song starts. Stream notifications also carry problem codes — 650 (cannot connect to the stream) and 651 (only white noise, no music) — so wire those into alerting and a dead feed won’t look like a quiet one.

Database design for rights tracking

Structure storage around three tables:

Catalog — your recordings: song ID, title, artist, album, ISRC, ownership percentage, territories.

Detections — recognition results: detection ID, song ID, source, timestamp, played duration, and score (match confidence, available on the Startup plan or higher).

Sources — monitored streams: source ID, name, type, market, contact info.

This supports queries like “every play of a song I own 100% of, on US stations, in the last 30 days.” Index the fields you query most — song ID, timestamp, source ID — and partition the detections table by date once volume grows.

For custom-catalog matches, the result carries the integer audio_id you assigned when you uploaded the track, which is how you tie a detection back to a specific release you control. Any field the API returns that the SDK doesn’t model as a typed property is on the result’s model_extra map in Python (extras in Node) — store what you need from there.

Building the dashboard interface

Different roles need different views:

Real-time monitoring

Show recent detections as they arrive — title, artist, source, timestamp, and score. Add filters by catalog subset, source type, or region so teams managing large catalogs can focus on specific artists or labels.

Usage analytics

Present historical data through charts: top recordings by play count, which sources play your catalog most, geographic distribution, and trends over time. Let users drill from a summary down to the individual detections behind it.

Unlicensed-use alerts

Flag detections from sources not in your licensing database, or plays in territories where you lack representation. Present them as actionable items with source contact details and score so teams can prioritize follow-up.

Export and reporting

Export to CSV for spreadsheets and JSON for downstream systems. Generate reports formatted for PRO submission, including ISRC, play timestamps, and source identification.

Advanced features

Monitoring your own catalog

To identify unreleased tracks, alternate versions, or recordings not in any public database, upload your masters to a private custom catalog. You assign each uploaded track an integer audio_id, and later matches return that audio_id (often with artist/title null, since a private track has no public-catalog metadata). This lets a label monitor its own releases against a catalog it controls. The upload endpoint is provisioned on request — email [email protected].

Multi-territory ownership

Ownership varies by territory — a recording might be owned 100% in North America but 50% in Europe. Store ownership percentages per territory so the dashboard can attribute detections correctly and estimate royalties from territorial splits.

Integration with existing systems

Expose API endpoints so your rights-management, royalty-processing, or CRM systems can query monitoring data — to flag unlicensed use automatically or trigger licensing outreach.

Controlling cost at scale

Stream monitoring is billed per concurrent stream, so cost scales with how many sources you watch at once rather than per detection. That makes it economical to start small:

Prioritize by impact — major-market stations and high-listenership feeds drive the biggest royalty impact; monitor those first.
Start with a pilot — 2–3 strategically chosen sources validate the approach before broader rollout.
Scale by adding sources — predictable per-stream billing means you grow capacity by adding streams, not by guessing at per-detection volume.

For current pricing, see dashboard.audd.io.

Getting started

Build the recognition layer first with a small pilot, confirm the matches are accurate against your catalog, then expand. The streams API and SDKs handle the identification; your work is the storage, the dashboard, and acting on the data.

Get a token at dashboard.audd.io and start with the recipe below.

Related