Monthly Archives for March 2009

 

Pull Folders From The URL To Populate Channel and Hierarchy From Inside The S_Code File

EDIT: I have a better way of doing this. Please check out the post New Plugin Function to Populate Hierarchy From URL in Omniture SiteCatalyst. You can still glance at what I have here, but that new post is really much better.

In many organizations, trying to get the development team to implement any enhancements to your SiteCatalyst implementation is not always going to be the top thing on their to-do list. After dealing with trying to work around their schedule, and working with smaller sites that don’t have the best resources, I have come up with quite a few tricks to get as much done in the s_code file as I can. Here is a neat trick to grab folders from the directory structure to fill them in to the Site Sections or any prop or evar you would like. Check out this piece of code:

var folders = new Array();
var path = window.location.pathname;
	
path = path.replace("http://", "");
path = path.slice(path.indexOf('/') + 1, path.lastIndexOf('/'));
	
folders = path.split('/');
	for (var i = 0; i < folders.length; ++i) {
		if (folders[0] != ""){s.channel =folders[0]};
		}

What this does is takes the first folder from the URL, and plugs it right into the s.channel variable. It will not take the first file, just the folder. For example looking at the URL:
http://webanalyticsland.com/channel-name/folder2/folder3/folder4/index.php
We would end up with s.channel=channel-name
Most sites ‘should’ have a good directory structure:
Ideal Directory Structure
so that first folder can usually be considered a channel of the site.

EDIT: Again, I would ignore this following section. There are some errors with my logic, and I can admit when I made a mistake. I really do recommend you check out the new post I have shown above.

If your site is laid out a little differently, another neat use of this code, is if you want to use it to populate the Hierarchy variable (s.heirN). By making a few changes to the code, you can set the heir1-heir5 variables right in the script:

var folders = new Array();
var path = window.location.pathname;
	
path = path.replace("http://", "");
path = path.slice(path.indexOf('/') + 1, path.lastIndexOf('/'));
	
folders = path.split('/');
	for (var i = 0; i < folders.length; ++i) {
		if (folders[0] != ""){s.heir2 =folders[0]};
		if (folders[1] != ""){s.heir3 =folders[1]};
		if (folders[2] != ""){s.heir4 =folders[2]};
		if (folders[3] != ""){s.heir5 =folders[3]};
		}
s.hier1="home";     

This assigns the value of ‘home’ to any page with no folders, basically your home page any any files directly attached to it, and counts each folder after that as one more step in the hierarchy. Looking again at that example URL:
http://webanalyticsland.com/channel-name/folder2/folder3/folder4/index.php
The code would populate the variables like:
s.hier1=channel-name
s.hier2=folder2
s.hier3=folder3
s.hier4=folder4

Give it a try. Any time you can save your developers is just a bonus for you. It is so much easier to get a new s_code file pushed live, than to get coding done on the site.

Using Visitor Intentions To Track Your Web Site

Implementing basic web analytics on your web site should be pretty straight forward. Add the code to every page and your on your way. Once you start getting creative with your site elements is when you really need to look at which elements you are tracking as basic traffic metrics. Just blindly adding tracking code to every single page you have listed on your server can lead to miscounting what is really going on. Let me explain.

The two biggest things that I have seen a problem with is pop-ups and iframes. These elements while both technically can be additional pages to your site, they should not be considered as additional page views. The main thing to consider here is visitor intention. Consider the following example. If you take a look at this page on Boat Trader.com, you will see a form at the bottom of the page. While everything looks nice and seamless, that form is actually a iframed in page. Even though you are viewing two pages here, the visitors intention is not to see two pages but a single page. That iframed form should not be tracked as a page view. This can easily be overlooked if adding code to everything you see. Still looking at that page we see a link near the top of the page that says “Send to Friend”. Clicking this brings up a pop-up form which is also another seperate page, presented as a pop-up. Again, the visitor did not intend to view another page of the site so that pop-up should also not be considered another page view of the site. All of this should be pretty simple to figure out. Nothing really ground breaking yet.

When I talk about this to others the largest debate I come across is tracking outsourced sections of your site. Content syndication has been around for a long time and comes in many different forms. But when it comes to tracking these pages is where it gets a little hairly and we need to rely on visitor intention to help us out.

Lets look at another example. If you visit Walmart’s site, you will see a link on their left nav, for Job Classifieds. Clicking on that link takes you to a Walmart Job Classified page. Now this page is completely outsourced and is actually a subdomain of Oodle. Looking at the page it is branded and styled to look just like a page of walmart.com. Walmart’s intention is to let the user feel like they are still on their own site, and this is just another page. Walmart should count this as another page view of their site. Now lets look at this from Oodle’s side of things. This page is ‘technically’ a part of oodle.com, with all of Oodle’s content. So what do they do? Does Oodle get credit for another visit, visitor or page view? Looking at the visitors intentions, they never intended to visit oodle.com. They intended to visit walmart.com. Walmart did all the legwork to attract that visitor to their site, and should get credit for everything that happens with that visitor. That is Walmarts visit, visitor and page view and should be credited toward the walmart.com report suite.

But that is Oodle’s content. It is Oodle’s advertisers that are getting impressions and the leads. What do they get out of the deal? How does Oodle tell their advertisers that their ad recieved 2 leads with 0 visitors? This page still needs to be tracked by Oodle in some fashion, but in a separate report suite than the main site. To someone in this situation I would recommend that they create a new report suite and call it ‘affiliate network’. Then they have the ability to track all of the leads generated from this page to their advertisers, but without artificially inflating the number of visitors who actually intended to visit www.oodle.com. Then by using the SiteCatalyst Excel client you can bring in both site’s metrics on to a single spread sheet and you have the ability to report on the performance of main site and the affiliate network of sites.

I can see where it would be tempting by the crew over at Oodle to call that another page view of their site to bump up their traffic numbers, but that is misleading. Our sites are built for our visitors, and should be tracked using their intentions.

How To: Split Metrics Between Two Report Suites Using A Single s_code.js File

One thing I like to do is snoop around at others code. Some may say I’m being nosy, I like to think I’m admiring others work. You come across some pretty neat ideas looking at the code of others. With a little creativity you can use others ideas and apply them to something that is beneficial to you. Sometimes you come across a neat chunk of code that you will want to keep as it. This is one of those interesting finds.

Many of the sites I work on are rather large, and have separate domains setup for our dev/testing environment. If you are delivering millions and millions of page views a week, you don’t want to test in a live environment. What we like to do is have out pubic facing site set up as www.mysite.com, and our testing/development site setup with a dev subdomain, dev.mysite.com. The value in this enhancement come where both sites, your public site and development site,have the ability to use the same s_code.js file without mixing the metrics in the UI.

Let’s say your site is www.mysite.com and your testing site is dev.mysite.com. In the top on your s_code.js file, add a function before any other code.

function switchSuite() {
	var suiteList= "";

	if (location.hostname.indexOf('dev')!=-1) {
		suiteList += "DEV_SUITE_NAME";
		} else {
		suiteList += "MAIN_SUITE_NAME";
		}
	return suiteList
	}

When the main code begins, insert the function call in the s_account spot.

var s_account=switchSuite()

On the sites I work with, we actually have many different testing, development and staging subdomains that I want to keep separate, so I can use a few domains listed in that first position.

	if (location.hostname.indexOf('dev')!=-1 || location.hostname.indexOf('qa')!=-1 || location.hostname.indexOf('staging')!=-1) {
		suiteList += "DEV_SUITE_NAME";
	} else {
		suiteList += "MAIN_SUITE_NAME";
	}
	return suiteList
}

This will now look at the subdomain and fill in the correct account name. You may just say ‘hey, just remove the analytics from the testing page’, but I like to keep that on there to make sure any enhancements to the site do not have any effect on the analytics.

Another neat use of this is if you have multiple subdomains of unrelated content that you have individual report suites set up for. Take a look at Yahoo. They have tons of micro-sites, all subdomain based that I would want to count individually of one another. I may not want all the data from autos.yahoo.com swimming around with realestate.com so this is a great use this code as well. Hopefully you will be able to find some interesting uses for it.

Tip: Finding Missing Revenue Opportunities With Web Analytics Data

Revenue. The goal of every Website. As long as it’s up, everyone is happy. When it’s down, there are a few less smiling faces. But what can you as a Web Analyst do to help that? I have all these cool numbers, but how can I help turn them into revenue? This tip is one of my favorites.

The majority of the sites I work on are classified advertising sites. They are quite simple in nature, at it’s core consisting of a home page with search functionality, search results pages, and listing pages. Now there are actually much more pages than these, but this is the real bread and butter of the site. One neat item I like to track is the number of results returned when someone does a search.

Taking a look here at eBay, I do a search for Apple iPhone and it shows me how many results were returned for that search.
Number of Search Results
Now I like to grab that number and record it into a s.prop in SiteCatalyst. Ok so now you end up with a report full of numbers. How is this useful to me? Let’s open SiteCatalyst and take a look at this new Results Returned report and take a look at what we have.
Results Returned Report
Look what this tells us. For the time period selected, we had just under 195k times where someone did a search on the site and got nothing. The marketers did what needed to do to drive traffic to the site, only for these people to not get what they wanted. Now let’s take it a step further. What were these people looking for? That’s where Data Correlations come into play. If you are capturing all the other elements of that visitors search on your site, you are now able to break down that 0 Results Returned, and find out where they were searching and for what item. You know the exact make, model, city, state and whatever else about what gave this visitor nothing from your site.

You now have pinpointed where you have a demand with no supply. Once you know this you can help work to tailor your site to give your users what they want, and what they expect out of your site, and generate that revenue you are missing out on by having a visitor leave your site not being able to find what they want.

Optimizing The SiteCatalyst Page Code

You’ve signed the agreement, you received your username, and you are ready to get started with Omniture SiteCatalyst. Or maybe you have had it a while, and are looking to optimize your installation. You’ve come to the right place. Let’s take a look at one of the two core pieces that make it work, the page code. The other piece, being the s_code.js file is a complicated animal, but the page code is pretty straight forward.

After logging in with admin privileges in SiteCatalyst, you can find the code files in the code manager in the admin console.

Here is the basic, vanilla, out of the box page code file.

<!-- SiteCatalyst code version: H.19.4.
Copyright 1997-2009 Omniture, Inc. More info available at
http://www.omniture.com -->
<script language="JavaScript" type="text/javascript" src="http://INSERT-DOMAIN-AND-PATH-TO-CODE-HERE/s_code.js"></script>
<script language="JavaScript" type="text/javascript"><!--
/* You may give each page an identifying name, server, and channel on
the next lines. */
s.pageName=""
s.server=""
s.channel=""
s.pageType=""
s.prop1=""
s.prop2=""
s.prop3=""
s.prop4=""
s.prop5=""
/* Conversion Variables */
s.campaign=""
s.state=""
s.zip=""
s.events=""
s.products=""
s.purchaseID=""
s.eVar1=""
s.eVar2=""
s.eVar3=""
s.eVar4=""
s.eVar5=""
/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
<script language="JavaScript" type="text/javascript"><!--
if(navigator.appVersion.indexOf('MSIE')>=0)document.write(unescape('%3C')+'\!-'+'-')
//--></script><noscript><a href="http://www.omniture.com" title="Web Analytics"><img
src="http://mysite.112.2O7.net/b/ss/mysite/1/H.19.4--NS/0"
height="1" width="1" border="0" alt="" /></a></noscript><!--/DO NOT REMOVE/-->
<!-- End SiteCatalyst code version: H.19.4. -->

There is tons of stuff here that is completely unneeded. Lets try to strip it down a bit and see if we can lighten our page weight. Why? The lighter our page weight the quicker it will load. The lighter the page weight the more of the actual content will get indexed. Believe me, lighter is better.

The first thing we see is a basic introduction:

<!-- SiteCatalyst code version: H.19.4.
Copyright 1997-2009 Omniture, Inc. More info available at
http://www.omniture.com -->

This is absolutely not needed at all. Not a bit of it. But I do like to keep a small bit around just to keep developers who don’t know what it is aware of whats going on. For this first section I recommend chopping it down to:

<!-- SiteCatalyst Code  -->

Sweet and simple. No need to keep the version number in there either. Keep that in your s_code file where its needed.

Next thing we see is the call to the s_code.js file.

<script language="JavaScript" type="text/javascript" src="http://INSERT-DOMAIN-AND-PATH-TO-CODE-HERE/s_code.js"></script>

Yank this out too. But wait you say, I need that file, I can’t get rid of it! I’m not saying get rid of it, I just want you to move it. Keep all your JavaScript calls together where they belong, in the head section of your page. Move this call to the top of the page.
EDIT: There are some potential repercussions to moving this out of the BODY section. I like to keep the code nice and neat so I keep all the .js calls in one place but this is by no means without consequence. There is nothing wrong with keeping this line with all of the rest of the code.

Next up is the variable section.

<script language="JavaScript" type="text/javascript"><!--
/* You may give each page an identifying name, server, and channel on
the next lines. */
s.pageName=""
s.server=""
s.channel=""
s.pageType=""
s.prop1=""
s.prop2=""
s.prop3=""
s.prop4=""
s.prop5=""
/* Conversion Variables */
s.campaign=""
s.state=""
s.zip=""
s.events=""
s.products=""
s.purchaseID=""
s.eVar1=""
s.eVar2=""
s.eVar3=""
s.eVar4=""
s.eVar5=""

Tons of useless junk here. If your not using it dump it. Only fill out variables that are specific to whats going on with that page. Try to move as many things to the s_code.js file as you can. For example if you want to use the page titles as each page name in Omniture (which I think is a good practice) then just set that one time in the s_code.js file. Something like s.pageName=document.title; and no need for that code on the page. Try to move as much stuff as you can to that file.

On to the end

/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
<script language="JavaScript" type="text/javascript"><!--
if(navigator.appVersion.indexOf('MSIE')>=0)document.write(unescape('%3C')+'\!-'+'-')
//--></script><noscript><a href="http://www.omniture.com" title="Web Analytics"><img
src="http://mysite.112.2O7.net/b/ss/mysite/1/H.19.4--NS/0"
height="1" width="1" border="0" alt="" /></a></noscript><!--/DO NOT REMOVE/-->
<!-- End SiteCatalyst code version: H.19.4. -->

This section is a disaster. You have a huge noscript section that is udderly useless. The very very very first thing I do is to kill that section. I mean Omniture themselves don’t even use it. Kill it and never look back. That leaves you with this:

/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
<!-- End SiteCatalyst code version: H.19.4. -->

The big scary “do not alter” message is somewhat important. Well the message itself, not that actual line of text. If I am going to have someone else install the code on their site I have them leave it, so hopefully they won’t touch anything they are not supposed to. If I am putting the code on the page myself then I yank that out too. The line that follows that is the money shot. That’s what makes it work. Don’t touch it. I usually never go near that line. I say usually because there is one time where I will touch it. More on that in a few. The final closing line, yank out the version and that one is good.

Lets take a look at the chopped down page code where we just set a single eVar and event.

<!-- SiteCatalyst Code -->
<script language="JavaScript" type="text/javascript"><!--
s.events=1
s.eVar1=blue
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
<!-- End SiteCatalyst Code -->

Much better. Now I mentioned earlier that I would touch that one ‘money line’ of the code. If I have a site that I really don’t need much info on, and i can get everything I need from the s_code.js file I will hack everything down to the absolute bare minimum. You still need the call to the s_code.js file in the head section, that will never change, but the page code can be reduced to:

<script language="JavaScript" type="text/javascript">var s_code=s.t();if(s_code)document.write(s_code)</script>

A call to the s_code.js file and that single line is the bare minimum that is needed to make SiteCatalyst work.

Look at your page code. Move the call to the s_code.js file to the header, move everything you can to that file, and strip out all the unnecessary junk.

Hello World!

Welcome to the new WebAnalyticsLand.com a place for Web Analytics discussion, tips and tricks. I am going to be covering a lot of topics from optimizing your Web Analytics implementation (specifically Omniture SiteCatalyst), to what to do with the data once you have it. If there are any topics anyone is inteested feel free to contact me here, or shoot me a message on Twitter. Enjoy and thanks for stopping by!

Almost there!

Well it looks like I missed the Monday deadline I set for the first ‘real’ post to go live. But no worries, I have a couple about half ready to go in the draft folder. I have been trying to find a good plugin to show off some code examples. I think I’ve got one yo use but I’m still going to look a little more. Expect to see the first post about optimizing your SiteCatalyst page code before the end of the week.