Mobile and video tracking challenge the Web analytics

It’s been 15 years since the first Web servers generated the first traffic logs. And ever since, we’ve been trying to make sense of mysteries within. Where do our Web site visitors come from? How do they behave? Why don’t they do what we want them to do?

Over time, a robust Web analytics technology marketplace evolved. Vendors came up with new approaches to gathering a wider set of data, most notably JavaScript page tags coupled with cookies. Recent years have seen innovations in the way all that data got reported, with an increasing emphasis on visitor segmentation and campaign analysis. And finally, we’ve seen the meteoric rise of free analytics services from Yahoo and Google.

As the Web has changed, visitors’ experiences and needs have changed apace. Today, mobile and video tracking have become the new frontier. And what a frontier! Tracking what mobile users actually see and do, and how much of a video stream the average viewer actually deigns to watch, have become essential metrics for many Web site marketers.

But the technology behind this is not trivial. CMS Watch recently completed a detailed customer study of the problem and found a variety of different approaches and methodologies among the vendors we evaluate. It also turns out that tracking mobile and video usage represents a particularly thorny challenge for the free services, and may be driving some customers to supplement their current analytics solution with offerings from niche vendors.

Mobile analytics is now a marketplace

When it comes to measuring Web site effectiveness, analyzing traffic from mobile phones is the next big thing. Why? According to the research firm IDC in a June 2008 study: "Roughly 40 percent of all Internet users worldwide currently have mobile Internet access … and [the number] is forecast to surpass 1.5 billion worldwide in 2012." Add to this the fact that more mobile phones are sold than computers, and you get a sense for the sea change that is taking place in Web usage.

Unfortunately, getting good mobile Web analytics data is akin to getting good fixed Web analytics data in 1996. On the plus side, some emerging niche vendors, such as Bango, AdMob, Amethon and Mobilytics, have sought to stand out in the market as targeted solutions. Those are venture-fueled startups with big ambitions, but very new technology. In the meantime, established commercial Web analytics vendors such as Omniture, Coremetrics and Webtrends all jumped into the fray during 2008 with competitive offerings to cover mobile access. The no-cost darlings of the market, Google Analytics and Yahoo Analytics, have not yet rolled out serious mobile analytics solutions.

The challenge of data collection

Regardless of the solution, measuring mobile access presents some difficult technical challenges to any analytics vendor.

The biggest challenges revolve around data collection, which is highly inconsistent due to the fact that JavaScript and cookies—as common constructs for tracking Web traffic today—are not accepted by a high percentage of existing phones. Industry vets disagree about the specifics, but it is generally assumed that most phones do not accept JavaScript and very few devices at all—including "smart phones"—accept cookies.

The most common approach to data collection then is to employ a specialized image tag. Log files and sniffers are also used as data collection alternatives but are not nearly as common, and the data they collect is much less rich.

A mobile beacon

An image tag or "beacon" comes in the form of a 1x1 pixel image embedded in each page with parameters set by your server. When a mobile phone browser requests the image, as it is rendering the page, data is passed to the Web analytics solution collection servers.

Image tags differ from JavaScript page tags because they are essentially a blank slate that requires you to explicitly specify all Web visitor behavior variables—such as referring URL—within the tag. That is done through the use of query strings.

Even though all vendors using image tag data capture provide documentation outlining how to construct the tags, you’ll still find it time-consuming to hand-code the whole image tag. As with JavaScript-based tagging, your life becomes much easier if you can populate variables out of a content management system.

Each vendor’s formats will differ, but here’s an example tag:

<img src="http://XYZvendor.net/CustomerID/CampaignID.gif?page= YourPageName&RandomNum=0123456789" alt="" height="1" width="1" />

The tag calls a blank image from your analytics vendor, with your customer number and various other parameters attached. For example, it might pick up the page name if you want to report against that. A random variable could get assigned to reduce pervasive image caching. Which brings us to our next topic ...

Embedded image tracking is far from infallible. Some things that can go wrong:

• Mobile browsers and sometimes carriers will aggressively cache images; some analytics vendors will have you insert randomizing parameters to try to mitigate that, but they may not always work.
• The carrier may attempt to transcode images to reduce bandwidth; that may or may not affect tracking.
• Like JavaScript tags, the image tag may load last, which means a visitor may have moved on to another screen before the image loads.
• Last, but most importantly, unlike JavaScript, image tags are static. They cannot capture events, and as such, they cannot track things like submits, downloads and other transactions. Here again, vendors have workarounds that you are likely to find a bit lacking, often entailing redirects from their own servers.

Parsing headers

Many of the basic metrics associated with mobile usage focus on handset, manufacturer, browser type and screen size, as well as potentially carrier and perhaps even phone number. Most of the time, your vendor will attempt to extract as much of that information as possible from the "header" of a request from a mobile device.

Header data will vary according to manufacturer, device and carrier, and potentially preferences set by the individual device owner or national privacy laws. That’s where mobile analytics vendors come in: They claim to have the latest and greatest matrices of that data.

Here’s part of a header from a Windows Mobile device, showing some potential values.

HTTP_USER-AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.1)

UA-pixels: {for example, 240x320}

UA-color: {mono2 | mono4 | color8 | color16 | color24 | color32}

UA-OS: {for example, Windows CE (POCKET PC)—Version 4.1}

UA-CPU = {for example, MIPS R4111}

UA-Voice = {TRUE | FALSE}

Handset and manufacturer identification requires the translation of header information through the Wireless Universal Resource File (WURFL) database and that of DeviceAtlas, which many consider to have a more current database than WURFL. You don’t need to access those datasets; the idea is that your vendor tracks it for you.

But are they unique?

Savvy Web analysts know that the key metric is not overall visitor counts and activity, but unique visits. In the mobile environment, tracking unique visitor behavior has remained a rather nebulous exercise. Again, many phones do not accept persistent cookies—which help traditional Web analytics systems distinguish you from your colleague surfing in the cubicle next to you.

The mobile analytics specialty firms seem to spend a lot of time bickering among themselves as to who has the best workaround here. All the vendors appear to use one or several different methods for identifying unique visitors to include cookies, header information associated with the phone, browser and operating system combinations, modeling and carrier translation tables.

Indeed, the niche vendors have in common that they claim to have a proprietary method for culling unique visitors. We understand from customers who have tested those solutions that the numbers amongst all are widely different, leaving us skeptical whether the new breed is any more accurate than what’s currently offered by the traditional vendors who are active in that area. For standardization, you’re better off looking at simple numbers, such as visits and page views, or conversion events if you have any associated with your mobile Web applications.