I've published a 35-page report on one of the mobile
industry's lastest overhyped ideas: the concept of a "1-800" model
for apps, where the user doesn't pay for data against their quota or cap, but
the app or content publisher picks up the tab instead.
The idea has been floated by various operators - notably AT&T
and Verizon Wireless - and supported by assorted network and
policy-management/charging vendors.
Although superficially compelling, there are numerous practical
flaws with the idea, ranging from difficulties with pricing of such
"sender-pays" data charges, through to unexpected side-effects as
users and developers try to "game" the system. Add in uncertain IT
systems, the rapidly changing nature of apps themselves and assorted other
"gotchas" and the idea starts looking unworkable.
The report elucidates 10 separate reasons why the general model for toll-free apps can't work, as well as identifying a handful of niche use-cases where it might be OK.
One of the main problems is defining exactly what an app actually is - I've mentioned the famous YouTube-video-inside-Facebook example for a couple of years, but it's now getting much more complicated than that. HTML5 means that "apps" can be created on-the-fly, individualised for different people. How does a 1-800 model work when your Facebook app and mine are different?
Then there's things like WiFi. If I'm an app developer, why should I pay for someone's mobile data traffic when I can just suggest they connect via WiFi instead? Maybe for the small amount of "absolutely need-it-now" data there's more of a case, but that makes it much more difficult to separate out the time-critical vs. delayable parts of the app. Unless the price is so cheap that the developer doesn't care - in which case the operator probably won't be making much money either.
Then there's the IT and back-office side of all of this. How does an app developer sign up, track their data costs, manage fraud and abuse - or complain if it goes wrong and they're mischarged by the operator? And if you try and implement a version of the tollfree data model where the traffic isn't just charged differently, but prioritised or given extra QoS it gets 10x harder still.
My view is that it's a nice idea for press releases and conference soundbites, but when you look at the detail it just won't work, especially in the general case where any app-developer or content provider can use the platform. The 1-800 phone industry - where anybody from a florist's shop to an international airline can offer free calls - simply cannot be replicated for mobile data and apps. There are far too many gotchas, many of which I'm not mentioning in this blog post.
Let's just work out a way to gracefully back away from the idea, look at a couple of niche and highly-customised special cases, and move on. "Sender-pays" for mobile data simply will not work for massmarket apps and content.
The report's contents (total length 35 pages):
Introduction
Several different models of “toll-free”
1. No clear definition of “an
app”
2. Business Model Fit
3. Apps’ data usage is device-dependent
4. Apps have multiple
functions
5. HTML5 changes the game again
6. Poor fit with WiFi and femtocell offload
7. OSS/BSS challenges & “dashboards
8. How would operators price toll-free?
9. Network dependencies & standards
10. Arbitrage & other unintended consequences
Can two-sided business models ever work
Exceptions where Toll-free might work
Conclusion
About Disruptive Analysis
I'll put up a more full blog post and description in coming days,
but for "early adopters" willing to pay upfront, I'm offering a $100
discount for a short introductory period.
The report is available as a PDF only, delivered via email within
24 hours of payment via the Paypal / Credit Card link below. The discounted
price is US$595 for a 1-3 user licence, and $895 for a corporate licence. (If
you're in the UK or EU, you'll need to select the option with 20% VAT added).
If you prefer to order and pay via PO/bank transfer, please email
via information AT disruptive-analysis DOT com . Also please note that I have been experiencing occasional problems with the Paypal BuyNow links below - please let me know if you have trouble.
If paying via a personal email account, please also send me your work email address or a contact phone number.
Disruptive Analysis 1-800 Toll-Free Apps report:
1-3 User Licence
If paying via a personal email account, please also send me your work email address or a contact phone number.
Disruptive Analysis 1-800 Toll-Free Apps report:
1-3 User Licence
Corporate Licence
2 comments:
We discussed this model extensively with operators when I was at Ericsson. I hope I'm not giving anything away from the $900 report here but we found 3 main issues (this is in 2009 though):
1) Operators couldn't settle on a price for data - it was impossible to tell what a service provider would pay for 1 MB. Since the operators had so many different subscriptions the price varied wildly.
2) In all BCs operators wanted to charge crazy amounts for 1 MB. Basically, if a music streaming service wanted to give the service for free to it's premium users every song would have cost them € 1 to stream.
3) Service providers were generally uninterested. They don't pay for data and users use their apps anyway. If you're really big (FB, Google) operators will agree to set your data charges to zero anyway.
We could circumvent some of the drawbacks by defining a yearly subscription fee granting the app access to the network regardless it is mobile of fixed/Wifi.
A mere web-based interface with payment methods interfaced with a provisioning system updating the list of allowed apps would make the job.
Nevertheless I agree with Niklas about the reaction of big OTTs scared to see the model becoming pervasive. We can expect that they would simply stop offering the service on the considered network which would hurt more the operator than OTTs.
Post a Comment