Standard Metrics Revisited: #4 : Time on Page & Time on Site
I 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:
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…..
Tp = Time spent on a page.
Ts = Time spend on the website.
Someone visits your website at 10:00……
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....
111.111.111.111 - - [08/Oct/2007:11:17:55 -0400] "GET / index.html HTTP/1.1" 200 10801 "http://www.google.com/search?q=avinash+kaushik&ie=utf-8&oe=utf-8 &aq=t&rls=org.mozilla:en-US:official&client=firefox-a" "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7"
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! :)
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!!"
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…..
Exit!
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).
Hence:
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….
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….
Bounce!
This is what is computed….
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…..
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……
[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!
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.
You 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.]
PS:
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:
- Standard Metrics Revisited: #1: Visitors
- Standard Metrics Revisited: #2: Top Exit Pages
- Standard Metrics Revisited: #3: Bounce Rate
And here is a related post that outlines four attributes each great metric should possess:
January 8th, 2008 at 02:02
Interesting read Avinash, thanks – as Google Analytics uses Javascript tags to measure the data, is it one of the tools which uses a script to measure time spent on the site?
January 8th, 2008 at 02:54
Really?! I didn't know that. I assumed (oh dear, slapped wrists) that it 'knew' when the browser had moved on. Now I think about it, how could it? 'Doh' to me too then.
January 8th, 2008 at 03:55
Avinash,
Thanks for this post. It's really good to see this confusing concept explained simply. However, I do have one quibble! I think in your second example, most programs will actually report Ts = zero, not Ts = N/A. Google Analytics started using N/A a few months ago, but quickly changed it back to zero.
Zero makes more sense. In your first example, Ts is really "5 minutes + N/A but we'll pretend it's 5 minutes". In the second example, it's "0 minutes + N/A but we'll pretend it's 0 minutes". If you call it N/A instead, then the average time on site will take the average of everyone who saw more than one page. That might be an interesting KPI for some people, but it's more complicated to explain and will significantly inflate the average compared with standard average time on site.
January 8th, 2008 at 03:56
I'm no Analytics God but afaik you got it right. :)
However, I think that "Time on Site" is really pretty useless metric because of the limitations outlined by you.
And there's more which, in my opinion, renders this metric very unreliable:
Tabbed browsing
I use to browse a lot of web sites by not opening links in the same window but by opening them in a tab, so I can read the content of the current page in the first tab, maybe follow another link in this same tab, while the other pages opened in tabs "sit" there waiting to be read.
This does not only mean that the time spent on that first tab is reported as being much shorter than it actually was but also that the time on page for the pages in the background tabs will appear to be much higher than it actually is.
I haven't actually been on one of those background, after all. They were just waiting there to be read by me.
Well, but maybe it's just me browsing a site this way… :P
January 8th, 2008 at 05:25
Great post, Avinash!
@Rob Lewis — page tagging or log files…are both log file based (I recently wrote a post titled "Web Data Capture Methods — Two Methods that Suck" that explains how both work — the "Suck" part was an homage to a post from Avinash back in 2006): http://tinyurl.com/2yo4o6
Using Javascript to capture the onunload would work with either page tagging or log files…but it does then require some processing modifications to interpret whatever "request" that script fires.
One of the "other hacks" is to use scripting to fire off a request at a regular interval. I was playing around with Fiddler a while back and could swear I found a couple of sites that were doing this. This, though, seems like a really good way to tee off the user!
January 8th, 2008 at 06:08
I hope you plan on continuing this standard metrics series for all 28 WAA standard metrics. It's a lot of fun to follow along (for us metrics nerds)!
- CJ :)
January 8th, 2008 at 07:43
If a website is designed entirely in Flash, how does the analytics software capture time stamps if there is only "one" page to the entire site? Just curious…
January 8th, 2008 at 07:44
Avinash-
I always enjoy the way you break down concepts. Somewhere deep within you there lies an academic:-). This was an enlightening read as I did not think about "The Case of the Missing Timestamp".
One quick question though. If page 1, 2, and 3 above were to be part of a funnel (say a 3 level) would the total time for the linear path still be Tp(page1)+Tp(page2)?
On the time spent on Page 3, I was thinking that the calculation should be the other way around
(Time Next Page – Time of request for page 3). Did I get this wrong?
-Ned
January 8th, 2008 at 08:08
Great article as always – i too was wondering about the whole tabbed browsing issue?
I think a large percentage of (primarily) FF users split the site onto different tabs – especially if it's a site with a main page or index, then flip between the different tabs. Does analytics pick this up?
I'm not thinking this will be a big problem with the new website i'm working on – but it's an interesting question for sure.
Also – i don't want to make the site stats of regular sites i visit seem worse than they should be if analytics doesn't like tabbed browsing :)
January 8th, 2008 at 08:57
Interesting post Avinash. I always figured the 'time on site' metric was a tough one to understand, just considering my own browsing habits of having multiple browsers and tabs open.
It's also one of these metrics that hard to interpret when you do have it. IMO most pages have an 'optimal' time based on the goals of the content. Index type pages want you to find what you are looking for fast and move on, heavy content pages want you to stop and read. In isolation of the goal of the page, the metric is rather useless – it seems.
The best use is probably as a tracking unit – time-on-page moving up or down compared to its historical average needs looking into.
I'd be interested to hear from people who actually use this metric for a KPI.
January 8th, 2008 at 10:35
I remember reading up on this in your book, b/c somebody asked about it on an SEO forum. Great to have another post about it. Especially one that's so visual :-).
Everytime I hear about this what comes to my mind is the fact that click density reports/heat maps (not sure which is the correct WA expression) exist.
If you know where users click isn't it possible to find out also when those clicks occurred? I often spend tons of time just reading the same page, however I usually have to scroll, etc.. I assume for some reason it's not possible/too complicated to pull this off?
January 8th, 2008 at 10:42
This is a fantastic post series! These posts make very complex ideas so simple that even internet novices can understand.
Please keep this series going ;)
AH
January 8th, 2008 at 10:59
Great post and I learned a lot. I'll have to go back and dig through your previous articles.
One question – you mention "the session is terminated at the end of 29 mins". Is that the case for Google Analytics? I understand that analytics packages take different approaches but I've been curious about some of the disparities I've seen as I've compared Google Analytics to PMetrics, Statcounter and several local analytics apps. In many cases, I've found Google Analytics reporting significantly fewer visitors and page views as compared to other packages. Thoughts?
January 8th, 2008 at 14:59
Great article! I have started to get involved with web analytics. I am in the process of reading the book which my boss sent me for Christmas :). I am sure I'll be referring back to it too. Love the site.
January 8th, 2008 at 15:15
I thought that Google Analytics injects some JavaScript that catches "onbeforeunload event" and reports back to Google Analytics.
Why standard urchin.js script doesn't do that?
January 8th, 2008 at 16:38
Can you explain a bit how Google Analytics handles this using their "old" method (urchin.js) and how they handle it with their new event tracking (and ga.js)?
The reason I ask is because most of the sites I work with are in Flash and with urchin.js I've been creating fake pageviews to track "events" (which may have had a side benefit of creating lots of little time stamps – good for time on site, bad for time on "page").
However, with the transfer to ga.js and event tracking, I'll have less pageviews and more events tracked in the real sense. And since I compare performance across sites (using time on site as a performance metric – for better or worse), I'm afraid this might be unfair to the newer sites using ga.js.
Thanks for the post Avinash – makes me realize how much I don't know.
January 8th, 2008 at 23:42
Rob : You asked since tag based solutions were already using "script / code" to collect data if they were currently automatically using the "unload" code in measuring Time.
The answer is no for pretty much all analytics tool in the market, including Google Analytics and others.
My hypothesis has always been that it is probably because by doing that the vendors will instantly get twice the amount of data (rather than one "hit" per page it will now be two). Impacting storage, compute power, query times etc etc (especially in a ASP implementation).
I want to stress that this is my personal hypothesis. For the actual best answer please ask your vendor.
Dr. Turner : You are right about 0 instead of N/A in the case of bounce / single page view session. I have corrected the post above. Thank you so much!
In terms of what GA did: It was not so much that they started storing N/A where they used to store Zero.
It was more the case that for that short duration the query that computed time on site would simply ignore single page view sessions since in reality there was no actual data for how long the Visitor was on the site. So technically improving the Average Time on Site. As you note this was reversed quickly (though it would make a very interesting computation of how long the actual Average Time on Site is for sessions were data is available).
Lars : I can't believe I forgot tabbed browsing!
For you and others who asked about it I have added a whole new section in the post, please scroll up and read the "Case of Tabbed Browsing" section above.
Kristine : What I described in the second scenario happens. It appears as a single page session.
So zero time on site and zero time on page.
But if you use features like Event Logging from Google Analytics (and couple other web analytics tools that also do true event logging) then you can capture how long they spend interacting with your cool flash website. What buttons they pressed, how much they forwarded or rewinded etc.
Everything except from the last click to exit from the site. There you are still stumped and for that last click you don't know how long (unless you do a hack).
[
Bonus Info: These two articles from Justin are a bit technical but a excellent read for understanding exactly how event logging works and how you can implement it:
http://www.epikone.com/blog/2007/10/16/event-tracking-pt-1-overview-data-model/
http://www.epikone.com/blog/2007/10/16/event-tracking-pt-2-implementations/
I also highly recommend Justin's excellent book: Google Analytics Short Cuts: http://www.oreilly.com/catalog/9780596514969/
]
Ned : You are right, it would be Tp(page1)+Tp(page2).
For the latter question you had: bigger number minus the smaller number (if the bigger number is present!).
Alex -S : Please see the new section in the post above on tabbed browsing! :)
Paul : I don't know if I'll agree that it is not a useful metric (think of content sites, think of 98% of the visitors on ecommerce sites that will never convert, think of non-profit or non-ecommerce sites).
The number is important but: Few people understand how it is computed (then they average it!) and fewer still then can make decent decisions off it.
Patrick : If there is a click (what you are seeing in click density / heat maps) then there is a time stamp.
Remember the article mostly covers the problem of what happens on the last page, in that case there is no click. The Visitor simply leaves. This means you have no idea how long they spent on that page.
Robert Irizarry : The standard for pretty much the same for all web analytics tools now in terms of how the sessions are terminated when there is inactivity.
Many tools will allow you to change the value from 29 mins of inactivity. So net net you should check your tool.
Also just to quickly note that this will impact the Visits number, not Unique Visitors.
Dennis : Please see the Tabbed Browsing computation section in the post above. I think it answers your question.
Latham : You are mixing a bunch of things together. Let me try to see if I understand your question and try to explain….
Time computations between urchin.js and ga.js have not changed one bit. So absolutely no impact on stuff you read in this post. It is how it used to be.
You were creating "fake page views" to measure rich media in the past. This had a detrimental impact on your page counts, as well as time spent. You were just mixing real page events with fake page events. (Don't feel sad, this is still how most, but not all, web analytics tools still measure rich media.)
If you use Event Logging which is available via ga.js you will capture true events, this data is not fake page views, it is stored separately in a clean way, and hence you can get real time on page and time on site and real time spent interacting with your rich media.
Hope this helps.
Everyone : This post was a lot of work and then it was several hours of more work to update it for tabbed browsing and cleaning things up.
But your comments and fantastic questions make it all worth it. Thank you and please keep your comments / feedback coming!!
-Avinash.
January 9th, 2008 at 07:30
Thank you for writing this! Now if we can only get it on the front page of the WSJ so the rest of a business will understand it!
January 9th, 2008 at 12:51
Hi Avinash – I think you touched on this at Blog World and after reading this post I really understand how the time is computed.
My question are –
Even though the data isn't completely correct, it's consistent, so as a blogger, should I be paying attention to this metric?
Should I be watching for trends?
Thanks!
January 9th, 2008 at 16:07
Heh. Tabbed Browsing. The amusing side of that for evil-me, is the mindset(?) that no-one ever had multiple browsers open to the same site before tabbed browsing came along.
The entire web is so unstructured, so non-linear, yet the common viewpoint from the analysis side only wants to see the linear view.
Recognising that no-one else is me. :-) Buying Stuff sites are the ones where I have always had multiple windows or tabs open. It's just easier to bounce around and compare "stuff" that way vs. back and forth.
I'd disagree with your phrasing :-) of "linearise" for the 2nd tabbed option. As the first option of splitting the two streams is somehow according that single person a split personality – that the two streams are somehow divisible. They are not.
So it's not "linearising", it's showing exactly what happened. *Hopefully* the referral side will allow for understanding and actions to take to fix the possible problem of … hmmmm…. "forcing" end users to split ones site up across multiple tabs.
The assumption I feel you've made here Avinash, for eg, Page 5 is *only* accessible via Page 4; is the key issue. The user may be using the 2nd tab as a scratch pad. Lookup style of Thing. Page 5 was simply more convenient for them off the 2nd tab than the first.
I guess what I'm saying (eventually :-) ) is that we are trying to complicate and understand something that is all but impossible to understand. We have no mind-reader tags yet. ;-)
Cheers!
- Steve
January 9th, 2008 at 17:16
I'm probably guilty of promoting time-on-site reporting as much as Avinash. I'm puzzled to read the criticism of it and all the inaccuracies, when ROI / ROAS / Revenue reporting is even more error prone.
People feel confident about ROI reporting because it seems to solid, and time on site seems vague.
I assure you, if you knew the process by which ROI gets assigned, you'd run into the safe arms of time-on-site.
Maybe we should dissect ROI calculation?
January 10th, 2008 at 00:33
On some sites i have a bounce rate of 40% for returning visitors. So tab browsing could be a part of the explanation?
For average time on site GA takes the average of all times including the 00'00 of the bouncers =A.
Then they take the average of the time on site without the bouncers =B.
And then they take the average of A and B.
That result is your "average time on site".
January 10th, 2008 at 01:00
[...]
Simone Lovati segnala un interessante post di Avinash Kaushik sul modo in cui vengono calcolati i tempi di permanenza sui siti.
Il post è il 4° della serie “Standard Metrics Revisited” che si propone, appunto, di “revisit some extremely well established and accepted metrics with the goal of providing fresh insights. “
I temi trattati in precedenza sono visitors, top exit pages e bounce rate.
[...]
January 10th, 2008 at 05:24
Once again, great post.
Are you sure GA will report 2 visit for the tab-browsing case even though it happened in the same time frame?
January 11th, 2008 at 01:10
[...]
Mobile Search and Internet Access Data from Japan – Global Thoughtz Japan
Web Analytics
2008 Google Analytics Resolutions – Epike One
Standard Metrics Revisited: #4 : Time on Page & Time on Site – Occam's Razor
No time like the present! – Google Analytics Blog
[...]
January 11th, 2008 at 02:59
Just a question/idea.
What if in the GA code tracking we add
var pageEventTracker = pageTracker._createEventTracker('Exit');
and then in the onbeforeunload event we put
pageEventTracker._trackEvent('Exit', 'Exit');
Would GA be able to compute the correct time on page for this page? Has anyone tried it? I mean, GA may not have a following request to compute the time on page, but it is certainly receiving a hit and somehow knows the user is still in the page.
January 11th, 2008 at 03:05
Just another idea. If GA doesn't use this events to compute the time on page at least we could pass the time on page – calculated via JS – to the event via the value parameter. Then in the event tracking at least we would see how many people spent how many seconds in their exit page.
January 11th, 2008 at 20:35
[...] Standard Metrics Revisited: #4 : Time on Page & Time on Site – Extremely interesting and useful for any analytical mind. I will be using one of the techniques mentioned to better track the time a user is on my site. [...]
January 12th, 2008 at 06:36
Thanks for updating the post with tabbed browsing!
And also great that you explained how GA handles it, I didn't know that – yet another thing learned from your blog… ;)
January 13th, 2008 at 10:03
[...] Standard Metrics Revisited: #4 : Time on Page & Time on Site (Avinash Kaushik) [...]
January 14th, 2008 at 00:28
Sheila : As a blogger I think Time on Site it is less useful for blogs. Mostly because people will come, they will read the latest post and they will leave. Especially your regulars. So I focus on other blog metrics.
From time to time I'll look at the Time on Site number.
One of the tools I use on my blog is ClickTracks and it allows me to analyze New Visitors separately in a very easy way. So what I'll do is from time to time I'll see what new visitors are doing, what pages interest them, how long they tend to stay on the site etc.
John : Hurray! I completely agree with you, and you are on!!
Peter : To your comment about 40% bounce potentially cased by tabbed browsing, if you were referring to Google Analytics then the answer is no. GA uses Method #2 described above.
In terms of Average Time on Site Goggle Analytics does what all other tools do. Take the average of all Visits to your site and report that (and that "average taking" includes bounce and no bounces etc). That would apply if you are looking at data in aggregate or if you segment it. For this, and other reasons, in the past I have recommended using reports that show distributions.
Open your web analytics tool and find the report that looks like this, every tool should have it (if you can't find it reach out to your web analytics vendor help center):
You can easily see how the attached image is so much more helpful in understanding what is happening on your site.
Zvika : GA will report one visit, see this link (or post above, Method #2)…
http://www.kaushik.net/avinash/wp-content/uploads/2008/01/time_on_site_impact-tabbed_browsing-linearized_2.png
Sergi : Great suggestions. I am afraid the Google Analytics help team might be best placed to answer the deeply technical questions. You can find them by clicking on the Contact Us link in the footer of any GA report – they will reply back in 24 hours or less.
Thanks everyone for your kind contributions and delightful comments.
-Avinash.
January 14th, 2008 at 18:16
[...] Vitally important is knowing what each specific metric means and how it gets calculated. One metric that I look at on a regular basis is Time on Page and Time on Site. They measure how long a visitor is engaged on your site. The conventional thinking is the more time that is spent on a specific page or site as a whole, the better. I came across a great summary by Avinash Kausisk, a Google Analytics Evangelist that really explains how Time on Page and Time on Site are calculated. It’s a little bit different that I had originally thought and he dives deep into how opening links in tabs can affect the calculations. Interesting stuff. [...]
January 15th, 2008 at 07:02
Sorry to have missed you at the eMetrics. but I hear you spoken to Ian.
The actual page view time based on the onUnLoad event is something that we have been doing for some time with our performance tag code. You're absolutely correct in that this results in addition log entries (three in total: Page Access Time, Page Loaded Time, and Page UnLoaded Time) for each actual page impression, but the results can be extremely insightful. On a basic level, this allows us to show slow loading pages (Page Load Time – Page Access Time), as well as individual page view times (Page UnLoaded Time – Page Loaded Time). In additional we often find that people have had a web page open for many days, which may be a result of power saving techniques such as hibernation or stand-by!
Additionally, we have been analysing tabbed browsing by comparing a pages stated referrer to the previous page in the context of the visit. Using your above example, the 'linear' sequence would result in the following:
Page
Home (Referrer = Google, Sequence = N/A)
Page 4 (Referrer = HP, Sequence = Home)
Page 2 (Referrer = HP, Sequence = Page 4)*
Page 3 (Referrer = Page 2, Sequence = Page 2)
Page 5 (Referrer = Page 4, Sequence = Page 3)*
The * represents the results of tabbed based browsing. Reporting on this, can help enrich the understanding of user behaviour.
Anyway, another great post, which I'll be pointing many people towards.
Sean.
January 15th, 2008 at 08:14
I have posted on this great post on my blog as I find it extremely helpful.
That being said, Now after I've also read the great comments I am about to write a much deeper post on the whole concept of these metrics, their meanings and how to filter out the garbage.
Basically, once we realize the zero seconds concept, we must get rid of all these users while analyzing and counting. If we know that a zero seconds visit means that we couldn't actually measure the visit (and that's most visits!), it's best to discard these users and focus on the ones we CAN measure.
A second thing is with regards to John Marshall's comment(Hi John :-) ) about ROI/ROAS calculations – I think we all need to get awy from the solid numbers and get much deeper into the trends and movements – It does not really matter if my conversion rate is 1.8% or 2.6% as both numbers will probably be inaccurate to some degree. It is CRUCIAL to know when the number is MOVING and changing up and down.
January 15th, 2008 at 08:56
[...] Following Avinash’s great post I’ve already mentioned yesterday, I re-read the entire post and more than 3o interesting comments. The main problem as Avinash explains, is that we can’t actually calculate the time on page and time on site where we don’t have an “exit” mark. This basically means, that most of our “bounces”, “zero” time on site and “short visits” (depending on your software verbiage) are related not only to those who close their browser right after entering your page, but to those who viewed 1 page, perhaps even for a while – but didn’t go any further. Well I say delete them! [...]
January 15th, 2008 at 08:58
I've just added a post with my thoughtsd and examples on why we should eliminate the zero time on site from the analysis, following the explanations and comments to this post.
January 16th, 2008 at 23:20
[...] Standard Metrics Revisited: #4 : Time on Page Very well written and easy-to-understand explanation of how analytics software tracks time spent on a given page or site. (tags: analytics statistics) [...]
January 17th, 2008 at 06:35
Thanks for the very informative post, Avinash.
January 18th, 2008 at 07:18
Hi Avinash,
Great post! The knowledge you provide us by this blog is extremely helpful for us.
And i have a question Avinash, In many organizations for some security reasons I.T dept. implement websense for blocking some websites of specific categories. So a lot of websites get blocked by this, Now if a visitor type the URL of such kind of websites he'll get blocked message on his PC but just before that he redirected to that website for a short interval which might not opened although.
Now i want to know that it'll count as a hit or bounce coz time interval is very less? or visitors are not counted at all by this activity?And if traffic are coming thro' Google or other search engines will it be display in referrals or not?
Regards,
Suchet Vatish
January 18th, 2008 at 17:49
Suchet :It is hard to say definitively. I see two scenarios….
Usually the javascript tag for all web analytics tool sits at the end of the page and so all of the page has to render before the tag gets executed and sends data.
This means that if the redirect is happening quickly then the javascript might not have been executed and no data – no impact on time on site.
If the redirect you describe happens after all the elements on the page load (including the web analytics javascript tag) then data is sent – impact on time on site will be the same as described for bounce above.
Hope this helps.
-Avinash.
January 18th, 2008 at 23:56
Suchet: The situation you are describing is like banning some websites using your organizations' proxy server filtering the websites to specific users or all users. If we type a wesite name ( or go through SERPs, or links on website, email, chat window etc. etc.), then the request will be first processed by proxy server and if it is banned then the request will end here only. So, there is no question of request reaching at actual website's web server.
January 21st, 2008 at 07:41
Avinash, in response to this and to your earlier post at http://www.kaushik.net/avinash/2006/05/excellent-analytics-tip2-segment-absolutely-everything.html is it possible using Google Analytics to isolate visitors by their time on site? To be able to understand the site browsing difference betweens the long-duration visitors and the brief? And to completely eliminate the under-10 second visitors?
Thanks.
January 22nd, 2008 at 06:06
Hi Pat,
It is rather difficult to create a profile in Google Analytics based on the length of a visit. To do so you would need to customize the JavaScript page tag. Unfortunately there is no way to use a filter to create the data you're looking for.
What you can do is create profiles for important visitor segments based on attributes of the visitor (geo location, keyword, marketing campaign, etc.) This can provide insight into which segments may be affecting your time on site metric.
Here are instructions on how to segment visitor loyalty reports in Google Analytics. I hope you find it useful.
Justin
January 22nd, 2008 at 07:11
[...] the latest posts on time on site on this blog and on Occams Razor by Avinash Kaushik, I received a few questions and I also saw a few comments about Segmenting Visitors by Average Time on Site [...]
January 22nd, 2008 at 07:16
Hi Justin and Pat,
I just wrote another post here: http://www.ophircohen.com/2008/01/22/segmenting-visitors-by-average-time-on-site/ which explain exactly how to accomplish the segmentation you mentioned.
Only thing is, I don't use Google Analytics but ClickTracks. Still I think you should give it a try – use the trial and setup some data and see some insights which literaly blow your mind :-)
Oohir
January 30th, 2008 at 06:38
[...] 1. How long did that person stay on the page before bouncing? Most popular Analytics packages (Google Analytics) have a problem – the average time a user spends on a page, given that it is the only page they land on, is not recorded. I would say that an average of 15 to 20 minutes on a page with detailed instructions that drive somebody to a form of action that is not a click through the site is extremely successful even though the bounce rate would be almost 100%. A good example is our NUDE series posts – we receive 100+ visits to those every day and the bounce rate is around 90%…I haven’t implemented the fix I linked to a couple sentences ago but I do have a live chat program that let’s me view the footprint of a visitor and the time they spent on that particular page. The average time spent on those pages is around 12 minutes and I’m certain that those visitors walked away with something very engaging and valuable. At least I like to think they got something valuable out of it. [...]
January 31st, 2008 at 23:09
[...]
Web Analytics
* Avinash/Occam’s Razor: Standard Metrics Revisited: #4 : Time on Page & Time on Site
[...]
February 1st, 2008 at 11:51
[...]
Standard Metrics Revisited: #4: Time on Page & Time on Site
I found the above article to have a lot of details about “Time on Page ” and “Time on Site”. If you want to know how these metrics are created read the post.
[...]
March 11th, 2008 at 08:39
Thank you for this site.
This is just what I needed.
I plan on returning here frequently.
March 24th, 2008 at 01:10
Let me ask something about tab browsing you mentioned in this post.
I am confused the number of sessions for "Dealing with tab browsing # 2". One or two?
* Outcomes: One Sessions, visit “reorganized” by time stamps.
* Net net: 2 Visit. 1 Unique Visitor.
These two are conflicting each other?
If I am false, please let me know.
p.s. One Sessions -> One Session(misspeled)
The purpose I comment like this, just complete a great post if it needs. ;-)
- – -
NOTE: Minjae: My apologies, it should read 1 Visit and 1 Unique Visitor. I have fixed it now in the post. Thanks for pointing it out to me! -Avinash.
April 4th, 2008 at 06:01
Hi Avinash,
I'm trying to get to the bottom of a problem we're having about the 'time on page' stat for pdf files. We have onclick GA JavaScript set up for pdf downloads, but how on earth is Google Analytics recording a time on page stat for these pdfs?
It's been flagged up by a client because the time on page for these pdfs is showing up as considerably higher (up to 11 mins) than all the HTML pages being tracked. If, as I suspect, it's not possible for GA to track how long someone has spent with a pdf open, where on earth is the stat coming from?
I'd really appreciate your help on this.
Thanks
April 4th, 2008 at 12:53
Hi Jammit,
I have a feeling your tracking code referrs to counting clicks on links to pdf files rather than actually analizing time on pdf files.
Unless the GA code was embedded somehow inside the pdf (which I am not sure is possible – but will be happy to learn is it is) – It only counts the click on the link.
Ophir
April 7th, 2008 at 00:35
My thoughts exactly – so my question is, where is GA getting the "time on page" data for PDF downloads from??
April 7th, 2008 at 02:22
Jaamit – probably the same way all other "time on page" calcs are done. Delta between click/open time; and the next html click. 11 mins doesn't sound too unreasonable.
Also: Check the lunametrics blog. Robbin S did an experiment with some other funky GA stuff a few months back. You could easily duplicate and cross verify??
HTH?
- Steve
April 7th, 2008 at 03:11
OK, assuming most people get PDFs opened in a browser window, most people wouldn't navigate away from a PDF via a link click – I'd say it would either be with the back button or closing the new window / tab. From reading this post it seems GA would not be able to measure the time from a close window action, so is it measuring time between the initial click and 'back' button click? :|
True, but with the HTML content on this site has an average time on page of 1 minute! Which leads me to think that there's something strange going on with the way it's measuring this stat. What I would like to know is, can I trust the 'time on page' metric for PDF files?
April 7th, 2008 at 14:52
Jaamit: Let's dissect things a bit to get a richer understanding.
Time on site is computed using this "formula":
Time Stamp (last link hit) Minus Time Stamp (first link hit).
(Or look at the picture in the above post).
Let's talk a couple scenarios:
1)
+ Requested home page: 0900
+ Requested page two: 0901
+ Leave
Time on site: One minute.
Time on page two: Zero minutes.
2)
+ Requested home page: 0900
+ Requested page two: 0901
+ Click on link to download pdf on page two: 0902
+ Leave
Time on site: Two minutes.
Time on page two: One minute.
3)
+ Requested home page: 0900
+ Requested page two: 0901
+ Click on link to download pdf on page two: 0902
+ Dance for 13 mins to Ini Kamoze's Here Comes The Hotstepper
+ Go back to the site and click on a link to page four: 0915
+ Leave
Time on site: Fifteen minutes.
Time on page two: Thirteen minutes.
That should help you understand what is happening in your case.
Couple points of note:
# Pretty much every single web analytics tool will behave as above, GA or otherwise.
# Javascript based tools (pretty much all of 'em right now) don't track the download time of the pdf (even if they say that they do, push 'em and ask them exactly what they do).
# In your case, or in scenario #3 above, the whole pdf / download thing is a "distraction" to understanding. The pdf click was captured and reported, but what might be impacting time on site is the fact that the person came back to the site before the session was terminated (in less than 29 minutes).
# Above, #3, would happen to time on site even in this case: click page one, click page two, go to google.com and search for dresses, come back 28 mins later, click on page three.
Web Analytics is fun! [Seriously!!]
-Avinash.
April 8th, 2008 at 01:56
Excellent, thanks for a very clear reply Avinash. Love the Ini Kamoze reference too (13 minutes…do you know of some secret extended version? lol)
May 30th, 2008 at 00:54
Great Explanation, BUT (!!) I have an important question:
On google analytics, when "Time on site" is, for example, 00:03:42, does it mean 3 min's and 42 sec's? Or is it 3 sec's and 42… smaller parts??
May 30th, 2008 at 07:48
I never see a topic is clear like this ! I'm clear about TS & TP mean now. GA shows all TS are zero for me, I wonder if my site can't open or too slowly. finally I know it's because high bounce rate.
thank you very much.
June 16th, 2008 at 08:24
Thanks for this. Huge help.
It also begs the question(s)… as this turns to a KPI for monitoring those who travel to +1 pages, how does that change the landscape? Is there a benefit in knowing that the time on page is directly tied to those who visit a page and decide they want more?
Cheerio
@Trontastic
July 20th, 2008 at 11:13
Just a comment to those interested in getting the real time on page. It's possible to get it two ways, triggering a fake pageview with the tracker inside the event window.onUnload (better in another profile as we would get a lot of fake pageviews) or via the new GA event tracking (now still in beta but available if you requested it) triggering a event when the user leaves the page, that passes as a parameter the time on page.
September 16th, 2008 at 09:12
[...] This was another recommendation by the same vendor that he said would help tests complete faster. There are significant problems with time-on-page metric, though, as Avinash’s excellent article (one of many) explains. To summarize the article, bounces and multi-tabbed visits are probably not being tracked the way you expect (I couldn’t explain the details better than Avinash does, so please read his article for more on that subject). And, even if the measurement method were flawless, what does time-on-page tell you? If visitors spend more time on your landing page, is that a positive or negative conversion indicator? [...]
October 14th, 2008 at 14:46
[...] How time on site is calculated. Nothing can be that easy, right? Most analytics packages count a single page visit (no matter how long you stayed on that page) as spending 0 seconds on the site. For an in-depth explanation of how most web analytics packages measure time on site, you can read this post on Occam’s Razor. I’ll give you the Readers Digest version here, though. [...]
December 22nd, 2008 at 13:35
[...] analysts recently used competitor data to find a decrease in a client competitor’s site. Is this evidence of an improved site design, perhaps a redesign? Happy visitors, quickly finding what they need? But isn’t Time on Site also sometimes used as an indicator of successful engagement, in the absence of Conversion Rates, to determine whether a page is successful? (albeit with a bit fuzziness due to the way time on site is calculated online). Should we celebrate a trend toward long sessions, or cringe in horror? [...]
January 7th, 2009 at 09:57
Hi Avinash, I enjoyed the post thoroughly and enjoyed the extra credit section even more. This post actually was the strongest when doing a site search on google when i was searching for an answer on how I can get Analytics to do ROAS reports. Currently I'm using a commercial technology but I would prefer to use Google Analytics – where I can parse the product revenue into the javascript action tag – can analytics do this??
January 7th, 2009 at 14:04
Andreas: I am not sure I understand your question completely, but. . . . .
In this post check out item #4 and the links provided:
Google Analytics Maximized: Deeper Analysis, Higher ROI & You
GA provides a very flexible javascript for ecommerce tracking and it has the ability to capture lots of different kinds of information (this kind of robust and flexible functionality is also provided by pretty much all good WA tools provide).
-Avinash.
April 6th, 2009 at 15:22
[...]
Average time on page — this prompted some debate, but the general agreement, I think, was that the problem with this report is that many, many people use it without understanding its shortcomings (which Avinash covered in detail early last year in a blog post).
[...]
April 22nd, 2009 at 08:38
[...] 网页访问时间实际上是应该这样计算:通过该页面请求第二个页面的时间点减去请求该页面的时间点所得的差才是这个页面的停留时间。 这与我原先以为的计算方法是有很大的差距的。宋星对这点也有连载翻译Avinash的文章来说明这个访问时间是如何处理的。 [...]
June 19th, 2009 at 12:07
Thanks! Excellent info – you spent a lot of time – great value – had to tweet it -
June 21st, 2009 at 11:00
I am setting up a segment and I can't find the answer to this.
What is the unit of value that Google uses for 'time spent on…' ?
June 22nd, 2009 at 07:19
David,
I believe time is measure in seconds in Google Analytics.
Best,
Justin
June 24th, 2009 at 07:12
Many thanks for this explanation. I have been working with my analytics provider the last few days trying to understand how time on site is computed. As a non-technical person, I was having a difficult time understanding how the data was computed. This article is very clear. Thanks again.
July 18th, 2009 at 06:32
[...]
Time on site is the length of visit on your website. A high time on site may indicate your visitors may be interacting extensively with your site. However, high time on site can be misleading:
Your visitors may have a hard time looking for what they want
Your visitors leaves their browser windows open when they are not actually viewing or using your website
Occam’s Razor explains how time on page and time on site are calculated.
[...]
July 20th, 2009 at 07:29
Time on Page and Time on Site metrics are important, but they don't tell the whole picture. Also it depends on what analytics package you are using. Using Omniture SiteCatalyst or Google Analytics will show different results.
August 11th, 2009 at 03:09
My apologies if I missed this among the many replies above, but I have a question: when a visitor has my site open in one tab and another site open in another tab and is looking at the other tab, does Google Analytics count that time in the time on site in my site? Does that change if they go to a new page in my site during that session or not?
Thanks!
Alex
August 14th, 2009 at 22:18
Hi,
Everyday I compare site avg time on site through my alexa.com and find that it is higher than facebook.com, youtube.com, myspace.com.
What does it mean?
Alex
September 1st, 2009 at 01:06
[...]
In analytics… as far as tab goes… as soon as you go to a new page on the same site in a different tab… it will change the users click track history and time on page would be updated… as to the system you have left the old page. For a bit more technical details see… Standard Metrics Revisited: #4 : Time on Page & Time on Site | Occam's Razor by Avinash Kaushik
[...]
September 18th, 2009 at 00:16
Having found this article, I've learned a lot today. Thanks for this valuable share.
October 17th, 2009 at 11:52
[...] http://www.kaushik.net/avinash/2008/01/standard-metrics-revisited-time-on-page-and-time-on-site.html [...]
November 13th, 2009 at 01:34
[...] Otra métrica interesante a este efecto es el Tiempo en el sitio/Tiempo en la página. Una medida de cuanto tiempo conseguimos que el usuario pase en nuestro sitio (leyendo, interactuando con él, …). Si este dato es bajo es señal de que nuestras propuestas no interesan mucho al visitante. De nuevo, para saber más sobre esta métrica os recomiendo encarecidamente leer Standard Metrics Revisited: Time On Page. [...]
December 22nd, 2009 at 13:32
[...]
The other thing I tried during this series is to both include a ton of links (Don MacVittie called it a link-fest) to referring stories along with links to the previous stories in the series for easy perusal. When one got read, so did multiple others which positively influenced Pages per Visit and Average Time on Site – key metrics for any website. Finally, I’m thinking about recording the blogs to offer an audio version (à la Audio Whitepapers) of the series.
[...]
December 27th, 2009 at 22:31
Hi Avinash,
Its a wonderful post. Nowher have I seen the above topic explained soo clearly and simply.
Thanks dude. :-)
February 2nd, 2010 at 08:06
[...] Avinash's Blog: Calculating Time on Site & Time on Page. [...]
May 27th, 2010 at 02:09
Could "Time on page" be considered a worthy metric for pages which are purely educational in nature?
May 27th, 2010 at 14:11
Audrey: It could be, but as you would have noted in that post it is not possible to accurately capture that piece of data (i.e. without extra specialized coding or without special tools that add a lot of weight).
But the time someone spending on a page might not allow you to infer as much intent / success as you might believe.
Here is a blog post that has my point of view on how to measure pure content site, in this case measuring Government websites (can't get any more content only than the government!)…
Web Analytics Success Measurement For Government Websites
-Avinash.
August 4th, 2010 at 13:20
[...]
2. Забудьте о времени на сайте. Современные системы веб-аналитики (Google Analytics, Яндекс. Метрика ) измеряют время, проведенное пользователем на сайте неправильно. Детальнее об этом можно прочитать в блоге Авинаша Кошека. Это техническая проблема, которую можно решить используя альтернативные системы (например, Webvisor.ru ), если действительно есть потребность измерять время правильно.
[...]
September 8th, 2010 at 01:57
I appreciate the information. I'm on my way to finding the answers to my questions. Thanks and God Bless!
October 12th, 2010 at 11:17
[...]
Time on page is a tricky metric because if you have a standard implementation of *any* Web analytics tool, then they don’t provide you the time on page for visits with single-page views.
For more detail on this, see this post: “Standard Metrics Revisited: #4: Time on Page & Time on Site.”
So, it is not that these metrics by themselves are playing a more vital role, because while they are great diagnostic metrics (at least bounce rates), they are simply not strategic enough.
[...]
October 14th, 2010 at 06:34
[...]
the “Avg. Time on Page” metric in Google Analytics (GA). I recommend that you also read Avinash Kaushik’s post about how GA calculates Time on Page and Time on Site. If you don’t know this by now, you may be surprised to find out the Google Analytics doesn’t actually know how long a visit’s last pageview lasted. GA only knows how long a pageview lasted if there is another pageview on that site following it (or a track event, add transaction, or add item hit for that matter).
[...]
October 22nd, 2010 at 17:59
[...]
Sobre tempo de permanência acho necessário alertar que essa métrica é um tanto complicada. Se você tiver implementada a versão padrão de qualquer ferramenta de analytics, jamais terá dados consistentes sobre o tempo de permanência para páginas separadas. Mais informações você pode obter nesse artigo (em inglês).
Então não acho que essas métricas estejam desempenhando um papel mais importante. Ao mesmo tempo em que são ótimas para o diagnóstico (pelo menos a taxa de rejeição), sua função estratégica é bastante limitada.
[...]
October 27th, 2010 at 20:59
How does GA define "activity" in the website?
Is it possible to have pages with 30+ minutes avg time on page registered in GA?
I understand that after 29 minutes of "inactivity" the session is terminated…
Thanks!
October 27th, 2010 at 22:06
Gustavo: Consider these two scenarios:
1. You come to the page. You do nothing and you leave (or leave the browser open) after 35 mins. In this case the time on page can never be more than 30 mins. You did nothing on this page for 29 mins and at that point your session was terminated.
2. You come to a page. You do nothing for 26 mins. You reload the page (or do some action) at min 27. Then you read the page. Hit reload again (or do some action) at min 40. In this case it is possible for the page to have more than 30 mins of time on page.
This applies to pretty much any web analytics tool's behavior on standard settings and not just Google Analytics.
Hope this helps.
Avinash.
October 27th, 2010 at 22:27
Thanks for your reply Avinash.
That's what I thought…
I just still can't understand why do I have several unique visitors (with repeated visits) to my home page with an average time on page of ~1 hour or more…
Is there any other activity (or action) besides clicking and reloading that can be considered part of an active user? (scrolling?, clicking non-items?, moving the mouse?)
Thanks again and greetings from Sydney!
Gustavo
October 31st, 2010 at 01:29
[...] Длительность просмотра страницы – это довольно обманчивая метрика. Когда вы используете любой стандартный инструмент веб-аналитики, он никогда не покажет вам время, проведенное пользователем на просмотренной странице, если такая страница была всего одна. Чтобы лучше разобраться в этом вопросе, рекомендую прочитать пост «Standard Metrics Revisited: #4: Time on Page & Time on Site». [...]
November 2nd, 2010 at 12:17
Using Google Analytics:
This may seem a little novice, but here is my question.
What if the same scenario happened and Page 1 and 2 were coded with the GA code but page 3 was not. Would GA pick up the time on site for Page 2 after going to Page 3 (the non-coded page)? What if they left Page 3 to go to Page 4 (a coded page) would the time on site start over? Would the original referrer still be given credit?
Thank you in advance.
November 2nd, 2010 at 14:58
Jim: Assume this scenario, based on your comment:
Page One viewed at 1000 hrs
Page Two viewed at 1010 hrs
Page Three viewed at 1020 hrs
Page Four viewed at 1030 hrs
If page three is not tracked then that won't be in GA, or Omniture or WebTrends or anywhere. No javascript code, no data.
In this case:
Time on Page Two = 20 mins (1010 – 1030)
Time on Page Three = no data
Time on Site = 30 mins (1000 – 1030)
I hope this helps.
Oh and in this case since the the "hits" were in the same session all the referrer info is the same (as it was for Page One). If Page 4 was viewed 30 mins after Page 2 then the original referrer will be "lost" as the Page Four hit would start a new session (since after 29 mins the original session expired). This is how it is in every tool, GA does nothing different or extraordinary.
Avinash.
November 11th, 2010 at 08:05
Thank you Avinash! The issue I am facing is that the Bounce Rate I am seeing for a specific referrer (search engine x)on GA is relatively low (between 5-10%) but the average time on site for that source is very low as well ~50 secs. The average time for the website overall is ~ 6min. Every page is coded properly. How is it that this referrer could send so much traffic that moves past the homepage but only stay less than a minute. Some of the "hits" even show as a 1 second visit??? What could be the issue with this referrer? Any input would be helpful.
Again, thank you in advance.
November 11th, 2010 at 08:34
Jim: It is hard to identify the issue with the context in your comment. But when I run into issues like this I use surveys or other such mechanisms to collect VOC.
For example at the moment I am running a survey to collect task completion rate for my site. It has amazing insights into what people are doing. You can review my results at http://zqi.me/wakiss
I would recommend using qualitative analysis to get insight when quantitative fails. Better than guessing. :)
Avinash.
November 15th, 2010 at 14:48
I had a follow up question about this post:
"Oh and in this case since the the "hits" were in the same session all the referrer info is the same (as it was for Page One). If Page 4 was viewed 30 mins after Page 2 then the original referrer will be "lost" as the Page Four hit would start a new session (since after 29 mins the original session expired). This is how it is in every tool, GA does nothing different or extraordinary."
Let's say the visitor in this scenario left after visiting all coded pages. Closed the browser and everything and 20 minutes later decided to run a search for the website on Search Engine X. Who would show as the referrer for this second visit? The seach engine/term used on the initial visit or would this second visit be seen as a different referral path with a different time on site, page, etc.?
Thanks in advance.
November 16th, 2010 at 00:32
[...]
Habiendo descartado esta opción, solo nos queda la solución de generar páginas vistas adicionales para poder controlar este tiempo. Esto se debe hacer con un perfil nuevo (con nuevo UA) para no alterar el resto de métricas, aunque cualquiera de estos métodos incrementará mucho el número de llamadas a Google Analytics.
Si aun tenéis alguna duda, podéis escuchar la explicación que da Google o leeros la explicación que hizo Avinash hace un par de años
[...]
December 15th, 2010 at 23:38
[...]
So when I look at the analytics for my individual posts and see 0 seconds for time on page, it doesn’t mean that no one is reading my content. It just means they found what they were looking for and left my blog.
If you would like to learn more about the time on page or site metric, visit this post by Avinash Kaushik.
[...]
December 21st, 2010 at 16:04
[...] Avinash’s blog on how time on site and time on page are calculated [...]
December 22nd, 2010 at 13:29
[...]
W związku z tym również statystyki średniego czasu spędzonego w witrynie zostają zaniżone, ponieważ system nie rejestruje czasu spędzonego na ostatniej przed zamknięciem przeglądarki stronie. Podobnie dzieje się z użytkownikami, którzy zostali odrzuceni (lub raczej odrzucili nasz serwis). Dla nich system automatycznie przypisuje wartość 0 czasu spędzonego na stronie. Z czym również wiąże się zaniżony średni czas spędzony w ramach danej witryny.
Bardzo dobrze powyższy problem opisany został przez Avinasha Kaushika w artykule zatytułowanym Standard metrics revisited: Time on page and time on site.
[...]
February 4th, 2011 at 14:06
Avinash,
Nice post, Wondering if you know if the type of cookie effects the time calculation.
On one of our clients sites we changed all 3 cookies to be session (timeout set to 0). Now our time metrics are 2 to 3 times higher.
Any ideas???
Thanks, matt
February 4th, 2011 at 21:13
Matt: When you set the timeout to zero what you are essentially doing is telling the analytics system to blow all the cookies away when the browser closes.
Additionally you are also setting the session timing cookie to ignore the 29 minute timeout signal, which will mean sessions that otherwise would have ended now could last all day (technically from 0001 hrs to 2359 hrs)!
By doing what you are doing you are ensuring at least two problems: 1. Every single visitor to your site will be counted as a new visitor to your site (so wrong Unique Visitor data) and 2. Average session duration (time on site) will also be messed up.
You can well imagine that #2 will also mess up your time on page for at least some pages.
Typically unless there is a magnificently profoundly good reason (which you might well possess) it is inadvisable to mess with how your web analytics provider has set up the cookies to work.
Avinash.
February 13th, 2011 at 16:35
[...]
You might find useful information in this post:
http://www.kaushik.net/avinash/2...
I had the same problem before, it was related to a spammer who visited first our blog, let some spam comments and then went to our main site.. The visits were not significant in relation to the overall traffic we've got.
[...]
February 16th, 2011 at 17:05
What is confusing to me is how to measure how one's site is doing. Each common measure besides bounce rate has its flaws.
Time on Site: What is the ideal time on site? You want it to be long enough that the visitor was actually able to accomplish something, but a lower time on site means your site is streamlined and intuitive enough that visitors go from A to B quickly (ideally).
Pages/Visit: seems like it would pose the some interaction/ease of customer navigation duality as time on site. What is too high and what is too low?
Do you look at these two measures, and if so what do you look for?
If you don't, what else should I be looking at (ecommerce site)?
February 17th, 2011 at 09:32
Natasha: You should not be confused that you are confused. That is very common given the field we occupy. :)
There are a couple of metrics that are almost always useless (say % Exit Rate, unless you are looking at a structured funnel). But most other metrics fall in this category "this is a great metric for us because it helps us measure specific goal x for our website".
Time on site can be a good metric, Pages/Visit can be too, so can Bounce Rate and Visitor Loyalty and Task Completion Rate and …. so many more. But not all of them are right for you.
Here is a blog post with a framework you can use to pick the right metrics for your business:
~ Web Metrics Demystified
I also encourage you to embrace the Web Analytics 2.0 mental model, simply because it will help you answer your questions, like in your comment, in a much more sophisticated way than just using Clickstream. See the first part of this post:
~ Best Web Analytics 2.0 Tools: Quantitative, Qualitative, Life Saving!
All the best!
Avinash.
May 20th, 2011 at 06:31
[...] registrar ese momento temporal voy a usar una imagen para hacerlo más facil: Imagen del blog de Avinash Como se aprecia en la imagen la herramienta solo calcularía 7 minutos totales en el sitio porque [...]
May 31st, 2011 at 07:27
Dear Avinash,
I can not figure out the calculation of time on page(Page 2) of Sample Dealing with tab browsing # 2:
Tp (Page 2) = 4 minutes? (10:05-10:01)?
I think the time on page of page 2 should be:
Tp (Page 2) = Time of next page request (10:05) minus Time of page request (10:02) = 3 minutes.
right?
May 31st, 2011 at 11:40
Nick: The most important thing to take away is that it will "linearize" the hits (put them in the order the links were clicked, and then compute the times.
Here is what happens in our specific example…
1000 visit starts
1001 click to new tab (Page 4), this tab is in the background
1002 click (in the original tab) to page 2
1005 click (in the original tab) to page 3
The time spent on page 2 will be 1002 minus 1005 and so three minutes (and not four as I had stated it).
Thanks for helping me fix it.
Avinash.
May 31st, 2011 at 13:05
Thanks for explaining this. Someone has probably mentioned this elsewhere on here but I got some much more realistic Avg Time on Page data when I segmented to exclude average time on page greater than 5 minutes.
It'll vary from site to site what is a reasonable limit (since I'm in retail page dwell times are not particularly long and 5 mins is much more than enough to view any page on site unless perhaps it's account creation pages) but a bit of common sense can do wonders here!
June 1st, 2011 at 08:59
[...]
Sobre tempo de permanência acho necessário alertar que essa métrica é um tanto complicada. Se você tiver implementada a versão padrão de qualquer ferramenta de analytics, jamais terá dados consistentes sobre o tempo de permanência para páginas separadas. Mais informações você pode obter nesse artigo (em inglês).
[...]
June 1st, 2011 at 15:38
Charles: Averages stink, as we both well know! :)
I typically look at the distribution of the time spent on the site and use that to determine "typical" behavior or "desirable" behavior or, in your scenario, choose the number to exclude.
In GA the report is called Length of Visit (in the Visitors -> Visitor Loyalty section) in the old version, and Engagement (in Visitors -> Behavior section) in the new version.
All other tools also have this metric.
Thanks for sharing your tip!
Avinash.
June 2nd, 2011 at 19:21
[...] a great (authoritative) blog article from Avinash Kaushik, complete with easy-to-follow images:http://www.kaushik.net/avinash/2…This answer .Please specify the necessary improvements. Edit Link Text Show answer summary [...]