Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

His proposition may sound simple to him, but it really isn't.

It becomes very hard to ensure you are being paid properly in his proposed scenario, I would personally expect it would create even more controversy, or extremely long payment records every month for artists.

For instance say we have 500 paid users. Lets call them user1 through user500. Each user listens to the same number of songs a month as the value following the word user in their name. Then we have 500 different rates at which artists are paid for their song playing ranging from the entire monthly fee to 1/500th the monthly fee. Therefore providing a full accounting of each of those rates would be necessary for an artist to understand why they got paid more the month they had a single play than the month they had 400 plays.

To be fair assuming the minimum song length on Spotify is 30 seconds this record provided to artists would have a max length of (31 * 24 * 60 * 2)+1 = 89281 items for premium users plus items for add supported users if they did not overlap exactly in rate. Assuming all Premium users paid the same rate, which is not the case.

Edit: I ignored the 0 listen use case, as well as spotify's 30% cut to simplify an already complicated 'simple proposal'. I also forgot to account for daylight savings time in which a day can have 25 hours.



Complex accounting isn't a good reason to pay artists unfairly.

Having said that, the accounting doesn't have to be that complex:

1. When paying out an artist, list out the (anonymous) users who listened to their music on Spotify.

2. For each user:

a) Show the what percent of the user's total listening was spent listening to that artist. (e.g. 40%)

b) Multiply the amount the user paid by the percentage from (a). (e.g. $10/month * 40% = $4)

3. Sum all of the amounts from #2. (e.g. $4 + $3 + ... = $total)

Also, accounting would only be a problem for Spotify. 99% of artists would prefer this model, even if it meant more complex accounting.


It might not be complicated, but it's cumbersome as hell: "Hey, Rhianna, here's your 65-million line payment breakdown for the week! I know it used to just be one simple intuitive calculation, but isn't this great!?"

> 99% of artists would prefer this model, even if it meant more complex accounting.

What are you basing that on?

Artists paid more might not complain, and those paid less (likely the more popular artists) would complain. Then there are new artists, growing artists, and people who would just be annoyed by the complexity.

The theory is simple, but the implementation is a complete nightmare.


If only we had some kind of machine that was capable of computing these complex models for us...

EDIT: my point being, if the model is fairer, we can deal with a little extra complexity.


It's a zero sum game. Spotify isn't going to pay any more in total, no matter how the rules change. That means for every winner under a new scheme, there will be a loser. If those losers are the popular artists that the service can't exist without, you have a non-starter.


> That means for every winner under a new scheme, there will be a loser.

No, that doesn't follow. Imagine one artist is receiving all the money, and the other 10,000 artists are receiving none. Spotify could move to another payment model that would result in 10,000 winners and one loser.


Not really. Right now streaming services barely manage to pay even the top artists anything meaningful. This scheme would mean everyone gets paid barely anything, and the bigger artists may leave, which is an existential threat to the business.


It would be up to the smaller artists and their fans to pressure this change, and I'd bet there are some popular artists willing to join the cause at a small personal loss. It's good to consider the incentives, but people are invested in having an equitable society as well.


Wow great catch on the the fact that any system that results in necessary artists being payed less, simply won't happen if Spotify wants to continue existing. Really applies to the entire scope of the article and not just the comment you replied to.


That assumes that those artists are already on the verge of quitting spotify, which is a bad omen for the continued existence no matter what.


>> 99% of artists would prefer this model, even if it meant more complex accounting. > What are you basing that on?

Simple, artists who are paid penauts would prefer getting paid more. We just released an album but we are not putting it on Spotify. Why bother.


i treat rdio like a collection of full length previews that allow me to discover a lot of new music. stuff i like gets my money for tickets, merch and vinyl. i do not understand why anyone would pay $10 a month to listen to the same shit they have on their ipod.


Same here, rdio is a giant preview platform for me, and it's a surprisingly great experience when you follow a bunch of people with good taste (heavy rotation section, collaborative playlists, etc.) - however everything I like gets bought since I want to own my music and prefer to keep it even if the licensing deals or the service itself changes. However, that means that there's actually a lot of overlap between my own personal (digital, lossless) collection and the one I have on rdio.


> 99% of artists would prefer this model

I mean that objectively, based on how much money they would make.

99% of artists would make more money in this model.

And, again, cumbersome accounting is a bad excuse for unfair pay.


> 99% of artists would make more money in this model.

You just shifted which number you pulled out of thin air, not the fact that you did so. Do you secretly have Spotify's streams database?


I never said it was a reason to. I simply said this method is anything but simple, as the author called it. Your method would require even more potential lines on the monthly report than the nearly identical method I described above. As yours would require a per user line, even though many of them would have duplicate rates.

Keep in mind things would still need to be split per song also, as rights holders vary per song.

Do you really think giving every artist that many potential lines of accounting every month can be called simple?


Exactly. Based on data from Spotify[1] and taking an average payment[2] of $.0052, I calculated Spotify would be storing about 20 BILLION accounting records PER MONTH.

Showing my work: 15m paying subscribers = ~150m per month, ~105m paid to artists @ .0052 per song = 20.154 million songs in a month.

[1]https://press.spotify.com/us/information/ [2]http://thetrichordist.com/2014/11/12/the-streaming-price-bib...


20 billion records per month is still reasonable, there are hundreds (maybe thousands) of businesses storing a multiple of that amount of data daily.


So your argument is that it's unreasonable to store a list of every song play, even though they already do so?

Or that it's unreasonable to make them "accounting records"? Not a problem. They aggregate using the current method to limit the number of "accounting records", they can aggregate just fine using the new method. Have "accounting" start with revenue per song the same way it used to start with listens per song, after asking the database to process its 20 BILLION records.


The model is extremely simple. The number of formulaic, near-identical lines on an arbitrary report has nothing to do with complexity.

Splitting per song already has to be done. This just gives you a different amount of money to split per song with the existing mechanisms.


Implementation and adoption are part of the complexity of a solution, in my book at least. I assume those who do not consider implementation and adoption part of the complexity have either come up with genuinely simple solutions to problems or never had to complete those portions of the task when they were not simple.


Implementation is one paragraph of SQL or statistical code, given access to the data set and a few minutes to execute.

This change in how revenue per song is calculated is truly simple.

The only hard part is convincing people it's better.

Adoption has nothing at all to do with complexity. Be careful you're not moving the goalposts.

Bill gates giving me a billion dollars to screw around with is extremely simple, and also will never be adopted.


Adoption is directly effected by the implementation and design you choose. If your app is nothing more than a table and some aggregate statistics, because you just made the simple implementation with absolutely no design, then good luck getting musicians especially older ones who probably still rely on paper copies of their monthly records being gasp mailed to them to adopt the app.

It is not moving goal posts its considering whether the 'solution' will actually work given circumstances outside the technical feasibility.


The old method mailed them revenue taken in per song. The new method will do the same. You mail them the same sheet as before, but it's probably more fair.


The old method mailed them how many times a song was played and total revenue for that song. Therefore it was easy to see the rates. With what you are describing they would only see average rate if you mail them the same sheet. It is not the same.


> Complex accounting isn't a good reason to pay artists unfairly.

But is it Spotify that pays the artists unfairly? AFAIK, Spotify pays to the record labels, and then it is up to the record label, how they distribute the money to the artists? (Also some of the money, the labels keep them selves, and do not distribute to artists.)


>Complex accounting isn't a good reason to pay artists unfairly.

That wasn't ever mentioned or implied. The point was, the author doesn't understand how complex his simple solution is.


This is a very good point. I'm sure that Spotify could encode the rules and accurately calculate what each artists was owed under such a model, but it would be far more complicated to communicate to people.

There are already a bunch of assumptions in the payment model, do you pay per track? (In which case, the artists could game it by sticking in 30 second intro tracks and things like that). Do you pay per minute? (In which case, artists can increase their revenue by putting in dead time in "bonus tracks").

It would be an interesting experiment for Spotify to calculate what the payouts would be given the proposed scheme, and compare the differences.

Anecdotally, the people I have met that work at Spotify are a lot more sympathetic to the indie artist and non-Top 40 music than the average person listening to Spotify. There is a reason they keep building ways to discover non-Top 40 music. I'm sure they are interested in making things better for these types of artists.


It gets even more complex if you take the fairness he's suggesting to it's logical conclusion. The system proposed still values playing each song equally, but shorter songs comprise less of a user's streaming activity.

So the per play rate should be determined by taking 70% of the user's subscription, dividing that by the number of seconds of streaming that user streamed that month and then multiplying that by the number of seconds that user streamed the artist's song (since songs can be stopped mid-song).

Regardless of how they bill, it's likely that artists will have to, for the most part, just trust Spotify. There can, and should, be independent audits of the billing code. It seems an analogous situation to what the NGC does around computerized gaming systems. Users have to trust that the system is fair, but the NGC is very thorough about checking that code complies with applicable laws.


Do you artists would prefer being underpaid to getting extremely long payment records? I really don't see the issue.


Right now the payment is easy to understand why you were paid as you were. Listens * payment * .7 = my check.

If the proposal were followed, all transparency is lost.

"Extremely long payment records" is quite an under-statement. Imagine sending a popular artist a 27-million line breakdown (you'd need a LINE PER LISTEN, and what % of a listeners listens that was). That's absurd, and STILL less transparent.

I understand the problem, but this is actually a pretty terrible solution. Future complexities build on existing complexity. I can't even imagine the monstrous data, business, and programming nightmares that would arise from breaking payment down in the proposed manner.


I am not sure which payment model I prefer, but I don't buy the technical reason against the OP's proposed solution.

I imagine Spotify already maintains a list of songs played by each user (to build their recommendation engine).

You could report to the artist using a histogram (bucket the listen by the percentage of user's listens they represent).

Also, Spotify could build a nice web interface that allows artists to understand their revenue stream, with various aggregated stats and graphs.


SO that's what, a few gigabytes? Takes 30 seconds to download? Then run some stats, get some totals and compare it to your check. What's the problem? Its the 3rd Millennium, get with it.


> "Its the 3rd Millennium, get with it."

No need to be condescending. People can disagree with you without being technically stupid.

> "SO that's what, a few gigabytes? Takes 30 seconds to download? Then run some stats, get some totals and compare it to your check. What's the problem?"

I think you underestimate the complexity of a database that grows by 20 million records per month, but let's say you solve the technical, computational, and programming issues. It's still a bad idea.

Most of Spotify's customers can open and understand their Spotify payment today. Your customers are not database experts. Most people have rudimentary Excel skills at best. Talk down to them all you want, but they won't know what to do.

So what, they should all hire data analysts? To understand their Spotify invoice?? You know you're using technology wrong when you take something your customers currently understand intuitively, and alter it in a way that requires technology. I understand that you're trying to fix a problem, but you're actually introducing new problems that are far more significant.

Don't let the love of nuance override your customer's experience. That's how you build "perfect" products no one wants.


> I think you underestimate the complexity of a database that grows by 20 million records per month

Why does it need to grow per month? Create a new database each month and archive.

> So what, they should all hire data analysts? To understand their Spotify invoice??

There must be some misunderstanding here. The customer's invoice is for $10 per month regardless of invoice complexity. The record of accounting that goes to the artists is what's being discussed.

It seems very simple to provide a database to artists, then also provide an open source database analyzer that will verify your pay check is accurate.


I want the broadband connection you've got.


No, but I believe humanity in general wants things to be beneficial to them AND simple. Hell most Americans (being one myself) don't just 'want' they feel entitled to. Because of that, I believe a huge number of artists would not bother to make sense of monthly records which could reach 1800 pages, and would complain even though they were presented with such records explaining why their 50000 plays this month were less valuable than their 3 plays the prior month.

I am not saying the Spotify method should not be changed just showing that the proposal at hand should not be called 'simple'.


> I believe a huge number of artists would not bother to make sense of monthly records which could reach 1800 pages

I don't understand this argument at all, which suggests that reviewing a monthly report is an O(n) task. Spotify, if they chose this route, trivially solves this with a simple open source app that analyzes your monthly report making it, basically, an O(1) task.


And gets every artist to happily learn how to use that app to examine 90000 entries in it? My whole argument is that his solution is not simple, while I agree designing, making, and getting artists to use this app which could be made, is indeed possible, would you not acknowledge it makes his solution just a tad more complicated than 'simple' to accomplish that design, creation, and acceptance?


Another thing to note (although it represents a pretty useless edge case) is that given a user who spends $10 a month on Premium if they were to listen to 1400 songs in a single month (10/(.005/.7)) bands who he is the only person who listens to and he only listens to once would receive nothing, due to accounting (and the ieee) using round to even, and 0 being the closest even penny.

I realize this the amount they are paying now per song is not too far above the $0.005 amount which rounds to 0, and therefore given changes in the market could potentially drop to an amount which would round to 0 for single play also. I also get that a single penny isn't what anyone is going to be upset about. Also that few artists will have a single play. I just find the low number of plays (1400 in a month isn't really that many) required by a person for an artist to potentially not get paid interesting.


> I also forgot to account for daylight savings time in which a day can have 25 hours.

Fortunately, the 25-hour day is in November, which is only a 30-day month. So you're okay on that front.


Daylight savings is easy to fix: don't use it, just standardize on UTC. That's what essentially everyone does in, say, telecom.


In telecom there is a lot of local-time based billing.


I guess GP was talking about switches and mediation. Certainly, once you get to billing (and downstream to "data warehouses"), CDRs have local times! Although they also have a duration field, so extra or missing hours don't cause a problem, which was the original concern.


Uber and Lyft don't provide per-ride accounting for rides for this reason. I think spotify could get away with "N plays - total $X" in this case, especially since user privacy is at stake. Also the %30 cut is extremely easy to model -- a user that pays $10 with a 30% cut is like a user that pays $7 without one.


How is this any different than say a phone bill format? that shows totals such as 'minutes' $XX, 'data' $XX' and then you can optionally view the entire logs


The royalty reporting is this complex already anyway. It's really crazy.


Please provide an example. As the examples I have seen of artists showing their Spotify payments do not support this assertion.

Here is a link to one such example I have seen which has each song paid at the same amount per play. This has made the number of items on the payment record to simply be the number of different songs which were played by that artist. http://www.digitalmusicnews.com/wp-content/uploads/2015/02/B...


That is a statement sent to the artist but broadcasters report far more detail to SoundExchange and licensing agencies.


And this whole time I was precisely talking about what would need to be sent to the artist...

Guess I am just missing your point, if you had one.

Edit due to reply since its getting nested way too deep: Thanks for clarifying. I never meant to say it was a reason to switch, complexity should never be a reason not to improve. I am just trying to say it isn't what I would call a 'simple' solution as the author asserts. I am also questioning just how much individual artists would actually want to receive all that information, which I believe would become necessary for them.


Just trying to convey that complexity of the accounting for broadcasters is not a reason to stick with the current payout system. The proposal isn't much more complicated than the data we already have to report to some agencies.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: