“I can’t find anything!”

This is the most common response we came across during the scoping and implementation of Search and Promote as the new internal search for Murdoch University.

Hardly surprising, given the issues with internal search that I covered in my previous post, but amazingly consistent!

In fact, one of the great truths we found during this project is that people truly don’t care where content is located, or whether it’s authenticated and/or accessible – they just wanted to type something in the search box, immediately find what they’re looking for, then carry on with their work.

We’ve now completed the implementation across our internal sites, and it’s working really well – so well that we’re now 2-3 weeks away from covering our external sites.

In my last post I promised to run through the implementation, however there’s a lot to talk about, so today I’ll cover SEO metatags (or the lack thereof), using multiple content sources, and how we integrated Search & Promote with SiteCatalyst to dynamically alter search result ranking.

Given the issues with internal search across campus and the wide range of staff and students that were more than happy to tell us just how bad it was, we decided to first implement Search & Promote across the internal sites where our primary audience are current staff and students.

Through the implementation of SiteCatalyst a few years back  across our network sites we have been able to segment our staff and student traffic, so we knew from the onset just how many searches each segment were doing, and how long on average they were taking.

Looking specifically at staff, approx 2,400 people collectively performed 234,131 searches in 2010, spending an average of 202 secs per search. Wow!

That equates to 13,137 hours, which, at an average of $40/hr, comes out to a $524,498 productivity cost. This figure alone should catch the attention of your key stakeholders and finance people.

Armed with that knowledge, we set the following key objective for the  Search & Promote trial across our internally facing sites;

• Reduce time staff spent searching by 10% by delivering a single set of filterable results, transparent of source, influenced by recent traffic.

Now that we had a clear objective, we could begin on the planning and implementation. We were greatly aided by a project team at Search & Promote – thanks John, Wally and Richard; you were all very helpful, and it was great working with each of you.

The first step was to set up the organic crawl of our internal sites, which largely consisted of listing the appropriate entry points;

And their corresponding URL masks (note the test feature that allows you to try your masks before saving them);

Search & Promote works on a number of pages crawled – your licensing allows you to go to a certain number of pages, and after that the pages are not added to your index. There was a bit of tweaking to figure out what that level was, however there’s a cool feature in Search & Promote that allows the crawl to continue and count the number of pages that you’ve gone over by so you at least have an idea of where you are. From there you can either increase your licensed limit, or identify the larger than expected sites and par down the number of pages found by using the error logs and URL masks.

Compensating for the lack of SEO content

One of the issues I’d talked about previously was a lack of the bare minimum SEO metadata across many sites, most of which we had no direct control over. We tackled this by using the metatag injection feature in Search & Promote, which can be configured to dynamically inject metadata during a crawl, based on a URL pattern. This metadata is then included in the index as if the metadata was already embedded within each page, and can range from standard title/description metatags, to custom tags that can be use to create search filters (facets).

We soon found, however, that a significant portion of internal content required authentication to access, which meant that the crawler could not get in to that content. The Search & Promote crawler can be given credentials to access that content, however our concern was that content was authenticated for a reason, and to show even a title or extract from authenticated content on a public search may give away too much.

Given that the “we can’t find anything!” comment included authenticated content and applications, we needed an alternate option for this implementation to be successful.

At Murdoch we have a database called the A-Z index, which is maintained by our IT area, and over the past 5-6 years has grown to include an entry for most of our authenticated content and applications. This was a perfect source of information, now we needed to somehow incorporate this content into our search results.

Enter a feature in Search & Promote called ‘index connectors’.

Incorporating multiple sources of content

The index connector feature within Search & Promote allows you to define a third party xml feed, xml file, or comma/tab delineated file as an alternate source of content to be crawled.

The IT at Murdoch team were able to provide us an xml feed out of the A-Z index which allowed the Search & Promote crawler to include each entry/link within the feed in its scheduled crawls, together with custom mappings for each tag within the entries  to predefined custom metatags;

Not only were we able to crawl the feed and include all the authenticated content as separate entries (‘restricted’ in the above screenshots), but we were able to alter the look and feel of the specific A-Z results within the wider search results, and account for a lack of  description within the feed.

The side-effect that we hadn’t counted on, but worked to our benefit, is that the A-Z index had entries for related non-Murdoch sites that were still of value to staff and students.

By having entries for the non-Murdoch sites in the A-Z as wayfinders, we didn’t need to crawl the actual sites themselves. This resulted in a significant reduction in the number of sites/pages we needed to organically crawl, while still providing our audience with a complete set of search results.

Using this same index connector functionality we were also able to incorporate the university’s campus directory listings via a new xml feed; whereas with the A-Z feed we only wanted to incorporate the results within the wider results set, we wanted results from the campus directory to always be the first results and be displayed in a table format, but more on the styling and positioning of these multiple content sources later.

Allowing for cyclical requests to ensure the most relevant results appear

In my previous post on Search & Promote, one of the key advantages the product had over its competitors was the ability to natively integrate with SiteCatalyst.

Via SiteCatalyst we already knew that our internal search terms follow highly cyclical patterns as our student (and staff) needs change over the semester. For example, the term ‘timetable’ is searched for throughout the semester, however the anticipated result changes as the semester progresses. At the beginning of semester, people are looking at for their semester timetable and towards the end their exam timetable.

In the past we’ve used custom coded mechanisms to help staff and students find what they’re looking for, however with Search & Promote we can take that to a whole new level!

Search & Promote allows you to define a data source within SiteCatalyst, in our case Global Production > Page Views, and then add ranking weight based on those values – the higher the weight, the higher the impact the SiteCatalyst data will have over your search results.

We defined s.prop41 under our Global Production suite in SiteCatalyst as SearchPromoteURL, and then used it to cross reference the Search & Promote crawled URLs with the associated Page Views data in SiteCatalyst;

Now, every day the last seven days worth of aggregated SiteCatalyst page view data is automatically downloaded and fed into the Search & Promote custom defined field SearchPromoteURL, which in turn is used in a ranking rule that increases the relevance of highly trafficked pages in the last seven days;

A good example of this in action are our sample and past exam papers in our Library website, where there is a separate page per letter – with the SearchPromoteURL ranking rule disabled, the pages are literally ranked A through to Z, as the other active ranking rules see them as equally relevant. However when the SearchPromoteURL ranking rule is in place, the top ranked exam page is Exams B, followed by P and I.

In the admin data report for “exams” below you can see how the ranking, relevance and score metrics are all the same for the exam paper pages, and that the differentiating ranking  factor is delivered by the page views;

The same ranking results can be seen on the front-end at http://search.murdoch.edu.au/?q=exams;

This is exactly what we set out to achieve, and it’s so far looking to have worked pretty well!

In part 2 of this post, I’ll cover how we combined all our sources of search results into a single set of user-centric, filterable search results, well as how we fared against our original objective of reducing time our staff spent search by 10%.

One of the things that stopped many companies from upgrading to SiteCatalyst v15 was the use of video.  Well that’s no longer the case, as v15 Video Measurement has now been fully released and is ready to go.

Video tagging changed from v14 to v15 and an updated way of measuring video was introduced, which required a few more things to be configured before it would actually work.  In my previous post Lights, Camera, Action…Video Measurement, I focused on how easy it was integrating the Brightcove platform for SiteCatalyst v14.

So, this is a functional post on how to integrate video measurement into SiteCatalyst 15, if you’re using the Brightcove platform.

Integrate and measure

There are still only really 10 steps involved:

1. From your Omniture Reporting Suite admin, download the AppMeasurementExtension.swf file.
2. Edit your report suite settings to enable video measurement (see below).
3. Create a config file.
4. Host the AppMeasurementExtension.swf file and the config file on your server.
5. Update your crossdomain.xml file to allow brightcove.com.
6. Upload your video to Brightcove.
7. Add a setting for your AppMeasurementExtension to be called.
8. Attach the video to a player and generate the website code.
9. Add the code to your website.
10. Play the video through your site and you’re done.

How easy could that be.  No flash programming.  No fuss.

New reports

The new set of video reports are fairly comprehensive.  You can also sub-relate by other eVars, and add in different success events so you can gauge how well they help in converting visitors.  Pathing on the video name also shows which videos they go through.

eVars, events and s.props

Video in v15 requires that you use a minimum of 4 events, 3 eVars, 1 optional s.prop (and a partridge in a pear tree).  While that sounds like a lot, they actually make much more sense than the old way of doing things.

So, your 3 eVars will be used for:

• Video Name
• Segment
• Content Type

Your 4 events will be used for:

• Video Time (in seconds) spent watching
• Video Views
• Video Completes (100% view)
• Video Segment Views

It’s also a good idea to use an 3 additional events as well, to track percentage viewed:

• 25% viewed
• 50% viewed
• 75% viewed

(Ok, so that’s actually 7 success events you need).

And your optional s.prop will be used for pathing between the different Videos.

Note: the Video Name eVar requires Full Sub Relations.  Now, on the face of it, that seems a bit weird given that all eVars are now fully-subrelatable. The reason for this is that if you’re running on v14 you can upgrade your video measurement now, while you’re waiting to upgrade to v15. Just note that with full-subs on the eVar, it won’t show up in the list.

Note: the Video Name sProp requires Pathing enabled before it becomes available in the dropdown too.

SiteCatalyst Video Management

In your report suite admin, after you’ve configured all of your eVars, events and s.props, select Edit to go to the new Video Management > Video Reporting section.

You’ll be presented with a list of requirements for Video.

When you select the checkbox, the dropdown next to it will appear listing all available eVars, events etc.  The first one, Video Name, will only appear if Full Subs are enabled on the eVar.  You can actually select new eVars and events from the list and it will create them and rename them in your admin console…but, it won’t do the optional events at the bottom.

Once you’ve populated the list of required variables, you can add in the optional variables (s.prop and your 3 percentage viewed events).  The optional events get added at the bottom where it says “Include additional Event”.

Hit save and you’re ready to create your config file.

It’s also a good idea to write them down on a bit of paper, so when you create you’re config file, you’ve got a handy reference.

Ours are as follows:

Standard eVars:

• Video Name = eVar50
• Segment = eVar36
• Content Type = eVar37

Standard events:

• Video Time Played (in seconds) spent watching = event31
• Video Views = event32
• Video Completes (100% view) = event33
• Video Segment Views = event34

Optional s.prop

• Video Name = prop23

Percentage viewed events:

• 25% viewed = event35
• 50% viewed = event36
• 75% viewed = event37

The main config file

If you’ve used Brightcove and SiteCatalyst before you’ll know that you create a config file with all of your SiteCatalyst variables declared in it, which is loaded into the AppMeasurementExtension file through the video player.  Easy enough to do.

Simply create a new XML file called config.xml and put it somewhere on your servers.

The file should contain the following:

<config>
<account>your-rsid</account>
<debugTracking>true</debugTracking>
<visitorNamespace>your-namespace</visitorNamespace>
<trackingServer>your-tracking-server</trackingServer>
<media>
<autoTrack>true</autoTrack>
<trackMilestones>25,50,75,100</trackMilestones>
<trackVars>events,eVar50,eVar36,eVar37</trackVars>
<trackEvents>
event31,event32,event33,event34,event35,event36,event37
</trackEvents>
<segmentByMilestones>true</segmentByMilestones>
<trackUsingContextData>true</trackUsingContextData>
<contextDataMapping>
<a.media.name>eVar50,prop23</a.media.name>
<a.media.segment>eVar36</a.media.segment>
<a.contentType>eVar37</a.contentType>
<a.media.timePlayed>event31</a.media.timePlayed>
<a.media.view>event32</a.media.view>
<a.media.segmentView>event34</a.media.segmentView>
<a.media.milestones>
<item name="25">event35</item>
<item name="50">event36</item>
<item name="75">event37</item>
<item name="100">event33</item>
</a.media.milestones>
</contextDataMapping>
</media>
</config>

As you’ll immediately notice, the config.xml file got a whole lot longer than the original.

The context data mapping section describes each variable and the name.  I found it easier to make a list of the names and values, write them down, then check them against my config when I’d finished, just to make sure everything was in the right spot.

Notice that event33 (our Video Complete event) is matched against the item.name=”100”.

AppMeasurementExtension

The next part is downloading the latest AppMeasurementExtension.swf file from your code repository inside  SiteCatalyst.  Once you’ve downloaded it, you need to upload it onto your server somewhere.

Brightcove

When you’ve uploaded your video to Brightcove, you edit/create a new player to include a custom plugin.

The plugin needs to know where the App Extension and Config file is.  This demo is located at:

http://www.elephantsandanalytics.com.au/omniture/
AppMeasurementExtension.swf
?s.configURL=www.elephantsandanalytics.com.au/config.xml

Note that this is all on one line.

And that’s pretty much it.  Again, how easy was that.

Now when you browse the video, and use something like Fiddler or WASP, you’ll see a number of new calls being made to the Adobe Omniture servers, at the beginning of the video play, during the plays and at the end.

Happy video’ing.

This topic was requested by one of my readers – thanks for the inspiration Dan. 

And it comes back to segmentation.  And the value derived from measuring your customers/members behaviors across your digital channels, and the impact they could be having on your conversion rates if you don’t segment.

Ok, so, we’ve all likely got some form of customer – either a lead, or a customer who has purchased, or a member, such as a policy-holder or a service-holder.  For the purpose of this post, I will call members, customers.

Why do we want to measure their activity?

Well there’s a number of reasons.

If we run a self-service site, we might want to know what self-service transactions are being done beyond the login (within the customer self-service portal, nowadays commonly called My{something or other}).

That’s pretty straightforward and you can achieve that with traditional metrics if you are reporting solely within that “site”.

But customers are not all the same.  There are business customers, there are residential customers, there different types of customers within each of those segments – business types, business size, residential locations, MOSAIC-based classifications of customers, demographics and so forth.  And guaranteed they will do stuff differently.  They purchase different products and services.  They’re interested in different content and so forth.

And many self-service sites are purely transactional in nature – change your address, update something or other, check usage of something or other etc.  Most of your content will be on the “outside” and these guys use that content too.  But they have a closer affinity to your brand and will use that content differently.

And the other big thing about them is, they’re customers.  They’ve converted.  Not only are they your golden opportunity to

a) cross-sell/up-sell and
b) observe their activity and figure out why they converted so you can better optimize

but (and possibly more importantly) unless you measure their activity, they are negatively impacting your conversion rates on your regular website and your average revenue per visit is understated.

Huh? Why?

Because they probably go through that site to get to their My{something or other} self-service site.

Consider this:

Let’s say you’re an insurance company.  Your acquisition team wants to know the sites conversion rate for product sales and the average revenue per visit.  You also have a self-service site and the way that most of them get to that site is through your regular homepage.  Suppose your overall traffic to your site is 350,000 visits per month and you get 10,000 product sales per month, with revenue of $500 per sale.  Suppose also that 200,000 visits per month go to your fabulous self-service site where they’re busy updating their info, checking on their policy and so forth.

If you DON’T strip out known customers, you’re under-reporting. 

Your average order value is unaffected – it’s still $500.  But your visit conversion rate is showing as 3%, and your average revenue per visit is $14.29.

If you strip out the known customers, your conversion rates just went through the roof.  It’s now 7% (10,000/150,000) and the average revenue per visit is $33.33 ($5,000,000/150,000).

Ok, a little extreme maybe, but you get the general idea.

So, measuring customers not only provides more accurate conversion rates, but also gives you better insights into their activity.

And SiteCatalyst allows you do all that – and more. 

Customer segmentation

Right, so you want to measure customer activity for a variety of reasons.

For basic customer segmentation, you’ll need an eVar and an s.prop and one or two success events.  The eVar will enable visibility of conversions back to them (revenue and the likes); the s.prop is used to segment your traffic-based reports by customer/non-customer type and the success events are for things like logins, failed logins etc.

If you’re measuring self-service activity, you’ll have another eVar for self-service transaction type and a counter success event.  These two are set every time the user completes a transaction.  You pass the type of transaction to the eVar and set the success event.  All pretty much no-brainer stuff.

If you really want to get value, you’ll also use an eVar to capture their memberID, userID or some other unique value that can be used for customer-type segmentation.

Basic segmentation – customer/non-customer

When a user does something that only a customer can do, or if they make a purchase, you set the eVar as “customer” or something similar.  You also set the success event, such as login, if that’s what they did. 

You will also need to set the s.prop to “customer” and you need to make sure it’s remembered and set again on every single page view.

The way to do this is through the getAndPersistValue plugin – a handy little plugin that will set a traffic prop automatically from a value in the cookie.

For example:

Let’s say that you have a My{something or other} self service site, and the user logs in.  Upon login, you would use the following in your s_code:

/* My Self Service Login */
/* Set User Type */
if((s.pageName.match(/loggedin/)){ // change for your page
/* serialised login and self service success success event*/
s.events="event1,event2";
s.eVar10="Customer"; // Customer Non Customer
s.eVar11="Login"; // Self service transaction name
}
/* Check existence of persisting prop10 - user type */
s.prop10=s.getAndPersistValue(s.eVar10,'s_prop10',365);
if(!s.prop10&&!s.eVar10) {
s.prop10="Non Customer";
s.eVar10=s.prop10;
}
/* Set persisting prop10 to value of the eVar10 */
s.prop10=s.getAndPersistValue(s.eVar10,'s_prop10',365);


Basically what happens is when the user logs in, the eVar is set to Customer.  The success events count the number of successful logins and also a general self-service transaction count.

Line 8 says set s.prop10 from the value of eVar10 and store it in a cookie for 365 days. 

Under non-logged in status, eVar10 will be empty, so line 9 is true (eVar10 has no value but s.prop10 may have a value).  If that’s the case, set it Non Customer and set the eVar to Non Customer.

Then line 14 re-evaluates s.prop10 from eVar10 and resets itself.  Odd I know, but it works.

You end up with a number of different states:

1) For non customers eVar10 and s.prop10 = Non Customer

2) For customers in the same session, eVar10 and s.prop10 will be Customer

3) For customers in a later session, eVar10 and s.prop10 will be Customer (because of the getAndPersistValue)

A word about the success events:

I’ve used two success events – event1 as a discrete count of logins and another as a general count of self service transactions.  You could combine, but I like the separate count and you can serialise the login event so you only count it once per session – giving an idea of true logins, rather than repeat logins per session.  The self-service transaction type (eVar11) would generate a report of all the different types of transactions by customer type, when viewed using the Self Service Transaction event (event2), or specifically logins (event1).

The Result

Now you have the capability to report on not only logins and self-service transactions types, but also your conversion rates are more representative of real rates by Non-Customers (and Customers – very important for retention purposes), and you can see their behaviors across pages when you use the s.prop. 

In v15, or with Discover, you can create and use these two segment values for more analysis to filter out or filter in based on Customer or Non Customer.

Of course, the next thing you’ll want to do is further enhance your Customer segments with demographics, or those additional business segments, using extracts from your customer database.  Take a look at 1 million rows and it still wants more, for an understanding of how that works.

So, segment, strip out your non-customers and re-run your conversion rates.  Now do the same for customers.  And now start looking at what customers did prior to conversion so you can influence those non-customers to do the same thing. 

My final tip…use Test&Target to provide more relevant content to Customers or Non Customers…because, now you can identify them.

Well, it’s August and true to their word, Adobe upgraded us to SiteCatalyst v15 on the 1st, and so I thought I’d share a few of the golden nuggets within v15.

I was thinking about how to order them…do I go by not bad to flamin’ eck, that’s awesome? Or start with the big bang and then let it continue to smoulder throughout? 

The problem is there are too many new and great features that you can’t really put them in any type of order.  They appeal to you on different levels, from functionality, to UI, to analysis, to reporting, to combination segmentation and sub reporting.

And as this post is kind of huge (sorry you might a coffee and a bagel on this one), here’s a little taste of what’s covered in it:

•  Segment, the all powerful segmentation
•  New segments
•  Site Overview Report
•  Segmented Overview Report
•  Side by Side segments (well sort of)
•  Key Metrics report
•  Normalization (one of my new best friends)
•  Visits, Visitors and PageViews
•  Full Sub Relations – multiple breakdowns on eVars
•  Traffic prop breakdowns
•  Login as another user
•  Calendar events specific to report suites
•  Significant changes

So let’s start with the big one that everyone knows about, or at least should.

Segments

Unless you’ve been living under a rock for the last 5 months, you’ll have heard about the segmentation capability within SiteCatalyst v15.

Out of the box, it comes with 7 pre-defined segments that are shared across SiteCatalyst, Discover, and Test&Target.

These segments were chosen because, according to Ben Gaines at Adobe, they are “valid (and important!) for all of our users—across vertical and market size. We’ve also seen these types of segments predict different behavior across a variety of actions: registration flows, purchases, and general site browsing.”

New Segments

You can, of course, create your own segments on the fly and apply them to any report as well.  If you’re a Discover user, you can create them in Discover and save them back into SiteCatalyst for later use.

I’ve not yet figured out how to create a segment available across all report suites, without creating it in Discover.  Perhaps Adobe can help on this one?

Segments can also be used in Test&Target too. There’s a one-click little target icon next to the segment box which opens up a new A/B..n campaign in Test&Target, although it doesn’t specifically target custom segments that you’ve created as that’s a little more complex – but the preconfigured ones are available for use immediately.

Site Overview report

This new report is actually a dashboard, but, it’s highly useful and can be modified to your needs.  Using the same features as dashboards, you can set this one to your landing page when you log in (no more pinwheel).

From those reportlets, you can get to the main report by clicking on the name of the reportlet.

You can also change the date and the whole thing will rerun against the new dates.

Segmented Overview

If you want to see a particular reportlet using a specific segment without running the whole dashboard again, just click on the report suite name within the reportlet and a little popdown appears, allowing you to select not only the report suite, but also a segment to use.

When you select a new segment, it will re-run the reportlet, not the dashboard, against the new segment.

 

Of course if you want to run the entire dashboard against the new segment, then just select the segment in the main segment dropdown and you’ll get instant gratification.

Side by Side Segments

Ok, so you still need Discover to do comparative segmentation, but, there is a sneaky little way to show two segments at the same time, using a dashboard report.  Generate your base report, for example, I’ve used calculated metrics on the new Key Metrics report (see below for more info).

Then apply a segment, and add it to a dashboard.  Apply another segment and add it to the same dashboard.

Then go to the dashboard layout editor (which is also new), and just put both reportlets into the new dashboard.

What you get is a visualisation of the two (or more) segments, plotted over time.

Key metrics report

One of my personal new favourites here is the Key Metrics report, which allows you to put multiple metrics on a time-based report.  This was always one of the big challenges before, but, they listened to us, and here it is.  And there’s a bunch of nifty things about this report that I just love!

Firstly, as shown above, you can add multiple metrics, or calculated metrics to the report – something you could never do before.  For instance, you can add Visitors, Visits, Page Views, Conversion Metrics, Conversion Rates and so on.

Now that you’ve got the key metrics trended side by side, every worthy analysis ninja will look to segment that information – so, just go ahead and apply those segments.

One of the great things about this report is you can do calculated metrics too…side by side (see the image for side by side segments above).

Normalization

Ah, what a great idea this was.  Normalize your data on the Key Metrics Report.  As you can see from the above screen shot, the page views data is overwhelming the trending report, making it difficult to view some of the trends for the other metrics.

But that’s ok now – just normalize it.  Same report as above, just normalized.  And the other metrics pop up.

Ok, so those metrics that I’ve used don’t really tell us anything.  How about this one then?

I’ve highlighted dates when certain metrics weren’t in line with the norm.

Now you have something to go and look at.  Why, on those dates, did those metrics “pop”.  What did you do?  Did they vary by segment?  And what can you do to nudge those that didn’t behave similarly?  You can learn from that.

Love this report.  One of my new best friends.

Visits Visitors & PageViews

Yes, these are now available across most conversion reports.  You used to be able to get Visits and Visitors by special request, but now, they’re enabled and you get Page Views as well.  And they’re particularly useful across things like campaign reports, referring domains, search engines, keywords etc.

Full Sub Relations – multiple breakdowns on eVars

Remember the days when you had to think carefully about setting up subrelations on eVars…should you use Full or Basic?  And remember the impact if you got it wrong, or realized later that you needed Full Sub Relations on a key eVar?

Well, those days are gone.

You now get full subrelations on all eVars (although I don’t quite understand why the admin asks you still for the type of subrelation you want when you create an eVar – Omniture…can you add any info here?)

In this example, I’ve used two eVars, both are set up in the admin as Basic Subrelations, but I’m able to now break one down by the other, and then I’ve added a filter to remove the keyword “murdoch” from the report.  As you can see, it’s a conversion report, with Unique Visitors, Visits and Page Views, as well as success events.

Once again, you can sub-segment this report against any of your existing (or on-the-fly) segments. Yay!!!

Traffic Prop breakdowns

Another great feature is the ability to now breakdown key traffic props, such as the referring domain report.  It used to have basically “instances” and allowed you to put in success events.

No more.

Now you can not only see Visits, Visitors and Page Views, as well as success events, but you can also now break it down by things like Average Time on Site, and, all eVars…wow!  Couldn’t do anything like that in v14.

And you can flip it too…start with a conversion report, such as our Figure Out Your Life segments, and you can break them down, by Referring Domains, or Time Spent per Visit etc.

Ok, long post I know, but, there’s so much going on that I’ll probably add more posts in the future on the new features.

Just to touch on some of the other new things as well…

Login as another user

Do you have a user that’s experiencing problems?  Well, now you can log in as that user.  Go to the admin and views the users, then click on “Login as this user”.

Report specific calendar events

One of the problems with SC14 calendar events was that they showed up across every other report suite…which made it very unhelpful to users that had somewhat restricted views, such as global sites and regional sites.  The UK office didn’t really care that you ran a specific promotion, but they saw it anyway.

Now you can apply a calendar event to a specific report suite only.  To be honest, the link for it is a little tough to spot, so I’ve put a whopping great big arrow to it:

 

Ok, now I’ve covered the things that I’m excited about, there are a few things that new users need to understand with this version.

This has all come about because of the way that data is stored.  It used to be pre-processed into the reports, which resulted in the limitation on segmentation and other capabilities such as breakdowns.  But Discover always worked off the original unprocessed data, which also led to some differences in the data, especially around unique visitor counts and classification deduping.

SiteCatalyst v15 now runs off the raw data – the same as Discover, so the datasets are the same, hence the reports are the same.

Key Differences

There are some key differences between v14 and v15 that you need to be aware of:

Visits for Non-Cookied Visitors

All visitors, regardless of them accepting a cookie are now included in Visit counts and pathing data.  But this increases your Visits metric, so your conversion rates will likely go down a bit.  In testing, the increase of visits was about 0.5% for first-party cookies, and 5-12% for third party cookies.  Another great reason why you should be on first party cookies (contact your account manager if your tracking server has 2o7.net in it).

Time Spent metric 

Both the time spent per visit and the average time spent on page metric now use all server calls to generate the metric, which is much improved on SC14.  What this means is that non-page view data is included in time spent reports, such as custom links etc.  And, they’re no longer bucketed.  It now works off an average for each and every individual page view.

De-duplicated Visits and Visitors in Classifications 

Classifications are now correctly de-duplicated, meaning that when you group things using classifications, they are now de-duplicated, whereas before, they would count each instance of a visit or visitor.

Ben Gaines wrote an excellent blog post about these and a couple of others which is definitely worth reading and getting to grips with.

Summary

What can you say?

Thank you, Omniture Business Unit within Adobe, for listening to us.  These changes make the platform even more useful than it already was and clearly makes it a powerhouse in the web analytics space.

With these, and many other changes made, we’re able to provide our organizations with even more insights that lead to more business optimization capabilities, a better ROI and hopefully more analysis ninjas.

Thanks guys!