We’ve all seen charts like the one above from StatCounter, often accompanied by headlines saying things like “the iPhone is responsible for 64% of all mobile traffic”,  “4.5% of all web traffic comes from mobile browsers”, or “smartphones are responsible for over half of all mobile page views”.

These reports make interesting reading but I’m not sure how accurate most of them are. The data usually comes from analytics services like Quantcast, StatCounter or Net Applications. These services do a good job of reporting the data that’s available to them. But I believe that mobile traffic, and especially traffic from basic feature phone browsers  is underrepresented in these reports. That’s because  they rely on web publishers to insert a bit of markup into every page.  The code generally involves an invisible image (a “web beacon”) or some JavaScript.  The trouble is that web analytics services primary targeted at desktop publishers invariably under count mobile traffic.  Here’s why:

• Feature phone browsers can’t display many desktop pages and thus aren’t counted by sites without mobile formatted versions.
• Many, perhaps most, feature phone browsers have no or very limited JavaScript support.
• Most BlackBerrys come with JavaScript support disabled by default and many users never enable it.
• Many sites redirect all mobile browser traffic to a mobile formatted site. There is a good chance that the mobile site doesn’t include the tracking image or code.  The mobile site’s design and hosting may be outsourced to a third party like Mobify, mDog,or Usablenet which has it’s own separate statistics module. Or perhaps the publisher uses a different, mobile specific analytics service like for the mobile pages.

For evidence of under reporting take a look at the Wikipedia entry , “Usage share of web browsers“, which has a table showing the relative usage share of mobile browsers based on data from three sources.  For Decenber, 2010 the numbers where:

Wikimedia is reporting a mobile browser share that’s 86% higher than the Net Applications number. Which is right? I believe that the Wikimedia number is the closer to being accurate. It’s based on server logs from Wikipedia and other Wikimedia sites and should accurately reflect mobile visits to those sites. The big question is whether Wikimedia traffic is representative of Web traffic as a whole. I don’t know but suspect that it’s fairly typical.

The examples of Net applications tracking code that I’ve seen are pure JavaScript. That means that NetApplications probably doesn’t count devices that don’t support JavaScript or have it disabled.

StatCounter uses JavaScript plus an image beacon so that it should work even on devices without JavaScript. But it still depends on publishers and web masters to insert the tracking code in all pages, including mobile ones.

It’s important to recognize the limitations of web statistics when it comes to mobile.  In particular I’d be wary of building a business model around numbers that suggest that mobile isn’t important, or that only smart phones or only the iPhone are worth developing for.

Mobile browsing is growing rapidly as is  Smartphone market share. But there are still a lot of feature phones around and people are using them to browse the web The last AdMob Mobile Metrics Report from May 2010  shows (chart above) that feature phones were responsible for 42% of all of Admob’s mobile ad requests in May. Admob data is shewed toward the US and Western Europe, the non-smartphone share is likely even higher in the developing world.

If you are serious about reaching all mobile users don’t assume that everyone who tries to visit your site has a modern browser.  There are still millions using basic browsers that ignore Javascript, make a mess of all but the simplest CSS and choke on pages that are larger then 20-30KB! So what can web publishers do do handle all browsers? A good approach is to detect browsers, segment them into groups and adapt your pages to each group’s capabilities. Three groups is a good start;

• A rich browser group for modern browsers like Safari, WebOS, bada, Android and Opera Mobile. This group gets the full featured mobile version of the page.
• A second group of browsers like the pre OS6 BlackBerry browser, Opera Mini and the Symbian Browser that do all right with large pages and lots of images but misbehave if asked to handle complex JavaScript (or ignore it, in the case of Opera Mini). You can serve these browsers pretty much the same text and images as the first group but without most of the JavaScript dependencies.
• The last group is the basic browsers like Openwave and Obigio.  These browsers need to have large pages broken up into multiple smaller pages with only a few small images on each page.

Sure it’s easier to just create an iPhone/Android version of your site and say you have mobile covered.  But do you really want to leave over half your potential mobile customers behind?