June Dershewitz on Web Analytics

Advancements in Mobile App Tracking [Or, the Mini-Me of Web 2.0]

When I got into mobile analytics a couple of years ago, I quickly realized that there were several very different ways to interact with (and therefore, to measure) the medium: there's the mobile web, and then there are mobile apps.

Mobile web - even though it's fraught with data collection problems - is easier to come to terms with as a web analyst because it's like the Mini-Me of the existing desktop (or "fixed") web. We know exactly what to expect from the mobile web, it just has a smaller-than-normal screen and lame browsing technology.

Continuing with the Austin Powers analogy, mobile apps are like the Mini-Me of Web 2.0. Since the "Web 2.0" buzzword can mean several things, in this context I am referring to rich internet applications. When RIAs first became popular on the fixed web, analysts had to shift our thinking away from measuring page views to measuring events. The same holds true with mobile apps, where we now have no tiny page views, just tiny events.

When I've written about measuring the mobile web in the past, I've always intentionally stepped around the issue of mobile apps because they seemed like a bit of an edge case. Well, those days are over. With the rise in popularity of the iPhone and similar devices, we see an increased awareness of and interest in mobile apps. You get your new phone and immediately you want to download apps. Back in September 2009 Apple announced that more than 2 billion apps have been downloaded from their app store. Wow.

As a web analyst, this is why I care:

Every time a new mobile app is born, there will come a point when the marketing managers and usability specialists and business executives want to know how customers are interacting with their mobile app. They will then turn to their resident web analyst and ask the classic, "So, how'd we do?" to which the web analyst will likely reply, "Uh ... we're not tracking the app."

The "we're not tracking the app" excuse won't fly much longer. There are many ways to track your mobile app, it's just a matter of realizing that you need to have a plan and convincing your development team to implement it. Unlike tracking a static page on the fixed web, it's not as simple as tacking on a snippet of javascript code. As stated earlier, it's more like tracking a Flash app on the fixed web - you have to use real brainpower to determine which events you consider significant, and then you need to embed the tracking within the app so that the appropriate events are logged as they occur.

In the past I've been involved in Semphonic client projects where we used the Omniture data insertion API to push mobile app activity to SiteCatalyst alongside related fixed web and mobile web activity. Omniture is definitely a viable solution for tracking mobile apps; within the past 6 months they've expanded the list of smartphone platforms whose apps they're able to measure. I have also recently learned about stand-alone mobile app tracking applications like Flurry and Pinch. I welcome your blog comments if you've used these products or others like them.

The big news, though, is that Google Analytics has entered the running as a mobile app measurement solution. Last month GA announced a set of new features, including the ability to measure iPhone and Android mobile apps. GA doesn't cover as many smartphone platforms as Omniture (yet), but then again it, uh, costs a lot less than Omniture. In another recent official GA post highlighting app tracking, they offer up a video clip case study:

The video interviewee says mobile app tracking has led to insight about popular features, which in turn has informed product development and usability initiatives. It's a useful story no matter which tracking tool you happen to use (or plan to use).

Lesson: the minute you get the idea to build a mobile app, take a breath and then think about how you're going to track it. You have a number of options. None are super-simple, but they're all manageable and will meet an important need down the road when your business executives want to know, quantifiably, how customers are using the app. Good luck!

[PS For those of you following my blog post series on functionalism, I will get back on track in my next post. I could not resist this tangent.]

Mobile Analytics Whitepaper: Written by Me, Available Free

I'm pleased to announce that - as a joint effort between Semphonic and our partner, Tealeaf - I have published a whitepaper on mobile analytics and customer experience management (CEM). You can get the whitepaper at Tealeaf's site or write to me directly (june@semphonic.com) if you want to know more.

Working with Tealeaf has given me a new appreciation for the value of CEM, and I believe they've got a very unique offering when it comes to mobile web usage analysis. So have a read through the whitepaper. I welcome your feedback either privately or as comments on this blog.

Mobile Analytics: A Personal Story

"The mobile phone is the most personal device you’ve got, aside from your keys and your wallet," observed Bob Schukai during his X Change session on mobile technology a few weeks ago.

By way of illustration he had each discussion participant tell a story about our own favorite mobile feature or technology. The stories were as unique as the individuals in the room, but they all fit into the idea that mobile is "personal." I can't resist; here's my story:

I live in a dense, urban neighborhood in San Francisco. Like a fair number of this city's residents, I don't own a car. I love the fact that I can get around locally and do most of my daily business by taking the subway, riding my bicycle, and walking.

When I do need a motor vehicle I use a car-sharing service called Zipcar. They've got cars all over San Francisco - all over North America, actually - that I can rent on the spot for an hourly fee. The closest Zipcars live 3 blocks from my house, which isn't bad considering how impossible it is to find parking here. Once I've made a reservation all I have to do is wave my magnetic membership card in front of the car; the doors unlock and the keys are inside. Gas and insurance are included. I get in and drive away.

Here's where mobile technology enters the story: Zipcar has a great mobile web site. Once I log in on my phone's browser I'm able to make, extend or cancel car reservations. This is incredibly convenient because I might not know I want to extend a reservation until I'm actually out running errands, without access to a desktop computer. If my car is available I can extend my reservation and pay my fee with a few clicks on the mobile web site. Every time I do this I think, "Zipcar just made money, AND they made me a happy customer."

Their mobile technology even amazes me when things go wrong. I recently reserved a pickup truck so I could move some furniture. When I went down to get it, though, the truck was missing - the guy who reserved it before me had failed to return it.

Right there in the parking lot I launched Zipcar's mobile site, found their customer service information, and clicked on the phone number. It auto-dialed on my phone (wow!), and when I got connected the system was smart enough to link my phone number with my Zipcar account number (wow!). I was so amazed that I almost forgot how mad I was. The customer service rep quickly found another truck for me in a nearby lot and I was on my way. I remain a happy customer.

Since I measure online behavior for a living I can't help but wonder if, how, and to what end Zipcar is tracking their mobile site usage. Are they optimizing mobile sales conversion rate? Are they watching satisfaction ratings for customers who use mobile features? Perhaps. If they're not now they will be in the future.

That's my story. Half the people in the world now have mobile phones, says Bob Schukai, and each one of us has a story. We are beginning to use the mobile web to purchase things, to locate things, to get customer support, to get entertained, you name it. As web analysts we must take note; mobile analytics is poised to play an important role in this revolution.

[See also my post on real-world challenges of mobile analytics.]

Real-World Challenges of Tracking Mobile with Page Tags

[I offer a more-formal-than-not article based on recent real-world experience doing mobile analytics for a Semphonic client.  You will be interested if you are a traditional web analyst who soon faces the added responsibility of measuring mobile.

For what's bound to be an engaging discussion about mobile analytics, come to the X Change Conference and attend Bob Schukai's 2 huddles on the topic.  Bob advised me as I wrote the following article and I was really impressed with his depth of knowledge about the mobile space.]

Real-World Challenges of Tracking Mobile with Page Tags

As the mobile web grows in popularity, so does the need for mobile measurement.  When put to the test, say, with a basic mobile campaign, we find that mobile measurement has not yet reached the level of maturity that we have come to expect from traditional web analytics.

If we treat mobile measurement like traditional web measurement we face challenges right away, starting with data collection.

Many popular web analytics tools available today – like Omniture and Google Analytics – rely on JavaScript tags for data collection.  Using this method, site owners place a tag on every page they wish to track; when a visitor accesses a tagged page, event-level data is sent back to the web analytics tool. 

Tracking mobile web in this manner is problematic, though, because mobile browsers do not reliably support JavaScript.  Some tag-based web analytics tools provide a fallback tracking method when JavaScript is not present – namely, a hard-coded 1x1 pixel image request that collects a subset of the standard event-level data.

An increasing number of mobile-specific tracking solutions are surfacing on the market; they offer arguably more robust data collection methods than traditional web analytics tools.  [My colleague Phil Kemelor has written a nice series on the mobile analytics vendor landscape, if you're interested.] However, despite known deficiencies, site owners may still opt to use a traditional web analytics tool for mobile measurement simply because it’s already an accepted business standard for tracking existing web content. 

In this article we will outline some of the challenges faced when using a tag-based web analytics tool adapted – by way of an image request – to measure mobile. 

An example

Consider two very similar online campaigns aimed at promoting the download of an application: the first campaign goes out as an email blast on traditional web, and the second campaign goes out as an SMS blast on mobile.  Beyond the difference in screen size, these two campaigns look a lot alike: a message, a click, a download.  But, when it comes to measuring the effectiveness of each campaign, mobile brings a whole new set of challenges.

Using this example – a pair of simple campaigns – we will illustrate common mobile measurement issues concerning campaign clickthroughs and downloadable files.

How do we track campaign clickthroughs?

In our campaigns, site-side tracking begins the moment someone clicks through from the message they receive to the landing page on the site.  This tracking process is well-defined on traditional web, but less so on mobile.

Campaign clickthroughs are typically tracked using a code appended to the query string of each URL.  When a visitor clicks through to the site, the campaign code gets collected by the JavaScript tag on the landing page and is then passed on to the web analytics tool.  Without the use of JavaScript, a bit more effort is required.

On mobile, and with image requests for data collection, we cannot easily intercept campaign code query parameters on URLs.  As a workaround, unique landing pages can be set up to track traffic from each campaign.  This approach, although it works, does add a layer of complexity to the campaign creation process beyond what we would normally do to track campaigns on traditional web sites.

How do we track downloads?

The measure of success in our campaigns is the download of a file.  Once again, established tracking techniques on traditional web must be re-evaluated on mobile.

Traditional tag-based web analytics tools track downloads at the moment the visitor clicks on a link to get a file.  This counts downloads initiated, not downloads completed, but it is a concession we’re willing to make in return for the convenience of tag-based tracking.  [For more on this somewhat-sticky subject see my recent post on downloads and page tags.]  However, since link click tracking requires the use of JavaScript, even this limited functionality is lacking on mobile.

On mobile, and with image requests for data collection, we must make do by treating the page just prior to download as a signifier of the download itself.  This method will necessarily inflate the number of downloads, though, since it’s entirely possible to back out of the process before actually requesting the file.  In this case, clear communication to data consumers is recommended in order to set expectations about data quality.

After all that, just the basics

The tracking techniques described above provide the absolute bare minimum we need in order to measure mobile campaign effectiveness, namely page views of the campaign landing page and downloads of the file.  Tracking becomes more problematic if we hope to get accurate visit and unique visitor counts; mobile browsers do not reliably set cookies, and we are left with very weak rules for visitor identification.

The lesson learned, in comparing very similar activities across traditional web and mobile, is that mobile requires somewhat more effort just to get the most basic tracking in place.  While we need not reinvent the wheel as we move into this new medium, mobile does force us to reconsider some of our fundamental assumptions about web measurement.