Building music analytics that never store fan personal data

A music analytics platform can answer every question a manager has without holding a single record about an individual fan. That is not a marketing position, it is a design constraint, and it is easier to state than to hold.

The questions, and why counts answer them

Where is the audience: listener counts by city and country. Which platform do they use: click counts by platform. Did the campaign work: arrivals and click-through rates. Is the show selling: cumulative tickets by date against capacity. Is the list healthy: subscriber counts and aggregate open and click rates.

Every one of those is a count or a rate. None needs a name, an email address, a phone number or a device identifier.

The exception people reach for is targeting, and even there the channels are aggregate: a platform's own audience tools, a market-level campaign, a local press push. None requires you to hold the underlying records.

Where the line gets crossed

Not by decision. By four convenient features.

Spreadsheet uploads. Somebody has a box-office report with buyer names and email addresses. They upload it because it is the file they have.

The guard is column-level. Reject the whole file when a header matches a pattern for personal fields, name the column in the error, and say plainly that fan personal data is not stored. Ours also rejects any unrecognised column rather than importing it, because the alternative is a permissive parser that silently accepts a name field spelled unusually.

Pair that with a downloadable template. Most people upload personal data because it was in the file they were given, not because they wanted to.

Link pages. Every analytics vendor will happily identify visitors. What is needed is a platform choice, a country from an edge header, a device type. All cookieless, none personal.

Session recording. Genuinely useful for finding a broken page, and a recording of a fan's session is a recording of a real person. If it is used at all, mask all text and inputs, so the recording shows layout and flow rather than content, and gate it behind consent where consent is required.

Email integrations. The platform holds addresses because that is its job. Your analytics layer needs the campaign totals and the subscriber count, so sync those and nothing else. It is tempting to pull the list because the API offers it.

Consent, handled honestly

Two categories on a fan-facing page.

Essential, cookieless measurement that stores no personal data. A server-side record of which platform was clicked, from which country, sets no cookie and identifies nobody. That can run for everyone.

Everything optional: browser analytics, session recording, marketing pixels. In the UK and EU these need consent first, and the workable arrangement is to detect the region from the edge country header and gate them behind a clear notice there, with the choice remembered locally.

The cost is losing some browser-side data from a subset of visitors. That is the correct trade, and it is much cheaper than the alternative.

Make it a codebase constraint

A privacy commitment that lives only in a policy document erodes, because each individual exception is reasonable and nobody is counting.

What holds is making it structural. One place where redaction rules live, so a new rule is added once rather than at every call site. A schema with no columns for personal fields, so storing one requires a migration somebody has to justify. Upload parsers that reject rather than accept unknown columns. Tests asserting the rules, so a regression fails a build rather than shipping.

Where it genuinely costs you

It is worth being honest about the trade rather than pretending there is none.

You cannot do individual-level personalisation, build lookalike audiences from your own customer records, or tell a manager which specific people bought a ticket twice.

For an analytics platform serving managers, labels and artists, none of that has come up as a real requirement. What has come up, repeatedly, is managers checking that connecting Backline does not make them the custodian of another database of other people's personal information.