Many SiteCatalyst users are familiar with the Time Spent on Page metric in the Pages report (which shows the average amount of time that visitors spend on the various pages of your site) and with the Time Spent per Visit report, which displays overall visit times as well as the amount of time that users spend prior to completing any success event. But what if you’d like to see “time spent” for something other than a page?

A user asked me just such a question a couple of weeks ago via Twitter. He had a Flash application and wanted to see the average amount of time spent interacting with the app. It’s a KPI that makes tons of sense when optimizing flow and structure of an app, site section, or some other portion of the user experience that doesn’t fit neatly into the definition of a “page.” Fortunately, this sort of measurement is entirely possible and fairly easy to implement.

SiteCatalyst pathing allows you to see how users moved from one value of a traffic variable to another. When you view the Time Spent on Page metric in the Pages report for “home page,” what you’re really seeing is the average time elapsed from one page name (“home page”) to another (such as “product page”). The fact that Time Spent calculations are based on changes in variable values is important, because it means that with a bit of planning, you can capture Time Spent data for various site sections and applications simply by controlling how traffic variables change from one page view or user action to the next.

First, you’re going to need one Custom Traffic (s.prop) variable, or perhaps the Site Sections (s.channel) variable if you’re looking time spent on a certain site section. Regardless of how you choose to do it, make sure to get pathing enabled on this variable. Your Account Manager can help set this up.

Once you’ve got your variable, set it on every page view (and, where applicable, custom links) regardless of whether the page or link falls inside or outside of the area/app in question. If you’re using s.channel, come up with a good strategy for grouping pages and areas of the site into sections. In a more specific case, such as time spent on a Flash app, you can set the variable to any value (e.g., the page name) outside of the app, and the app name or some other identifier/differentiator inside of the app. This identifier should stay the same as the user moves through the site section or app in question! Because of the way that pathing works, you’ll want to use the same value for every page view or user action that should be “grouped” in terms of time spent. To see time spent on a Flash app, you would use the same value in this variable as the user moves through the app.

Example:

Landing Page: s.prop1=”landing page”
Second Page of Visit: s.prop1=”some other, unrelated page”

. . .now the user enters the Flash app and clicks around a couple of times. . .

On app load: s.prop1=”flash app – super fun game v2.0″
First click: s.prop1=”flash app – super fun game v2.0″
Second click: s.prop1=”flash app – super fun game v2.0″

. . .notice that the value of prop1 stayed the same within the app. . .

Third Page of Visit, now outside of app: s.prop1=”a third unrelated page”

Because time spent metrics describe the amount of time until a variable’s value changed, an implementation like the one shown above would cause all of the time spent in the Flash app to be reported together, as a single “time spent” total, because the value of the variable never changed within the app (or site section).

The resulting report might look something like this (presuming, again, that pathing has been enabled on the variable in question):

Time Spent

So, by carefully implementing the same variable with the same value as users move into, through, and out of key site sections and apps on your site, you can easily determine the time spent interacting with key areas of your site so that you can gauge success and better determine ways to improve your site.

BONUS: This can also show you how people move from site section to site section, or how they move into and out of your site sections and apps.

As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter or LinkedIn, or by e-mailing omniture care [at] adobe dot com.

6 comments
Bella Benedict
Bella Benedict

Great post. Waiting for you to continue the topic. Bella Benedict escort service warsaw indiana

Bella Swenson
Bella Swenson

It is very interesting for me to read that post. Thanx for it. I like such themes and everything connected to this matter. I would like to read a bit more on that blog soon. Bella Swenson escort privat schweiz hausbesuch

Rob Blakeley
Rob Blakeley

I believe it is worth noting that one needs to make sure everything passes a value for the chosen variable. For example, say you have "sponsored" pages in Prop1. No not all of your pages are sponsored so some pages may not have a sponsored value. When you move from sponsored page #3 to some non-sponsored pages where there is no value set, the time in those non-sponsored pages can be counted in the sponsored time spent. This is because the last sponsored value did not change when you looked at the non-sponsored pages. However, if you pass a value such as "not-coded" on non-sponsored pages the value will change and the time spent in non-sponsored pages will not be counted. Time spent also appears to be variable based, so that a value passed in prop2 will not affect the time spent calculation for prop1.

nic
nic

Hi Ben, there is one - probably important - addition to this: A "change" of an s.prop value is not happening, if the next click does not populate the s.prop at all. When it comes to Time Spent, the s.prop behaves like a visit-based eVar. Example: 1. s.pageName="pathtest1" and s.channel="pathstart" 2. s.pageName="pathtest2" and s.channel="" 3. s.pageName="pathtest3" and s.channel="pathend" Pages-Report with "Time spent": * pathtest1: 2 Minutes * pathtest2: 2 Minutes * pathtest3: 0 Minutes And a look at the Site Section report with "Time spent": * pathstart: 4 Minutes * pathend: 0 Minutes So it is dangerous to use Time Spent, if you can't guarantee, your s.prop is set all. so long nic

Joy
Joy

Great post Ben! "Time on..." metrics can be confusing, but this post and the knowledge base helped me too. I had a follow-up question about time on page: Let's say we have a custom traffic variable (prop1), that shows site sub-sections (electronics, housewares, apparel, etc). The sub-sections are made up of pages (naturally). If I run a pages report, filter by "housewares" and add up all the time on page data, will that total time on page be the same as if i ran my prop1 (filter by "housewares") report? Thanks!

Ben Gaines
Ben Gaines

Joy, assuming that Site Sections (s.channel) is always populated on page views and does not change to a different value on custom link calls, and that you're sure to include all of the pages that belong to the site section, then yes. They should at least be very close (depending on rounding and bucketing). There may be exceptions that I haven't seen/considered, but fundamentally I think you're understanding the way that this works.