So what does that theory have to do with the mobile web? I think it helps summarize one of the primary failure modes for doing mobile web work. There’s a natural tendency to look at the desktop web when thinking about how to address mobile. However, many things that we’re doing on the desktop web just aren’t adjacent to the existing practice on the mobile side. We might make it there eventually, but we can’t make it there now. We assume we know where the mobile web is eventually going TO because we know all the awesome things that grew out of the desktop web, but it’s more important to think about what the mobile web is going THROUGH in order to up the chance of being successful.

For instance it’s pretty natural to assume that because more capable devices are ending up in the hands of a wider audience now would be the time to start working on mobile media properties. However I don’t think the advertising environment is really at the right stage of evolution on the mobile web to make that style of property the same slam dunk as it would be on the desktop web. I think what we really need are a few direct monetization services to kick things off. We need the Amazon and eBay of the mobile web. Those two shifted perceptions on the desktop side, one with direct sales and the other as a sales platform. The media models formed around the commerce that started flowing. I’m starting to think that until the mobile web has something to sell it’s premature to start trying to run media models.

Not that media properties won’t work, I just don’t think they’re what we need to significantly shift development toward the web. And of course, I’m planning to test some of this out cause I might be completely insane. Hat tip to Jay Jamison and Eric Ries for the recent discussions at Founders Labs and Bluerun that have kicked off some interesting ideas.

Even with that simple arrangement there is a degree of complexity to take into account though, mostly in the form of pricing. A high priced item is generally a higher margin item for the developer, but will also normally shift few units. Sometimes lowering the price so that you can get additional purchases will give you the extra lift you need to get into the charts, and the volume you sell will more than make up for the lower margins. It’s a very error prone process, because there’s so little hard data about individual applications available to the public. And even when you do have hard data it’s pretty hard to replicate previous successes because the marketplace is evolving rapidly.

Then there are a few hacks you can use to segment the two functions. The most common is having a free or low cost ‘lite’ version of the app and charging for enhanced functionality either via in-app purchases or having another version of the app with a different price. This allows the lower cost version to hopefully make it up into the charts for you and serve as a marketing function, while being able to keep the price of the full version at a point where the margins are a bit thicker without losing out completely on the exposure the app store itself can get you. The other option is to offer the main app for free and use some kind of in-app purchasing for segments of functionality or content, the so called freemium business model.

Then there’s advertising and affiliate programs. The success of advertising and affiliate programs is majorly a function of how large your audience is. The number of users your app has. And (just as important!) how often they use your app. It’s not very useful to try to advertise with a generic network in an app that’s been downloaded 3 million times, but only has 30 thousand active users on any given day. However the success of an advertising or affiliate program is also a function of how strongly segmented your audience is. For instance if you have 1 million users from all age groups and all walks of life, you might not have the kind of audience you would be able to find eager advertisers for. However, if you have 500 thousand users, all of who live in the San Francisco Bay Area, have indicated in some way that they’re at an auditorium or concert venue in the last week, and tend to be in the 18 to 25 age group – you could probably find someone looking to reach those people.

This is where the fundamental tension comes from. If you setup your app to do well getting directly sold through the app store (broadly appealing, low cost) you normally have to tilt things in the direction of that being your major monetization route. If you raise the price to where you can make decent money off the initial sale you’re normally also cutting the audience side down and limiting the scope of the advertising and affiliate programs you can run. Same thing with more directly targeting your app. If you make the app more specific and compelling to a smaller group of users, you can raise the price. But if you raise the price you usually also cut down volume.

This isn’t to say that you can’t come up with a targeted app that you can sell at a decent price, but also yields a good audience for advertising and affiliate programs. After all that’s what magazines do. They’ve managed to charge for buying the issue off the newsstand, but also take advertising money from companies who want a presence in that issue. However, I frequently hear the options expressed as either/or by app developers. They feel if they charge for the app they shouldn’t be running advertising. I understand where that sentiment comes from, but it’s not the way most other areas of business operate. I wish my cable provider didn’t run advertising in exchange for my paying for the service, but unfortunately that’s not the case.

Our first panel discussion at Mobile 2.0 developer day is going to explore a bunch of these issues, in addition to some talk about alternative distribution models I’m sure. Peter from Rovio is going to weigh in on how Angry Birds has managed to hold the #1 paid app in the app store for just about every region. They’ve sold more than 6.5 million of the paid application to date. Chris Dury from GetJar is also going to be present, he had some fantastic commentary at a recent Mobile Monday when he summarized the options available to developers as get featured, get targeted, or get viral. Sean from Flurry is going to be weighing in not just on the AppCircle system they have setup for promotion and monetization in-app, but also bring some numbers to the conversation from the huge base of info Flurry collects on the analytics side. Jahanzeb from iTeleport is going to represent the targeted side of the house, discussing how their app makes more than $1k a day without ever appearing in any charts at all. And finally Raj Singh is there to moderate, he’s worked with big companies, startups, and frequently his own efforts to find novel distribution and monetization models for consumer mobile apps and services.

If you want to join us at Mobile 2.0 use the promo code ‘friends’ for a 20% discount off the normal ticket price. Hope to see you there!

The comments about Silicon Valley and Madison Avenue just starting to realize the potential in mobile advertising with the iPhone because it’s the first time they’ve actually seen it themselves, that rings really true. Lots of us thought the iPhone was going to take a long time to make a difference, if it made a difference at all. We were so very wrong about that. Just goes to show, being “in the industry” doesn’t really mean crap in terms of your ability to predict what’s going to happen when there’s a discontinuity. That discontinuity that happened in mobile is now working it’s way through complementary and adjacent markets. Should be an interesting few years coming up.

I haven’t been using the service actively for my sites (the main one I would think about using it on would be Mowser, which is ummm.. headed in a different direction these days), but I have sat down with the system and poked through it using other folks data. In my opinion one of the most important set of stats is around number of users over time and how long they stay. How many users do I have in a day? How many of them are returning users vs. new users? What are the “front door” areas of my site that drive new users, and how often do those users visit other areas? Stuff that AdMob has thought through both from the publisher and advertiser perspective and is well represented.

The area I’m most curious about is the device capability breakdown. Custom iPhone sites are relatively common because of the marketing and discussion that goes around that particular device. But I’m not sure that anyone has ever really exposed the additional device segmentation for the off-deck folks. Of the folks that are looking at device breakdown many that I talk to see Nokia N-series devices as the extreme front runners in terms of their total number of pageviews. While the browsers in those devices don’t have the same emotional impact that using Safari on the iPhone does the first time, I do think the devices are successfully driving mobile web usage. Will exposing some of the additional info about devices drive additional middle web style site development? It’s a question not just of device penetration and capability, but of developer mind-share and impact of user interface. There’s a real ecosystem around the iPhone, go to developer events and people are “dabbling in iPhone development”. No one is “dabbling in N-series development.” This is why I’m still an engineer by trade, I just don’t understand how Apple manages to do these things. Much respect.

Stepping up a level however, I would have really liked there to be some public consensus around how to count users and identify uniques – with compliant products following on. But one of the principles I’ve come to understand recently is that it’s easier to build something that works and let standardization form around existing practice than it is to try to drive unity from diverse groups through committee discussion. I’m hoping that what happens is that the practices that AdMob has put into place will drive behavior like the content adaption manifesto Luca put together helped to identify destructive behavior across the environment and correct it. There’s certainly the mass there to make an impact.

Japan is already a booming market in terms of mobile advertising, so it’s a logical place to start. What I’m really curious to see however is how enabling advertisers in some of the less mainstream areas where mobile is popular would change the network. In theory you should have a big group of “local advertisers” that should be interested in any chunk of media you put out there. And here I mean “local” in the sense of in the same country, not in the sense of hyperlocal location based services kinds of stuff. I was lucky enough to spend a bit of time in Mumbai, and I was surprised both by how much mobile marketing there was (normally in the form of SMS tie ins for print, outdoor, and television ads) as well as the spirit of the folks I met at the local Mobile Monday.

I’m curious if the potential advertisers in those areas have started looking at the advertising networks to bring in their users. There was a lot of talk at the MoMo I attended about data usage not being high in India. However the AdMob metrics reports place it very high in terms of number of pageviews. I wonder if there’s a perception issue that could be cracked. I wonder if the current marketing providers in the area are working to protect their revenue stream for as long as they can and seeding misinformation. I’m sure all the SMS marketing going on there feeds back into the carrier pockets, and I’m not sure data revenue always would (they have a lot of flat rate data from what I’m told). I wonder, I wonder…

Omar took the time to poke around and ask Russ what I was lusting after but didn’t already have, and the N810 was at the top of the list. As if I didn’t already have enough good stuff to say about the folks there, they went and piled even more icing on the cake. Thanks everyone!

I’ve already screwed it up, but then fixed it. So it’s all good. Just want to lay down the order of operations in case anyone else runs across it. My problem was pretty much the same as the one described here, after updating the firmware the internal memory card was getting mounted read-only. I discovered this because I was trying to install apps using the package manager and it was failing. The app manager log viewer showed the errors as /media/mmc2 being read-only. I think this was related to me setting up swap on the internal storage card and it being on when I did the firmware upgrade.

The kicker was that I had yet to install becomeroot or SSH, and I hadn’t reset the passwords. So how do you unmount and reformat the internal card on the N810 pre-hackery? Here it is:

• Enable RD mode using the flasher. Despite the indication to the contrary on the HowDoIBecomeRoot page, you can enable RD mode on the N810 to enable access to gainroot. Just run ‘flasher-3.0-static –enable-rd-mode’ using the same process described for firmware updates (plug in the N810 with the power off, run command, power on while holding home key).
• Now you should be able to use ‘sudo gainroot’ from xterm (which is distributed with the base OS, interesting) to get root access to the device.
• Unmount the internal card using ‘umount /media/mmc2′.
• Reformat the internal card, which will destroy all the data on there. For me this wasn’t an issue cause I had yet to put anything at all on the device. The command I used was ‘fsck.vfat -a /dev/mmcblk0p1′, which is a slightly different device name than given in the Internet Tablet Talk forums, I think there’s just a typo in that version.
• Reboot the device and run ‘mount’ from the command line, you should see /media/mmc2 as read-write mounted now.
• Do a little victory dance.
• I installed openssh and reset the passwords for both the standard user account and root account.
• Disable RD mode using the flasher using ‘flasher-3.0-static –disable-rd-mode’. Power consumption and response times seem to really suffer with RD mode left on, so I always turn it back off now.

Seems like a really nasty firmware update bug too, if I weren’t prone to hackery of the sort or attentive with respect to what’s causing errors I could have easily assumed an incorrect root cause for these issues. I was already on my way down the path of cursing the package repositories for including screwed up dependencies before I realized the app installer log indicated a completely unexpected error from the underlying tools. The package manager should really throw a better error for something like that.

I had a conference call with the participants today, it should be an interesting discussion. We spoke about some interesting stuff, like how does the mobile advertising market in evolving areas like the US and Europe compare to the setup we see in more mature markets like Japan, are there any particular technical hurdles that need to be tackled before the advertising market can advance, and who’s really using mobile advertising currently as part of their media plan. Should be fantastic. Just don’t believe all the hype you read online, I don’t have all the answers. Only about 80 percent of them ;-) The other 20 percent I’m hoping will fall out during the conversation. Come down and join in, hope to see you there.

But now that we’ve succeeded in the initial battle, life at AdMob is changing. It’s no longer the kind of place where the fast and loose brand of programmerizing I practice should be the norm. And the challenges in front of the company are no longer related to proving that the model works and the ecosystem can support it, but rather that they can hold onto and grow their lead as the number one mobile advertising network. A great challenge to be placed in front of, but not really one that exactly matches up with my disposition and role in the world of mobility overall. So it’s time for me to step aside and let the AdMob engineering crew evolve. I wish the folks at AdMob the best of luck! It’s a fantastic service backed by a great team, and when the monetization question comes up during my next adventure AdMob is going to be the first place I turn.

So now comes the question of which way to turn to find the raggedy edge of mobile? I like somewhat unique work environments. Three parts programming, two parts white knuckled thrill ride, two parts scaling issues. Seems like there’s still a ton of stuff that could be done in consumer mobile services. As far as mobile data services have come in the last year, we’re still really at just the start. The interest is out there, but people need to provide the right services via the right channels to keep the growth going. Seems like that would be really difficult to do right, so it’s got my attention. The hunt is officially on!

The questions of web app vs downloaded application might actually get somewhat obscured by the likes of Android and Ovi. A focus on services instead of applications tends to blur the line somewhat. Jaiku is an excellent example there. They have an S60 app, you can use it via IM or SMS, there’s a widget for Widsets, and a mobile friendly web version. Still, I think there will be some consolidation over time where some preferred way exists for covering the maximum number of handsets without having to develop a half dozen different versions.

Personally I think that’s going to be based on the mobile web instead of downloaded applications. However that means that the mobile browser really needs to mature a lot to make it as viable of a delivery platform as desktop browsers are now. And I don’t necessarily mean mobile AJAX here, I mean that development for mobile browsers needs to be a deterministic process. It can’t be this crapshoot with standards support and capabilities all over the map.

Which leads in to the issue of will the mobile web continue to exist as devices get better. There are at least two different issues in there: there’s the technical issue of coming up with markup that will render on a mobile device and an application level issue of delivering information tailored for a more limited device. There’s a lot of attention going into the technical side of the equation. Stuff like transcoders meant to strip out extraneous data, clean up tagging, and format the info in a more usable layout for a mobile device. And there are W3C efforts to define markups that can be supported across a wide range of devices.

However, even if the markup ends up being the same, assume that my phone was able to render any web page just well as my desktop browser could, does that mean the “death of the mobile web”? Would it still make sense to do two versions of the web application based on the user’s modality? Not based on if they’re accessing from their phone or their desktop, but based on if they’re using from their phone will seated on the train or using on their phone while wandering around a strange city looking for their friends.

I think the distinction will always remain, but there are definitely questions about where that “other version” comes from. Does it get produced entirely by the application provider? Or do they provide some extra tags (like the fb:mobile tag in FBML) that give hinting to other services which still provide a degree of adaptation? Right now the only realistic method is to make the two versions yourself. The problem of adapting a web user interface just isn’t well understood enough for someone to be able to factor out common parts and expose a meaningful set of hooks and capabilities. That’s still up for grabs really. There’s still a lot of blank space and potential in the market. Plenty of room for great ideas and plenty of unpopulated areas.