One of the things that’s not “native” to SiteCatalyst reporting is Time Spent by Referring Domain, which can be quite a useful segment to use.  So here’s a quick tip to get it working.

The report below shows the end result; Time Spent by Traffic Source (a new custom insight prop).  The entry marked as “direct” are visitors that had no referrer string.

Time Spent is enabled by pathing a traffic prop (custom insight).  So to get Time Spent by Traffic Source you need to do a couple of little things.

Step 1 – Create a Prop

In the admin, create a new traffic prop and an eVar (if you want conversions by this too).  I named mine Traffic Source (p) and Traffic Source (c) – just to not confuse them with the native Referring-based reports.

Then ask Client Care to enable pathing on the traffic prop.

Step 2 – Modify your s_code

The following snippet of code should be added into your s_code, along with all of your other rules.  I’ve used s.prop7 and s.eVar16 for my new Traffic Sources reports.

/* Set persisting referrer */
if(document.referrer){
s_trafficsource = document.referrer.split(‘/’)[2]; // get the host
    if(s_trafficsource != window.location.host){
        s.prop7=s.getAndPersistValue(s_trafficsource,’s_referrer’,7);
        s.eVar16 = s.prop7;
        }else{
        // same referrer as site
        s_prop7=s.getPreviousValue(s.prop7,’gpv_ref’);
        s.prop7=s.getAndPersistValue(s.eVar16,’s_referrer’,7);
        s.eVar16=s.prop7
        }
    }else{
    // no referrer – so direct
    s_trafficsource = "direct";
    s.prop7=s.getAndPersistValue(s_trafficsource,’s_referrer’,7);
    s.eVar16=s.prop7
    }
s.prop7=s.getAndPersistValue(s.eVar16,’s_referrer’,7);

You’ll see from the above that it also uses the getAndPersistValue and getPreviousValue plugins.  If you don’t have them they are available for download through the Help section of SiteCatalyst.

Basically, if there’s a referring domain, it’s initially set and persisted through the getAndPersistValue plugin.  Then it’s passed from page to page via the combination of getPreviousValue and getAndPersistValue.

For those that don’t have a referrer, then it’s just set as "direct” initially and then persisted.

And that’s all there is to it.  The pathing reports that this enables actually don’t show too much so you might want to disable them (they do show multi-traffic sources during the same visit though).

I thought I’d write this one given the general lack of information available on the web around getting Flowplayer reporting into SiteCatalyst v15.

I recently worked with a client who uses Flowplayer and we needed to get them ready to upgrade to v15.  The challenge was, Flowplayer has no information about integration and what’s out there on the web seems to be for v14 code.  Additionally, with Flowplayer you can’t use the AppMeasurementExtension – you have to use the JavaScript methods.

So, with a little struggling and some help from Chris Meares (a fellow beta tester) over at Semphonic, we managed to get it all working properly.

I’ve added code files for you at the bottom of this post because the formatting is not the greatest.

Step 1 – Configure Video Measurement

Firstly, you need to assign your eVars, s.props and events for video measurement and configure them in the admin UI of SiteCatalyst.  Note that you’ll need to give one of the eVars full-subrelations.  Also you’ll need to enable pathing on the prop if you want to see video paths.

As per the previous post, you need 3 eVars, 7 events and an s.prop.

Once you saved your configuration the new video reports will become available in the reporting interface.

Step 2 – Media Module

Get the latest media module and put it into your s_code file.

I’ve made available the media module that I used as I could no longer find it anywhere in the admin.  Replace your existing media module (if you have one), with this one.

If you don’t have a media module, then this goes into your s_code, just after the section named

/****************************** MODULES *****************************/
/* Module: Media */

[paste the media module here]

/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=”,s_objectID;function s_gi(un,pg,ss){var …

Step 3 – Add media variables to s_code

Just before the Media Module section of your s_code and just after your tracking server value, you will need to add in the media variables:

s.loadModule(“Media”)
s.Media.autoTrack=false;
s.Media.trackMilestones=”25,50,75,100″;
s.Media.segmentByMilestones =true;
s.Media.playerName=”Flowplayer”;
s.Media.trackWhilePlaying=true;
s.Media.trackUsingContextData =true;
s.Media.trackVars=”events,eVar31,eVar51,eVar52,prop31″;
s.Media.trackEvents=”event9,event55,event56,event57,event58,event59,event60″;
s.Media.contextDataMapping = {
“a.media.name”:”eVar31,prop31″,
“a.media.segment”:”eVar51″,
“a.contentType”:”eVar52″,
“a.media.timePlayed”:”event55″,
“a.media.view”:”event9″,
“a.media.segmentView”:”event57″,
“a.media.milestones”:{
25:”event58″,
50:”event59″,
75:”event60″,
100:”event56″
}
}

You’ll need to modify the variables as per your configuration from Step 1.  Make sure you put them all in the right place and use all of the variables that you set up.

Step 4 – Modify your video player code

This step requires that you go back to your video player code and add in special handlers to “listen” so that they react when certain things happen.

With Flowplayer, you’ll have access to the clip: function.  This is where the handlers are put so that you can call the applicable Omniture video tracking functions:

<script type=”text/javascript”>
var omniMediaDetails = {“title”:”Test Video”}; // Name of Video
$f(“fzplayer”, { src: “flowplayer.commercial-3.2.5.swf”, wmode: “transparent”  }, {
clip: {
/* ——————————- */
// track start event for this clip
onStart: function(clip) {
s.Media.open(omniMediaDetails.title,clip.fullDuration,clip.url);
s.Media.play(omniMediaDetails.title,0);
},
/* ——————————- */
// track pause event for this clip. time (in seconds) is also tracked
onPause: function(clip) {
s.Media.stop(omniMediaDetails.title,parseInt(this.getTime()));
},
/* ——————————- */
// track resume event for this clip. time (in seconds) is also tracked
onResume: function(clip) {
s.Media.play(omniMediaDetails.title,parseInt(this.getTime()));
},
/* ——————————- */
// track stop event for this clip. time is also tracked
onStop: function(clip) {
s.Media.stop(omniMediaDetails.title,parseInt(this.getTime()));
},
/* ——————————- */
// track fast foward and rewind. time is also tracked
onSeek: function(clip) {
s.Media.play(omniMediaDetails.title,parseInt(this.getTime()));
},
/* ——————————- */
// track finish event for this clip
onFinish: function(clip) {
s.Media.stop(omniMediaDetails.title,parseInt(this.getTime()));
s.Media.close(omniMediaDetails.title);
}
},
/* ——————————- */
// show stop button so we can see stop events too
plugins: {
controls: {
stop: true
}
}
});

</script>

Step 5 – Verify

To verify that the correct variables are being sent at the correct time, use WASP or Charles or Fiddler.  The output should be something like what’s shown below.  You’ll get an event/events fired off at the start/25/50/75/100% milestones:

If you see something similar to what’s shown below as your pev3 variable, then you’re not using the correct Media Module:

No fixed length video?

If you are streaming videos with no end, (e.g. a running newscast or something like that), then you’ll need to change your tracking to s.media.trackSeconds instead of s.media.segmentByMilestones.

We added a variable into the player code (s_videolive) to set whether it was a “live” feed or if it was a known-length video, and then modified the in-page footer code as follows:

   if(s_videolive && s_videolive == “false”){
// Non Streaming Video
s.Media.trackMilestones=”25,50,75,100″;
s.Media.segmentByMilestones =true;
}else{
// Streaming Video
s.Media.trackSeconds = 30;
s.Media.segmentByMilestones =false;
}
var s_code=s.t();
if(s_code)document.write(s_code);

If it’s not a live feed then its tracked using start/25/50/75/100 milestones, otherwise, it’s tracked every 30 seconds.

Files

Adobe Omniture SiteCatalyst v15 Media Module

Media Variables

Flowplayer Sample Code

Help Files

Adobe has also put together some very good documentation on measuring video, especially around the use of the AppMeasurementExtension.

Example Video

Watch a video measured using SiteCatalyst, Flowplayer, and TagManager.

As I find myself sitting in Auckland International Airport, waiting 12 hours for my next flight to LA (it’s 2am Perth time so I’m not quite with it), I figured what better time to write about success event pathing, as apparently my success event pathing for this trip wasn’t quite optimised for connecting flights at reasonable hours.

One of the things that you want to know about your site is the order in which certain events happen.  If you’re using success events for various things, like tracking self-service transactions, or leads, purchases etc, it’s important to know the most popular order in which visitors interact.

Now, admittedly, if you’re lucky, you could get some of this through page pathing…but as they’re pages, you end up with a bunch of clutter in between and unless those key events happen almost simultaneously, you’ll struggle to get the information you need.

You could use the Path Finder if you’re on SiteCatalyst v14, but it v15 it’s no longer available.  You could use the Fall Out report to generate some insights, but again, it’s not optimal.

If you want to know which events people interact with after a specific event, or prior to a specific event, then you need to implement Success Event Pathing.

Quite simply, you just set an s.prop each time specific success events are set.  You pass the name of the success event into the s.prop and ask Client Care to enable pathing on the prop.

What could be easier.

In the following example, s.prop45 is out “Success Event Pathing” traffic prop.
/* Success Event Pathing */
if (s.events){
if (s.events.match(/event1,/)){s.prop45="Internal Search";
}else if (s.events.match(/event2,/)){s.prop45="Lead Start";
}else if (s.events.match(/event3,/)){s.prop45="Lead Complete";
}else if (s.events.match(/event4,/)){s.prop45="App Start";
}else if (s.events.match(/event5/)){s.prop45="Course View";
}else if (s.events.match(/event6/)){s.prop45="Tool Used";
}else if (s.events.match(/event10/)){s.prop45="Form Start";
}else if (s.events.match(/event11/)){s.prop45="App Complete";
}else if (s.events.match(/event12/)){s.prop45="Form Complete";
}else if (s.events.match(/event16/)){s.prop45="Social Share";
}else{}
}
First we check that s.events exist and if it does, then we’re looking to match certain event numbers.  If they match, then we set prop45 to be a common name for the success event.

Notice the commas in the some of the matches?  That’s because we almost always have event13 added to our event list (as a page velocity event) so it’ll likely contain a comma, and we need to not mix up event1 with event 12 etc.

So we end up with a pretty standard traffic report that looks something like this:

This obviously shows that Internal Search is the most popular thing to do (not surprising given this is an un-segmented report).  Once I segment it, to show only those that are not staff or students, it’s a little more in line with what we’d expect…course views being the top activity for that audience type.

Ok, so that’s just the basic traffic report.

We can see from the above traffic report that they are interacting with areas across the site, from internal search, to filling in forms, to applications etc…but we don’t know the order this all occurred in.

Next success event flow

Let’s take a look at what those visitors do after they’ve looked at a course, by opening the Pathing Next Page Flow report.

We can see that following course views, in many cases, no other activity is recorded (for this visit).  You have to remember that pathing is unfortunately not cross-visit.

Some of them do interact with search, become a lead etc, during the same visit.

Previous success event flow

Now if you open the Pathing Previous Page Flow report for this traffic variable, you’ll be able to see what success events led to a specific event…such as an Application (or a purchase).

What we see again is that Apps typically start on a new visit (unsurprising) and during this period (when applications are actually fairly low anyway), course views lead to apps (that’s good).  Internal search and leads also generate course views, which lead to apps.  So, the flow is good, the volume is ok.  And another insight that makes us happy is that internal search accounts for very few applications…meaning people are not having to search for something prior to starting an application…and that’s’ great news.

There we have it – the order in which these success events occurred, giving you the insight into what happens before conversions.

And as success events are the most important things you measure on your site, it’s a logical step to create pathing on them to understand that order, so that you can optimise things further.

Now, where’s that coffee shop?

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!

This is a follow on post to my previous one about measuring that elusive engagement.  This post focuses on the aspect of applying a score to visitor interactions, as they interact with your content and applications.

Visitor scoring is fairly simple – especially in SiteCatalyst, and by leveraging the data in Discover through segmentation, (and ultimately in SiteCatalyst 15), it’ll give you even more insight into visitor engagement.

Visitor scoring measures and assigns a relative value to individual customers and prospects based on their actions and behaviors over time. You can determine intent and engagement – even before visitors convert.

Once you’ve identified your most valuable visitors, you can dissect their actions to determine the campaigns, keywords, referring sites and offline touch points that engage them – and invest more on these efforts.

Scoring

The basic premise of a visitor score is to give them “points” for certain activities.  What score you decide to give them is entirely up to you…the important thing is that they accrue points over time, and you can use those points to create segments of visitors that have exceeded certain thresholds.

In doing so, you’ll be able to compare different visitors, for example, those with a high score, to those with a low score, from different traffic sources, or across different campaigns.

The theory behind this is that visitors with higher scores are likely to be more engaged – they’ve accrued more points over time, by doing the things you want them to do.  It’s not just looking at conversions, although they will probably feature in your scoring methodology.

Imagine for a moment that you have a number of visitors:

Visitor 1 – comes to your site from Organic search, looks at 5 different products, watches 2 videos, signs up for your newsletter, but doesn’t buy anything.

Visitor 2 – comes to your site from Organic search, looks at 1 product and buys it.

Visitor 3 – comes to your site through an email campaign, and views 8 of your products.

Visitor 4 – comes to your site through Paid Search, looks at searches for a product, views it once and then looks at 3 FAQs.

Which visitor is more valuable to you?  Who is more engaged?  Visitor scoring will assist you to better understand the answer to that – and when you slot this Visitor Scoring methodology into the Interaction Index, and use Discover, you really do get a good proxy for engagement.

Ultimately most sites exist for a specific reason, whether it be to convert the visitor to a purchase, or allow them to self serve, or engage them with your content etc.   And we all want them to do that.  But only a small percentage will.  In fact, in general, it’s around 3-5% of visitors that actually “convert”.

First things first

What you need to do initially is agree on a set of interactions across your site, and then apply an arbitrary score to them, either between 1 and 10 or 1 and 100.

For example:

1. Home page viewed or Landing Page Viewed = 1 pt
2. View a general content page = 5 pts
3. View a Product = 10 pts
4. Search = 20 pts (I tend to think that if a visitor is going to take the time to search for something they can’t find, they’re more engaged, hence the higher score)
5. Watch a video = 30 pts
6. Use an interactive tool = 40 pts
7. Sign Up for a newsletter = 50 pts
8. Provide feedback/rate and review/comment = 75 pts
9. Buy a product or conduct a self service transaction = 100 pts

Don’t worry about the actual scores, but do leave room for additional interactions that you can add in if you need to (but remember to communicate it out if you do add in others, as scores will go up).

Now that you’ve scored various activities, you need to implement the code to measure those interactions.

Implementing the scoring

In SiteCatalyst that’s easy enough to do – you need an eVar and a success event.

Set up the success event as a Counter Event. 

Note that you can now have counter events where they take a value other than 1, which is what is needed for the  scoring.  However, I believe you’ll need version H23 of the s_code to support this. 

Create the eVar as a Counter eVar, not a text eVar.

Visitor scoring is done by simply passing the score value as a +number into the eVar and the success event is set with the =number (yes, you no longer need to pass the event through the s.product string).

So, for example, on your homepage, you simply add the following:

s.events="event1=1"; s.eVar1="+1";

On your search page, you’d include:

s.events="event1=20"; s.eVar1="+20";

(The above obviously assumes you’ve used event1 and eVar1 for Visitor Scoring.

Complete that process for each of the key interactions and you’re set.  We implemented ours directly into our s_code through a variety of s.pageName value matches, or product views, or other success events occurring.

To put this in context, we’ve implemented the following scoring:

1. Homepage view = 1pt
2. Searched for something = 5pts
3. Viewed a course = 20pts
4. Completed a form = 30pts
5. Used one of our interactive tools = 50pts
6. Opted in to something = 70pts
7. Submitted an application = 100pts

Making it legible

First thing you need to do when you implement this type of thing is make it all a bit more usable.

When you look at the raw data (your eVar against conversions), you’ll see something like:

Remember that the success event (Application Submitted) is associated back to the value seen in the eVar, when the success event was applied – so, in the example above, 37 apps were submitted when visitors had a score of 190; 22 had a score of 211, etc.  Notice also that as we’re showing both Apps and Leads, we also see that they don’t correspond; Leads has a very different scoring result (see below).

Overall, it doesn’t tell you much – you actually want to group the eVars together.  So, use SAINT to classify them into buckets. 

Important Tip: When you use Excel to classify your eVar, the key column will be the interaction score.  You need to keep that column showing 2 decimal places – when you export from SAINT, it has the decimal places on it, when you open in Excel, the decimal places disappear, and if you re-save without decimals and upload again, they keys will be different, and the reports won’t work.  So, put the key column to 2 decimal places and then classify it.

That brings about the problem of what your buckets should be…well, that’s up to you.  Only your data will tell you that.  But, you can experiment with different buckets to see what works best.  To be honest, it’s best to do this in Excel, rather than SAINT, as you’ll want instant gratification.  And you’ll obviously need data collected before you can classify…so it’s best to run it without classifications for a while.

We classified ours following a bit of analysis using Excel to figure out the best buckets for Applications Submitted and Optins.  As it turned out, after a lot of playing around, we chose a logarithmic scale, as it seemed to group everything the best:

What we see in Excel is that with these buckets, 80% of applications occur before a visitor has a score of 320.  We also note that most apps occur when visitors have a score of between 160-320…our sweet spot.

So, using SAINT, we classified our Engagement Value eVar into our buckets and uploaded back to SAINT. 

Tip: Due to the size of the file, we typically use an FTP upload now – it took less than 10 minutes to classify the data in the reports.

Now re-run the above SiteCatalyst report, this time using your buckets:

Remember above I said that leads obviously have a very different score?  You can see that in the above report, that Lead Completes tend to happen when the visitor has a score of between 40 and 160.

What we see from Excel with Leads is that 80% of leads occur before a visitor has a score of 80 – which means that those that become leads, do so pretty quickly; they haven’t visited much other content (otherwise their score would be higher) – which is great news for us!

Another way to classify the scores is to set “low, medium, and high” buckets for engaged visitors.  I’m still trying to figure out what we should use as those buckets, as we have a very large spread.  Standard Deviation will probably assist in that one eventually.

Calculated Metrics

At this point in time, you probably also want to create a few calculated metrics to get some averages out.

Ones that I’d recommend are:

1. Score per Visit = [Engagement Score] / [Visits]
2. Score per Search = [Engagement Score] / [Instances (Report-Specific)]
3. Score per Referrer = [Engagement Score] / [Instances (Report-Specific)]

Why is Instances in there twice?  Because a) Visits are not available across every report type and b) the naming convention just makes it a bit easier to understand (IMHO).

Did you know you can also trend calculated metrics?

Now that you’ve got all this wonderful new capability, what do you do with it…?

Segment it (of course)

There’s all sorts of different ways you can use this…all basically segmentation based.

You can look at traffic sources, campaigns, keywords, geographics, user type segments, etc.  You can trend and compare your segmented values over time.

In the example on the right, we see that while Australian visitors have an average score of 5.82, the highlighted items have much larger scores, indicating that they are engaging with more of the things we want them to do.  The example on the right was extracted using Discover, as in SiteCatalyst 14 the capability with geo-demographic reports is somewhat limited to country/visits.

In the next example, we’re looking at scores by course interest.  The course category is actually an eVar that is set in various places across the site – similar to a product category.  When a visitor browsers different bits of content, we’ll set their course category differently, which is then used for Test & Target purposes…but works well here too.

We see that while Undergrad had more course views during this short time frame, they scored actually slightly less than Postgrad visitors.  This would indicate that PG visitors tend to read more, which would also make sense, as it’s a bigger purchase decision for them.

And as a final example, scores by different campaign types (Organic, Paid, Campaigns, etc).

Hmmm…seems Paid Search is doing really well; not a huge amount of traffic during this period, but they are interacting a lot.  Break that down by keyword or Adword group and you’ll get even more insight.

Here we’re looking at Branded vs. Non Branded keywords (and their top keywords):

Seems that branded search terms generate a higher interaction, and in fact when they type in the full name of the university, they have the highest interaction.

Multi-scoring techniques

You’re not limited to having just one scoring methodology.  We’re actually in the process of implementing a second one for a completely different reason.  All you need is a spare eVar, another success event, and bit of time.  Rinse and repeat!

Comparative and Trending

Of course, you can also trend on the calculated metrics to ensure your overall interaction score is going in the right direction, and you can trend by different segments too.

Likewise, you can do comparative analysis using different dates to compare the interaction scores.

Extending the scoring

In SiteCatalyst 15, you can leverage the segments for visitors with scores higher than X – you can either use the value of the event, or you can use the SAINT classifications. 

Additionally, you can use these in DataWarehouse and Discover – or start from Discover and put the segments back into SiteCatalyst.

And, you can leverage the segments and scores in Test & Target to further optimise user journeys and conversions.

There’s just a whole heap of different ways to use this information.

Next post

In my next post, I’ll combine the above interaction Visitor scoring into the Discover segments for a full on Engagement Analysis, replacing the previously described interaction score with this one.

Internal search is one of the best goldfields available to you.  Not only does it help you understand what your users can’t find in general, but it can also helps you understand what they expect to see on certain pages – and aren’t seeing.

Beyond just the basic keyword measurement, there’s also other things you can do to further enhance your internal search metrics.

For example, we generally all have search pages, which users end up at following a search.  The typical SiteCatalyst implementation involves setting an s.prop and an eVar with the value of the search term, and a success event, on the search results page.

Many also implement another s.prop with the number of search results found to get an understanding of searches that are returning zero results.

But you can take it one step further too.

Multiple ways to search

Most sites are designed with a consistent search field somewhere on the page, which means that entry to the search results page can be from any page on your site.  So finding pages that are causing people to search becomes a problem.  You could use pathing, but it doesn’t really help because it’s a combination of the search term and the page they were on that’s of most interest.

So there’s another way to do it, using a plugin you may already have.

getPreviousValue plugin

If you use the getPreviousValue plugin, you can correlate the previous page the user was on when they typed in the term to your search engine.

So in the example above, we see that “exam timetable” was the most searched for term over the last X period (in fact exam related information is quite heavily searched for in general).

To get greater insight, use the s.getPreviousValue plugin.  This plugin is most commonly used for understanding how far a user scrolls down the page, but it can also be valuable for search.

The first thing to do is implement the plugin into your s_code – if you’ve not done it already.

Typically, you’ll have something like the following in your s_code as well, which captures the previous page viewed into an s.prop and the percent the page was viewed into another s.prop:

/* capture previous page name; capture percent of page viewed */
s.prop31=s.getPreviousValue(s.pageName,'gpv_pn');
if (s.prop31){
s.prop32=s.getPercentPageViewed();
}

Once you’ve got that done, all you need to do is correlate your keywords s.prop with your previous page viewed prop (use the Admin to correlate the two).

When correlated, you can now breakdown the keywords report by previous page viewed report.  This only works because both the keywords prop and the previous page viewed prop are set on the same page…hence you get the value of the keyword as well as the value of the previous page they were on when they searched for the term.

For example, if we correlate the keyword “exam timetable” with Previous Page Viewed, we see:

Now we see that of the 1737 searches for exam timetable, 558 of them originated from our home page, 362 from our student portal, etc. 

It may be wise therefore, especially at a time like this (exam season) to provide those links within those pages.

You can also reverse it, to see what else they’re searching for from specific pages.

Open the Previous Page Viewed report, pick a page and correlate with internal search terms:

Here we see that from the same portal page above, the top things they cannot find information on, is all about exams.

A good indicator that something should be added to the page to support the users desire for information about exams.

By the way – “unspecified” exists in this report because it says that of the 16,631 page views to portal:students:myunits, 15,350 views didn’t result in a search.

We’ve got more coming on our Search soon as we’ve just gone through a Search & Promote implementation, teid to SiteCatalyst, with some incredible results…we’ll be sharing them with you once we’ve found the time to blog about them.  Let’s just say that we can demonstrate a savings of around $165,000 to the organisation through this implementation.

But more coming on that soon.

And there’s a humdinger of a Test & Target campaign coming up this week too…stay tuned for that one.

Oh, and sometime in the near future I’ll post something around the holy grail – measuring user engagement using Discover.

One of the most powerful ways to enable an audience connection is through behavioural segmentation.

Many companies today segment from a business standpoint.  Don’t get me wrong, this is a good strategy and aligns your measurement and optimisation strategy with your business segmentation model.

Customer / non-customer segments.  Product A owners / product B owners.  Mosaic-based segments.  Geographic segments.  Lead / Non-lead segments.  These are all typically business-based segments, and you should definitely be segmenting using this methodology if your overall business does.

But I think there’s a higher level of segmentation – behavioural segmentation.

Behavioural segmentation in action

Every time someone visits your site they’re telling you what they’re interested in.  These behavioural segments are measurable and usable.  And moving from business-based segmentation to behavioural segmentation truly allows you to relevantly engage with your customers based on what they’ve told you about themselves, through either their activity on your site, or through forms they’ve completed.

At Murdoch, we recently re-developed our primary lead generation tool, called “Figure Out Your Life”.

FOYL, as it was affectionately known to us, was the University’s primary lead gen tool – it essentially asks you a number of questions and then suggests courses or careers that may be of interest to you.

Overall, the redesign was based on user feedback from focus groups but we took the opportunity to introduce behavioural segmentation into it, to not only measure those segments over time, using a combination of SiteCatalyst and SAINT classifications, but to enable more refined and relevant content targeting to each segment for optimisation and engagement purposes.

The new FOYL, now called Figure Out Your Course (or FOYC) asks 6 personality-type questions, and allows the user to rate their answer to each question, on a sliding scale, from 1 to 10.

The combination of their answers to the 6 questions results in 3 recommendations for courses they might consider.  

I’m not going to reveal the methodology behind tool – that’s confidential IP and very complex, but I will talk about the segmentation opportunities it allows.

How we achieved behavioural segmentation

From a segmentation standpoint, we decided that we wanted to firstly measure the segments to see what “types” of users are completing the tool, and secondly, through integration with Test & Target, we can then customise content to each user, based on how they answered each question.

To do so, we needed to capture each of their answers in an eVar (conversion variable), which must be remembered over multiple visits.

To enable more realistic clustering of segments, we decided that while the tool works on a rating between 1 and 10, we’d actually work our segments on a rating of 1 to 5.  So we “bucketed” each answer accordingly:

Moving the slider to position 1 or 2 makes them segment 1,
3 or 4, segment 2
5 or 6, segment 3
7 or 8, segment 4
9 or 10, segment 5

In doing so, each user now scores (from a segment standpoint) between 111111 and 555555, which makes a total of 15,625 combinations (111111, 111112, 111113, etc through to 555555), or 5^6.

By combining their scores for individual answers into a single variable, we end up with a per-person score, where each digit in the variable represents their chosen response to each question. 

So for example, if a person answers question 1 with a rating of 2, question 2 a rating of 10, question 3 a rating of 7, question 4 a rating of 10, question 5 a rating of 6 and question 6 a rating of 1, their overall segment score would be 154531.

We store this in an eVar and a persistent s.prop, and pass them to SiteCatalyst.

Results

What we end up with is a list of scores in a SiteCatalyst report as follows:

Not a lot of use, except that we can see the raw scores and the number of instances of each score.  You can see as well that they’ve started to cluster.  50 people have been through the tool and selected 141515 as their answers to each question.

Using SAINT classifications, we then created every possible combination and classified every result.  Despite it being 15,625 combinations, this only took a few minutes – gotta love Excel for this.

We’ve classified each digit location as the question, and each digit value as the score from 1 to 5.

For example, the classification for digit location 1 is “Indoors (1) or Outdoors (5)”.  The values range from 1 to 5.

Our classification file looks like:

We set “No FOYL” as the default for people who haven’t been through the tool yet – which also allows us to use T&T to engage them into the tool.

Using the classifications, we can now see a report that shows all responses to digit location 1…i.e. how did people answer that question:

So we can see that most people are answering question 1 with a segment rating of 3 (mid way).  Unfortunately, we can’t order the values numerically, they are ordered highest to lowest on their instances.

If we chart that as a pie chart, we see:

Now we repeat that for every question asked and pop it into a dashboard for an overview of results, and we can see:

We can also now sub-relate those individual segments with the courses they’ve viewed:

Our true measure by segment is lead generation, so we just add in those conversion metrics too, Lead Start and Lead Complete and we can see conversion by segment.

Discover

Using Discover, we can create those segments individually and compare them.  Here I’ve compared search terms against anyone that answered the Behind Scenes/Lead a team or Indoors/Outdoors with a 5:

The same segment can be used in SiteCatalyst 15 to segment your reports.

We also pass these segments into our email marketing platform so we can segment our ongoing communications further, generating a more personalised and relevant experience for the user.  We can now customise parts of the message dynamically, based on the segment (or segments) that they told us they’re in.

Test & Target

Now the really useful stuff.

Because Test & Target can also see those segments and values, we can target content to each segment as they re-engage across our content.  For example, we can vary messaging to people who prefer to work outdoors instead of indoors.

We can target course content to them based on their selections.

We can build multiple targets and combination targets to get the content to them.  If they haven’t been through the tool, we’d also know that too, and we can target messaging to try to engage them that way.

In summary

Every company has the opportunity to segment. And that’s how you move beyond reporting to insight.  Understanding how your segments interact with your content or how they convert differently allows you to further optimise their experience. 

There’s plenty of opportunity to segment for measurement purposes, but when you combine Test & Target with those segments, and start to target information based on those segments, it’s really powerful.

When you move away from just reporting, to segmentation, and beyond to segmentation based on user behaviour, you can really start to generate user engagement and relevance of content.

You just need to open your mind to the segmentation possibilities and find out what works for you.

Let me know how you’re segmenting your site visitors and what you’re doing around optimising their user journey based on their segments.

Ok, so I admit it, I’m a massive (borderline obsessive) brand advocate for Omniture (now the Adobe Omniture Business Unit), and I’m definitely not alone, but we’ve been dealt a harsh card.

The card? The migration to SiteCatalyst v15.  We’ve been told we can’t migrate for probably up to a year.  In my opinion, quite frankly, Omniture that just sucks!

Many of us sit on the Customer Advisory Board for Omniture, where we talk about the product and roadmap and features and upgrades that we’re looking for.

Many of us were involved, at least over the last 6 months, beta testing SiteCatalyst v15 – quite frankly because we all tend to be power users, have multiple products and really push the envelope to what the product can achieve.  And during the beta test we helped Omniture “real world” test the product in readiness for launch.  And what an incredible new version it is.  Segmentation on the fly, full subrelations by default, more accurate visitor counts, a whole new architecture, better UI and usability…the list just goes on and on.

And now we’re told we can’t migrate because we’re either too big, too complex, or have to many integrated products (all Omniture products) and as that complicates things, the migration simply isn’t possible.

Part of the customer benefit to sitting on CABs and participating in Beta tests, which is very time consuming, is the promise of early adoption to the new product when it becomes available.

Omniture has some serious brands relying on their products for insight and optimisation…these are high net worth clients to Omniture, and yet, these are now the same clients that cannot migrate and cannot leverage the new capabilities, which we’ve all been loyally waiting for.

New clients can go straight onto the platform…but they’re not yet the brand advocates.  They’re not the ones paying the big bucks for insight.  They’re not the ones who have brand loyalty yet.  They’re not the ones who have stuck with Omniture for years. We, the bigger clients, are.  And yet, we, the ones who have invested a huge amount of time, effort, resources and money into the platform cannot get value from the new release, for at least 6-12 months, and in some cases, projected 18 months.

That makes no sense!

In Murdoch’s case, it’s because we use SearchCenter+.  In other cases, it’s if you use DataSources (a key advanced feature), Video measurement is another…in fact there’s a bit of a list involved that “qualifies customers to migrate”.

Now, I know, through participating in the beta and sitting on the CABs, that this release has a very complicated and new backend, but IMHO you’ve failed to looked after your number #1 clients…the clients who are pushing the boundaries, or who invest a lot with you.  They’re the ones who have been taken in to the candy store and told they can’t buy – having helped you set up the candy store in the first place!

Despite all of this, I’m still a massive brand advocate.  I think Omniture does an amazing job and has amazing products…but I really think the priority for this launch is all wrong!

Are you frustrated with this too…tell me what you think?