The mobile report­ing in Site­Cat­a­lyst is a pow­er­ful resource for those who are invest­ing in mobile apps, pages and adver­tise­ments.  This series of blog posts is to bring a few new mobile solu­tions to your atten­tion.  These solu­tions are designed to enhance your mobile report­ing expe­ri­ence and help you make more informed deci­sions related to mobile.

Mobile vs Non-Mobile

The Mobile vs Non-Mobile solu­tion is a stan­dard VISTA solu­tion that places “Mobile” into a prop (traf­fic vari­able) or evar (com­merce vari­able) when a hit comes in from a mobile device and it places “Non-Mobile” for all other traf­fic.  From this you get the fol­low­ing report.

In the above report you can see the per­cent­age of Page Views, Vis­its and Daily Unique Vis­i­tors for your mobile traf­fic and com­pare it directly to your non-mobile traf­fic.  This report will help you to under­stand how much to invest in mobile web­sites and application.

You can also look at the report in a trended view to see how the use of mobile is chang­ing over time.

You can also do some deeper analy­sis by break­ing down reports by Mobile Vs Non-Mobile.  For exam­ple, this next report takes the prod­uct page and breaks it down by Mobile Vs Non-Mobile report to under­stand how much traf­fic on a spe­cific page is com­ing from a Mobile device.

The final report I want to show you is fun because I took the last report and reversed the break­down.  In the below report I take the value Mobile and break it down by Page Names to see the top pages with mobile page views.

Report

The part of this solu­tion that I like the most is how sim­ple the data sets are and how easy the reports are to under­stand.  You can only take action on a report when you truly under­stand what the data rep­re­sents.  With the Mobile Vs Non-Mobile solu­tion every­one in your com­pany will quickly be able to under­stand and act on the results of the reports.

Get Started:

You can get started by going to our cus­tomers por­tal and down­load­ing the whitepa­per on the solu­tions.  And if you would like to request more infor­ma­tion, you can do it on the cus­tomers por­tal or talk to your account manager.

Other posts you might be inter­ested in:

As always, post your com­ments or e-mail me at pearcea (at) adobe​.com.  It is your com­ments and e-mails that keep me post­ing and give me ideas for future posts.

Tagged with →  
  • Eric Mati­soff

    So here’s a ques­tion. If we push Mobile/Non-Mobile into an eVar, are we then able to sub­re­late by s.campaign with events as a met­ric? Don’t eVars require cook­ies in order for them to be per­sis­tent? And a lot of my research lately has shown that cook­ies are being stripped by carriers/phones/browsers. Please let me know if this is not an issue though, as it’s just speculative.

    • http://blogs.omniture.com/author/paurigemma Pearce Aurigemma

      Hey Eric,

      So here’s a ques­tion. If we push Mobile/Non-Mobile into an eVar, are we then able to sub­re­late by s.campaign with events as a metric?

      Good ques­tion, you will be able to sub-relate with met­rics. Now that I think about it, it will be a really nice report. It will help you to see how cam­paigns are per­form­ing for mobile devices.

      Don’t eVars require cook­ies in order for them to be persistent?

      This should not be an issue as the evar per­sis­tence is dealt with server side and our servers are designed to han­dle sit­u­a­tions where cook­ies are dropped to increase accu­racy of reporting.

  • http://blogs.omniture.com/author/ehewett Ed Hewett

    Eric,

    As Pearce says, you will be able to sub-relate the Mobile/Non-Mobile eVar by cam­paigns. How­ever, you should also note view­ing cam­paign per­for­mance by mobile device is already pos­si­ble. If you want to sub-relate your mobile reports by cam­paign, just con­tact Client­Care or your account man­ager and they can con­fig­ure the proper set­tings for you. Of course you’ll want to make sure you are prop­erly cap­tur­ing your cam­paigns on mobile first–you may want to review the fol­low­ing post for more detail: http://​blogs​.omni​ture​.com/​2​0​1​0​/​0​8​/​0​2​/​m​o​b​i​l​e​-​c​a​m​p​a​i​g​n​-​t​r​a​c​k​i​ng/ .

    Regard­ing cookie accep­tance on mobile you may want to read the cookie sec­tion of this post as a primer: http://​blogs​.omni​ture​.com/​2​0​0​9​/​1​1​/​0​9​/​t​o​p​-​5​-​m​o​b​i​l​e​-​i​m​p​l​e​m​e​n​t​a​t​i​o​n​-​g​o​t​c​h​as/. How­ever, that’s only part of the answer. As Pearce points out, eVars rely on the per­sis­tence of a vis­i­tor id (regard­less of the iden­ti­fi­ca­tion method). In other words, if you are tag­ging an iPhone app, your eVars will per­sist even though this imple­men­ta­tion method lever­ages an id unique to the device and not a cookie for vis­i­tor identification.

  • Adam Egbert

    Hello, Eric,

    There are sev­eral dif­fer­ent meth­ods used by Site­Cat­a­lyst for track­ing vis­i­tors. The first which you men­tioned is to use a per­sis­tent cookie. The sec­ond, as indi­cated by Pearce, is used as a fall­back when the per­sis­tent cookie is not accepted and uti­lizes a com­bi­na­tion of the IP address and user agent string of the browser. The third method is to set the vis­i­torId vari­able explic­itly. This method should be used when the user is known and can be iden­ti­fied on the back end. For mobile imple­men­ta­tions specif­i­cally, the Devi­ceID is often used.

    Best Regards,

    Adam Egbert
    Tech­ni­cal Con­sul­tant
    Adobe Sytems, Inc.

  • http://www.symantec.com Mein­hard Schramm

    A report in your blog shows the page names. We are cur­rently dupli­cat­ing some pages to a more mobile friendly design. For exam­ple the prod­uct home page is now going to have a web (PC) ver­sion and a mobile ver­sion. The ques­tion is how we should track the pages:

    a) same page name for both pages and a prop/evar dif­fer­en­ti­at­ing mobile/non-mobile
    b) sep­a­rate page name with mobile dif­fer­en­ti­a­tion in the page name
    c) report suite for mobile traf­fic — no mix of web/mobile traffic.

    One lim­i­ta­tion for option b) is that we have only 500,000 unique val­ues for page names and we are always above the limit.

    The report­ing is bro­ken for com­bined report­ing for c) and par­tially b). The sep­a­ra­tion of report­ing becomes more work in option a). There might be other options that we have not consider.

    What is Omniture’s/your rec­om­men­da­tion to address this challenge?