So, you can’t mix eVars and sProps right…  But you still want to know certain things like what pages were viewed from visitors conducting a search, or which campaigns are driving most page views – and you don’t have Discover.

Well, there’s two parts to this post and a bunch of answers…so read on.

Page View Success Event

Firstly, set up a Page View Success Event.

Relatively simple concept.  Set a success event every time a page viewed.  It will result in a report-specific count of pages (and should be very close to actual page views), BUT, you can see it on Conversion Reports…such as Campaign Reports, or Search Reports.

And it’s easy to implement into your s_code:

/* append page velocity to the existing event, or set a new event */
if(s.events){
s.events = s.events + "," + "event13";
}else{
s.events = "event13";
}

In the above example, I’m using event13 to be my Page View Success Event.  In SiteCatalyst admin, I’ve created the success event and called it Page Velocity.  The event is created as a Counter type event.

The code basically says that if s.events is already populated with a value, then append it with “,event13″.  If s.events wasn’t populated, then just set it as event13.

Don’t forget to use the comma…you don’t want to mess up all your production events do you.

Now, every time a page is viewed, s.events will be either appended to, or set distinctly.

Ok – pretty straightforward – and pretty boring stuff.

But now, let’s open a campaign report to start with and add the metric “Page Velocity” to it.

Next, I created a calculated metric – CT/PVs, being Page Velocity /  Click Throughs – a rudimentary engagement value.  What it suggests is that Organic traffic views about 5 pages per click through, versus nearly 14 pages from traffic that comes from Social Media sites.  In case you’re wondering how we got Social Media sites, we use the Unified Traffic Sources VISTA rule.  You can also drill down on this report through your SAINT classifications.

So, now we are able to see Page View counts against conversion reports.

Let’s take it one step further.

Page Views by Campaign

Suppose you want to see what pages they view by campaign.

By default, SiteCatalyst won’t allow you to see that, but there are plenty of reasons why you actually need it.  From campaign reports, to search keyword reports – you could benefit from knowing pages viewed by that segment.  If you don’t have Discover, this is one thing that is somewhat frustrating.

Ah, but you can do it, although it’s a bit more work, but let’s walk through it.

Firstly, you need to store PageNames into an eVar.  Once you’ve done that, you’re set.  It’s also best to create an s.prop at the same time you create the eVar.

/* Set the s.prop as Page Name*/
	if(!s.prop19)
	s.prop19=s.pageName;

/* Set the PageName eVar */
	if(s.prop19&&!s.eVar19) s.eVar19=s.prop19;

In the above code, I’ve used s.prop19 to set my pagename (so that I can use it in reports later).  I’ve also set my eVar19 to be the same as my prop19 (which is pageName)

Set these up in the Admin console as well in SiteCatalyst.   I named my conversion variable “Pagename (conv)”  so that I can distinguish it in segment managers.

Right, now you can breakdown your campaigns (because by default Campaigns have Full Subrelations enabled on them), by Page Velocity, and then by Pagename (conv).

For example:

So in the 5×5 example above, visitors from Organic Search viewed around 1.5 million pages, of which, around 200,000 were to our homepage.  Click on the Search Organic link in the report and you can drill down further.

Obviously, I’ve just used overall campaign traffic in the above example.  You can also drill down on your campaign reports, through your SAINT classifications to, say, a creative element, and see what pages were viewed from people who clicked through from that element.

Now, here’s another example.

Internal Search Traffic

Let’s assume you track your internal search keywords.  I know you all do, because they are a gold-mine of information. Make sure though that you track them in both an s.prop and an eVar.  Why?  Most people track them as just an s.prop, which gives you straight-forward counts of keywords.  But as an eVar, you can also then see conversions against those keywords, and, with the changes you’ve just made above, you will probably be able to see what pages are viewed following a keyword search.

However, you will need to set up Full Subrelations on your eVar.

The above shows that on a particular day, there were 242 page views following a search for the word “bookshop”.  The pages visited are shown in the image to the right.

So, through simple code changes, we’ve successfully managed to get some visibility on activity within conversion reports.

Hope that all helps.

If you’ve ever wanted to know bounce rates by different campaigns, or other segments, there’s a relatively easy way to do it in SiteCatalyst, which also brings other benefits with it.

Despite the fact that Bounce is not a native metric for SiteCatalyst, it’s easy enough to calculate it (single access/entries)…but as you’ll realise, you cannot use that metric on Campaigns (or any eVar for that matter), because they are traffic props.

So, to get Bounce metrics onto a campaign report, you simply concatenate your campaign code to a page name and store it into an s.prop.  The following is an example of that code:

if(!s.campaign){ s.prop26=s.pageName; }else{ s.prop26=s.campaign+"|"+s.pageName;}

In the example above, I’ve used s.prop26 to store the concatenated values.  In the Admin for the report suite, under Traffic variables, create s.prop26 as Campaign Pathing.

At this point, you should also call support, or use the live chat and ask them to enable pathing on that s.prop.  By doing so, you immediately enable the two metrics that you’ll need to see bounce – single access and entries.

Once you’ve done that, everytime a campaign code is seen, it will be stored into s.prop26, followed by the page name.  Bear in mind this only occurs on the first page that the user visits.

Campaign Bounce Rates

Now you’ll be able to create a report that shows campaign codes and their respective bounce rates:

As the above report shows every instance of the s.prop, you can then filter on either a specific campaign code, or on a specific page name.  So for example, if you run multiple campaigns to a product page, simply filter on the page name.  You’ll get the added benefit of seeing “non-campaign” traffic to that page too.

That’s not the only benefit to concatenating s.props together.  You could do the same thing for different segments to understand how they interact with your site.  For example, you could put Visitor Type at the beginning, Customer or Non-Customer; or any combination really.

Just remember that there is a limit to the amount of characters that an s.prop will store…and you don’t want to exceed the 500,000 unique monthly values on s.props either.

There’s another benefit to this.

Campaign Pathing

Campaign pathing now works…you’ll now be able to see pathing from specific campaign codes (or the other segments you have put in there).

Simply create a pathing report to see where people go when they come in from a specific campaign code.

Despite the fact that the subsequent pages don’t contain the campaign code, you can be assured that they represent the traffic from the same segment that started this journey.