Was sent this article by my bro @groovemonkey (with a lot more followers than me) and it got me thinking more about app stores and payments.
This is the read: http://dancounsell.com/articles/paid-paymium-or-freemium.
Paymium is still relatively unknown and gets pretty much no press coverage compared to freemium. Paymium is going to become increasingly more widespread over the coming year, and incase you’re wondering exactly what paymium is, here’s my definition:
Paymium: An app that is paid for up-front, with additional revenue being generated by charging for extra features via In-App Purchase.
As with freemium this type of model can work perfectly well in place of yearly paid upgrades as you can add new features overtime with IAP to continue to earn revenue from your existing customers.
Paymium apps currently only account for 2% of apps on the App Store, yet they generate the same amount of revenue as paid apps. I believe now is a good time for developers to start experimenting more with this revenue model, I know It’s something we’ll be doing with a few of our apps at Realmac Software over the coming months.
This is a very interesting model and was wondering how to apply it to Spuul but I don’t see a fit, however part of that reason is I think both app stores, Google and Apple (is there any other?), don’t offer a lot of flexibility when it comes to payments and customers. What I mean is everything is so rigid when it comes to subscription based payments.
For example with Apple they don’t offer any sort of trial capability. Example. Please buy this monthly subscription and you can use it for free for 7 days and if you like it just keep using it and we bill you after the trial period. If you can cancel during the trail period you don’t get charged but you get your 7 days. Google, Facebook and Amazon (they don’t let you set the time period though) all offer it with good results. People tend to try it and the conversion rates are good.
The other problem with almost all of these systems is that they offer fairly rigid subscription SKUs that do not transfer or modify across lines. For example – I have a 1.99 payment tier for a monthly subscription and I also have a 4.99. Customer A buys the 1.99 tier and a month later wants the 4.99. The app stores should provide an automatic upgrade SKU and just start billing the user at 4.99. Even be smart enough to charge the difference if customer A upgrades within the month. There is little intelligence in the subscription SKUs so usually one has to cancel one to get another versus upgrading or downgrading.
So when I think of the paymium stuff I think of interesting use cases like you buy the app for 1.99 and later if you upgrade in app to another tier the 1.99 could be credited by the system since the customers used the same app store for the whole process. There are other examples along this line I can think of.
What I am looking for is the app stores to provide all the bells and whistles to allow us, the developer, to craft any sort of payment and decision flow we want knowing the user is able to pay with the app store and we are able to offer what we want real time based on what the data is telling us might sell. Standard consumer sales type of stuff.
Bottom line is the app stores are generally taking 30% and I think the should offer more value for it. Don’t get me wrong – app stores are doing good things and the payment mechanisms make it easy to build mobile apps and extract money for services but their overall intelligence and feature level is still pretty rudimentary.
Dreampipe's Blog 