Top 5 Mobile Implementation Gotchas

Six months ago, while on a High Fidelity kick, I posted on the top five JavaScript implementation gotchas (i.e., common and easily avoidable mistakes) that I have seen during my time working with Omniture customers. But what about non-JavaScript implementations? In his recent interview on CNBC, Josh James pointed out, “Our customers are asking us, ‘Can you do more with mobile?’” My colleague, Ed Hewett, discussed trends showing the growing importance of mobile measurement previously on his blog. And as the world heads in this direction, the number of questions I receive about mobile implementation and reporting is rising, so it’s time to discuss common pitfalls of mobile implementation—and how to avoid them.

1. Don’t assume that all of your mobile users execute JavaScript

I don’t know what I would do without my JavaScript-enabled smart phone by my side, but not everyone shares my enthusiasm for constant connectivity and script execution. Measurement on mobile-specific sites should not be implemented using JavaScript. Omniture provides several approaches for implementing these initiatives without JavaScript including hard-coded image requests, server to server HTTP requests, and the Data Insertion API.

But what if you want to track mobile usage of your non-mobile web site? One option is to implement a hard-coded image request on your site using <NOSCRIPT> tags just below your SiteCatalyst JavaScript tags. For example:


/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
<noscript><a href=”http://www.omniture.com” title=”Web Analytics”><img
src=”http://bengaines.112.2o7.net/b/ss/gainesweb/1/H.20.3–NS/41782378?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&c1=blog”
height=”1″ width=”1″ border=”0″ alt=”" /></a></noscript>


If you don’t like this approach, but would still like to seize the mobile opportunity for your business, some excellent guidance can be found in a previous blog post by Adam Greco.

2. Don’t rely solely on cookies—and especially not on third-party cookies

Mobile measurement actually has some huge advantages in capturing visitor data. HTTP requests from a mobile devices often include special carrier headers that SiteCatalyst can use to distinguish visitors from one another. Because these parameters do not change and cannot be disabled or “cleared” (a la browser cookies), they are much more effective at identifying mobile visitors. And who doesn’t want their mobile visitor data to be as complete as possible?

To ensure that Omniture is leveraging these special headers first where available, make sure to include /5/ instead of /1/ in the path of the request. For example,

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&c1=blog" height="1" width="1" border="0" alt="Omniture image request" />

This tells SiteCatalyst to use these headers first, and to set cookies only if the headers are not available (where as /1/ causes cookies to be set and disregards header identification). You’ll get the same effect using the Measurement Libraries for JSP and PHP (which handle writing the Omniture image to the page—perfect for mobile!) to build your image requests by setting s.mobile = true, as explained in the documentation available in the Online Marketing Suite.

Beyond this, keep in mind that many mobile devices (such as the iPhone) have default settings configured to reject third-party cookies. Therefore, even if primarily using headers for visitor measurement, implement a first-party data collection domain for your mobile site. Using a third-party domain dramatically decreases the likelihood that a mobile device will play nice with your analytics efforts.

3. Don’t forget your Traffic Sources reports!

It’s nifty that a standard, out-of-the-box SiteCatalyst JavaScript implementation will automatically capture referrer data. This information serves as the basis for all of the reports in the Traffic Sources section of SiteCatalyst and Discover, and you don’t even have to do much of anything in order to populate the reports. Mobile implementation doesn’t capture this referrer information quite as easily, although making sure that you grab this data isn’t terribly difficult.

Your server will have access to the referrer (in PHP, for example, you can use the $_SERVER['HTTP_REFERER'] variable), so you can simply write this value to the page in the image request. Here is an example of how this might look when finished:

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&r=http%3A%2F%2Fwww.google.com/search?q=little+saplings+handmade+toys&c1=blog” height=”1″ width=”1″ border=”0″ alt=”Omniture image request” />

I should also mention here that the Measurement Libraries do this automatically.

The result is the ability to attribute mobile conversion and engagement to specific referrers, including search engines. Very important stuff!

4. Don’t leave out image attributes

The image tag should have attributes. Make sure to include a height and width of at least one pixel. You never want a border (I mean, unless you want a nice little box around the otherwise-transparent image returned by the Omniture servers), so set border=0. And don’t forget the “alt” attribute, which you can set to anything at all. Each of these is automatic when using s.mobile=true in the Measurement Libraries. Some devices will not successfully request and receive the Omniture image if these attribute are omitted.

5. Ensure image request parameters follow established naming conventions and syntax

As developers can attest, syntax is critical in implementation, and mobile implementation is no different. However, even experienced Omniture developers can get tripped up when setting up a mobile site because, rather than s.pageName, s.eVar1-50, s.products and the rest of the familiar group of variables, you are building variables directly into the query string of the image request using shorter, very specific parameters.

The full mapping of parameters to SiteCatalyst variables is available in published documentation, so I won’t reproduce it here. I will, however, issue a word of caution: make sure that you are using the desired parameter name exactly as written in the documentation! Take a look at the two image requests below.

Request 1

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&r=http%3A%2F%2Fwww.google.com/search?q=little+saplings+handmade+toys&c1=blog” height=”1″ width=”1″ border=”0″ alt=”Omniture image request” />

Request 2

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&r=http%3A%2F%2Fwww.google.com/search?q=little+saplings+handmade+toys&cl=blog” height=”1″ width=”1″ border=”0″ alt=”Omniture image request” />

Identical, right? Mostly. The difference is that the first request has “c1=blog” as a parameter. This would pass a value of “blog” into Custom Traffic (s.prop) 1. The second request is definitely not what the developer intended; there, we have “cl=blog” instead of “c1=blog.” The “cl” parameter controls cookie lifetime (the maximum amount of time that the s_vi cookie can remain on the user’s device. This variable is almost never set manually, and the default is five years; by inadvertently setting the cookie lifetime to “blog” (which makes no sense) the actual lifetime will be the session, rather than five years. This would, of course, dramatically inflate visit and visitor metrics and kill any conversion variable persistence every time the user closed his or her browser app. This might be an extreme example because “c1″ and “cl” happen to look so similar—the more common outcome, assuming that the erroneous parameter did not map to an actual variable—would be missing data in individual reports. Still, that outcome can be just as disastrous to your mobile initiatives. So make sure that the parameters in the request match the variables you intend to populate!

Okay, so this “top five” list probably isn’t as fun or philosophical as those recounted by Rob Gordon. . . but I can guarantee that it’s much better at helping you avoid pitfalls of mobile implementation in SiteCatalyst!

As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter, FriendFeed, LinkedIn, or by e-mailing omniture care [at] omniture dot com.

• Ben Gaines
• 2 responses
•  Mobile Analytics, Web Analytics

• Share on   Digg Reddit Facebook MySpace StumbleUpon Propeller Slashdot Newsvine ma.gnolia
• Bookmark at   del.icio.us Technorati Google Bookmarks Yahoo Bookmarks Yahoo! My Web Windows Live Furl