Archives

 

How To Fix Google Plus Referrer Values In SiteCatalyst

Recently I was looking through some traffic sources reports in SiteCatalyst, and I noticed something odd. In my Referrers report I had a bunch of different referring URL’s that were all coming from Google Plus, all going to the exact same page on my site, but each referring URL was listed separately. Taking a closer look, I noticed that each referring URL contained some unique query string values, and my Referrers report was quickly getting filled up with a lot of redundant links.

Multiple Google Plus Referrers

I was curious to learn about what was going on, so using Chrome I logged into my Google Plus account looking for a link to click. I found a link one of my friends shared, clicked it, and then checked what the referring link to that site was.
Google Plus Referrer using Chrome
Next I did the same thing in Firefox. I clicked the exact same link as before shared by the same person, and then checked that referrer.
Google Plus Referrer using Firefox
Finally I tried clicking the exact same link for a third time, this time trying it in Safari.
Google Plus Referrer using Safari
The exact same link, shared by the exact same person, going to the exact same page, from the exact same Google Plus account, but three different referring URL values. It looked like Google Plus was using a unique URL value for each browser. But wait, I had a ton of different values in my Referrers report so that couldn’t be it. Still using Chrome I went back and clicked on the same link I’ve been using.
Google Plus Referrer using Chrome again
Another unique referring URL. As Google Plus usage beings to increase, I can see this becoming a big problem. I needed to find an easy way to clean up my Google Plus referrers.

Looking at each referring link I see that there are two parameters that are unique each time, n= and usg=. I could probably keep testing and find out what these two parameters meant, but I doubt I’ll need them. I just need to know that the visitor came from Google Plus. But looking closer at the referrer value I can see something else that could be useful. The url= parameter contains the page that the link was headed to, and that could be helpful to have. So if I had a way to just drop off everything from that Google Plus referring URL query string except for the url= value, that would give me what I’m looking for. I would now be able to clean up my Referrers report by removing all the redundant links, and as a bonus I would be able to tell which page of my site attracted the most attention on Google Plus just by looking at those referrers. So how do I do it?

All it takes is a little bit of code dropped into the s_code.js file and my problem is solved.
Google Plus Referrer's Cleaned Up In SiteCatalyst

The best part is that there is no set up required. I wanted to keep it really simple so I made sure that there’s nothing that needs to be configured. Just paste this plugin code right next to all of your other plugins, and all of your messy Google Plus referring URLs will get cleaned up automagically!

/*
 * Clean up Google Plus referrer values
 */
s.cleanGP=new Function("var s=this,a=document.referrer,b='plus.url.go"
+"ogle.com',c,d,e,g,i=0,p,referrer;if(a&&a.split('/')[2]==b){c=a.spli"
+"t(/[\?|&]/);d=c[0].length;e=c[0].lastIndexOf('/');g=d>e?c[0].substr"
+"ing(0,e+1):c[0];for(i=0;i<=c.length;i++)'url'==c[i].substring(0,3)&"
+"&(p='?'+unescape(c[i]),i=c.length+1);g&&(this.s.referrer=p?g+p:g);}"
+"return this.s.referrer")();

enjoy!

Optimize the Time Parting Plugin to get More Detail and Use Less Variables

The Time Parting Plug-in is one of the more popular SiteCatalyst plug-ins available. A standard implementation of the Time Parting plug-in will consume 3 variables. One for Time of Day, one for the Day of Week, and one for Weekday/Weekend. How can we improve this to get more information, and more importantly use less variables? Here is how I have been doing it.

I use a combination of stacking the variables and SAINT uploads. For those of you who are not familiar with SAINT, Omniture describes it as, “…an acronym for SiteCatalyst Attribute Importing and Naming Tool. This tool enables you to download the classifications template, apply attributes to it, and then upload the data, thereby enhancing your SiteCatalyst reports with the new attributes.” This will allow us to upload a lot of detail about any variable you record.

Here’s how I’m doing it on this site. First I am using the 2.0 version of the plug-in and not the 1.4 version that I describe in a previous post. The 2.0 version includes support for Daylight Savings time and globalizes the year. You can find the 2.0 version from the SiteCatalyst Knowledge Base. If you prefer to use the 1.4 version, you can find it on this site.

/* Set Time Parting Variables */
s_hour=s.getTimeParting('h','-5'); 
s_day=s.getTimeParting('d','-5');
s_timepart=s_day+"|"+s_hour;
s.prop16=s_timepart.toLowerCase();
if (s.visEvent) s.eVar16=s.prop16;   

Ok, let me explain whats going on here. As I said before the Time Parting plug-in captures 3 variables. If you notice in my code I am only using two of them. I don’t need to capture Weekday/Weekend anymore. I will take care of that later. The other two, I capture in two blank variables I created, s_day and s_hour. Next I combine the two of them in a single variable I call s_timepart, separated by a pipe. Then to ensure everything is consistent I copy the variable in all lower case to the prop that I am going to use. This next part is a little different. In the eVar I only want capture this value once per visit. Typically a simple getValOnce will be enough to get it done. Well then what happens when the visit extends from one time part into another? In that situation the Time Parting value will be different and therefore getValOnce will capture this as a new value since it has changed. I don’t want that to happen, I only want it once per visit. So this is when I tie in using the get Visit Start plug-in. This guarantees I will only capture the value only one time per visit.

This will return a report that looks like this:
Time Parting Report in SiteCatalyst

We now have a total of 672 possible options in this report. The next thing we want to do is to classify these using SAINT. I set up 5 different categories to use. Weekday/Weekend (this is why we don’t need to capture it in the code, Day of Week, Hour of Day, Hour Part and AM/PM.
SAINT Setup

I then created the template to use that contains all of these values.
SAINT Template
You can download a copy of the template that I use here.
Upload the template and that’s all there is to it. Do you have more conversions in the bottom of the hour or the top of the hour? How about morning vs afternoon? Which whole hour is the most profitable? Now you have an easy way to break down your time parting with finer granularity, at the sime time saving your self a couple of variables.

Enjoy!

Increase SiteCatalyst Clickmap Functionality with Dynamic Object IDs Plug-in

ClickMap. Pretty useful tool. It gives you a neat overlay that shows you what links are clicked on a page and the associated traffic. I wonder how we can make it better? Knock knock. Oh who is that at the door? Why its the Dynamic Object IDs Plugin. Please step right in.

The Dynamic Object IDs Plug-in dynamically adds an object ID to the click thru URL. You can see it using the debugger. It is designed to improve the function of the Clickmap.

Let’s take a look at an example. From the home page of this site, there are 3 links that take you to the Contact page. I click the last one on the page, then open the debugger on the page I land on. Here you can see that the click thru URL has been appended with the number of the order that it happened to appear in on the page. So now when I have multiple links on a single page each one is easily spotted in the debugger, even though they all have the same anchor text and click thru URL.
Dynamic Object ID Plug-in

Now what do we get? If you look at the clickmap report, Site Content>Links>ClickMap, you will now see a number attached to each URL.
Clickmap Report
Now you know exactly which link was clicked.

Here is how I have it implemented on this site. Before the function s_doPlugins(s) I include the code:

/* DynamicObjectIDs config */
function s_getObjectID(o) {
	var ID=o.href;
	return ID;
}
s.getObjectID=s_getObjectID

Then within the s_doPlugins(s) function, I include:

/* To setup Dynamic Object IDs */
s.setupDynamicObjectIDs();

And finally in the Plug-ins section I have the plug-in code itself.

/*
 * DynamicObjectIDs
 */
s.setupDynamicObjectIDs=new Function(""
+"var s=this;if(!s.doi){s.doi=1;if(s.apv>3&&(!s.isie||!s.ismac||s.apv"
+">=5)){if(s.wd.attachEvent)s.wd.attachEvent('onload',s.setOIDs);else"
+" if(s.wd.addEventListener)s.wd.addEventListener('load',s.setOIDs,fa"
+"lse);else{s.doiol=s.wd.onload;s.wd.onload=s.setOIDs}}s.wd.s_semapho"
+"re=1}");
s.setOIDs=new Function("e",""
+"var s=s_c_il["+s._in+"],b=s.eh(s.wd,'onload'),o='onclick',x,l,u,c,i"
+",a=new Array;if(s.doiol){if(b)s[b]=s.wd[b];s.doiol(e)}if(s.d.links)"
+"{for(i=0;i<s.d.links.length;i++){l=s.d.links[i];c=l[o]?''+l[o]:'';b"
+"=s.eh(l,o);z=l[b]?''+l[b]:'';u=s.getObjectID(l);if(u&&c.indexOf('s_"
+"objectID')<0&&z.indexOf('s_objectID')<0){u=s.repl(u,'\"','');u=s.re"
+"pl(u,'\\n','').substring(0,97);l.s_oc=l[o];a[u]=a[u]?a[u]+1:1;x='';"
+"if(c.indexOf('.t(')>=0||c.indexOf('.tl(')>=0||c.indexOf('s_gs(')>=0"
+")x='var x=\".tl(\";';x+='s_objectID=\"'+u+'_'+a[u]+'\";return this."
+"s_oc?this.s_oc(e):true';if(s.isns&&s.apv>=5)l.setAttribute(o,x);l[o"
+"]=new Function('e',x)}}}s.wd.s_semaphore=0;return true");

To see this code in the s_code file running this site, you can check it out here.

Ok great. Now what else can we do with this plug-in? Lets say I want to track how many contact form submissions I received from clicking the third Contact link that appears on the Home Page? Well I could add a custom onclick function. I could add a tracking code on the end of the click thru URL. But how can I use this new plug-in to track this?

Recently there was a post on the Omniture blog about using Dynamic Variables. Using these variables we can now grab the value of oid, which is the click thru URL with the new object id added to it, and you can get the pid which is the page the click happened on. I have it set up on this site:

s.prop20=s.eVar20="D=oid";
s.prop22=s.eVar22="D=pid";

Now with a simple subrelation I can get what link was clicked on what page and what events occurred, all without adding any additional code to the page.

Enjoy!

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.