Amazon Tech Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Wednesday, 2 January 2013

There really needs to be a "User tariff API" for developers

Posted on 01:25 by Unknown
Generally speaking, app developers and website owners know what device you've got, what OS, and what browser. Furthermore, they know what country you're in, and a ton of other information from cookies or that you've filled in through registration. The more sophisticated companies can also work out how fast your connection is, and also already know if it's WiFi or cellular.

Using all this information, they can tailor their software or site to give a good experience - as well as using it to manage their own operational costs and resources.

But what they currently don't know is what all this is costing you, and how that might drive your preferences and behaviour:

  • What data plan do you have? Unlimited or capped?
  • How much data do you have left? When does the new month start? Are you in any danger of getting close to overage fees?
  • What policies are in place? Bandwidth limits, peak/off-peak differences, certain things being blocked or charged extra?
  • Are you a postpaid contract user, or a prepay user either with infrequent top-ups, or US-style monthly plans?
  • Do you get unlimited telephony & SMS? Or do you get a "big bucket" you never use?
  • Are you roaming (and do you roam often, and how much does it cost?)
  • What international call destinations are included in the user's plan?
If developers had access to this information in a better (and ideally consistent) way, they could design an app's experience to work better for individual customers. They could suggest using WiFi for large downloads, or double-check that the user really wants to spend 30% of their monthly data use by streaming a movie. They could know if the user is happy to send SMS's via the app, rather than using alternative messaging options. They could potentially know if "carrier billing" for in-app payments was realistic, or whether it would use too much of the user's outstanding prepay balance.

They could work out whether it was better for person A to call person B - or vice versa, with the app setting up a dial-in. Or if the data connection was good (or cheap enough), use a VoIP app instead, or WebRTC if browsers or gateways support it.

In other words, they could make their apps or websites better, by personalising them to their users' network tariffs and spending preferences.

There are however a couple of obvious problems here. Firstly, there is a huge diversity of plans, with increasingly clever variables involved (time, date, location etc). Some of those will become dynamic over time, eg giving notifications of "happy hours" as a promotional tool. Secondly, customers often don't know or can't remember accurately what plan they've got. Lastly, telcos are going to be very hesitant to give a clean and convenient API that essentially enables better and smoother arbitrage plays, or allows customers to get "as close as they dare" to thresholds but not cross them.

For these reasons, I'm not expecting to see "official" tariff APIs from many operators. But it wouldn't surprise me at all if we didn't see intermediaries or third parties spring up, who have at least *some* of this data available - especially basic information about data plans and voice minutes.

There's probably a great two-sided business model here in fact - if you collected details about millions of users' plans and usage (and kept it updated), you could supply both developers with an API, and you could advertise better/cheaper/more suitable plans back to the users themselves.

I already know about several apps that monitor / help users control their data usage (Onavo, My Data Manager etc) but I'm not aware if any of them have developer APIs, or also watch voice/SMS plans too.

Ultimately, something like this might even help telcos' own efforts to sell things like "sender pays" - if a content company knew for certain that you didn't have enough data-allowance to download a movie (or were getting close to your quota), it might be more inclined to subsidise it for you. On the other hand, if it knew that you've got plenty to spare, it could also let you know not to worry.

Someone will get this right, I suspect - although possibly it would make most sense to bake into iOS, Android and other OS's, particularly for the telephony aspect. However, billing/OSS players like Amdocs or Ericsson or Convergys should give it some serious thought. It could also be a fascinating Telco-OTT play, with great synergies for whatever operator developed and hosted it - how much would you like to know what plans all your competitors' customers have?
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in | No comments
Newer Post Older Post Home
View mobile version

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Quick musing on Cloud Computing
    I just heard the phrase "Everything as a Service" during a presentation on Cloud, SaaS and other forms of managed service offering...
  • Apple, embedded SIMs, NFC and mobile payments - some speculation
    I wonder if I've just managed to join up the dots on something rather important: - Recent reports suggest that Apple is intending to use...
  • New Cisco VNI traffic report out
    One of the broadband industry's "bibles" has been published in a 2010 edition . Cisco's "Visual Networking Index...
  • Is the MID a market?
    MIDs (Mobile Internet Devices) are being pushed by some notebook OEMs and silicon suppliers as the next big convergent handheld category. I...
  • "You can't use my eyeballs for free"
    Let's look forward 10 years. We've all got augmented reality browsers on our handsets, or perhaps our 4G-connected sunglasses. They ...
  • Mobile traffic management - the Inter-technology war begins
    I've been following the proliferation of mobile broadband traffic management technologies for some considerable time now, having publish...
  • Pre-MWC notes for analyst relations staff
    OK, it's the time of the year when I get bombarded by emails and phone calls from a million people inviting me to briefings and similar ...
  • Mobile operators' future voice strategies decoded
    Apologies in advance, but this blog post is deliberately a bit of a tease. I'm not going to spell out the answer here, as it's too v...
  • Hosted mobile services in the recession - Caveat Emptor
    I used to work as an equity analyst at an investment bank back in 2000-2001. I remember an unending stream of first generation Application S...
  • Challenges in measuring offload volumes
    I suspect we're going to get bombarded with statistics in the next year, along the lines of "Operator X deployed Vendor Y's off...

Blog Archive

  • ▼  2013 (31)
    • ►  October (2)
    • ►  September (3)
    • ►  August (1)
    • ►  July (2)
    • ►  June (6)
    • ►  May (5)
    • ►  April (1)
    • ►  March (3)
    • ►  February (3)
    • ▼  January (5)
      • Microsoft and WebRTC - well, this is awkward
      • WebRTC - not just about browsers
      • Musing: exploiting under-used network capacity or ...
      • Retrospective: My most-read posts of 2012
      • There really needs to be a "User tariff API" for d...
  • ►  2012 (46)
    • ►  December (5)
    • ►  November (4)
    • ►  October (3)
    • ►  September (2)
    • ►  August (4)
    • ►  July (3)
    • ►  June (1)
    • ►  May (6)
    • ►  April (4)
    • ►  March (1)
    • ►  February (9)
    • ►  January (4)
  • ►  2011 (73)
    • ►  December (4)
    • ►  November (10)
    • ►  October (8)
    • ►  September (6)
    • ►  August (3)
    • ►  July (5)
    • ►  June (7)
    • ►  May (9)
    • ►  April (4)
    • ►  March (7)
    • ►  February (6)
    • ►  January (4)
  • ►  2010 (130)
    • ►  December (4)
    • ►  November (10)
    • ►  October (10)
    • ►  September (6)
    • ►  August (9)
    • ►  July (7)
    • ►  June (19)
    • ►  May (19)
    • ►  April (11)
    • ►  March (18)
    • ►  February (7)
    • ►  January (10)
  • ►  2009 (126)
    • ►  December (4)
    • ►  November (14)
    • ►  October (9)
    • ►  September (8)
    • ►  August (9)
    • ►  July (10)
    • ►  June (21)
    • ►  May (14)
    • ►  April (2)
    • ►  March (11)
    • ►  February (15)
    • ►  January (9)
  • ►  2008 (94)
    • ►  December (24)
    • ►  November (26)
    • ►  October (25)
    • ►  September (19)
Powered by Blogger.

About Me

Unknown
View my complete profile