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!

Google Changes Referrer Values Again For Secure Searches

Over the past 6 months Google has made changes to their search experience in an attempt to increase the privacy and security of their signed in users. What this has meant for analytics tools is that the referring URL for those signed in users was stripped of any searched keywords when clicking on Google organic search results.

Here’s what has been happening behind the scenes. All signed in users are now on a secure version of Google (https), and a redirect has been added to each search results click. That redirect is to a non-secure page (http), where the referring URL is changed before the visitor arrives at the page they requested. That new referring URL value has had its keywords removed, but still contains enough information to determine it was a Google Secure search. Workarounds were created to help identify a Google Secure search in SiteCatalyst keyword reporting, as well as Omniture making a change to try and account for those searches.

Since making that change Google has determined that the additional redirect is unnecessary and potentially slowed down the users experience, so they have decided to eliminate it (unfortunately that does not mean analytics tools will be able to see those keywords again).

Today Google announced a change to the way they plan on handling referring URL’s starting in April 2012. Google has decided that they will now begin to use the referrer meta tag for browsers that will support it, as opposed to the redirect to the non secure page. Currently the only major browser that supports it is Google Chrome.

If you are not familiar with the referrer meta tag, what it does is it lets each web page decide how referrer from it should be handled. For example, here’s what a meta referrer tag looks like:

<meta name="referrer" content="never">

What this tag will do is that it tells the browser to never pass any referring information from the page its on. The browser should then set the referrer header value to a blank string for referrers from that page.

Fortunately Google is not going to that extreme. They have decided to use the “origin” value:

<meta name="referrer" content="origin">

This is the referrer meta tag value that Google will begin to use in April 2012. When the change goes live, all search clicks from signed in users will now only have the referrer value of https://www.google.com/. There will be no other information in the referring URL, so no way to determine that it was specifically a Google secure search other than the URL being simply that host value. Non-secure searches, ones made from a user not logged into a Google account, will continue to function in the same way as they do now.

Currently the referrer meta tag is not currently supported in all browsers. I tried it using Chrome 17 and it is working. Testing it in Safari 5.1.4 and Firefox 11, the referrer meta tag has no impact.

So what does this mean as far as SiteCatalyst reporting? According to the Knowledge Base answer #5329, “If the domain of the referrer corresponds to that of a recognized search engine (e.g. “google.com”) and contains the recognized search keyword query parameter for the given search engine domain (e.g. for Google this is “q=”), then the referrer is considered a search engine, and the value of the keyword query parameter is taken as the search keyword.” So no search keyword query parameter, no search is counted. Currently for a Google secure search, the parameter is still there, but it’s unpopulated. Now Google plans to remove it all together.

Hopefully before Google rolls this out publicly Adobe will come up with a solution for SiteCatalyst so there are no interruptions in the Search Engine reporting. If Adobe does not get to it in time, or if Google decides to push the change out before April, then a couple of lines of code added to your s_code.js file will keep the impact to a minimum while Adobe works out a solution.

if(document.referrer=="https://www.google.com/"){
	s.referrer="https://www.google.com/?q=google%20secure%20search";
}

What this will do is look for a referrer with the exact value of https://www.google.com/ and append a q= value to it with the keyword of google secure search. If the .com version of Google is not the one most used by your visitors, then just replace it with the correct tld version applicable to your site. This snippet of code will make sure the search is still counted, and you will continue to keep the same level of reporting that you have now.

UPDATE: If your your visitors are coming to your site from multiple country specific versions of Google, then I have you covered. Just include this plugin in your s_code file and all Google secure searches from every Google domain will automatically be handled. All you need to do is cut and paste.

s.getGoogle=new Function(""
+"var s=this,a=document.referrer,b=a.split('/')[3],c=a.substring(0,19"
+");a&&26>=a.length&&(b||c=='https://www.google.'&&(this.s.referrer=a"
+"+'?q=google%20secure%20search'));return this.s.referrer")();

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!

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.

How To Stop Google Preview From Being Counted In SiteCatalyst – Updated

UPDATE: I have a much better way to block the Google Web Preview bot from being tracked as a visitor in SiteCatalyst. The original solution I had posted here, required a block of code to be placed at the very top of the s_code file, and your account ID was put into a function call. Then when the s_code was fired, a function would first check the user agent of the visitor to see if it was the Google Web Preview bot, and if so then swap out the account ID with a blank value. The SiteCatalyst code would still fire, but when Omniture received the image request it would get discarded because of the missing account ID. The more I thought about this I figured there had to be a better way. No reason to execute all the s_code javascript and fire off the beacon call when I don’t want that visitor (Google) to be tracked. So after a little brainstorming I came up with a new and improved way to do this. Now when the user agent is determined to be the Google Web Preview bot, then the SiteCatalyst code is prevented from even firing (how it should have been originally). Even better, this can now be done by simply adding a tiny bit of code to the plugin’s section of your s_code file, right next to all your other plugin code. Thats it. No other changes need to happen. No code at the top of the page, no adding calls to functions in the account variable. Just cut, paste, and done.

Here is the code. Just add this right next to all of your other plugins.

/*
 *  Block the Google Web Preview Bot from firing SiteCatalyst code
 */
if(s.u.toLowerCase().indexOf('google web preview')!=-1){s.t=function(){}}

If you are using the original version from below make sure you remove it. And as with any code, make sure you fully test it before deploying to a live site.
~kevin

Google Instant Preview, designed to show you a visual preview of your search results, rolled out in early November 2010. You now have the ability to click a small magnifying glass icon next to each search result to get a snapshot of what the page looks like.
Google Instant Preview

Seems like a pretty helpful feature, but how do they do it? Well it would appear that Google has a new spider that crawls the web and takes snapshots of each page in its results. In order for them to get an accurate look at what the page looks like, this new bot needs to able to execute JavaScript. Here is the problem. Since it is executing JavaScript that means it is also firing off the SiteCatalyst code and is being counted as another visitor and is registering page views.

How can you tell if this new Google Web Preview bot hit your site? If you are capturing User Agent you can see it show up in that report:
User Agent Report

NOTE: If you are not capturing user agent and would like to, a super simple way would be to use the SiteCatalyst Dynamic Variable functionality and include s.eVarX=”D=User-Agent”; in your s_code.js file. Just insert the number of the eVar you would like to use (a s.prop would work too) and you are all set.

Another way to see if you are being affected with spider traffic in your report suite from the Google Preview Bot would be to check out a Browser report (Visitor Profile > Technology > Browsers) and filter it to only show visitors using Safari 3.1 and then trend it.
Browser Report
We can see that this report suite has recorded about an additional 15,000 visitors over the last week that is just attributed to Safari 3.1. Checking the User Agent we saw earlier, the Google Web Preview bot is registering itself as Safari 3.1.

Now that we can see that the Google Web Preview bot is having an effect on our traffic how do we get rid of it? We could block that bot in our robots.txt file, but I like having that additional functionality available for my visitors in the Google search results. I just don’t want it to execute my SiteCatalyst code. Well here is how to do it.

I call this my bot detection code (real catchy title, right?). I currently have it just set to look for the Google Web Preview bot, but it could easily be modified to exclude other bots that can execute JavaScript. Here is how you implement it. In your s_code file, at the top you will have a s_account variable that contains your report suite id. It will look something like this:

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.
Test 1
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.
Test 2
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!

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!

Implement Adobe SiteCatalyst in 5 Minutes (or less!)

One of the biggest things I always hear from people considering moving to Adobe SiteCatalyst is the fear of a difficult implementation. It feels to me that most people think they need to implement everything at once, and that is not so. You can just take baby steps and implement small sections at a time. Let’s get started with just a standard implementation to get things going. I’m going to show you how to do a basic implementation of SiteCatalyst in 5 minutes.

First we need to set up a new report suite from the SiteCatalyst Admin Console Report Suite Manager. That can be found by selecting Admin > Report Suites.
Admin Console
Once we are in the Report Suite Manager, select Create New > Report Suite.
Create New
This will open up the New Report Suite setup page. On this page we have two sections to deal with, the first being where we can choose what type of site we are creating the report suite for. I recommend just leaving this set at the default suite type. Since we plan of adding some neat customizations in the future as our analytics needs increase, the default will work fine for us right now.
Suite Type
Next on this page we have five items that need to be filled in. They are all marked with red stars, with the most important being the first one, Report Suite ID. Why is this the most important? Because it the only one we cannot change later. I recommend it should be something you can easily understand what it means. If your site is apple.com then I would just simply choose apple and not something cryptic like 89e7rghv9e7gh (yes I have seen that done before). It actually doesn’t matter what you choose (in case you had your heart set on using 89e7rghv9e7gh), anything will work, but choosing something simple may save some headaches in the future. The Site Title is what you want it to be referred to by in the SiteCatalyst interface, Time Zone is your time zone, Go Live Date is when the site is expected to launch (it must be a date in the future), and Estimated Page Views per Day is just what it says. This number is used by the Adobe engineers to determine what resources to dedicate to your site to ensure everything is recorded correctly. Remember any of these items (except Report Suite ID) can be changed later if you need to. There are other things listed here and you can fill them out or change them if you would like, they are not required in setting up the report suite. Fill out the five required fields, click submit and the report suite is created.
Configure Suite
There are some additional things we need to set up before we start with the actual data collection code. Head back to the Report Suite Manager and find you new suite in the list. Click it to highlight it and then mouse over the Edit Settings link. This will bring up a list of additional settings we can adjust. Remember this section. Later when you get more advanced with your SiteCatalyst data collection, this is where you will go to turn on and off variables for more advanced tracking. There are only two items we need to touch right now, and are going to be located under General.

Under Internal URL Filters you need to set what the domain of your site is. On every single page view there is a referrer. When your visitors go from your home page to your about us page, the referrer to that page is the home page. You do not want that showing up in your referrer reports, so this is where you list out the domain names that you do not want included in those reports. Quick tip: If your site is www.homes.com, and you enter homes.com in the URL filter, it will also filter out sites that have that name included in it, for example newhomes.com or cheaphomes.com. Add a period to the front of the domain name to make sure that only your site is filtered, .homes.com. You can also enter the subdomain with the URL in the filter if your site only lives at a single subdomain, or you can list all of them in the filter.
Internal URL FIlter

Next you want to hit the Paid Search Detection. In here you need to set up a query sting parameter that will be used for your paid search. Even if you do not plan on doing paid search fill this out any way. It is important in making sure your Search Engine and Search Keywords reports work properly.
Configure Suite

We created our report suite, filled out a handful of variables and we are now ready to start playing with the actual collection code. From the Admin Console Home you can find a direct link to the Code Manager, or you can find it from the navigation menu on the left.
Admin Console Home

In the Code Manger we can generate all types of code for what ever we decide to track. From mobile phone apps to flash video players, all the collection code is here. We just want to generate the simple JavaScript Tracking code. Nothing fancy. Select your report suite, set your character encoding or your currency type and click Generate Code. You will get a little pop up warning you to make sure you know what you are doing or the world will end. Just click OK and move on.
Code Manager

Your code is generated now. Take the contents that are under the Core Javascript File tab and save them in a file that you name s_code.js. Take that file and upload it to your web server where it can be accessed from every page of the site.
Code Manager
Now take the contents under the Page Code tab and paste that to every page of your site, right before the closing body tag. In that code you will see the place marked INSERT-DOMAIN-AND-PATH-TO-CODE-HERE. In this position enter the path to the s_code.js file that you previously uploaded.

That’s all there is to it. This should be easily to be accomplished in 5 minutes or less. We setup the report suite, generated the page code and the s_code and added them to the site. This will give us the basic recording of the site traffic, referrals and visitor information. After this is up and running we can go back and add in some additional elements to the s_code file and the page code to customize your SiteCatalyst implementation to your specific site.

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!