[exelius]

I doubt it. The business overhead of distributing payment this way is enormous. Right now, Spotify just runs a report that takes some top level numbers, splits them out by copyright owner and divides a single pool of money. This means they manage only as many pools of money as they have copyright owners.

If they start doing it the way OP suggests, they DRAMATICALLY increase the number of pools of money they manage (and thus, would need to audit). They'd now be managing (number of copyright owners) * (number of subscribers) pools of money, which is a lot more. Additionally, they likely have some errors in their data, and the impact of an error in this scheme is huge.

tldr: It's too much work for too little money. Improved technology will not change anything because it's a finance process problem, and finance processes have to be regularly audited. The more complicated it is, the more expensive it is to audit.

[rwissmann]

They likely already record and store all the necessary data (and more) in order to build out people's listener profiles.

Pools of money is not really a relevant metric. They collect all the subscription premiums and pay a portion of them out according to their contractual agreements.

Pay(artist_i) = 0.7 * sum_j [ premium(viever_j) * ratio_ji ]

is not that much harder to do.

I agree that auditing would be more complicated, but usually one does selective audits anyway. I doubt this would be a show stopper.

The confusion on the receivers' side would increase massively though. As someone else has pointed out, there would be a lot less correlation between #plays and payout.

(To be clear, I have no real opinion on whether this would be a better schema.)

[exelius]

Actually, it is computationally much more difficult. You're masking another step in that the "ratio_ji" has to be calculated and stored for every artist-subscriber combination, which is significantly more complicated than calculating a percentage overall. Since they are almost certainly using map-reduce to calculate these metrics, you're basically running a nested map-reduce. I mean, it's not an unsolvable problem, but it takes a non-trivial amount compute resources that aren't free to solve a problem that isn't really a problem.

But yeah, there are many reasons its not calculated this way. Revenue predictability is another reason - companies like to be able to forecast revenue and that's hard if revenue has only a tenuous link to the other KPIs you use to run your business (which is the point you made).

Honestly, the current payout scheme makes more sense. Is it totally fair to the labels? Maybe not; but the labels it's most unfair to aren't making enough under either scenario for it to matter much. Would it really matter to an indie label if their monthly payout was $20 instead of $5? Once you get bigger than a few hundred listeners, the law of large numbers kicks in.

[Aloisius]

> The business overhead of distributing payment this way is enormous. Right now, Spotify just runs a report that takes some top level numbers, splits them out by copyright owner and divides a single pool of money.

Unless they are doing something special, they are actually just taking a bucket of money and sending it to SoundExchange or ASCAP/BMI (for the US at least) and letting the do the actual distribution. ASCAP/BMI are very used to distributing payments based on plays (they do it for radio, concerts, etc.).

It would really just be a matter of including the play counts for each song every month.