Apps are becoming a huge business, but the vast majority of them are free. (A recent analysis suggests 81% of iPhone app downloads by volume are free, even though other reports indicate that only about 28% are free by title. This effect has been described as the "penny-gap" -- products go like hotcakes when the price is zero, but demand drops hugely when the price increases to just 1 cent. This makes price setting a major dilemma for app developers. (One attempt to solve this software pricing dilemma was "shareware," in which buyers could Pay-If-You-Want, at a suggested price, but that has proven only marginally successful.)
FairPay can provide a way to bridge this penny gap, using a radically new variation on Pay What You Want, one that still limits buyer risk, but strongly encourages fair prices to sellers. As described elsewhere on this blog, and on the Web, this new variation, FairPay (short for Fair Pay What You Want), uses Internet feedback on what buyers pay, in order to develop a reputation for fairness. The seller (or multiple sellers) then use this FairPay reputation feedback to decide whether to extend further offers to a user based on how fairly he pays. Thus FairPay does not just rely on innate buyer fairness, but looks over their shoulder to help give that sense of fairness real teeth.
(This process also applies to other digital content, as explained elsewhere. The case of e-Books is especially similar to this example of apps. That should be fairly apparent, but I expect to do a blog post more specific to e-books in the near future.)
This process works best with an ongoing buyer-seller relationship, so in the context of an app store, FairPay would be best implemented by the store operator (Apple or Google, or whoever). That way the FairPay reputation feedback is collected across all purchases by that buyer. This enables a dynamically adaptive cycle of offers, prices, feedback, and further offers that rewards those who pay fairly, and cuts off those who do not. I suggest that app store operators should try this (and I would be happy to assist in such an effort).
Such a FairPay pricing process for an app store can be quite simple.
- The store offers to let buyers try a small number of FairPay-eligible apps on a FairPay basis, with the understanding that the buyer can try the apps for a time, see if they like them, and then set whatever price they consider fair (post-sale PWYW).
- The full FairPay process would be explained in detail up front, so buyers understand that future offers will depend on what reputation they develop for paying fairly. Their alternative will be to pay pre-set prices for future app purchases. A suggested price for each app might be provided for guidance.
- The buyer tries the apps, then sets prices, and can indicate why they paid what they did. For example a buyer might explain that they were disappointed in a product, if that is why they decided to pay little or nothing for it. (Of course they can also say the love it, and elect to pay especially well.)
- The store then assesses the prices paid, and the reasons, and decides whether to offer that buyer more items on the same FairPay basis. Criteria might include consideration of app-specific suggested prices set by the developer, and the prices set by other FairPay buyers.
- Obviously those who pay well will get a continuing stream of further FairPay offers (as long as they continue to pay reasonably well). Those who pay well for some, and explain why not for others, might also get a few further offers (effectively on a probationary basis), until it is determined by the store that they either do or do not pay fairly in general.
- Those judged by the store to generally not pay at an acceptable level can be cut off from further FairPay offers, and restricted to conventional, set-price prepaid sales (at least for some time, possibly extending a second chance to try FairPay sometime in the future).
- The cycle continues, based on these evolving FairPay reputations. The longer this process runs, the more meaningful the FairPay fairness reputations of the buyers, and the better able the store and developers are to manage revenue and risk, by controlling what offers are made to which buyers.
Presumably the store would implement and manage this process as a platform service, enabling developers to opt in to offer their apps on FairPay terms, typically in combination with the alternative of conventional pre-set prices. Developers might set suggested target prices and other evaluation parameters, and could change those parameters or opt-out, depending on results.
The result is that FairPay can be a win-win solution for both the developers/stores and for the consumers:
- Buyers will feel more respected and empowered by the added trust and flexibility.
- Some will pay less than the standard going rate, but some will pay more.
- Many who might not make a conventional paid purchase (because of the penny gap) might be willing to pay something reasonable for a FairPay purchase, once they can see that they have gotten a useful app -- the penny gap is smoothed over, and the developer and store get more revenue.
- Developers need not feel they must make their apps free in order to attract buyers (since FairPay gives a try-before-you-set-the-price option).
- The store can (with inputs from the developers) individually and dynamically tune the details of the offers and the process to encourage good payment levels, and to send free-riders back into the hard "pay wall" of the conventional pre-set price.