Recently I was speaking to someone who was in the process of creating an tablet experience for their visitors. At one point they asked the question “of my iPad visitors, how do I find out in what format do they view my site the most in, landscape or portrait?”. I started going through all of the reports in SiteCatalyst and tried to find the answer, but that information just was not available. So I decided to whip a little bit of code that would figure this out for us. I call this the screenOrientation plug-in.

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!

One of the most common things I get asked to track are specific links on the website. Typically to do that I would use a custom link tracking function. This typically involves adding a large chunk of JavaScript code to each link, or adding a function to your s_code file and then calling that function using an onClick function added directly to the link. That methodology works fine, and I’ve been doing it forever. But that means working with IT to add more code to your pages, something I want to try to avoid as much as possible. So how can we make the implementation of our link tracking quicker and use less code? If you haven’t figured it out by now, we’re going to use some jQuery.

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.

Today I show you how to setup and use contextData variables with processing rules in SiteCatalyst 15.

Enjoy.

Here is a quick look at what can be done with and how to set up processing rules in SiteCatalyst 15.

Enjoy.

Recently someone had asked the question, how do I capture a query string parameter that’s on referring URL? We all know how to grab a query string parameter from the current page URL by using the getQueryParam SiteCatalyst plug-in, but most people don’t know that plug-in can be used to get a query string parameter from the referring URL as well. I once had a real unique implementation that was not using that plug-in and needed to capture that value. I wanted to keep the implementation really light so I decided to give it a try using a smaller bit of code. I broke out a little JavaScript magic to see if I could make it happen simpler than using that plug-in. Turns out it’s not too difficult to accomplish, in fact I got it down to just a single line of code.

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.

At the Omniture Summit earlier this month, SiteCatalyst 15 was announced. There has been a lot said about the new tools it will offer but not much about the overall UI appearance update. Here is a quick look showing some of the changes you will see in the UI of SiteCatalyst 15.

Enjoy.

Recently someone asked me when was the best time to use the Scatter Plot graph type and the Bubble graph type in SiteCatalyst reports.

Enjoy.

The SiteCatalyst Target report is one of my favorite reports that I don’t see used enough. THis video gives you a brief introduction to the report, and walks you through setting one up, and how to view the results.

Enjoy.

Bounce Rates. For those of you who are unaware of what they are, bounce rate is essentially the percentage of single page visits, divided by your total visits. This metric can be pretty useful to figure out what pages of your site that your visitors enter on and decide not to venture any deeper into your site. Basically the visitor came to your site and the page they entered on did not entice them to view additional pages of your site so they left. This is obviously not what we want. We need our visitors to come to our sites and complete our desired action. This is where I run into a problem with the Bounce Rate metric. Lets say for example you have a lead generation site, which contains a form on the landing page which uses ajax or some other type of technology to process the form submission. That site would have a visitor enter, fill out the form (which is your desired action) and then leave the site. This would show up as a bounced visit since a second page view was not recorded. What can we do to record this action as a successful visit and not have it end up being considered as just another bounce?

One thing you could do would be to use the getVisitStart plug-in. With this plug-in you could set an event on the first page of the visit, and then using a conversion funnel you can see how many visits entered on your specified landing page and then completed your conversion event.



Pretty simple stuff so far. But what if I wanted to now know how many of those visits ventured on to view additional pages of my site, and how many left right after completing my conversion event? For this I would want to set a second different success event on the second page view of the site. For this we can use the getActionDepth plug-in.

What this plug-in will do is set a success event (or any SiteCatalyst variable you want) onto any page of the visit. In this case we want to set a success event on the second page view of the site. Using the Action Depth plug-in we can set individual events on only the first page view and the second page view of the visit. Now using the same conversion funnel we can see how many visits entered the site, completed our conversion action, and then stayed to view a second page of the site.



What if your site does not have an ajax type form conversion action and you just want to use the custom events funnel as a cool way to display how many bounces your site had? That can also be easily done.



By just including the event that fired on page 1 of the visit and the event that fired on the second page view of the visit we now have a nice graphical representation of how many of our visits left after viewing a single page and how many decided to move on to view additional pages of the site.

What if for your site only viewing 2 pages was not good enough? You need to see what percentage of your visits see at least three pages. The Action Depth plug-in can take care of that as well.



Now if you have spent more than couple minutes using SiteCatalyst you could probably be saying to yourself “I can find this information out already by using the Path Length report”. Yes that report will tell you what percentage of your visits saw any number of pages, but have you tried to add that report to a dashboard? It’s not pretty. This way you can easily show the exact information you need in a very easy to read format.

Let’s take a look at what the plug-in code looks like If we want to set an event on first page view of the visit, and another one on the second page view of the visit. First add this line in the top of your s_code file, in the config section.

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!