The 7 day problem in music dashboards
Why so many music dashboards show the same streaming figure for every date range, what the correct arithmetic is, and how to tell whether a tool has done it.
Danny Starr
Co-founder, Backline · 8 August 2026 · 4 min read
In short
- Switch a music dashboard from 7 days to 90 days. If the streaming headline does not change, the tool is showing a lifetime total with a filter drawn next to it.
- The cause is that most music data sources expose only a cumulative running total, never true per-day history. A window figure has to be computed as the total at the end minus the total at the start.
- That subtraction telescopes correctly across missing days and weekly refresh cadences, which is why it beats summing daily estimates.
- Levels such as follower counts need the same subtraction but must be allowed to go negative. Counters such as streams must be clamped at zero.
- When history is younger than the window, the honest output is not a smaller number. It is a labelled figure that says gained since tracking began.
Open any music analytics tool, look at the streaming headline, and change the date range from 7 days to 30, then 90. If the number does not move, you have found the most common defect in this category.
We shipped it ourselves. It is worth explaining properly, because it is not a rendering bug, it comes from the shape of the underlying data.
Music data sources give you a counter, not a history
Almost every public music metric arrives as a cumulative total as of the moment you asked. A track has 4,182,335 streams. An artist has 61,204 followers. A playlist has a follower count. Ask again tomorrow and you get a different single number.
What you almost never get is a dated series: streams on the 4th, streams on the 5th. Third-party APIs in this category generally do not expose one, and we have probed for it repeatedly across historic-data and date-range endpoint shapes without finding one.
So a platform that wants to show you a chart has to build the history itself, by taking a snapshot every day and storing it. That works, and it creates the trap.
The same data, read two ways
IllustrativeIf you store a daily snapshot of a cumulative counter and then display the latest snapshot under a date filter, the filter does nothing. The latest cumulative total is the same number no matter which window you asked for, because it is a total as of today either way.
The correct arithmetic
A window figure is a difference between two snapshots:
gain(window) = cumulative(window end) - cumulative(window start)
That is it. Two properties make this the right choice rather than a workaround.
It telescopes. If your snapshots are missing three days in the middle, the subtraction is still exact, because the missing days are inside both readings. Summing per-day estimates would lose them.
It survives weekly sources. Some sources only advance their counter once a week. A daily difference across them produces six zeros and one spike, but a 30 day difference is exactly right, because the intermediate steps cancel.
Levels and counters behave differently
There are two kinds of number in a music dashboard, and they need different treatment.
A counter only goes up: streams, plays, video views, shazams. Its window gain should be clamped at zero, because a negative result means an upstream correction rather than negative streams.
A level can move either way: followers, monthly listeners, playlist count, subscribers. Its window change must be allowed to go negative, because a project genuinely can lose followers, and hiding that is worse than showing it.
Getting this wrong in either direction produces a specific bug. Clamp a level and you never show a decline. Fail to clamp a counter and a data correction upstream reads as a catastrophic week.
Counters and levels need different rules
Illustrative| Counter | Level | |
|---|---|---|
| Examples | Streams, plays, video views, shazams | Followers, monthly listeners, playlist count |
| Direction | Rises only | Rises and falls |
| Window figure | End minus start, clamped at zero | End minus start, signed |
| Negative result means | An upstream data correction | A genuine decline, show it |
| Chart shape | Bars or area of per-period gain | Line of the level itself |
| Common bug | A correction reads as a collapse | A decline is silently hidden |
The baseline needs guarding
Two edge cases decide whether the arithmetic is trustworthy in the real world.
The first snapshot is not a baseline. The first time you crawl a source, the counter you get may be partial or may lag. If you use it as a window start, the first computed window inherits an artificial jump. Skip it: never allow the earliest stored reading to serve as a window baseline.
No snapshot on or before the window start means you cannot answer the question. If a project has 12 days of history and someone asks for 90 days, the difference between the oldest and newest reading is a 12 day gain. Presenting it as a 90 day figure is a lie of the most convincing kind, because the number is real, just mislabelled.
The correct output there is a labelled degradation: show the total gained since tracking began, and say so. Our window helpers return null in this case specifically so the caller has to make that choice explicitly rather than accidentally.
Reporting lag shifts the baseline too
If a source's counter runs a couple of days behind reality, then the reading you took on the 1st describes the 30th of the previous month. A window that wants to describe the last 30 calendar days has to shift both ends by the known lag, or the whole series sits offset. There is more on that in reporting lag in music data.
Three questions for a vendor
- Under a 7 day filter, is the streaming headline a gain or a total as of today?
- Do follower figures show negative movement when a project loses followers?
- What does a 90 day window show for a project with 12 days of history?
The third one is the tell. An answer that involves the words "since tracking began" means someone has thought about it. A confident 90 day number for a 12 day project means nobody has.
Common questions
- Why does my music dashboard show the same streams for 7 days and 30 days?
- Because it is displaying a cumulative lifetime total rather than a windowed gain. Music data sources expose a running total rather than dated daily history, so a correct window figure has to be computed as the total at the end of the window minus the total at the start. If that subtraction is missing, the date filter changes nothing.
- Is it better to sum daily numbers or subtract two snapshots?
- Subtract. The subtraction is exact even when days are missing and even when a source only refreshes weekly, because intermediate readings cancel out. Summing per-day values loses anything a gap swallowed and inherits any interpolation error.
- What should a dashboard show when the window is longer than the available history?
- A labelled figure saying gained since tracking began, with the actual start date. Showing the difference between the oldest and newest reading under a 90 day label is the worst option, because the number is real but describes a different period.
Sources
- 1Spotify for Artists, Reviewed August 2026. Data in Spotify for Artists
- 2Google, Reviewed August 2026. Analytics Data API: report basics and date ranges
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
Cumulative counters, daily deltas, and the data you can lose forever
Music data arrives as a running total, so daily numbers have to be derived. The three bugs that derivation produces, one of which destroys data permanently.
Danny Starr · 3 min read
Data engineering
Reporting lag: the two days nobody accounts for
Third-party streaming totals describe a day that already passed. Uncorrected, every chart and every correlation is offset, and the error is invisible.
Danny Starr · 3 min read
Data engineering
Weekly reporting sources and the phantom spike
Some music data only moves once a week. Charted daily it produces a spike every seventh day that looks like a marketing win. How to detect the pattern and what to do about it.
Danny Starr · 3 min read
