Mac blogger John Gruber at Daring Fireball posted a thoughtful, typically Apple-centric view of Apple's new, much criticized subscription policy cunningly titled "Dirty Percent." I thought he missed the biggest problem, so I wrote this.
[ UPDATE: A later post "Who is the customer?" mentions this issue. ]
John,
Your otherwise thorough treatment of the pros and cons of Apple's new in-app subscription system left out one very important, even critical issue and exaggerated a minor one.
Sharing of user names and email addresses is not, as your earlier post explicitly stated, just a matter of protecting users from sale of their contact info to junk-mail companies. To say that is to argue from the most obnoxious, lowest-level case of what can be done with user data.
It's more instructive to look at the relationship between the subscriber and the publisher or service provider. In 20th century broadcasting and non-subscription publishing it was typically an anonymous one. Analog Radio, TV, movie ticket buyers and daily newsstand users were never known to the broadcaster, theater owner, or publisher. (Public radio and TV were an odd exception, but even there only 10% of the users became members.)
In a non-interactive world, this was arguably a sufficient level of intimacy for what was typically designed to be a lowest-common-denominator relationship in terms of programming the broadcast schedule or editing the content bundle of the newspaper.
In this paradigm, subscriptions — whether to periodicals, paid media services like cable TV or even specialty content like porn — were uniquely valued not only for the recurring revenue, but because the user was known to the publisher/service provider.
If the product was good enough, the relationship was extended and secondary marketing efforts could be directed at the subscriber. These included all kinds of discounts, special offers, loyalty programs and optional extensions to the basic service. All these programs were designed to optimize, extend, and leverage the long-term value of a subscriber.
What has changed these old subscription paradigms forever is the almost effortless interactivity of the web and mobile applications, as well as the ability to support niche content by subscription.
Once it was clear that personalization was key to optimizing the online user's experience, most web services asked users to identify themselves and create an account. This not only allowed customization of the site's setup and content to the individual user, it enabled a previously unattainable level of secondary features and benefits, including ratings and rankings, recommendations, user reviews, user-specific data and the entire panorama of social network features and benefits.
We run a niche music subscription streaming service with a typical "freemium" stack of free and paid levels of engagement. We are not so worried about whether the 30% platform and processing fee Apple is mandating can be accommodated — though it would force us to raise our subscription prices. What most concerns us is that we absolutely must know who our user is and what they doing on our service, whether we or a 3rd party are handling the billing transaction.
The mechanics of this are critical. When Apple charges for a new subscription and integrates the authentication of the user for our app with their existing iTunes password (I'm assuming this because I haven't studied the API in detail) that allows the user to access our protected content via the app. But unless Apple provides us with tracking data for that user that is equivalent to what we get with our current system, we have no idea who they are. We are back to serving an anonymous user, who logs in using their Apple ID, rather than one we can see.
It gets worse. We also offer a Flash-based web app which predates our iOS app, and that requires a user account and sign in. Today a single subscription, email address ID and password allows the user to access our service both via the web and on their iOS device.
Under Apple's new conditions, a user would need an additional account and password to use our web app, while their Apple account would allow them to use our iOS app. A subscriber to our web service creates a trail of user data that allows us to view their account and deal with support and billing issues, but we see would nothing for the iOS-only user unless 1) the user opts in to share their data with us and 2) Apple decides we should see it via their API.
So the iOS-only subscriber is essentially a citizen of Apple's ecosystem and isolated there. This sucks, both for us and for the user. They would have to maintain two accounts — one for the web with us, and one for iOS with Apple. We would have to make post-facto efforts to integrate our existing account and usage data with whatever Apple in their wisdom decides to reveal to us.
A user who pays a premium for subscription to our content has a right to expect that they will be able to use it on every platform we support, but unless Apple opens up all the data about the history of our subscriber and makes it available to us via their API, we have no idea what's happening and the user is painted into a corner.
Long term I don't see how this is going to work unless Apple creates an ecosystem that really supports the relationship between publishers, service providers and the end user — and Apple as the hardware, platform and transaction provider.
If Apple is going to muscle itself into the value chain for subscriptions, it's going to need to do a much better job of it.
:: Stephen Hill
Comments