Mike Rowehl: This is Mobility

I’ve been thinking a decent amount recently about using SMS or other forms of messaging to drive mobile web usage. My overall question being can you drive mobile web usage with SMS and monetize your site with advertising? My gut feeling was no. And I think that’s what the number say. I figured I would share a bit of what I’ve been playing around with so that maybe we can work toward a shared understanding of SMS and mobile web interplay. My “model” of SMS/WAP usage has a few different variables:

• number of users
• number of SMS messages per user per day
• message response rate, what percentage of the time do users click on some message you send them
• average session length (number of pageviews) once a user does click through
• what’s your effective CPM on your site, how much do you make per thousand pageviews on average
• what do you pay to send a message

Relatively simple. Your daily cost is the (number of users) x (the number of messages per day) x (the cost per message). And your number of SMS driven pageviews is your (number of users) x (number of messages) x (response rate) x (pages per session). Divide that by 1000 and multiply by ECPM and you have your revenue.

Lets plug in some numbers and check it out, assume we have 1000 users. Lets assume that we’ve been ultra effective at figuring out what a user will really be interested in, so we send just one message per day and the user ends up clicking on that message and visiting the site 40% of the time. Take a session length of 6 pages, an ECPM of $5, and a cost per message of .02.

With a thousand users and one message per day that means we pay $20 to send out SMS messages every day. With a 40% click rate that means 400 responses at 6 pageviews per session, or 2400 pages. At $5 ECPM that means $12 in income from those pages. $20 spent and $12 made, not great.

Of course my numbers could just be completely off base. The one I’m really not sure about at all is the 6 pageviews per session number. I have a gut feeling that’s about right for mobile usage, especially in response to an asynchronous message. As far as the others, 40% click rate I think is extremely high, and 1 message per day is low. $5 ECPM for mobile pages is fantastic, I think most sites are way lower. And 2 cents for international SMS delivery is pretty cheap. I think if anything most people would see a bigger loss if they took a look at their site and plugged numbers in there.

Which isn’t to say that SMS is unusable for all services, just that if you’re looking at SMS and mobile web from the straight up media angle it’s not a great way to drive distribution. Lots of times I’ve said and heard people say “well if you had folks sign up and give you their phone number you could notify them of changes and drive users back to the site.” Technically true, but I don’t think the financials work out for the common case I’m seeing out there.

I’m going to pick up the handheld of the year thread from TabletBlog and encourage all you N810 fans to go vote N810 at the Engadget awards.

Michael Mace posted a great wrapup of a few threads that have been going around with respect to native vs browser based mobile development. He does a great job of laying down a nice linear story about the evolving development environment. And of course everyone who had an interest in seeing native mobile application development continue is all up in arms about his statements. I agree, kinda, but not really completely.

Of course this isn’t a black and white question. It’s not that mobile web apps have suddenly magically hit some threshold and now native apps will never be used for anything. It’s an analog value of course. Mobile web apps are getting better, the browsers more robust, the devices more capable. What’s happening is that while you HAD to write a native or Java app in the past in order to get a passable product to market, you can do more and more just using the browser.

Same exact thing as the desktop market. Pause, take a deep breath. Yes, same exact thing as the desktop market. Sure there are differences down in the details, and that doesn’t mean that mobile apps are going to be exactly like desktop apps. The market forces in play are the same. Web apps mean easier distribution, faster release cycle, higher leverage on improving the base platform, decreased barrier to entry, etc. And a third time, same exact thing as the desktop market.

Does that mean that native application development is dead on mobiles? Well, do you use any native applications on your desktop? Most people still do, but you use them when it makes sense to have a native app instead of a web based one. The same thing should shake out in mobile. That just means that native apps should be used where having a native app delivers actual increased value. Which I’m sure is what the folks defending native apps are most afraid of, needing to actually defend their position in the face of competition. That’s going to be rough, they’re so used to having a captive audience.

The overall statement from Michael I agree with however:

If you’re a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website.

Yes, that you should do. Step back and honestly ask yourself “can I do this on the mobile web instead more easily?” The answer might be no still, but for an increasing group of people it’s going to be yes. Take into account the off-deck monetization models available with advertising (and I do hope direct monetization will enter the mix soon on a global scale) and distribution through either advertising or searches (Google is sucking up as many partners as it can get to make its service the default) and the overall environment available for direct to consumer mobile web apps is starting to look like a viable alternative even when compared to native app development coupled with carrier partnerships. Because the off-deck ecosystem benefits from more network effects than the carrier model we should see it keep rolling right along now that it’s started to tip.

Update: The conversation going on around this thread has been great, plenty of bright people with excellent points to contribute. If you’re following it make sure to also read these posts:

• Sounding The Death Knell For Native Mobile Apps
• On Mobile Applications, RIP
• Standalone Mobile Apps vs Web Apps on Mobile

Great Jon Udell interview with Dr. Joel Selanikio, lots of interesting mobile commentary in there. First two bits that really grabbed my attention:

Think about what you could do if you could give access to all the information on the Internet to anyone with a cellphone.

Amen to that. They’re talking mostly about SMS and base cell phone apps, but on the details I actually disagree. I think it is going to be the mobile web that becomes the defacto development platform on mobile devices. The web in a different form than we have now, but the high capability browsers we see on high end phones are going to end up on every phone soon enough. And this one, fantastic:

It’s kind of comical how Twitter is the hottest thing on the block right now and all these people with their 2 gigahertz computers and huge displays are sending each other basically text messages over the web.

Yea, “funny”, that’s really funny stuff. I love the way all the pundits switch direction without acknowledging at all just how totally and horribly wrong they were. Always gives me a chuckle.

There’s a bunch of great stuff in there from document formats that scale from traditional web use to use over an SMS channel to use of SMS as a general packet transport for richer applications. I want to take just one thread and pull on it a bit however, using SMS as a generic communications mechanism for higher level applications. They’re talking about it as using SMS to transport and stitching together the content transparently.

So first off, I assume the reason for this is that the networks in the regions they’re operating in aren’t at least GPRS capable, or the potential users of the systems are on prepaid plans where all they have is voice and text messaging. Took me a little while to remember that constraint might exist in Africa. Bad me, I should have been thinking more expansively to begin with.

Okay, so problem established. We want to make this work on the existing networks with the existing handsets. I believe that means that the programs that do this would have to be written in Java, otherwise it wouldn’t really be usable by those folks. What’s the Java support like in those handsets? I believe they would need a Java implementation that support JSR 120 for access to messaging APIs. And even if they have JSR 120 the only way to get access to the SMS stream is to listen to “SMS messages sent to a certain port”.

This part of the systems has always been very fuzzy for me, even though at one point I implemented a system that did send SMSes on different ports (we had the server that did it at a test site at Telecom Italia Mobile). I believe that most external hookups to telecom networks don’t allow for sending SMS messages from outside a carrier in to an alternate port. I assume that normal text messages sent to the end user have some reserved port for SMS, like port 80 on tcp is the standard port for HTTP. Can the SMS aggregators most of us go through send SMS to alternate ports? I checked the XML API for Clickatell and I don’t see anything. Is there an SMS aggregator that would allow for sending on an alternate port?

Or would we have to do this peer to peer somehow? Sending from a handset with an alternate port? In the JSR I don’t see client side sending exposing a port number either, it seems to be a server side function. And what if these messages would have to cross carrier boundaries? Would they retain their port number in the interchange?

The examples that I’m digging up seem to be distinctly non-end-user focused, I’m not sure the technique would really work out without carrier backing. Does anyone know what the details are around this stuff? Any good references out there?

I’ve been fooling around a bit with doing IUI dev on and for the N810. IUI is the javascript library behind those cool iPhone web apps. It does a menu style rendering and slides and all that. It actually works quite well on the Microb browser that ships with OS2008. Here’s one of my test pages for instance:

It renders well on the minefield browser at well, but navigation doesn’t currently work:

And kick ass, with VIM installed on the N810 hacking on the pages when disconnected even is possible:

That colorscheme is delek by the way, and I think it works great on the device.

Sounds like there’s some interesting discussion going on at GDC. I liked the summary from MocoNews about the end of carrier control in gaming. It’s an excellent example of one of the positive benefits that comes out of having the mobile web look more like a web than a bunch of standalone content silos. I wanted to call attention to this bit in particular:

Who says you have to support 1,000 handsets from the start? How about 10 and see what the uptake is? Suddenly, you have all the options that weren’t available previously.

First of all cause the idea itself is worth pointing out - that distribution through the carrier often came with a required list of porting targets and you had to hit all of them. It was a pretty cumbersome requirement to go along with distribution. The ability of the developer to pick and choose targets as they go along is great news. But it also means that niche use spread across large areas also becomes possible. An application that appeals to 5% of mobile users was something that any single carrier would never go for unless the return per user was astronomical. Even if the worldwide number of users was large (5% of the worldwide mobile using public is a lot), there was no way for the app developer to reach that user base through carrier deals. Unbundling access to mobile users by hitting them via other distribution and discovery mechanisms makes those kinds of applications realistic again. I like it!

However, the flip side to this is thinking about why the carriers put those porting requirements in there in the first place. They didn’t do it to be jerks, they did it cause they wanted to deliver a consistent experience to as many of their users as they could while not bearing high support overhead. I don’t agree that was a great way to handle that problem, but it does point out an interesting area. What’s going to happen to customer support and consistent user experience in a post-carrier-dominated world? Who do I call or what do I do when an application I downloaded yesterday starts behaving badly or I can’t figure out how to configure it?

I think long term the answers to those questions should mimic the way these things are handled for PCs. The attempt to try to control the whole system of mobility from network to handset to user application resulted in the system we have now, and the whole thing needs to be supplanted with something more expansive. There’s a few things that probably go into that. There’s probably some degree of communal mobile user knowledge that needs to evolve. It exists for desktop systems, though for lots of us it’s so ingrained by now that we don’t see it. Users know what an email address is, they understand that when they install an application they should look for it in the start menu if they want to use it, that when they want to save a web page to use it later they add it to favorites, etc. Common user experience, frequency of tasks, shared understanding, and common sense all combine to make the stuff that people do frequently seem simple. And I don’t just mean “user education” here. I mean application provider and handset manufacturer education as well, cause it’s a two way street.

For an example take a look at the way that iPhone usage has pushed mobile to a different level. What happened with the iPhone was that the market potential for the device wasn’t set by how well the carrier could push services out to the end users. Instead, Apple decided what they wanted the phone to do, designed it the way they wanted it to work, and then marketed those functions directly to end users. Compare the iPhone commercials to the kind of stuff that Nokia makes to describe their products. Very different stances. But it’s not just the marketing, it delivers on what it says. Using the web on an iPhone is simple and intuitive, using the maps app is the same. It wasn’t designed by a committee, which is how a lot of the current phones on the market feel. It was designed with a strong and consistent hand guided by the practicality of the end user, not a reduction in support call costs. And the difference is obvious top to bottom.

I’m curious what else is going to come around and what else changes in this version of mobile. Are the rest of the device manufacturers going to follow suit and rethink their devices now that Apple has shown that it can be done different? I think so, which leaves the door wide open to get more open platforms into the mix. When I bring up OpenMoko frequently I hear responses from people that are tied to the “accepted knowledge” from that old environment. But I think it’s been proven that a single vendor with a strong vision, consistent implementation, and messaging to the end user can make a difference. So really all the arguments against a major disruption in the mobile devices market are pretty well voided at this point. And we have so many efforts lowering the bar for getting a new device out in the market. That could get really interesting really soon.

I have a problem with wifi routers. I don’t know why it is, maybe I abuse them too much. But I’ve gone through a few routers over the last year. At AdMob we had the same kinds of problems, wifi routers would just do odd things. They would just stop routing, or slow down to a crawl after a while. This one that I had at home last started “stuttering” when I connected to IM. It would stop routing packets for about 70 seconds when I connected to IM. I verified that I wasn’t crazy by running a ping to an external site from another machine while I connected to IM from this one. Sure enough there were a bunch of dropped packets right when I connected. Why? No idea.

Russ jokes that I have inverse technical ability - the more complex something is the more likely it is that I’ll get it working. And for some reason, the less complex it is, the more likely it is to cause problems for me. So naturally it would seem the right way to solve this simple technical issue of getting a base networking component to just route packets for me would be to make it more complex. So I was going to dig out one of my old Linux systems, put two network cards in it, and configure it as my router.

However, I also noticed that Linksys WRT54GL routers are on sale. The Linksys WRT54G was the router that folks hacked to run Linux, but then Linksys changed the design so that they could run VxWorks instead. The WRT54GL version is the old version, brought back by Linksys cause there was a lot of vocal support for the design from the hackers.

What’s this? A way to run Linux on my router using a platform and distribution system I’ve never even touched before? Well that’s sure to work! I just tried it out today, and it did:

Actually took less time to get this router working than it did to get the last commercial router swap working last time I decided to try a new bit of kit. Looks like Russ’s theory might have some legs.

I got networking going in my scratchbox install and was able to build my own minefield 1.9 Mozilla and get it talking to the intarwebs:

Pimp, I know, you’re jealous. Turns out Brad is way more pimp, and actually had debs packaged that I could play with and all.

I actually found his stuff before I did this, but I wanted to figure out how to build my own so that I could hack on it a bit. Unfortunately the extension developers extension didn’t install cause it doesn’t “provide secure updates”.. whatever that means. But Greasemonkey did:

I know, it’s hard to comprehend. I’ll give you a bit of time to catch your breath, I’m getting all excited myself.

I just signed up for the BarCamp Bank event in Berkeley next month. Not my normal venue, but I would really like to get a conversation going around mobile payments. In short, they don’t work. There’s point solutions here and there that allow a limited number of merchants to interact with a geographically segmented group of users, but nothing that works at the scale of the web. If 2008 is going to be the year of the mobile web we need a way for people doing stuff on it to be able to pay other people providing stuff. And it can’t be based on what carrier you’re on, and which handset you have, or if you happen to be in the United States. We need a global infrastructure for payments on mobile that works for everyone everywhere.

I’m hoping that with folks there looking at issues like social money, risk management and fraud prevention, and online operations maybe they can help us figure out how to crack the nut and get at something better than what we have.

I’ve been wondering a lot lately about search indexes and mobile content, and the reinforcing effect an established web index can have on the growth of any new channels. I’ve been paying particular attention since Google changed to a unified index for web and mobile searches a few weeks ago. It used to be that as a publisher providing both web and mobile content the only way to really make sure that my stuff would get indexed properly was to create a mobile sitemap for my mobile pages and inform Google of it as an explicit set of mobile pages. Now I’m not sure what to do.

My initial interpretation of the decision was that I should rely on the handheld media type alternate link to let Google know about the mobile version of pages, and rely on Google just indexing the main web version in order to find the mobile version. Makes sense, but what do I do about not having the mobile sitemap there to inform Google about the structure of my site? For instance normally there’s an indexing penalty associated with having duplicate content. Well, my web version and my mobile version are duplicate content. How much does Google use the linking from main web version to mobile version? Should I deny the Googlebot access to the mobile version in order to make sure that the web version doesn’t get penalized?

And of course there’s the problem of mobile only content. While folks can use the loopback handheld media type link hack to keep Google from transcoding their pages, how does that affect their indexing? Say that my statement from the paragraph above is true and Google uses the handheld media link to determine when duplicate content is actually a valid duplication. What does it do when the page points to itself? On our pages at Mowser we have a web version and a mobile version. The web version points to the mobile version as an alternate. The mobile version points to itself. That’s so that if the mobile version ends up in outside search indexes the page won’t get double transcoded. However I don’t have a good understanding of what that does to index ranking.

The layout really seems to encourage Google’s position of dominance with respect to search on the whole. By smacking their index together and refocusing people on increasing the ranking of their web content and relying on media linking to find the mobile version it really makes it hard for upstarts focused on making better mobile search to get any attention at all out of content owners. And with all the uncertainty around the behavior of Google’s index some of us are actually trying to hide away portions of our mobile content in order to figure out how to get the Google index to behave the way we expect it to. While Google controls the lions share of searches online, who would muck around with their content and endanger their position in the Google index in order to increase their ranking in the much lower utilization mobile specific indexes? Besides Russ and I at least. Although I love what the Google folks are doing for mobile in terms of GMail, and Gmaps, and Android - this whole issue around mobile search and advertising gives me the creeps.

Let me give a concrete example of something we just haven’t figured out yet. We have a directory of feeds at Mowser, organized by topics, rendering summaries and providing an adapted version of the full site if the user clicks through. We figured it would be a nice way to introduce mobile users to existing content without having to go to each of the publishers. We give mobile users content, give blog owners new readers, yay! Right? The problem is Google isn’t picking up the pages for some reason.

Take for instance our mobile technology blogs page, a page very near and dear to me cause it includes the greatest website in the entire world (this one). Now do a search for “mobile technology blogs” site restricted to mowser.com. It’s not in there for some reason. It’s not even very link deep from the pages we directly expose in our sitemap. Why does that page not get picked up? Is the sitemap we have there in some way affecting the normal behavior of the Googlebot? It’s not like it isn’t pounding on the site all the time, it’s just not finding stuff. I thought that’s what it was supposed to do.

Obviously, it’s Google’s site and Google’s index and Google’s users so they’re free to do whatever they want. For once I’m not going to bitch and tell them what they should do. But I do think a little extra transparency here would go a long way toward helping us figure out what we should be doing. Even just going through and whacking anything that’s old and outdated from the Google support section might help. Is the mobile sitemap even supposed to be used any more now that the index is unified? The information available for webmasters seems to be really conflicted now.