Archives

 

Track Copied Text SiteCatalyst Plugin

UPDATED: March 29, 2013 – Track Copied Text plugin version 2.0k

This was a bit of code that was in desperate need of an update, so thats exactly what it got. Here I have the updated version of the Track Copied Text plugin, version 2.0k.

Improvements with this version include:

  • The entire code has been completely rewritten and is now in a standard SiteCatalyst plugin format.
  • The ability to set any combination of eVars, props, events, or nothing but an empty custom link call.
  • Prevents copied text longer than 255 characters from being set in any variable (100 characters in a prop).
  • Prevents the same highlighted text to be copied multiple times in a row.
  • The ability to include or not include variables set in s.linkTrackVars or s.linkTrackEvents.
  • The ability to use a custom link name.

Implementing this version is quick and easy. First include the Track Copied Text plugin code below in your s_code file with all the rest of your plugins:

/* Track Copied Text v2.0k */
s.trackCopiedText=new Function("v","e","a","n",""
+"var s=this,x=arguments;s.ea=!1;if(!s.ea){s.ea=!0;s.cf=!1;function t"
+"ct(x){if(!s.cf){var b=s.linkTrackVars,c=s.linkTrackEvents,d=',event"
+"s',g=h='',f,i;e=e?e:'';n=n?n:'text copied';if(a){if(b&&b!='None')g="
+"','+b;if(c&&c!='None')h=','+c}if(e||h)g=g+',events';s.linkTrackVars"
+"=v+g;s.linkTrackEvents=s.events=e+h;j=gct();j=(String(j)).substring"
+"(0,255);if(v){f=v.split(',');for(i=0;i<f.length;i++){if(f[i].charAt"
+"(0)=='p'){s[f[i]]=j.substring(0,100)}else{s[f[i]]=j}}}s.tl(true,'o'"
+",n);s.cf=!0}};function gct(){if(s.d.selection){return s.d.selection"
+".createRange().text}else if(s.wd.getSelection){return s.wd.getSelec"
+"tion()}return ''};if(s.wd.attachEvent){s.wd.attachEvent('oncopy',tc"
+"t)}else if(s.wd.addEventListener){s.wd.addEventListener('copy',tct,"
+"false)}}");

Next add a call to the plugin in the s_doPlugins section of your s_code file (preferably near the bottom of the s_doPlugins section). The plugin call will accept 4 parameters, all of them being optional.

s.trackCopiedText(v,e,a,n);

v = The variable’s that you would like the copied text recorded to. Insert as many as you would like, each one comma separated. Any copied text will be trimmed to 255 characters, except for props which will get trimmed to 100 characters.
e = The events that you would like to set when text is copied. Again, feel free to set as many as you would like, or you can choose not to set any events.
a = This is a flag that when set to 1 indicates if you have s.linkTrackVars or s.linkTrackEvents set on any page to also include those variables with the Copied Text function call. If this variable is not included then no additional variables will be included with the call.
n = This is the name of the call that will appear in the Custom Links report in SiteCatalyst. If this is not set then the default value of “text copied” will be used.

Examples

To capture the copied text in s.eVar20 and set event15 (this is how I have it set on this site):


s.trackCopiedText('eVar20','event15');

To capture the copied text in s.eVar20, s.prop35, set event25, and include anything currently set in s.linkTrackVars or s.linkTrackEvents:


s.trackCopiedText('eVar20,prop35','event25',1);

To capture the copied text in s.prop30 and use the custom link name of “visitor selection”:


s.trackCopiedText('prop30','','','visitor selection');

To just fire a custom link call when the visitor copies some text (not capturing the copied text or setting any events):


s.trackCopiedText();

As with all code, make sure you fully test it to ensure it works with your site. Also let me know of any changes or additions you’d like to see with this plugin, and of any insights you were able to gain by using this plugin. I’d love to hear how its working for your site.

Enjoy!

Original Post: December 21, 2009

To me Web Analytics is the science of analyzing visitor behavior in order to improve the Web Site for the purpose of increasing conversion. Anytime I can use web analytics to help the visitor find what they are looking for, I feel I’m doing my job. But lets say your visitors are finding what they are looking for, but it is just not as easy as it could be? How would I know?

One thing I have been playing with is to monitor what content my visitors are selecting and copying from the site. If I see a lot of visitors copying my email address, maybe I should make the contact form a little easier to be found. If I see a lot of copying of some sample code, maybe I should make it easier to download it, or include a pdf copy. But how do I find out how to capture what my visitors copy? Here you go.

This is all done by adding a plug-in and a bit of code to the s_code file. This code looks for any time some text is copied and sets it in a prop and fires an event. This will work if the visitor highlights text and goes the right click/copy route, or by hitting Control/Command + C. You will need either 1 eVar and 1 event, or a 1 prop to use. If you want to go the eVar and event route, take this code and place it some where BEFORE the function s_doPlugins(s) call:

var eventAttached=false; 
if(!eventAttached){eventAttached = true;
function trackCopy(){
var overrides = {'events':'event8','eVar18':getCopiedText()};
	s.templtv=s.linkTrackVars;
	s.templte=s.linkTrackEvents;
   	s.linkTrackVars='eVar18,events';
	s.linkTrackEvents=s.events='event8';
	s.tl(true, 'o', 'Text Copied', overrides);
	if(s.templtv) s.linkTrackVars=s.templtv;
	if(s.templte) s.linkTrackEvents=s.templte; 
}

Insert the eVar and event you are going to use where you see them in the code. If you decide to just use a single prop instead, then use this bit of code, again before the function s_doPlugins(s) call:

var eventAttached=false;
if(!eventAttached){eventAttached = true;
function trackCopy(){
var overrides = {'prop49':getCopiedText()};
	s.templtv=s.linkTrackVars;
   	s.linkTrackVars='prop49';
	s.tl(true, 'o', 'Text Copied', overrides);
	if(s.templtv) s.linkTrackVars=s.templtv;
}

Insert the prop you want to use where you see it set. Next take this code and put it in the plug-in’s section of the s_code file:

function getCopiedText() {
if (document.selection){return document.selection.createRange().text;}
else if (window.getSelection){return window.getSelection();}return '';}
if(document.body && document.body.attachEvent){
document.body.attachEvent("oncopy", trackCopy);}
else if (document.body && document.body.addEventListener){
document.body.addEventListener('copy',trackCopy, false);}}

What are we going to end up with? You will get a report that looks like this:
Copied Text Report

It’s pretty interesting to see what your visitors are choosing to copy. Now do I expect to find huge some game changing incite that will lead me to make a change to the Web Site that will increase my conversion rate 100% with this report? Probably not. Do I expect to find one more place that allows me to make another 1% improvement? I sure do. Remember, all those 1% improvements add up. ;)

Big thanks to kgs/ksmith in the Omniture Developer Connection for the original idea to do this.

Enjoy!

How To Improve Referring Domain Reporting In SiteCatalyst

While going over my Traffic Sources reports recently, I realized that I had a problem with how my referrers were reported. Not a problem with bad data coming into SiteCatalyst, like the recent issue I fixed regarding the Google Plus referrers, but this was a problem with the Referrers and Referring Domains reports themselves.

Both reports are working as they were designed, but the problem is that both reports are on opposite ends of the spectrum from one another. I feel that at times the Referrers report gives me too much information, while the Referring Domains report doesn’t give me enough. I need a something a bit more in the middle.

Here’s an example of the problem. Checking the Referring Domain report in SiteCatalyst, this is a snippet of what I see:
Referring Domains Report in SiteCatalyst

I can see that some of my visitors came from Google, and some from Yahoo, and that’s all this report tells me. When I see something like that, I start to wonder which sections of the referring site lead to the visitors deciding to come to my site. Well, the first thing I could do in an attempt to answer my question would be to click the magnifying glass icon next to each line item in the Referring Domains report to get a quick view of what referrers specifically mades up that value. Unfortunately the little popup window doesn’t break out the referrers in any kind of a useful way, and I can’t do anything with that popup report myself because there is no export option in that window, so that option’s out. I could do a standard sub-relation breakdown of the two reports, then export the results into Excel, then do some sorting and filtering and could probably get the answer I need for a single Referring Domain value in roughly 5 to 10 minutes. But then I’m stuck having to go back and do that whole process again for the other Referring Domains. This method could end up taking a while, so this option is also out. I’m sure I could whip something up in Data Warehouse, but I won’t see that report anytime soon either. I could go set up a ton of Processing Rules, but that won’t work because I would end up using all the rules just to help me populate one variable. So how do I get the report I need? Looks like it time for some more s_code magic.

And voilĂ . I give to you the s.getFullReferringDomains plugin. What this will do is look at that referrer value and grab not only the domain name, but any subdomains it may have as well. This uses the same s.linkInternalFilters values that you’ve already set up to ensure that this will only set its value when there is an external referrer. So now I will get a better, quicker, easier look at my referring domains:
Full Referring Domains Report in SiteCatalyst

All that needs to be done is to choose an unused variable, and call the plugin from it. This should be placed inside of the doPlugins section of the s_code.js file.

s.eVar1 = s.getFullReferringDomains();

Then just add the plugin itself to the plugins section of your s_code file.

/*
 * Get Full Referring Domains
 */  
s.getFullReferringDomains=new Function(""
+"var s=this,dr=window.document.referrer,n=s.linkInternalFilters.spli"
+"t(',');if(dr){var r=dr.split('/')[2],l=n.length;for(i=0;i<=l;i++){i"
+"f(r.indexOf(n[i])!=-1){r='';i=l+1;}}return r}");

One last thing I like to do with this new report is to go into the Report Suite manager in the Admin Console, and move it to the Traffic sources menu. This way all of your referrer related reports will all live in one spot. It looks like it should have lived there all along.

Full Referring Domains Traffic Sources Report in SiteCatalyst

enjoy!

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!

Capture Mobile Device Screen Orientation In SiteCatalyst

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:

Mobile Screen Orientation Report

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.

SiteCatalyst Mobile Reports

enjoy!

How To Capture A Query String Parameter From A Referring URL In SiteCatalyst

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.

Track HBX Style Links in SiteCatalyst

I hear from a lot of people migrating from HBX to SiteCatalyst who are looking for ways to make that process a little easier. One of the hurdles I see is trying to migrate all of their HBX link tracking that is already in place to a format that SiteCatalyst can easily understand. That is an easy one to tackle. It’s called the setupLinkTrack plug-in.

Other than tracking all of you current HBX coded links, any SiteCatalyst user can get some benefit from it. Here is another great use for this plug-in. Recently I was reading a great article from @adamgreco about learning to track website navigation. It is a really great article and if you have not had a chance to read it you should go check it out. In one part of the article Adam writes “you should have your developer write code that will pass the name of the link to a Traffic Variable (sProp) when a visitor clicks on each link in your navigation”. Well I’m the guy responsible for the tracking code for my website, so how can I track those links without adding a whole ton of JavaScript onclicks or some other server side hacks? This plug-in will easily handle that, without adding the extra server calls that come with the standard SiteCatalyst link tracking.

First take the plug-in code and add it to the plug-in section of your s_code.js file. Make sure you have the utility functions s.split and s.apl.

/*
 * Plugin: setupLinkTrack 2.0 - return links for HBX-based link 
 *         tracking in SiteCatalyst (requires s.split and s.apl)
 */
s.setupLinkTrack=new Function("vl","c",""
+"var s=this;var l=s.d.links,cv,cva,vla,h,i,l,t,b,o,y,n,oc,d='';cv=s."
+"c_r(c);if(vl&&cv!=''){cva=s.split(cv,'^^');vla=s.split(vl,',');for("
+"x in vla)s._hbxm(vla[x])?s[vla[x]]=cva[x]:'';}s.c_w(c,'',0);if(!s.e"
+"o&&!s.lnk)return '';o=s.eo?s.eo:s.lnk;y=s.ot(o);n=s.oid(o);if(s.eo&"
+"&o==s.eo){while(o&&!n&&y!='BODY'){o=o.parentElement?o.parentElement"
+":o.parentNode;if(!o)return '';y=s.ot(o);n=s.oid(o);}for(i=0;i<4;i++"
+")if(o.tagName)if(o.tagName.toLowerCase()!='a')if(o.tagName.toLowerC"
+"ase()!='area')o=o.parentElement;}b=s._LN(o);o.lid=b[0];o.lpos=b[1];"
+"if(s.hbx_lt&&s.hbx_lt!='manual'){if((o.tagName&&s._TL(o.tagName)=='"
+"area')){if(!s._IL(o.lid)){if(o.parentNode){if(o.parentNode.name)o.l"
+"id=o.parentNode.name;else o.lid=o.parentNode.id}}if(!s._IL(o.lpos))"
+"o.lpos=o.coords}else{if(s._IL(o.lid)<1)o.lid=s._LS(o.lid=o.text?o.t"
+"ext:o.innerText?o.innerText:'');if(!s._IL(o.lid)||s._II(s._TL(o.lid"
+"),'<img')>-1){h=''+o.innerHTML;bu=s._TL(h);i=s._II(bu,'<img');if(bu"
+"&&i>-1){eval(\"__f=/ src\s*=\s*[\'\\\"]?([^\'\\\" ]+)[\'\\\"]?/i\")"
+";__f.exec(h);if(RegExp.$1)h=RegExp.$1}o.lid=h}}}h=o.href?o.href:'';"
+"i=h.indexOf('?');h=s.linkLeaveQueryString||i<0?h:h.substring(0,i);l"
+"=s.linkName?s.linkName:s._hbxln(h);t=s.linkType?s.linkType.toLowerC"
+"ase():s.lt(h);oc=o.onclick?''+o.onclick:'';cv=s.pageName+'^^'+o.lid"
+"+'^^'+s.pageName+' | '+(o.lid=o.lid?o.lid:'no &lid')+'^^'+o.lpos;if"
+"(t&&(h||l)){cva=s.split(cv,'^^');vla=s.split(vl,',');for(x in vla)s"
+"._hbxm(vla[x])?s[vla[x]]=cva[x]:'';}else if(!t&&oc.indexOf('.tl(')<"
+"0){s.c_w(c,cv,0);}else return ''");
s._IL=new Function("a","var s=this;return a!='undefined'?a.length:0");
s._II=new Function("a","b","c","var s=this;return a.indexOf(b,c?c:0)");
s._IS=new Function("a","b","c",""
+"var s=this;return b>s._IL(a)?'':a.substring(b,c!=null?c:s._IL(a))");
s._LN=new Function("a","b","c","d",""
+"var s=this;b=a.href;b+=a.name?a.name:'';c=s._LVP(b,'lid');d=s._LVP("
+"b,'lpos');return[c,d]");
s._LVP=new Function("a","b","c","d","e",""
+"var s=this;c=s._II(a,'&'+b+'=');c=c<0?s._II(a,'?'+b+'='):c;if(c>-1)"
+"{d=s._II(a,'&',c+s._IL(b)+2);e=s._IS(a,c+s._IL(b)+2,d>-1?d:s._IL(a)"
+");return e}return ''");
s._LS=new Function("a",""
+"var s=this,b,c=100,d,e,f,g;b=(s._IL(a)>c)?escape(s._IS(a,0,c)):esca"
+"pe(a);b=s._LSP(b,'%0A','%20');b=s._LSP(b,'%0D','%20');b=s._LSP(b,'%"
+"09','%20');c=s._IP(b,'%20');d=s._NA();e=0;for(f=0;f<s._IL(c);f++){g"
+"=s._RP(c[f],'%20','');if(s._IL(g)>0){d[e++]=g}}b=d.join('%20');retu"
+"rn unescape(b)");
s._LSP=new Function("a","b","c","d","var s=this;d=s._IP(a,b);return d"
+".join(c)");
s._IP=new Function("a","b","var s=this;return a.split(b)");
s._RP=new Function("a","b","c","d",""
+"var s=this;d=s._II(a,b);if(d>-1){a=s._RP(s._IS(a,0,d)+','+s._IS(a,d"
+"+s._IL(b),s._IL(a)),b,c)}return a");
s._TL=new Function("a","var s=this;return a.toLowerCase()");
s._NA=new Function("a","var s=this;return new Array(a?a:0)");
s._hbxm=new Function("m","var s=this;return (''+m).indexOf('{')<0");
s._hbxln=new Function("h","var s=this,n=s.linkNames;if(n)return s.pt("
+"n,',','lnf',h);return ''");

Next in the s_doPlugins section of the s_code file you need a couple lines of setup.

s.hbx_lt = "auto" // manual, auto
s.setupLinkTrack("prop1,prop2,prop3,prop4","SC_LINKS");

The plug-in will use 4 variables and a name for a cookie it will set. For this example I am going to use props 1 thru 4.

Next we have the actual code that will appear in the anchor tag that the plug-in will look for. It is a simple name attribute tag of lid and lpos. This is what a link would look like with the code properly formatted.

<a href="my-page.php" name="&lid=Featured Articles&lpos=Left Nav">Cool Article Name</a>

Here’s what it will do. After clicking on a link that contains a lid and lpos (the exact link shown above), this is what you will find in the debugger on the page you land on:
Debugger 1
The plug-in entered the s.pageName value of the page that the click occurred into prop1, the value of lid into prop2, a combination of the prop1 and the value of lid into prop3 and the value of lpos in prop4.

Lets change up what we include in the actual link code. Lets remove the lid from the tag and just use this link:

<a href="my-page.php" name="&lpos=Left Nav">Cool Article Name</a>

This is what we will get from the debugger:
Debugger 2
You can see by not using the lid tag then the plug-in will use the actual anchor text in those positions.

Now lets say you are not interested in capturing the previous pageName value, or the combined previous pageName/lid value. You can just omit those variables in the plug-in setup. Change the code to:

s.hbx_lt = "auto" // manual, auto
s.setupLinkTrack(",prop2,,prop4","SC_LINKS");


You can see I left the commas in there as empty place holders. Clicking the link with that setup and a lid and lpos value will return this in the debugger:
Debugger 3

What about the other links on the page? What if they do not include a lid or lpos value? The plug-in will track those also. Clicking one of those links will return this in the debugger:
Debugger 4
The plug-in will still capture the previous pageName value, the anchor text and the combined values of the two.

I’m sure by now you noticed that auto/manual setting. Up to now its been set on auto. Let’s flip it to manual and click a link on the page that does not include any code. Here is what you will get:
Debugger 5
You will only get the two previous pageName values. If I would have omitted those two variables like I did earlier then it would have not returned anything. If you click on a link with a lid and lpos variables then it will perform the same as if it were set to auto.

If you want to not add the code to the links so you can track all of the links on a page, but you only want to do it on a specific page and not the whole site you can then wrap the code in an if statement like this:

if(s.pageName=='Home'){
s.hbx_lt = "auto" // manual, auto
s.setupLinkTrack(",prop2,,prop4","SC_LINKS");
}

You could also do that using document.location (or a million other ways to identify a specific page).

Since it also grabs the previous page value I no longer need the previous pageName plug-in (useful when using the getPercentPageViewed plug-in).

Enjoy!

Track Hash Query Parameters in Omniture SiteCatalyst

Do you have a site that uses a hash symbol in the URL with query parameters and you want a way to track them in SiteCatalyst? Well you have come to the right place.

What am I talking about? Lets say you have a URL that looks like this:
http://webanalyticsland.com/#cid=Hash_Param_Test
and you want to capture the value of cid=. The standard getQueryParam plugin will not work in this case. It looks for a question mark in the URL, and as you can see this one did not have one.

To capture this value we can use the getHashQueryParam s_code.js plug-in. What this plug-in does is looks for the hash symbol # at the end of the URL, then looks for the parameter you have listed in the function, then inserts the value in to the associated variable. This works just like the standard getQueryParam plugin, but looks for the hash instead.

Here’s how to use it. Insert this line of code in the s_doPlugins(s) section of your s_code.js file. Make sure you use the correct variable you want the metrics recorded in and which query string you want it to be associated with. I’m using s.prop17 and cid in this example.

s.prop17=getHashQueryParam('cid');

Next enter this code in the plug-in’s section of your s_code file:

/*
 * Plugin: getHashQueryParam
 */
function getHashQueryParam(a){
var QueryString=window.location.search.substring(1);
if(QueryString==''){var WinExtra=window.location.hash;
if(WinExtra.length > 0){if(WinExtra.indexOf(a)>-1){
QueryString=WinExtra.substr(WinExtra.indexOf(a))}}}
var returnValue='';var keyValPairs=QueryString.split('&');
if(!keyValPairs){ keyValPairs = new Array();  
keyValPairs[keyValPairs.length]=QueryString}
for(var counter=0;counter<keyValPairs.length;counter++){
var keyVal=keyValPairs[counter].split('=');if(keyVal[0]==a){
returnValue=keyVal[1];break;}}return returnValue;}

Here is an example of it live in action. After you click on the link, open the debugger you will see the value entered in s.prop17.

Enjoy!

Don’t Forget Your SiteCatalyst Utility Functions!

Have you ever tried to use a new plug-in and found it did not work? You were probably missing a utility function. Utility functions are designed to work with SiteCatalyst plug-ins. There are 6 utility functions that are commonly used. They are apl, p_c, p_gh, split, replace, and join.

These functions do things like join elements of an array into a string delimiter by a string, replaces characters in a string, splits a string on a specific character, append a value to any delimited lists, and more. THese utility functions are referenced by several standard plug-ins.

Here’s how I do it. I take all these utility functions and wrap them all up in one neat package, and include this as one of my standard plug-ins to add when creating a s_code file. This way not thing is missed, nothing is forgotten and all of my plug-ins will work no problem.

Here’s what it looks like:

/*
 * Utility Functions: apl, p_c, p_gh, split, replace, join
 */
s.apl=new Function("L","v","d","u",""
+"var s=this,m=0;if(!L)L='';if(u){var i,n,a=s.split(L,d);for(i=0;i<a."
+"length;i++){n=a[i];m=m||(u==1?(n==v):(n.toLowerCase()==v.toLowerCas"
+"e()));}}if(!m)L=L?L+d+v:v;return L");
s.p_c=new Function("v","c",""
+"var x=v.indexOf('=');return c.toLowerCase()==v.substring(0,x<0?v.le"
+"ngth:x).toLowerCase()?v:0");
s.p_gh=new Function(""
+"var s=this;if(!s.eo&&!s.lnk)return '';var o=s.eo?s.eo:s.lnk,y=s.ot("
+"o),n=s.oid(o),x=o.s_oidt;if(s.eo&&o==s.eo){while(o&&!n&&y!='BODY'){"
+"o=o.parentElement?o.parentElement:o.parentNode;if(!o)return '';y=s."
+"ot(o);n=s.oid(o);x=o.s_oidt}}return o.href?o.href:'';");
s.split=new Function("l","d",""
+"var i,x=0,a=new Array;while(l){i=l.indexOf(d);i=i>-1?i:l.length;a[x"
+"++]=l.substring(0,i);l=l.substring(i+d.length);}return a");
s.repl=new Function("x","o","n",""
+"var i=x.indexOf(o),l=n.length;while(x&&i>=0){x=x.substring(0,i)+n+x."
+"substring(i+o.length);i=x.indexOf(o,i+l)}return x");
s.join = new Function("v","p",""
+"var s = this;var f,b,d,w;if(p){f=p.front?p.front:'';b=p.back?p.back"
+":'';d=p.delim?p.delim:'';w=p.wrap?p.wrap:'';}var str='';for(var x=0"
+";x<v.length;x++){if(typeof(v[x])=='object' )str+=s.join( v[x],p);el"
+"se str+=w+v[x]+w;if(x<v.length-1)str+=d;}return f+str+b;");

I just make sure that is block is included in every s_code file. Then I am assured that every plug-in I use can find the correct utility function it needs to work properly.

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!