Backfilling history you were never given

Connect a new analytics platform to a project with four years of catalogue and the charts start at zero, today.

That is not a limitation of the platform. It follows from what the sources expose.

Why history cannot be recovered from a counter

A cumulative counter tells you the total now. Yesterday's total is not retrievable, because the value was overwritten by today's.

If nobody was snapshotting on that day, the number that existed then is gone. We looked for dated history endpoints on the providers we use, probing several plausible shapes for historic data and date range parameters, and found none. What is available is the total, as of asking.

So the only history a counter-based system has is history it recorded itself.

What can be recovered

Platform exports. The real answer. Spotify for Artists provides timeline exports of audience and per-song data. Those are dated daily figures produced by the platform itself, which is exactly the history a third-party pipeline could not have collected.

If your tooling accepts one, an artist onboarded in 2026 can have real data from 2023.

Anything with a proper reporting API. Advertising platforms, search, analytics and email all serve a trailing window on request, so they backfill themselves the moment a connection is made. A newly connected ad account arrives with its recent history intact.

Ticketing. Depends on the partner, but a settlement or a box-office export can rebuild a pacing history that was never captured live.

Nothing else. Public streaming and social counters start from the connection date, and no amount of engineering changes that.

Handling an upload honestly

Once you accept uploaded history, you have two provenances in one series and a set of decisions to make.

Merge only before live tracking began. For any date where you have a real snapshot, use it. Uploaded data fills the period before, never overwrites the period after. That keeps one rule, avoids reconciling two sources for the same day, and means an upload can never quietly rewrite recorded history.

Flag every uploaded point. In the data, not only in the interface. Downstream consumers, chart tooltips, exports and AI summaries should all be able to tell that a point came from an upload.

Record the boundary. The date live tracking began, per source, so the interface can mark it.

Replace rather than accumulate on re-upload. A second upload for the same scope should replace the first. Otherwise a user correcting a mistake ends up with two overlapping histories and no way to tell which is current.

Showing it

The temptation is to render one continuous line, because it is prettier. Resist it.

Draw uploaded segments distinctly, dashed or lighter, mark the boundary with a label such as live data begins, and note which platforms the uploaded data covers, since a platform export usually covers one service rather than all of them.

This looks like admitting a weakness. It reads as the opposite: a chart that distinguishes its own sources is more credible than one that hides the seam. The first time somebody spots an undeclared join themselves, they stop trusting the whole chart.

Who should be allowed to upload

Worth a thought, because it is a permission that does not fit the obvious buckets.

Uploading history is not the same as changing what a project tracks. A member of a project should generally be able to add historical data without also being able to change the catalogue, so it makes sense as its own permission rather than being folded into a general settings capability.

What to tell somebody migrating

Be direct. Streaming and social history does not transfer, and it cannot be reconstructed later, so the first month on any new platform has no comparisons.

Two things reduce the pain. Export whatever the incumbent allows while you still have access, since even monthly totals give a reference. And upload a platform export on day one rather than after three months of flat charts.

The second is the one people skip, and it is the difference between a first quarter that can answer questions and one that cannot.