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="" title="Web Analytics"><img
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="" 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 = 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="" 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 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="" height="1" width="1" border="0" alt="Omniture image request" />

Request 2

<img src="" 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.


Ben, is the only thing preventing me from seeing referrrers for mobile visits the fact that I don't have = true in my s_code.js file? (I have version H.16) Is it safe for me to simply add that line, or does it jeopardize any of the non-mobile data I'm collecting?

Ben Gaines
Ben Gaines

Hi Craig, I don't think I was very clear about this in my post, but the variable only applies to the PHP Measurement Library (and also JSP, .NET, etc.); it is not a recognized variable in JavaScript. If you are implementing SiteCatalyst on your mobile site (or any site) using JavaScript, and the device in question executes JavaScript, you will get referrer data for mobile visits just as you would for normal visits. I assume you are not seeing referrer data. . . is this in a separate mobile suite? If so, are the Internal URL Filters in order? I would pursue this like a normal tracking issue, at least based on the way you asked the question :) Thanks, Ben