Time Spent on the Site Metrics

I have come across this KPI over and over again. Many of my clients want to report it on frequent basis and some even have this as one of their goals for the site. However, I am surprised to find that not many people (not even a lot of web analysts) understand how this metrics is calculated and what this is actually reporting. I am personally not oppose to tracking this metric but have an issue when people try to set goals with respect to improving time on site without knowing what this metrics is actually measuring.

What are the issues with the metrics?
Let’s start with looking at the issues with “Time Spent on the Site” or “Time Spent on a Page” metrics.

1. Last page viewed in a visit is not counted in this metrics
2. Single Page Visits are not counted in this metrics
3. Visitors are multitasking, causing inaccuracies in actual time spent on the site.
4. Tabbed Browsing, causing inaccuracies in actual time spent on the site
5. Download time of the page – Time spent on page calculation includes time taken to download the page.

Let’s cover this one at a time

1. Last page viewed is not counted in the “Time Spent on the Site” calculations. – All most all of the tools (Since I don’t know exactly how many tools are there and how each of them work, I am using almost instead of saying all the tools) use the time lapsed between 2 page requests to calculate “Time Spent on Site”. Since last page viewed does not have any subsequent page request, there is no time lapsed recorded and hence the time spent on last page is not counted in the calculation.
To illustrate let’s take an example of a person viewing page A, B and C
A was requested at 10:00:00 AM
B was requested at 10:00:20 AM
C was requested at 10:00:30 AM
User leaves the site at 10:01:40 (Read page C for 1 Minute and 10 seconds)
Web Analytics Tool will show Avg. Time on Site as 30 seconds instead of 1 min and 40 seconds, the actual time spent by the user.
2. Single Page visits – Since this is the first and the last page viewed by a visitor, as explained above this page views is not counted in “Time Spent on Site” calculations. Single page visits are very common due to search engines and other sites linking deep into the site, this is especially true for content sites (news, articles etc.). Users search or click on links and then read the content spend 5-10 mins and then leave. These users will never be counted in “Time Spent on Page/Site” calculations. If yours is a news/content site then I can assure you that you will be underreporting the time spent on site due to either large percentage of single page visits or the users clicking on few links (within seconds), finding what they are looking for and spending majority of the time (few mins) on the last page and then leaving the site.

Above is the report on a page I created to track timespentonsite.asp, this page was the only page that I viewed in my visit (single page visit), this page shows an AvgTime of 00:00:00 even though I stayed on this page for 5 or so mins. (Snap shot from http://www.USAIndian.net)

3. Visitors are multitasking – Most of the time visitors are multitasking. If they are at work they are doing their regular work, talking to other, getting coffee etc. A visitor opens site, views it for 20 seconds, gets distracted come back 20 mins later, pick up the site where she left, clicks on another link views that for 2 mins, clicks another link views it for 20 seconds and then leaves. Does this happen a lot? You bet, look around talk to your colleagues you will find this happening all the time.
How much time will be reported by web analytics tool? 22 Mins. Is that correct? No. Isn’t the actual time viewed 2 mins and 40 seconds.

4. Tabbed browsing – Tabbed browsing even complicates the issue. Jason Burby’s article http://www.clickz.com/showPage.html?page=3623280 talks about how tabbed browsing has made it much easier to open different page of the site and multiple sites. Jumping to another site, opening various pages of the same site complicates the calculation of time spent on page/site. A visitor comes to the site, within 1 min opens 10 pages in different tabs that he/she wants to view. Now spends 1 hour looking at these pages. What will web analytics tool report as the time spent on site? 1 min, even tough user viewed it for 61 mins.

4. Download times of the pages – If a page takes longer than normal to download it will affect the time spent on the site. User might spend 10 second downloading while only 5 seconds viewing the page, however time spent will show 15 seconds.

So with all these inaccuracies is this metric still useful. I think it still has a value as long as you understand what this metrics is showing.

Sudden changes in time spent could indicate a problem with site navigation, search engine optimization or users behavior. It can shows that one of the factors on your site has changed
a. Single Page Visits – Change in single page visits will affect this metrics. If you search engine rankings have changed that can affect single page visits and hence time spent on site.
b. Navigation on your site – it either is obstructing finding the correct information (time spent goes up) or has improved so users are getting right to they content they are looking for (time spent goes down).
c. Problems with a page – This can cause users to exit site prematurely, causing time spent on the site to go down unless the problem is on one of the pages with very high exit ratio. Since the last page is never counted in calculating time spent, a user who exits after seeing this page or exits after getting an error on this page won’t make much difference in time spent on the site calculations.
d. User Behavior – If nothing else changed, then users might be either multitasking more than before or are using tabbed browsing. This will result in changes in the time spent on the site.
Contributed By Anil Batra: Understanding the “Time Spent on the Site” Metrics – Web Analytics, Behavioral Targeting and Optimization

Measurement isn't enough. Think beyond dashboards and take action

Get in-depth insight from web analytics expert Eric T. Peterson, and find out what’s truly needed to drive value from your data. Dashboards are vital, but they’re only tools—too much focus on individual metrics can cause analysis paralysis.

Download the whitepaper to learn why even the best-designed, most strategic dashboards are just the start. Find out how to move your marketing out of the dark ages and into a bright future by using best-of-class strategies that lead to action—and results.

Download the White Paper

You’ll learn:

* The need for dashboards and key performance indicators in digital measurement
* Why many companies focus too much on individual metrics and indicators—and how to avoid the trap
* The dynamic relationship between dashboards and analysis in high-functioning organizations
* Over-arching recommendations from Web Analytics Demystified for success through digital measurement

What is Bounce Rate?

Time and again my clients ask me about Bounce Rate. This made me think that there is still confusion about what is bounce rate and exit ratio. The three main questions that have come up are

  1. What is bounce rate?
  2. What is the industry standard for bounce rate?
  3. What causes high or low bounce rates?

I am going to answer these questions in this post.

What is bounce rate?

Bounce rate is the percentage of visitors who enter a site (or a page) and then leave immediately. Think of a ball (visitor) that is thrown (visits) towards a table (site). It hits the table and bounces back without rolling (visiting any other pages).
Generally, “leave immediately” in the above definition means without going to any other page. However it could also be expressed in terms of time spent on site, say users who spend 5 seconds or less on the site irrespective of the number of pages they view.

Bounce rates are calculated both at the individual page level and at the site level. For an individual page, bounce rate is the ratio of visitors who enter the site from that page and leave without going any deeper, to the total number of visitors who enter the site through that page. In other words it is single page visits/ total entries to the site through that page.
At the site level, bounce rate is simply single page visits/total site visits.

Note: If a visitor enters though a page, refreshes it (manually or via auto refresh such as ESPN score page or MSN money page) but never goes beyond the first page the visit is not counted in the bounce rate.

  • Bounce rate is often confused with Exit Ratio. Exit ratio is usually expressed as the percentage of exits from a page to the total number of visits to that page. As a side note: A lot of times exit ratio expressed as % of visits can be misleading. In most cases, page views are actually more appropriate than visits for this ratio. Why page views and not visits? If I view the same page twice during the same visit, and after one of those page views I exit, shouldn’t my exit ratio be 50% rather than 100%? The first view of this page was compelling enough for me to further engage. A 100% exit ratio would indicate a problem that may not be there.
  • Bounce rate is confused with Single Page Visit Ratio: Single page visit ratio is calculated as a percentage of single page visits over total visits to a page.
  • Here are two examples that will help you clarify

    1. A visitor who enters site at home page and then goes to contact us page and leaves from contact us will be counted in the exit ratio from the contact us page but won’t be counted in the bounce rate of contact us page.
    2. A visitor who enter the site from contact us page and then leaves without going any further counts in all three, exit ratio, single page visit ratio and bounce rate.

    So to Recap:

    Single Page Visit Ratio= Single Page Visits to the page/ Total Visits to the page
    Exit Ratio= Total Exists from the page/Total Visits on the page or Total Exits from the page/Total Page Views of the page (see explanation above)
    Bounce Rate= Single Page Visits to the page/Total Entries to the site through that page.
    Note: All of the above three are generally expressed as percentages.

    What is the industry standard for bounce rate?

    The simple and short answer is that there is no industry standard. I know you don’t want to hear that, but it is true. There is no industry standard. There are some ranges that I will share shortly but we can’t call them industry standards. There are a lot of factors that influence the bounce rate, so you really can’t compare bounce rates of one site (or page) to another. I have listed those in the next section.

    The goal of the site should generally be to reduce the bounce rate to as low as possible. The lower the bounce rate the better job the site is doing to keep users engaged. One exception may be a site that is intended to accomplish all relevant user engagement on it’s landing page. This is more common on say, a campaign landing page intended to sign up users for direct marketing emails.

    Bounce rate is very unique to your site and page. The best way to know if you are doing better or worse is to set your own baseline and compare your performance over time.

    I have seen most bounce rates fall between 18 – 30% on home page and the site overall. Any page with a bounce rate higher than 30% should be looked at closely. I am not saying that you should not analyze the pages below 30% bounce rate. Remember there is always room for incremental improvement.

    There are several factors that determine the actual bounce rate of any page.
    Here are some of the numbers that were listed by Steve Jackson based on his experience with various sites.

    Source: http://tech.groups.yahoo.com/group/webanalytics/message/6116

    Retail sites driving well targeted traffic 20-40% bounce.

    Simple landing pages (with one call to action such as add to cart) I’ve seen bounce at a much higher rate, anywhere from 70-90%.

    Content websites with high search visibility (often for irrelevant terms) can bounce at 40-60%.

    Portals (MSN, Yahoo groups etc) have much lower bounce rates in our experience 10-30%.

    Service sites (self service or FAQ sites) again usually lower 10-30%.

    Lead generation (services for sale) 30-50%.

    Per Steve,
    “I must stress that all the above figures are based purely on our own
    experience after working with clients. I wouldn’t advise you base an
    optimization model around these numbers. We advise that when forming a
    benchmark, that you do it internally. Take the average bounce rate over a
    given period on your current site. You need to have at least 1000 entries
    coming from normal sources to get reasonably actionable data.
    Measure what the average bounce rate is and then work to get that down.”

    What are the factors that affect the bounce rate?

    Below are some of the factors that determine the bounce rates. You can use this as a checklist to diagnose a high bounce rate issue.

    1. Source of your traffic – Each source results in a different bounce rate. When setting your baseline create overall baseline and baselines for each traffic source e.g. display advertising, organic traffic. With one client I found out that the traffic driven by searches (paid and organic) and sources other than campaigns had a much lower bounce rate than traffic that was driven via display ads. Their display ad had 90% bounce rate while other traffic only had 35% bounce rate. Their overall bounce rate was around 55%, way lower than 90% and giving them a misleading picture.
    2. Search engine ranking of the page – A page which ranks higher on irrelevant keyword will get a higher bounce rate. I have seen this to be an issue a lot of times. I wrote an article on how to follow the search and reduce your bounce rate.
    3. Type of Audience – If you are advertising and reaching the wrong audience you will see higher bounce rate. Bounce rate will tell you if you need to better target your ads.
    4. Landing Page Design – Landing page design affects the bounce rate. I suggest A/B testing to improve after you have set your baseline. No matter how low you go there is always an opportunity for improvement unless you somehow achieved 0% bounce rate.
    5. Ad and Landing Page Messages – If the messages on your banner or search ads are not aligned with the messages on the landing page then the chances are you will have one of those 50% + bounce rates. Make sure messages are aligned and give visitors a clear call to action. Many a times I have seen marketers sending users to a generic page instead of an appropriate landing page. This can (and will) result in higher bounce rates. Again A/B or multivariate testing should be used to reduce the bounce rate.
    6. Emails and Newsletters – Subject lines, to and from, links, banners, the layout of email and the landing pages all work in tandem. They can either result in a great user experience and hence lower bounce rate or can result in a disaster. Do testing (More on this later in another post) to reduce bounce rate.
    7. Load time of your page(s) – A longer load time can result in visitor bailing out of the site causing higher bounce rates. Conversely, users can hit the refresh button, thinking there was a problem with the page load. This will incorrectly reduce bounce rate.
    8. Links to external sites – A page that has links to external sites (or sub domains/ pages that are not tracked in the same data warehouse) will show higher bounce rates.
    9. Purpose of the page – Some pages’ purpose is to drive users inside the site while other pages provide the information that user is looking for. A page that provides the end result can show higher bounce rate. One example is the support page on my bank’s web site, I have this page bookmarked. Whenever I need my bank’s phone number, I go to my favorites, pull this page, get the number and leave.
    10. Other factors – Pop-up ads, pop-up survey requests, music, streaming video, all can have an adverse effect on bounce rates if users become annoyed.

    Hope this clarifies the confusion around Bounce Rate. I would like to thanks Brad Gagne, who challenged my thinking on this subject, provided his valuable insight and proof read this article.

    Contributed By : Bounce Rate Demystified – Web Analytics, Behavioral Targeting and Optimization by Anil Batra

    Hits, Page Views, Visitors and Visits Defined

    This article is an introductory level and the intention of this article is to clarify few terms that you constantly hear in Web Analytics. Why am I writing this article? I hear some confusion about these terms from people new to field, so I thought I will write this blog post to clarify some of the common terms.

    I am going to explain, Hits, Page Views, Visitors and Visits in this blog post.


    Back in the early Internet days, Hits was a term commonly used to measure websites traffic. This term was mainly used by IT folks, early users of web analytics tools, to get an idea of the load on the server. As Web Analytics has moved into marketing and we have move to JavaScript based solutions, this term does not hold much meaning today as terms such as Page Views, Visits and Visitors have taken over.

    So what is a Hit anyway? Let’s take an example of a simple web page shown below

    This page is an html file with one image embedded in it.

    When a person browses to this page (in her internet browser), she is requesting this page from the server to be downloaded to her internet browser. She views this page as one entity. In return browser is actually requesting 2 items from the server

    1. The actual HTML page
    2. The image embedded in it

    When server returns these items, the browser assembles them and makes them look like one page to the person browsing this page.

    This is what the log file of the server might look like (I have removed several items to make it simple) – – [16/Jun/2007:11:17:55 -0400] “GET /samplepage.html HTTP/1.1” 200 3225 “http://www.anilbatra.com/” “Mozilla/5.0 (Windows; U; Windows NT XP; en-US; rv: Gecko/20070914 Firefox/” – [16/Jun/2007:11:17:55 -0400] “GET /batman.jpg HTTP/1.1” 200 3225 “http://www.anilbatra.com/” “Mozilla/5.0 (Windows; U; Windows XP; en-US; rv: Gecko/20070914 Firefox/”

    That means there were 2 hits on the server, one for the html page and one for the image. So with one page request there are 2 HITS (in this example)

    All the above items will show up in your analytics reports if

    1. You use log file based solution
    2. You do not filter them out when setting up your reports

    If you use a JavaScript solution then the only thing which is tagged (contains the JavaScript code) is the HTML page and that’s the only thing which will show up in the Web Analytics report.

    Now let’s take a look at this sample again but this time we will look at the source to make sure there are no items hidden behind the HTML code. Sometimes (read most of the time) there are files that are not visible to the individual but still need to be downloaded from server and count towards the hits.

    Here is what the source code looks like:

    You will see there are two more files that are embedded in the page. One is a style sheet (stylesheet.css) and the other is a JavaScript (myjavascript.js) file.

    So when a user requests this page, a total of 4 files are being requested from the server

    • The actual html page
    • The image embedded in it.
    • The .css file (stylesheet)
    • The .js (JavaScript File)

    This is how the log file will look like – – [16/Jun/2007:11:17:55 -0400] “GET /samplepage.html HTTP/1.1” 200 3225 “http://www.anilbatra.com/” “Mozilla/5.0 (Windows; U; Windows NT XP; en-US; rv: Gecko/20070914 Firefox/” – [16/Jun/2007:11:17:55 -0400] “GET /batman.jpg HTTP/1.1” 200 3225 “http://www.anilbatra.com/” “Mozilla/5.0 (Windows; U; Windows XP; en-US; rv: Gecko/20070914 Firefox/” – [16/Jun/2007:11:17:55 -0400] “GET /stylesheet.css HTTP/1.1” 200 3225 “http://www.anilbatra.com/” “Mozilla/5.0 (Windows; U; Windows XP; en-US; rv: Gecko/20070914 Firefox/” – [16/Jun/2007:11:17:55 -0400] “GET /myjavascript.js HTTP/1.1” 200 3225 “http://www.anilbatra.com/” “Mozilla/5.0 (Windows; U; Windows XP; en-US; rv: Gecko/20070914 Firefox/”

    If you are counting the Hits then there are 4 Hits on the server. It is evident it does not make a lot of sense to count Hits. Let’s look at what make sense (at least for now).

    Page Views

    According to Web Analytics Association Standards, “Page is an analyst definable unit of content”. Page Views is the number of times a page (an analyst-definable unit of content) was viewed.

    So what does it mean? It means you can define type of file, Module, Flash interaction, PDF etc as a page and when a user views them they can be counted as Page Views.

    Let’s use the above example and define a valid page as the files with .html extension only. When using a log file solution we configure the tool to filter out the other types of requests and only count pages with .html extension as valid pages. In a JavaScript based solution, all other types of files mentioned above (except .html in this case, if it has the JavaScript tag) will be automatically excluded from the Page View count.

    So how many pages will the analytics report show? One, as there is only one html page. (You can configure your JavaScript based web analytics tool to track other forms of files as page views too but that requires customization).
    The one page that is showed in the reports is a page view.

    Visitors or Unique Visitors

    Visitors or Unique Visitors, sometimes also referred as Unique Users is the number of unique individuals visiting a site. The most common way to identify an individual is via an anonymous cookie. Keep in mind that this is a close estimate of unique visitors and not an exact measure. Here are four examples on how unique visitor count can be wrong

    1. If two people use the same computer and same browser to visit a site, that identifies users by an anonymous cookie, both of them will be counted as one unique visitor since their cookie will be the same.
    2. On the flip side, if one individual uses two different computers to access the same site, the individual will be counted as two unique visitors because the new anonymous cookie will be issued on both the computers and show up as two different cookies in the analytics tool and hence will count them as two different visitors.
    3. If an individual uses the same computer but two different browsers (say IE and Firefox) then the person will be counted as two unique visitors because each browser will have its own cookie.
    4. If the individual visits the site, she will be counted as one visitor. Then if she clears her cookie and then visits the site again, she will be counted as two visitors.

    Note: Visitors are calculated over a period of time e.g. day, week, month, year etc. and a visitor count from two periods can not be added together to get a total visitor count. Let’s take the data for following 2 days
    Day 1 – 30 visitors
    Day 2 – 45 visitors

    The total visitors count for day 1 and day 2 is NOT the sum of the visitors count for the two days i.e. it is not 75 (30+ 45). Why?

    For simplicity let’s assume that all the visitors who came to the site on day 1 also returned to site on day 2. In that case we will have 30 visitors from day 1 and 15 (45-30) on day 2 as unique between those two days, making the total unique to be 45 for the two day period and NOT 75.

    The calculation I showed above has been simplified for this example. My advice is to let the analytics tool do the calculation for you and not sum the visitor count from separate period to come up with the total count of unique visitors.


    Visit is also known as session. Visit starts when a visitor interacts with this site. In most case the interaction is the first page view by the visitor. The visit ends when user does not interact with a site for specified period of time. Most of the web analytics tools set 30 mins of inactivity as the end of the visit, however in most tools it is configurable and you can set it to whatever makes sense for your business.

    Unlike, unique visitors, total visits to the site can be summed across time periods to get the total visit count for the period.

    Hope this clarifies some of the confusion surrounding these terms.

    Questions? Comments?

    From Anil Batra: Hits, Page Views, Visitors and Visits Demystified

    What is a HiPPO?

    web analytics hippo
    Web Analytics HiPPO

    HiPPO, as it relates to web analytics, is an acronym for “Highest Paid Person’s Opinion” or “Highest Paid Person in Organization”, the term is widely used and made famous by Web Analytics guru Avinash Kasuhik (Not sure if he actually coined the term).

    Many in the web analytics community believe that a person in Highest Paid Position is generally wrong because that makes random decision based on intuitions and instinct rather than data.

    Real Time Analytics Tools

    Below is a list of Real time Web Analytics tools that you can you to optimize your landing page and conversion paths. We will continue to update this page so that you have the latest information. If you find something that we should include then please email us.


    Tool Price Site
    Clicky Free Trial http://getclicky.com/
    Clicktale Free Trial http://www.clicktale.com
    ShinyStat Free Trial http://www.shinystat.com/
    Reinvigorate Free Trial http://www.reinvigorate.net/
    StatCounter Free http://statcounter.com/
    Woopra Free http://www.woopra.com/
    Performancing Free Trial http://pmetrics.performancing.com/
    Piwik Free http://piwik.org/
    SiteMeter $6.95 and up http://www.sitemeter.com/
    TraceWatch Free http://www.tracewatch.com/
    Chartbeat $9.95 and up http://chartbeat.com/
    W3Counter Free Trial http://www.w3counter.com/
    Histats Free http://www.histats.com/
    GoSquared Free Trial http://www.gosquared.com/
    DaCounter Free http://www.dacounter.com/

    Source: http://www.Optizent.com


    Web Analytics and Usability Testing

    Here are two presentations about marrying Web Analytics and User Experience (UX). Since there are not very many articles, presentations on this subject this should help you get started. If you do find something that we should include here then please let us know.

    Here are two presentations about marrying Web Analytics and User Experience (UX). Since there are not very many articles, presentations on this subject this should help you get started. If you do find something that we should include here then please let us know.

    1. Marrying Web Analytics and User Experience Louis Rosenfeld • 5 August 2009 Delve NYC • Brooklyn 1

    [slideshare id=1401452&doc=keynote-090507123424-phpapp01]

    2. Web Analytics and Usability Testing: Triangulate your way to better design recommendations by Eva Kaniasty

    [slideshare id=1579031&doc=analyticspresentation-090613183722-phpapp02]

    Creating a Culture of Web Analytics

    All those who have worked at companies which never used or do not use web analytics to make decisions about site changes, know how difficult it is to create a culture of web analytics. It is very hard. Building a culture of web analytics is a grueling uphill task.
    After working with various client I have found that reasons for not using web analytics vary from company to company, some of the common ones are:

    • Gut feel has always worked or at least it seems like it has worked
    • It is an additional step in the process
    • New skills are required to use web analytics. They feel they don’t have the required skills for using web analytics
    • Fear of accountability i.e. now I will be measured and I don’t like that
    • The reports that they got in past were pretty useless
    • They didn’t believe in web analytics data because they have no clue on how the data was collected
    • They don’t understand how web analytics can help them
    • They don’t understand what web analytics is

    The first reaction of many newly hired analyst/analytics manager is to start talking about KPIs, reports, what web analytics can do etc. But before you start digging into the data and analysis and start to talk about KPIs, dashboards etc. you need to understand the root cause of why analytics has not been used in the past. Understanding and tacking those issues will give you a better platform to build the culture of analytics on.

    Here are few things you need to do before jumping into KPIs

    • Identify various stakeholders, who could benefit from web analytics, in the company. You don’t have to have a comprehensive list of every person but some that you think could immediately benefit and you can immediately help is also a good list to start with
    • Get a meeting with them, individually or grouped together in groups based on their roles/departments etc.
    • Agenda of the first meeting should be to understand why they have not used web analytics in the past and what they would like to see from web analytics group. Don’t talk about KPIs yet. This meeting is about hearing them, if they talk about goals, metrics etc. then fine but don’t jump to discussing KPIs
    • Make sure they understand that there will be a follow-up and you are there to help them not to use numbers to find faults. You need collaboration. Don’t let other people’s opinion about HiPPOs put you in an offensive or defensive position
    • Schedule a follow-up meeting to go over you analysis of the past meeting, address any concerns/issues that are preventing them to use analytics

    The goal of this exercise is to make people feel confident that you can truly help them make data driven decisions without jeopardizing their job. You understand their concerns and are willing to address them.

    During this process you will also find out who all (groups/individual) are more willing than others to help you build your case and will provide you small wins that you can use to garner more support. If you have an executive support e.g. your bosses boss then leverage that to help you.

    At the end,remember, every company is different. The culture is different, challenges are different, political structure is different so it is critical you understand all those elements. It is not going to happen overnight so be prepared for a long rocky journey.