Mark Goldenstein

Blog

by Leave a Comment

Spotify and others use an unfair formula to pay artists

Tomorrow, Apple introduces its own music streaming service. It seems to be the right moment to explore how the music streaming industry splits its revenue.

There have already been some articles written about the unfairness of Spotify’s model (one, two, three) but I’m looking at the issue from a different perspective.

Ready? Let’s go.

Is this about the whole music streaming industry or just Spotify?

I’m focussing on Spotify but the thoughts probably apply to all other offerings as well.

So… how much does Spotify pay rights holders?

According to its own website for artists, Spotify pays out about 70% of its revenue to rights holders. Those rights holders then pay the actual artists according to their own contract terms.

Spotify Revenue Split Overview

This doesn’t look too bad! So what exactly is unfair?

Glad you asked! The devil is in the detail. Spotify uses roughly the following formula to split its revenue:

Spotify Royalty Formula

The interesting part here is part two of the formula, the Artist’s Spotify Streams divided by Total Spotify Streams which Spotify describes as calculating the artist’s popularity or market share . The problem is, in a nutshell, that it does not matter how many streams a user listens to, each stream counts the same. Those users who listen to the most streams also exert most of the influence over how much rights holders and, consequently, artists get paid.

What does that mean in practice?

Imagine the following simplifying scenario: There are two users, let’s call them Alice and Bob, and two artists, let’s call them Amazing Rock and Junk Pop. Just for the sake of argument of course. So Alice loves listening to Amazing Rock. Because she is a workaholic she has only time to listen to 100 streams per month. In contrast, Bob likes to listen to Junk Pop and, because he’s a student, he has a lot of leisure time. Hence, he listens to about 5000 streams per month. Alice and Bob each pay $10 to Spotify. Now Spotify splits its revenue of $20 according to the formula quoted above; for the sake of simplicity we disregard taxes. Spotify takes 30% or $6 to cover its own costs. This means that $14 remain to pay rights holders. Amazing Rock gets $0.27 and Junk Pop get $13.73.

Wow! That does not seem right!

Exactly! It also means that your subscription fee pays for artists that you don’t give a shit about.

What? Are you fucking kidding me?

Nope. See those artists in the Global Top 50 charts that you never listen to? You pay for them![1]This is true if you listen to fewer streams than the average stream count per user.

It sucks! But maybe that’s just how a flat rate model works?

While it is true that a flat rate model often means that those who use a service less tend to cross-finance those who use it more, I believe that this is not the right model for music streaming. It simply gives “power listeners” too much power.

So what would be a fair revenue split model?

In my opinion the customer that pays the subscription fee should also have decisive influence over which artists receive his money. This model is much closer to traditional album sales where the customer knows that his purchase supports the actual artist. With Spotify’s current royalty system this is not necessarily true.

Are there any other benefits to a fairer system?

In fact there are. Changing the formula could also fix the problem that indie labels are getting almost nothing from Spotify.

Cool! How does the improved royalty system look like?

We only need to adjust part two of the current formula a bit. Instead of

\text{Artist's Popularity} = \frac{\text{Artist's Spotify Streams}}{\text{Total Spotify Streams}}

we should instead use

\text{Artist's Popularity} = \frac{\sum_{i=1}^{N} \frac{\text{Artist's Spotify Streams by User i}}{\text{Total Spotify Streams by User i}}}{N}

where N is the total number of users.

What is the advantage of this alternative formula?

This improved formula would make sure that the subscription fee of any customer is distributed according to his own listening habits and not those of others. Another way to describe it: If you pay $10 a month, Spotify would still take $3 out of them but the remaining $7 would be split according to your listening habits, and not according to the listening habits of others.

By the way, this is similar to how flattr works, a micro donation service.

Got it! So why is Spotify not using this formula?

That is a good question.

Update: I just saw that there has been a similar discussion a few months ago: Jack Stratton’s take on the same topic and corresponding HN thread.

Notes   [ + ]

1. ↑ This is true if you listen to fewer streams than the average stream count per user.

by 9 Comments

Building a Websocket client to btcwallet using Scala and akka

I’ve been experimenting with the Bitcoin wallet daemon btcwallet for some time. btcd and btcwallet provide support for notifications via websockets which allows to process bitcoin payments in an event-driven programming style instead of polling. As of this writing proper notification support in bitcoind seems to be in limbo state (cf. this and that). It is possible to get notifications using scripts and the *notify command-line options but this seems to be a rather hackish solution.

So let’s build a websocket client to btcwallet. How do we do that in my favorite programming language, Scala?

Implementation

Usually, it’s inconvenient to use websocket or json APIs directly. As an abstraction to btcwallet’s websocket API I use akka, a library that implements the Actor model. Actors are threadless, stackless units of execution that process messages (events) serially. Messages are delivered to an Actor’s mailbox, and the Actor processes them by looping over a method that pops the first message from the mailbox.[1]David Pollak, Beginning Scala, Apress, Berkely, CA, 2009 I want to talk to btcwallet using Actor messages and receive Futures in return. Those messages will then be forwarded to btcwallet using its websocket API. When a response is available the corresponding Future will be completed.

Therefore, we can design our websocket client as follows. We define our BtcWalletActor such that it establishes a websocket connection to btcwallet as soon as it starts. If it loses the connection, it tries to reconnect in five seconds intervals. Objects that need to talk to the websocket service use the ask pattern to send requests to our actor. Finally, we define the reactions to notifications and requests by implementing the receive method of our actor.

In order to connect to our service we need a websocket library. There are several different options available. I’ve chosen Java-WebSocket because it is actively maintained, popular, and has support for TLS connections (right now only in the 1.3.1 development snapshot).

We also need a library for serializing and deserializing JSON. Again, there are numerous libraries available. I’ve chosen play-json. We also define some case classes for our actor messages, and for the JSON serialization.

Websocket messages are asynchronous, there is no request-response standard in the protocol. To work around this, btcwallet uses IDs in the request and response messages. Hence, when we make a request we need to supply and store an id for it. Then we can match the response message to our request.

To account for this aspect we implement our actor as follows. When our actor processes a message from another object that requests information from the websocket service, it creates a Promise and pipes the corresponding Future to the object that requested it. Then it generates a UUID for the request and saves it together with the Promise in a Map. After it receives the response (which also contains the UUID), it pops the Promise from the Map and fulfils it with the response. If you’re wondering what Futures and Promises are, then check out this introductory guide.

Once we put everything together, we get something like this (GitHub). I’ve provided an example in which I’m processing incoming transactions by sending the bitcoins back to the sender address. I’m using the outputs of the incoming transactions as inputs of the corresponding outgoing transactions. Therefore, there is no need to wait for confirmations.

Notes   [ + ]