Recently I was speaking to someone who was in the process of creating an tablet experience for their visitors. At one point they asked the question “of my iPad visitors, how do I find out in what format do they view my site the most in, landscape or portrait?”. I started going through all of the reports in SiteCatalyst and tried to find the answer, but that information just was not available. So I decided to whip a little bit of code that would figure this out for us. I call this the screenOrientation plug-in.
Basically what this will do is it will check to see in what position the mobile visitor is viewing the site in, whether they are viewing the site in a portrait or a landscape view when the page loads, and capture that value into a SiteCatalyst variable.
To implement this plug-in you first need to take this code, and add it to your s_code file near the rest of your plug-ins.
function screenOrientation(){switch(window.orientation){case 0:case 180:return("Portrait");break;case 90:case -90:return("Landscape");}window.scroll(0,0)}
Next in the do_plugins section of the s_code file, add the call to the plug-in to what ever SiteCatalyst variable you want this data captured in. In the example here you can see I am capturing it in s.prop1
s.prop1=screenOrientation();
Thats all it takes. Once the code is implemented, if the device does not have an orientation value the variable will not capture anything, but if the visitor is on a mobile device with an orientation value, the value of Landscape or Portrait will be captured on each page load. You will end up with a report that looks something like this:
To make it easier to access the report I also moved it into the Mobile report menu by using the customize menus option in the admin console of SiteCatalyst.
One of the most common things I get asked to track are specific links on the website. Typically to do that I would use a custom link tracking function. This typically involves adding a large chunk of JavaScript code to each link, or adding a function to your s_code file and then calling that function using an onClick function added directly to the link. That methodology works fine, and I’ve been doing it forever. But that means working with IT to add more code to your pages, something I want to try to avoid as much as possible. So how can we make the implementation of our link tracking quicker and use less code? If you haven’t figured it out by now, we’re going to use some jQuery.
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.
At the Omniture Summit earlier this month, SiteCatalyst 15 was announced. There has been a lot said about the new tools it will offer but not much about the overall UI appearance update. Here is a quick look showing some of the changes you will see in the UI of SiteCatalyst 15.
The SiteCatalyst Target report is one of my favorite reports that I don’t see used enough. THis video gives you a brief introduction to the report, and walks you through setting one up, and how to view the results.
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.
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:
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.
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.
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.
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.
A Solution Design Document is a complete blueprint of your web analytics implementation. It outlines where every variable is set and why. It can really be a lifesaver. You should start keeping a solution design document as soon as you begin your implementation. Every time you add a prop, an evar, an event or any other variable, make sure you add it in there. Every time you make a change to your implementation, make note of it in there. It’s an easy place to go to see what variables are being used for what where they are being set and which ones are still available.
“But do I really need to keep track of everything to that level of detail, just checking the Admin console has been working well for us.” Well have you ever opened a report and find information there that shouldn’t be there?
How did that get in there? It’s being set somewhere in our implementation, but where? What page sets that variable? What function could set it? A quick check of our solution design document and we can see every place were that particular prop is set, well where they should be set. If one of your developers decided to get the implementation and set a variable in a non traditional way, it can be a real nightmare trying to figure out what was done. Without that you could waste a lot of time hunting through code searching for where a random variable is being set.
Here is an example spreadsheet that you can use as a basis to start your Solution Design Document: Sample Solution Design Document
If you have a large team that all have their hands in your web analytics implementation, it may be beneficial to could place the solution design document in a location where the different members of your team can have access and add to it, like for example Google Docs or some other shared folder or public drive.
