Freitag, 13. Mai 2016

The revenue share model of Tailorstage

Back when we wrote the blog post about Spotify, we discussed the question of what happens in terms of money for songs listened to in a month from a particular band. What happens, and specifically, how much money does the band get for it? This is assuming that the band receives 0.0065 USD per song streamed.

The purpose of this was not to bash Spotify, who have proven their model to be very successful, and have had an outstandingly professional approach to applying it. This is especially true, seeing how our business model’s base approach isn’t so different. And there are indeed similarities—even still, it is not particularly on these similarities that I want to concentrate as much as on some of the differences. For this post I want to talk about the revenue sharing model we are using in a way that would be enlightening for game developers.

Since the realm of gaming also possessing some particular peculiarities in terms of business opportunities compared to the commercial music industry, we believe that we can be extremely successful with a lightly tweaked approach. We have spoken at other times about how we  want our game service to be available in many countries, and especially we want to implement the many different types of payment methods that would allow as many end-users as possible to have access to our services. This could be seen as problematic when it comes to regional payment options, as transaction costs can be very high in some countries. It becomes even more of a headache, because these payment options are sometimes the only way to reach customers in these countries. This, by the way, is one of the reasons that Paypal was first conceived.
'
To come to the point, we have certain considerations in our revenue sharing model bear a short explanation. To remain flexible enough to be internationally effective, we have translated the difficulty with high transaction costs to a method of calculating revenue shares after transaction and distribution costs. This is the stepping-off point for our cost calculations, that lets us pay as much as we can while keeping the same model from country to country. We want to develop a fair way to implement revenue sharing, that allows a user to pay a monthly fee, and then, based off of this income, and costs, than the revenue share will be calculated out for the individual Game Developers. Thus, a user can play a play games, and we can use this information to then calculate which Developers get paid what amount. That means that our system is dynamically individual!! Every single monthly fee will be paid out through a shared revenue system—completely!! No matter if a Game was played for one minute, or ten games 20 hours each.

We think that is fair!

Keine Kommentare:

Kommentar posten