Top 5 Mobile Implementation Gotchas

Six months ago, while on a High Fidelity kick, I posted on the top five JavaScript imple­men­ta­tion gotchas (i.e., com­mon and eas­ily avoid­able mis­takes) that I have seen dur­ing my time work­ing with Omni­ture cus­tomers. But what about non-JavaScript imple­men­ta­tions? In his recent inter­view on CNBC, Josh James pointed out, “Our cus­tomers are ask­ing us, ‘Can you do more with mobile?’” My col­league, Ed Hewett, dis­cussed trends show­ing the grow­ing impor­tance of mobile mea­sure­ment pre­vi­ously on his blog. And as the world heads in this direc­tion, the num­ber of ques­tions I receive about mobile imple­men­ta­tion and report­ing is ris­ing, so it’s time to dis­cuss com­mon pit­falls of mobile implementation—and how to avoid them.

1. Don’t assume that all of your mobile users exe­cute JavaScript

I don’t know what I would do with­out my JavaScript-enabled smart phone by my side, but not every­one shares my enthu­si­asm for con­stant con­nec­tiv­ity and script exe­cu­tion. Mea­sure­ment on mobile-specific sites should not be imple­mented using JavaScript. Omni­ture pro­vides sev­eral approaches for imple­ment­ing these ini­tia­tives with­out JavaScript includ­ing hard-coded image requests, server to server HTTP requests, and the Data Inser­tion API.

But what if you want to track mobile usage of your non-mobile web site? One option is to imple­ment a hard-coded image request on your site using <NOSCRIPT> tags just below your Site­Cat­a­lyst JavaScript tags. For exam­ple:


/************* 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 oppor­tu­nity for your busi­ness, some excel­lent guid­ance can be found in a pre­vi­ous blog post by Adam Greco.

2. Don’t rely solely on cookies—and espe­cially not on third-party cookies

Mobile mea­sure­ment actu­ally has some huge advan­tages in cap­tur­ing vis­i­tor data. HTTP requests from a mobile devices often include spe­cial car­rier head­ers that Site­Cat­a­lyst can use to dis­tin­guish vis­i­tors from one another. Because these para­me­ters do not change and can­not be dis­abled or “cleared” (a la browser cook­ies), they are much more effec­tive at iden­ti­fy­ing mobile vis­i­tors. And who doesn’t want their mobile vis­i­tor data to be as com­plete as possible?

To ensure that Omni­ture is lever­ag­ing these spe­cial head­ers first where avail­able, 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 Site­Cat­a­lyst to use these head­ers first, and to set cook­ies only if the head­ers are not avail­able (where as /1/ causes cook­ies to be set and dis­re­gards header iden­ti­fi­ca­tion). You’ll get the same effect using the Mea­sure­ment Libraries for JSP and PHP (which han­dle writ­ing the Omni­ture image to the page—perfect for mobile!) to build your image requests by set­ting s.mobile = true, as explained in the doc­u­men­ta­tion avail­able in the Online Mar­ket­ing Suite.

Beyond this, keep in mind that many mobile devices (such as the iPhone) have default set­tings con­fig­ured to reject third-party cook­ies. There­fore, even if pri­mar­ily using head­ers for vis­i­tor mea­sure­ment, imple­ment a first-party data col­lec­tion domain for your mobile site. Using a third-party domain dra­mat­i­cally decreases the like­li­hood that a mobile device will play nice with your ana­lyt­ics efforts.

3. Don’t for­get your Traf­fic Sources reports!

It’s nifty that a stan­dard, out-of-the-box Site­Cat­a­lyst JavaScript imple­men­ta­tion will auto­mat­i­cally cap­ture refer­rer data. This infor­ma­tion serves as the basis for all of the reports in the Traf­fic Sources sec­tion of Site­Cat­a­lyst and Dis­cover, and you don’t even have to do much of any­thing in order to pop­u­late the reports. Mobile imple­men­ta­tion doesn’t cap­ture this refer­rer infor­ma­tion quite as eas­ily, although mak­ing sure that you grab this data isn’t ter­ri­bly difficult.

Your server will have access to the refer­rer (in PHP, for exam­ple, you can use the $_SERVER[’HTTP_REFERER’] vari­able), so you can sim­ply write this value to the page in the image request. Here is an exam­ple 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 men­tion here that the Mea­sure­ment Libraries do this automatically.

The result is the abil­ity to attribute mobile con­ver­sion and engage­ment to spe­cific refer­rers, includ­ing search engines. Very impor­tant stuff!

4. Don’t leave out image attributes

The image tag should have attrib­utes. Make sure to include a height and width of at least one pixel. You never want a bor­der (I mean, unless you want a nice lit­tle box around the otherwise-transparent image returned by the Omni­ture servers), so set border=0. And don’t for­get the “alt” attribute, which you can set to any­thing at all. Each of these is auto­matic when using s.mobile=true in the Mea­sure­ment Libraries. Some devices will not suc­cess­fully request and receive the Omni­ture image if these attribute are omitted.

5. Ensure image request para­me­ters fol­low estab­lished nam­ing con­ven­tions and syntax

As devel­op­ers can attest, syn­tax is crit­i­cal in imple­men­ta­tion, and mobile imple­men­ta­tion is no dif­fer­ent. How­ever, even expe­ri­enced Omni­ture devel­op­ers can get tripped up when set­ting up a mobile site because, rather than s.pageName, s.eVar1-50, s.products and the rest of the famil­iar group of vari­ables, you are build­ing vari­ables directly into the query string of the image request using shorter, very spe­cific parameters.

The full map­ping of para­me­ters to Site­Cat­a­lyst vari­ables is avail­able in pub­lished doc­u­men­ta­tion, so I won’t repro­duce it here. I will, how­ever, issue a word of cau­tion: make sure that you are using the desired para­me­ter name exactly as writ­ten in the doc­u­men­ta­tion! 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" />

Iden­ti­cal, right? Mostly. The dif­fer­ence is that the first request has “c1=blog” as a para­me­ter. This would pass a value of “blog” into Cus­tom Traf­fic (s.prop) 1. The sec­ond request is def­i­nitely not what the devel­oper intended; there, we have “cl=blog” instead of “c1=blog.” The “cl” para­me­ter con­trols cookie life­time (the max­i­mum amount of time that the s_vi cookie can remain on the user’s device. This vari­able is almost never set man­u­ally, and the default is five years; by inad­ver­tently set­ting the cookie life­time to “blog” (which makes no sense) the actual life­time will be the ses­sion, rather than five years. This would, of course, dra­mat­i­cally inflate visit and vis­i­tor met­rics and kill any con­ver­sion vari­able per­sis­tence every time the user closed his or her browser app. This might be an extreme exam­ple because “c1” and “cl” hap­pen to look so similar—the more com­mon out­come, assum­ing that the erro­neous para­me­ter did not map to an actual variable—would be miss­ing data in indi­vid­ual reports. Still, that out­come can be just as dis­as­trous to your mobile ini­tia­tives. So make sure that the para­me­ters in the request match the vari­ables you intend to populate!

Okay, so this “top five” list prob­a­bly isn’t as fun or philo­soph­i­cal as those recounted by Rob Gor­don… but I can guar­an­tee that it’s much bet­ter at help­ing you avoid pit­falls of mobile imple­men­ta­tion in SiteCatalyst!

As always, please leave a com­ment with any ques­tions, thoughts, or sug­ges­tions that you may have! I’m also avail­able Twit­ter, Friend­Feed, LinkedIn, or by e-mailing omni­ture care [at] omni­ture dot com.