Comparing releases properly: align on day zero, not the calendar

The question comes up in every campaign: is this one doing better than the last one? It sounds like a chart problem and it is really a date-alignment problem.

Why calendar alignment cannot answer it

A calendar chart puts real dates on the x axis. If one single came out in March and the next in July, their interesting periods never overlap, so the chart shows two humps side by side and the eye compares peak heights. That comparison is close to meaningless, because the two tracks had different starting audiences, different day-of-week starts and different amounts of accumulated catalogue behind them.

What the manager wants is the two first weeks laid on top of each other.

Re-indexing on day zero

The fix is to replace the date axis with days since that track's own release date.

day_index = days_between(reading_date, release_date_of_that_track)

Every track then starts at zero, and a 2023 release can be overlaid on last month's. Two properties make this worth doing carefully.

Each track needs its own release date, from a reliable source. Not the date it was added to your system, and not the date its first snapshot appeared. If you are off by a few days on one track, its curve shifts against the others and the comparison quietly lies.

Both a per-day and a cumulative view are useful, for different questions. Per-day answers whether the shape of the launch was better. Cumulative answers whether the track is ahead in total at the same age.

The eligibility problem, which matters more than the chart

Here is the part that most implementations get wrong.

To compare first weeks, you need data from the first week. A track that was released three years before anyone connected your project to an analytics tool has no early-life readings, and never will, because public streaming counters do not expose dated history to backfill from.

If you plot that track anyway, it shows up as a thin, sparse line starting at whatever day index its first reading happened to fall on. Read quickly, it looks like the older track performed badly. It did not, you just were not watching.

So a release comparison needs an eligibility rule, and the rule is simple: the track's earliest real reading must fall within a tolerance of its release date. We use 30 days, which is forgiving of reporting lag and of weekly-cadence sources while still excluding anything onboarded months or years after the fact. Tracks that fail the test are not offered for comparison, and the interface says why.

Gaps have to break the line

The second honesty rule concerns missing days inside the tracked range.

A cumulative comparison line adds each day's value to a running total. If day 14 is missing and you resume on day 15, the running total is now permanently short by whatever happened on day 14, and every point after it is wrong by that amount. The line still looks smooth and credible.

The correct behaviour is to end the cumulative line at the first missing past day and leave it ended. A curve that stops with a visible gap prompts a question. A curve that continues quietly gives a wrong answer with no prompt.

Per-day lines are more forgiving: a missing day is simply a gap in the series, and the surrounding days remain correct.

Making old releases comparable

There is one genuine route to comparing a release from before you were tracking: a platform export.

Spotify for Artists provides timeline exports of audience and per-song data. If your tooling can ingest one, an older track gains real dated history for the period before live tracking started, and becomes eligible for comparison. We merge uploaded history only for dates before live tracking began, flag those points as historical, and render them as a distinct segment with the boundary marked, so nobody mistakes a manual upload for a live feed.

That distinction is worth preserving even though it makes the chart busier. Uploaded and live data have different provenance, and a reader deciding whether to trust a comparison is entitled to know which is which.

What a good comparison view shows

• Day zero aligned, with a per-day and a cumulative toggle.
• Only eligible tracks, with an explanation for the excluded ones rather than silence.
• Gaps as gaps, and cumulative lines that stop at the first gap.
• Uploaded history visually distinct from live tracking.
• A note on which sources in the comparison report weekly rather than daily, since a weekly source compared against a daily one will look spiky at low day counts.

None of that is difficult. It is just a set of decisions to make deliberately, because each of the shortcuts produces a chart that is more attractive and less true.