In my previous post on People who liked this, also liked…, I put forward an idea how to generate “related” products of interest, based on what users were looking at, which could then be automated and re-published back to a site, based on Omniture data.

We implemented this in our s_code, largely as a test, to see what the results would be like, and to further enable proof of concept testing when we exported the data.

Well, we’ve had an interesting observation as a result of this (we haven’t yet fully implemented the re-publishing part) and I thought it was worthy of a quick posting.

Our expectation of user behaviour was that they look at multiple courses, during their first visit – in essence, they would browse courses looking at what was on offer, reading about the various differences between them.

It turns out that is not the case.

If we look at Course views over a certain period we can see what are the most popular courses (and not so popular).  What I have shown here is a list of the top 15 courses viewed over a specific time frame.  So we can see from this that Vet Science was the most viewed course over time, but it doesn’t show whether this was the “first choice” or the “second choice”.  It doesn’t show whether this was viewed during the initial visit or a follow up visit.

So, this doesn’t help in our People who liked this, also liked…scenario.

In putting in place our Course Stacking code, we are now able to see the order in which courses are typically viewed in.

Bear in mind that we have implemented this as a solution that we can export and then re-integrate into our site, so we have purposely used Course ID, not the name of the course.

The result within SiteCatalyst, is that the report isn’t easy to read…but I’ll attempt to explain it.

The Course View Stacking column contains the Course ID’s in the order that they were viewed.  So for example, the first entry “39>146″ tells us that there were 133 instances where a user started with viewing course 39, then went on to view course 146.

Utilizing Course Stacking, there are an enormous amount of combinations that will ultimately show up in this report.  Just in the short time this has been going, it has already generated 6,275 combinations.

Of course, this could be other products, product categories etc.

So we can get these into perspective, and not use just ID’s, Course 39 is Law (Four-Year Degree) (LLB), and Course 146 is Law (Three-Year Degree) Juris Doctor (LLB).

So, what we’re seeing is that there have been 133 instances of visitors starting with the four year Law degree, then going on to look at the three year Law degree.

A bit further down the report in position 9, you’ll also see “39>146>39″.  This is a different stream to the above.  In this stream, there have been 47 instances where visitors have gone from the 4yr degree, to the 3yr degree and back to the 4yr degree – which is different to the above, where they went from the 4yr to the 3yr, and have not looked at anything else since.

This is the reason why we can get so many combinations.

Ok, so overall, that seems to make sense – users would look at other courses.

Notice the percentage (of overall) is very low.  This activity only occurred 0.5% of the time.  This is due to the amount of time we’ve had this running.

However, remember our original assumption – users will look for a course, then browse to other courses, during their first visit.

Out of curiosity I exported the data from Omniture, segmented by New vs Repeat visitors, so see whether the behaviour changed.  The question I wanted to answer was “do users typically look at more than one course [product] during their first visit”.

I was surprised by the result.

I actually used a different product to analyze the results here.  The above chart shows the number of different courses viewed (x-axis) and the number of times that occurred.  New visitors are blue, repeat visitors are orange.

It’s split roughly 50/50 for people who view 1 course, but it’s certainly the largest category, inferring that the majority of visitors come to the site and are engaged with one course, which is also good news, suggesting that they are satisfied with the content of the course.

Now look at the weightings for those who view more than one course.  There are clearly more repeat visitors who view 3 or more courses, and that really spikes at the end (10 or more courses are grouped together).

This suggests that our original assumption was wrong.  First time users, on balance, view only one course.  But when they come back, they view either one course, or more than one course – suggesting that they begin to browse courses only on their repeat visit.

This is very interesting and insightful.  We can use this to our advantage.  We can target content to repeat visitors who have viewed a course previously – either prompting them back into their original course, or present them with “related” courses.

We can also try to better cross-promote courses on their first visit.

This was an unexpected insight that came out of this analysis, but to us, very valuable information that can be used.

I was chatting with one of our School Deans today about various results and he posed the question “Is it possible to see which courses people viewed after seeing one course?”.  His interest was based on the fact that the user doesn’t always purchase the “most frequently visited course”.  They often view one thing, but end up purchasing something else, and our reporting doesn’t highlight that behaviour.

Now, that got me thinking…that’s probably pretty common behaviour.  So how can we make that visible?

Pathing is common

Of course, it’s easy to show page pathing (which pages are viewed before and after a certain page), section pathing (similar but for a section), but pathing isn’t available across multiple visits (for the obvious reasons).  Traffic pathing is available on s.props, so as long as you report something into an s.prop, you can generate paths to/from it.  Paths are very valuable to see where a user goes after visiting a specific item such as a page, or how they got to a specific page.

However, the problem arises when you want to see something across multiple visits.

We’ve just had a similar problem with multi-visit campaign results, where the success event was being attributed to the latest campaign id, which wasn’t neccessarily what we expected.  In our case, due to the sales cycle being long (typically 1-3 months), many visits will occur and the user won’t always come in with the same campaign code.

For example, we might send them an email which drives them to the site.  The user engages, finds out what they need, but doesn’t convert.  They then come back a few days or weeks later by either typing in our web address directly, or come in through a search engine.  In either case, the success event (if they convert) would be attributed to the latest campaign, for example, Google or Direct/Typein (as we also have a VISTA rule).

Enter Campaign Stacking…

So, to provide some visibility to this activity, we worked with our consultant who recommended we implement Campaign Stacking, which, through the use of a cookie, appends a different campaign code (if they have one) to any previous one.

So, in the above example, we now have reports which show conversions by campaign combination.  We accomplished this by setting up a new eVar and writing a cookie (through an s_code plugin) appending the next campaign code to a previous campaign code.

Now we should be able which campaign combinations are driving conversions, over multiple visits.

Now stay with me…

I’ll bet we can do the same thing to understand product view combinations over multiple visits, leading to conversion.

In our case, a product is a course, but no reason this couldn’t work for any product category.  In our case, we don’t want to see which course “pages” they visited (we have that through course page pathing).  We want to see course pathing across multiple visits (or the same visit).

By setting an eVar with the name of the course, and using the same methodology as above, we should be able to get a view on this activity and user behaviour.

In theory, we should then be able to export the data and generate promo-type content that says “People who liked this course, also liked these courses…”

That will then help us to cross-promote “related” courses – not what we think are related, but what users are thinking are related.  Do that on an automated, daily basis and you really start to apply some value for the user.

That’s one of the great things about Omniture – flexibility to do this.

Guess what I’ll be trying over the next few days…I’ll update this one over time, if we get it working.