One of the big problems with single page microsites is that traditional measures, such as bounce rates, engagement time, scrolling etc, all go out the window because there is no “second page” activity by the user.
Take, for example, a recent press-release microsite that we did at Murdoch University. The press release is about snake bites and what owners can do to protect their pets. There’s a bunch of information on the page, including an infographic, downloadable files, images, and other stuff.
The problem is, as the user interacts with the page content, they don’t actually move from page to page – which represented quite a challenge in the way it’s measured.
For instance, as there is no “second page”, there is no time spent on page metrics – because to measure that, you need the time difference between page 1 and page 2.
Bounce would be around 100% too…it’s the landing page, and it’s the exit page.
SiteCatalyst doesn’t record time between clicks when you use custom link tracking. And even if the user interacts with the infographic (downloads it), clicks on the Flickr gallery exit link etc, there’s still no time recorded and no “second page”, so that doesn’t help either.
So, what to do?
Well, it’s possible to do it, but it takes a tiny bit of extra code to enable it all.
Assuming that your page of content has some interactivity on it that the user can click on, you can treat those clicks as page views. In doing so, you’ll have all of the standard metrics available to you in SiteCatalyst, including pathing.
Our single page of content has a right hand side module that expands/contracts to reveal other content, such as documents, contact information, images and so forth. We record clicks to those sections as separate page views, by using some custom code attached to the link and a separate JS file (see the nitty gritty bit below).
Each interaction, for example, a click on the tab to expand the content on the right hand side, will then appear in the pages report and you can then add in your desired metrics, including bounce, time on page etc.
One thing to note though, time on page will essentially be interpreted as the time on the piece of content between clicks. If you want true time on page, then you should use average time on site, providing you’re reporting this into a separate report suite.
The other benefit to this is that you can also see how much time they spend within each “section” on the right hand side.
So, to the nitty gritty of it all
Firstly, make sure you have the s_code implemented normally on the page. When the page initially loads, it fires off all of the information as usual including campaign codes, referrer and so forth.
Then add a special class and a unique ID to every link on the page that you want tracked, add in the special JS file (see below) and you’re basically up and running.
Clicks as Page Views
To get the clicks tracked as separate page views, you need to fire off the s_code again, each time a click occurs.
We created a piece of custom code that enables you to just name the link using an ID and add in a special CSS class on each link. Then, with the custom JS code as well, located at the top of the page, each time the user clicks on a link, the ID is passed to the custom code and the s_code refires.
For example:
<a href=”#”
class=”omn_click head”
id=”FlickrLink_low_res“>Snakebite low res images</a>
The special class is “omn_click” and the ID must be a unique ID – we’ve named ours as if it were a page name, so that we can understand it better in the reports.
The custom JS file that we use is called “omniture_clicktracking.js” and you can download it from our site and use it as you see fit. You’ll need to modify the props and eVars though depending upon what you want tracked. The s_code for the particular page can also be viewed.
The custom file gets the name of the ID through a bit of JS wizardry and creates a new object called vars. Then by passing in the new values that we want to see, it re-executes the s_code but passes in the new values, by using s.t(vars); instead of just s.t();
The code snippet below shows what I mean by that.
vars = new Object();
vars.pageName=omn_code;
vars.eVar3=s.eVar2 + “:” + omn_code;
vars.eVar4=vars.eVar3;
vars.eVar7=vars.eVar3;
vars.eVar5=s.prop5;
vars.eVar10=s.prop10;
vars.hier1 = vars.eVar3.replace(new RegExp(/:/g),”|”);
s.t(vars);
One thing to remember is that there are values that are already set because the s_code has already fired on the page when the page loads. So, by getting it to re-fire, those existing values will be re-sent to Omniture. The trick is then to change only the values you want to change.
We make sure that we change the pageName variable and a few others, so that in our page reports, we have the name of the site:section:pagename as site:section:link clicked (see below for how we change the pageName using the s_code)
/* Set Page Name */
if(!s.pageName) {
s.pageName=s.prop1 + “:” + s.prop2 + “:main page”;
}else{
s.pageName=s.prop1 + “:” + s.prop2 + “:” + s.pageName;
};
The second time this code runs, when they click a link, it executes the “else” statement. It concatenates prop1, prop2 and the pageName (being the ID from the link) together to form the new pageName. Then the rest of the s_code executes, passing all of the other s.props, eVars and events into SiteCatalyst.
Now we have an ability to properly measure user engagement on this page, by treating the links as separate page views, bounce rates are accurate and time on page becomes visible to us.
Hope that helps.
