Posted by Gary Angel

At the last eMetrics, Greg Dowling of Nokia and I did a presentation on Mobile Measurement and the work we’ve been doing in that area. Greg is leading a Huddle on the same topic at the upcoming X Change Conference, and X Change is the perfect venue for this type of topic because it’s mobile measurement is so new, so fractured and so important that the best way to learn about what’s happening there is to talk with people on the front-lines of trying to do it. Leading up to that, I’m going to do short series on Mobile Measurement.

First some quick background. A good part of what makes mobile a challenging measurement environment comes from some pretty basic limitations on the infrastructure as it currently exists. What ought to be an environment even more measurable than the fixed web often, in practice, turns out be significantly less open to any form of reasonable measurement.

Among the many challenges you have to worry about with mobile measurement, the problems with javascript tagging are probably the most important. Mobile environments being what they are, not every device supports javascript and cookies. Of course, most heavily used internet phones do. But even if phones support javascript, the weight of javascript tags is a significantly bigger concern than it is on the fixed web. Mobile pages tend to be much lighter than fixed web pages for a reason – and adding weight with a tag is definitely a drawback.

So for both portability and weight, companies like Omniture that use a javascript tag usually recommend an image tag for mobile. There’s nothing very mysterious about an image tag. When you use a javascript tag, all it’s really doing is using some helper functions to append parameters to a existing template image and then making an image request. You assign a bunch of object variables, then call the builder function and it assembles the image request and fires it. If you’re using a tag-based system, you’re already using image requests.

An image tag system takes that concept and instead of loading the javascript and using it to customize the image request, simply inserts a fully-customized image into the content as it is served. This server-side configuration of the image request is a little different that what’s involved in a javascript tag but the end result is the same.

These image requests will work in any browser and any system and, of course, they are extremely light-weight. I’ve had engineers tell me after they’ve looked at server-side image requests that they’d rather do fixed web measurement the same way!

But there are some drawbacks to image tags. The biggest and most important is that an image tag is firing server-side – so you have no opportunities to do client-side customization. That means tracking forms, click-handlers, and campaigns are all problematic. Anything that happens client-side is essentially invisible.

There are some solutions for these problems. Omniture, for instance, will let you target an Omniture redirect with an image href that will record the measurement of a link click and then make the actual call. But this isn’t a system most IT departments will fall in love with.

There’s also the problem of image length. Unless you’re fairly technical, you might not even realize that image requests (which form the basis of all tagged measurement) have a size limitation in every browser. For most versions of IE, for example, the limit is a little over 2000 characters. That’s pretty long, but there are times when you can exceed it and if you do, your image request just fails. That means you don’t get any measurement.

If you load up your tags with lots of variables (especially long text strings), it’s not all that hard to exceed the 2000 character limit – and, since the failure is situational, you’ll probably never even realize it’s happening.

But in mobile, there can be much shorter limits on the length of image requests. Of course, this applies to both javascript generated image requests and server-side image requests. If you move your existing javascript tags over into mobile and you have a fairly rich measurement environment, there’s a pretty good chance some of your image requests will be too long.

There are some techniques that Omniture provides to help with shortening mobile image tags. You can use shortened versions of some variable names, you can pass some items in the cookie, and you can use parameter assignments to pass a value into more than one variable (as is extremely common with Omniture props and eVars).

All this helps, but it introduces some significant complexity as well. In particular, we’ve found that developers often need help getting started with mobile image tagging and that they frequently trip up using features like parameter assignments (the implementation of which is rather poor).

To help with this, we’ve put together (it was Jon and Breen mostly) a clever little Excel tool that generates mobile image tags for Omniture from a basic measurement specification. It shortens the image requests as much as is possible and it calculates the length so that you get fair warning if the requests are getting too long.

It even has a deconstructor component that takes an existing image tag and parses it back into a measurement specification. It’s a surprisingly useful feature for debugging.

We’re going to be releasing it on our website soon (for free) – and in my next post, I’ll show how it works and show some screen shots from it. Though a simple application, we’ve found it quite handy and a great way to make sure your developers get into mobile measurement with the right foot forward!

Comments

This entry was posted on Monday, August 17th, 2009 at 9:23 am and is filed under Analytics, SEO, Search. You can leave a response, or trackback from your own site.

About the Author: Gary Angel is the author of the "SEMAngel blog - Web Analytics and Search Engine Marketing practices and perspectives from a 10-year experienced guru.