Success Event Pathing

pic
Share this article

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 in 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:

success_events

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.

success_events_anonymous

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.

paths_from_success_event

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).

paths_to_success_event

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?


Share this article