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

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Mobile social networking - how I'll know when it's going mainstream....
    This falls into the category of "amusing personal anecdotes" rather than "rigorous industry analysis". But it also refle...
  • Forget lobbyists, this is how Net Neutrality gets enacted in law....
    I've long held that the Internet will always find ways around any blocking/filtering mechanisms for certain types of application, especi...
  • UK ISPs Code of Practice on Traffic Management - OK as a start, but major flaws
    A group of the UK's largest fixed and mobile ISPs have published a "Code of Practice" about managing traffic on their broadban...
  • The mobile industry buzzword of 2009 will be......
    OFFLOAD This year has been all about mobile broadband revenue and traffic growth. Dongles, iPhones, embedded PCs, Android, consumer BlackBer...
  • The danger of "cutting the cord" - where's the femtocell going to go?
    I see many references to people wanting to "cut the cord", and have an all-mobile home. This is particularly the case in the US, w...
  • The "Social web" - does anyone actually want it?
    Is this another example of The Emperor's New Clothes? I've lost count of the number of pitches I've heard recently along the lin...
  • The Novatel MiFi - possibilities for new mobile broadband business models
    OK, I realise that I've been a bit grumpy and critical of some things recently. But before everyone assumes I'm getting more cantank...
  • Is it just me, or is 3G either really good or really bad, but rarely "OK"
    I've started noticing that my experience of mobile broadband (iPhone 3GS on Voda UK) is much more polarised than that of fixed broadband...
  • What's the story with the Phonejack 'femtocell"?
    I'm now trying to catch up with events and analysis over the past few weeks, as I've been on vacation. One of the more bewildering t...
  • Android - the retail experience
    I just stopped off at my local branch of Carphone Warehouse on a whim, to have a quick look at what's being sold and how. (By coincidenc...

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