two of a kind 1I was merrily using Time on Page and Time on Site metrics for quite some time before I actually realized how they were being measured.

It was a real Doh (!) moment.

Turns out we have not rfid'ed every visitor and they don't rub their head against their monitor before starting their session on my website (and of course another head rub when they decide they have had enough and exit). This would allow us to capture the time stamps accurately and have exact measures.

What a disappointment! Joking, just joking!! :)

I find that few people understand correctly how the Average Time on Site calculation is made.

That's regardless of source: weather they use the religious truth from a Competitive intelligence tool or from their website web analytics solution. For the latter it does not matter what data capture methodology you use on your site, WebLogs or JavaScript Tags.

This post is my humble attempt at explaining how Time on Page and Time on Site are computed.

In order to make life easy I am going to assume the following session happening on a website:

typical website session 2

Someone requests your home page, your web analytics tool starts a session for the visitor, two more pages are requested before the visitor decides to leave your website (close browser, type in a url of a different site, click on a link on your site to go to different site….).

What we want to compute is…..

how to compute time on site

Tp = Time spent on a page.
Ts = Time spend on the website.

Someone visits your website at 10:00……

start of website session

There is a entry in your log file (weblog or javascript tag, does not matter) that says, in English, "someone has requested the website homepage file at 10:00".

It actually looks more like this.... - - [08/Oct/2007:11:17:55 -0400] "GET / index.html HTTP/1.1" 200 10801 " &aq=t&rls=org.mozilla:en-US:official&client=firefox-a" "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv: Gecko/20070914 Firefox/"

Notice the time stamp there?

Why spoil the fun with technical stuff! But if you want more the tech stuff is explained very nicely here: Log file sample explained.

So far all your analytics program knows is when a page was requested, hence:

Tp = N/A [Not Available]
Ts = N/A

Next more fun happens on your site: someone clicks on a link to Page 2 from your home page. Hurray no bounce! :)

time on page one

Now there is a new entry in your log file that says: "The same Visitor requested page two at 10:01"

Finally your web analytics program can compute some time metrics!

It knows how long the Visitor spent on the home page. It subtracts 10:01 from 10:00 and gets one minute. Hence:

Tp (Home Page) = 1 minute.

Notice something important: the only way your program knows how long someone spent on one page is by looking at the two time stamps. One from the request for the first page and one from request of second page.

Next the blinking "get $200 rebate on a $210 product" link on Page 2 entices the person to click on to Page 3 to buy the product. More sweet success! "Engagement!!"

time on page two

The magical math outlined above happens (10:05 minus 10:01) and for Page 2:

Tp (Page 2) = 4 minutes.

The Visitor reaches Page 3 and notices that the rebate offer only applies to people who live in Antarctica who can show they currently own refrigerators (!!). As you can reasonably imagine this happens on the site on Page 3…..

time on page three


How long did it take to find and read the rebate fine print? You could reasonably guess if you knew how long the Visitor spent on Page 3.

The problem is that your logfile is missing one time stamp to do the magic math.

Tp (Page 3) = Time of page request (10:05) minus Time of next page request (N/A).


Tp (Page 3) = 0 minutes (Since N/A!)

The program has no idea how long the Visitor spent on the last page on your site.

This is true for pretty much all web analytics programs in terms of default behavior.

Let's wrap this puppy up….

time spent on site 1

Tp (Home Page) = 1 minute.
Tp (Page 2) = 4 minutes.
Tp (Page 3) = 0 minutes.

Ts = 5 minutes. (Time on Site, also known as Session Length)

Makes sense?

I mean it probably does not make sense that you don't know how long Visitors spend on the last page in the session, but the explanation of how it works makes sense?

The Case of Bounce / Single Page Sessions:

Now I am sure your are asking yourself: "I wonder what happens in cases of sessions where there is only one page?"

Good question. This is what you are wondering about….

time on page for bounce


This is what is computed….

time on site for bounce

Tp = 0 minutes.
Ts = 0 minutes.

For bounced sessions (single page view sessions) your web metrics program can't compute how long people have spent on the page or on your website. It certainly records the page request (10:00) and it records start of the session but it does not know how long someone was there.

In case the Visitor came at 10:00 and leaves the browser open and rushes as the Visitors Wife / Husband / Boss yells at them to do the dishes and cleaning the dishes takes and hour…. the session is terminated at the end of 29 mins (default setting in most session based web analytics tools). It is important to note that the web metrics program will still say:

Tp = 0 minutes.
Ts = 0 minutes.

The Case of Tabbed Browsing:

Firefox gets credit for popularizing tabbed browsing – I love it and I have no idea how we survived for years without it! The latest versions of IE also support tab browsing, so the masses are also now using this delightful feature.

But what happens to the Time on Page and Time on Site computations when people open a link on a site in another tab and browse the site via two tabs at the same time? I do this all the time! :)

It messes up the time computations.

Here is a common scenario that we'll use to understand the impact…..

time on site impact tabbed browsing

A Visitor comes to your home page. From there opens the first link in a new tab, but continues to scan the home page. The clicks onto a link to Page 2 from the home page, then onto Page 3 and then closes the tab (or moves away and forgets about it).

The Visitor goes to the tab opened from the home page to Page 4 of your site, spends time there, goes on to Page 5 in that tab. Then exits.

How is time on site computed? There are two ways in which I have seen web analytics tools report on this customer behavior.

Dealing with tab browsing # 1:

The web analytics tool takes the above picture literally and this happens…..

Outcomes: Two Sessions, one for each tab in the browser.

Session One (top): [referrer -> Google]

      Tp (Home Page) = 2 minutes
      Tp (Page 2) = 3 minutes
      Tp (Page 3) = 0 minutes

      Ts (session duration) = 5 minutes

Session Two (bottom): [referrer -> your site/homepage]

      Tp (Page 4) = 6 minutes
      Tp (Page 5) = 0 minutes

      Ts (session duration) = 6 minutes

Net net: 2 Visits. 1 Unique Visitor. Also notice the impact on referrers (for the second one you'll see your site referring to itself).

Really interesting outcome!

Dealing with tab browsing # 2:

Some web analytics tools "collect" all the "hits" (entries in the log files) and they will "linearize" the hits and construct one session from all the tabbed browsing Visitor behavior.

So keeping our use case exactly as above, visually this is what happens when data is processed……

time on site impact tabbed browsing linearized

[Pretty high resolution image: Click: Time on site impact tabbed browsing -linearized]

Outcomes: One Sessions, visit “reorganized” by time stamps.

Session One: [referrer -> Google]

      Tp (Home Page) = 1 minute
      Tp (Page 4) = 1 minute
      Tp (Page 2) = 3 minutes
      Tp (Page 3) = 2 minutes
      Tp (Page 5) = 0 minutes

      Ts (session duration) = 7 minutes

Net net: 1 Visit. 1 Unique Visitor.

Neither one perfectly captures exactly what the Visitor is actually doing on your site.

Which one do you prefer?

Be sure to ask your web analytics vendor which of the above two (or a different method) do they use to deal with tabbed browsing when it comes to computing time one site.

Given the increasing popularity of tabbed browsing the impact on your numbers could be big.

Google Analytics uses the second method ("linearization").

Take a deep breath now!

time on site explained

Extra Credit Section:

As always there are hacks that might allow you to capture the time spent on the last page (or even on the last event if you are using event logging).

One of the most common (and when I say most common I mean used by the 0.001%) is to add extra script / code that would capture the fact that the page was "unloaded" in the browser. Technically it is often called "onbeforeunload event".

In this case for each page you have a page request time stamp as well as a page unload time stamp. Hence you can do clean magic math required.

hacks extra coolYou will have to script this yourself or ask your vendor to help you create such code. You would then also have to ask your Vendor to modify how time on page (and time on site) are computed in the web analytics tool to take advantage of the additional time stamp.

If you are doing your own logfile parsing then you can more easily modify the log file to parse and data and then compute the metric for you.

There are other hacks as well.

Some people have also ventured that if your analytics tool has outbound link tracking (also often called exit tracking) then the web analytics tool has the time stamp of that click and can use it to compute time spent on the last page.

I am not a big fan of this because most people on your site will not exit the site by clicking on a link on your site (because most links on your site don't link to other sites, how inconvenient!). So if you use the outbound/exit link time stamps you'll end up computing Time on Site / Page for some Visitors to your site one way and everyone else another way.

It muddies waters, it becomes mixing apples with watermelons.

I am a fan of consistency, even if you consistently measure something imprecisely.

I hope that this post has helped you understand how time on website and time on a page is computed. Next time you see Average Time on Site or Average Time on Page you'll know what data is being included and what is not.

Also next time you compare numbers between a external tool, one of the competitive intelligence tools, and those reported by your internal web analytics tool, you'll know the questions to ask before you jump to conclusions!

Closing Thought : The purpose of this post is not to imply, overtly or covertly, that Time on Site is not a good metric. Far from it. For many types of businesses it can be a critical metric. My hope here is to educate you about how it is computed so that you can make more informed decisions. Computation of no web analytics metric is without flaws (look no further than Unique Visitors!!), time on site is perhaps one of the less flawed ones. :)

Ok now its your turn.

Please share your perspectives, critique, bouquets and brickbats via comments. For the Analytics Gods out there, did I get it right? Please comment.

[Like this post? For more posts like this please click here, if it might be of interest please check out my book: Web Analytics: An Hour A Day.]

Igor was upset that I was not doing a good job of cross posting. Since customer feedback is important… here are earlier posts in this series:

And here is a related post that outlines four attributes each great metric should possess:

Social Bookmarks:

  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite
  • services sprite