Basically what this will do is it will check to see in what position the mobile visitor is viewing the site in, whether they are viewing the site in a portrait or a landscape view when the page loads, and capture that value into a SiteCatalyst variable.

To implement this plug-in you first need to take this code, and add it to your s_code file near the rest of your plug-ins.

function screenOrientation(){switch(window.orientation){case 0:case 180:return("Portrait");break;case 90:case -90:return("Landscape");}window.scroll(0,0)}

Next in the do_plugins section of the s_code file, add the call to the plug-in to what ever SiteCatalyst variable you want this data captured in. In the example here you can see I am capturing it in s.prop1

s.prop1=screenOrientation();

Thats all it takes. Once the code is implemented, if the device does not have an orientation value the variable will not capture anything, but if the visitor is on a mobile device with an orientation value, the value of Landscape or Portrait will be captured on each page load. You will end up with a report that looks something like this:



To make it easier to access the report I also moved it into the Mobile report menu by using the customize menus option in the admin console of SiteCatalyst.

enjoy!

For more information how to do this, please read the full article Custom Link Tracking in Omniture using jQuery.

For more information on website optimization solutions, please visit Keystone Solutions.

Enjoy.

Enjoy.

function getRefQueryParam(a){a=a.replace(/[\[]/,"\\[").replace(/[\]]/,"\\]");a=RegExp("[\\?&]"+a+"=([^&#]*)").exec(document.referrer);return a==null?"":a[1]};

Its a little function called getRefQueryParam. To use it just place that code in your s_code file, and then call it with the name of the query string parameter you want to capture. In this example I want to capture the value of the parameter forumID= from the referring URL and record it in s.prop1.

s.prop1=getRefQueryParam('forumID');

With a little JavaScript goodness it is an easy value to capture.

Enjoy.

Enjoy.

Enjoy.

Enjoy.

s.ActionDepthTest=true;

Next this call to the plug-in should be placed in your s_code file in the s_doPlugins section.

if(s.ActionDepthTest){
	s.pdvalue=s.getActionDepth("s_depth");
	if(s.pdvalue == 1) {
		s.events=s.apl(s.events,'event1',',',1)
	}
	if(s.pdvalue == 2) {
		s.events=s.apl(s.events,'event2',',',1)
	}
}
s.ActionDepthTest=false;

And here is the actual plug-in that should be placed after the s_doPlugins section, along with your other plug-ins.

/*
 * Plugin: getActionDepth v1.0
 */
s.getActionDepth=new Function("c",""
+ "var s=this,v=1,t=new Date;t.setTime(t.getTime()+1800000);"
+ "if(!s.c_r(c)){v=1}if(s.c_r(c)){v=s.c_r(c);v++}"
+ "if(!s.c_w(c,v,t)){s.c_w(c,v,0)}return v;");

But there is one more thing (sorry I was feeling very Steve Jobs for a moment). Actually I have two more things but I couldn’t pass up on a good Steve Jobs reference. Let’s say you also need to set an additional event and an eVar on the 6th page view of the site, and only on the 6th page view. That can easily be done as well by just changing somethings around in the plug-in code. By looking at the call to the plug-in it should be pretty easy to see what’s going on. When the specific page view of the visit is reached, then the actions that are attached will occur.

s.ActionDepthTest=true;
if(s.ActionDepthTest){
	s.pdvalue=s.getActionDepth("s_depth");
	if(s.pdvalue == 1) {
		s.events=s.apl(s.events,'event1',',',1)
	}
	if(s.pdvalue == 2) {
		s.events=s.apl(s.events,'event2',',',1)
	}
	if(s.pdvalue == 6) {
		s.events=s.apl(s.events,'event3',',',1)
	        s.eVar="This is the sixth page view";
        }
}
s.ActionDepthTest=false;

Now how about you want to know how many page views deep do your visitors go when they complete your conversion action. A little change to the plug-in code and we can capture that as well. What we do here is just capture what the page number of the visit is on each page view in an eVar, then we can just add in our conversion event to that report and there we go. Then we can see directly in our optimization efforts if we are helping our visitors quickly get to our conversion event. Here is the code to capture the page number of each page of the visit in an eVar.

if(s.ActionDepthTest){
	s.pdvalue=s.getActionDepth("s_depth");
	if(s.pdvalue) {
		s.eVar1=s.pdvalue;
	}
}
s.ActionDepthTest=false;

Enjoy!

var s_account="dead"

To implement the bot detection code you will want to change that line to include the function call. It should look like this:

var s_account=botCheck("dead")

Pretty simple so far, right? We just added the function call and included our report suite id in it. Next we have a block of code that needs to be added to the plug-ins section of the s_code file:

function botCheck(b){var c=navigator.userAgent.toLowerCase(),a="";a+=c.indexOf("google web preview")!=-1?"":b;return a};

And that’s all there is to it. So how does it work you ask? What it does is it removes your report suite id if it is the Google Web Preview bot that is accessing the page. The SiteCatalyst code will still fire off, but it will not include the report suite id so it will be discarded by SiteCatalyst and it will not affect your metrics.

Want to see it in action? I thought you’d never ask! Check out the page http://webanalyticsland.com/test.php. On this page I have a basic SiteCatalyst implementation, one line of code that displays your user agent, and then I print the results of the SiteCatalyst debugger right to the screen. Opening this page in a standard Firefox browser we can see that the SiteCatalyst code has fired off properly, it has displayed the correct user agent and the report suite id is contained within the image request string.

So far so good. Using the User Agent switcher plug-in for Firefox, we can switch out user agent to the one that we found in the SiteCatalyst report to mimic the Google Web Preview bot.

We can now see that when we use that bot’s user agent string, the report suite id is missing from the image request call. Any action that happens now will not be recorded in my report suite, and when SiteCatalyst receives this request it will be discarded. I’ve had this running for a few days now and have not found any issues, but since this is a pretty new chunk of code be sure to test it out before using it on your production site.

Enjoy!