Google Analytics Bug(s), Time On Page grossly Inaccurate
I describe a pretty good workaround for this Analytic's bug. You do need some javascript coding experience. I've only tried this for a few days but am pleased to finally see accurate "time on page" data for "bounce" pages (much longer times). I hope someone will find this intriguing enough to experiment and improve on it. If only Analytics provided a trackPageExit function none of this would be required. If Google doesn't provide a fix in Univeral Analytics I think this trick will still work, but I wanted to test in a known, stable, environment. I also noted during this investigation that analytics is not handling thumbnails well, thumbnails that open in the same window, but a quick fix is to open thumbnails in another tab, a compromise.
For any page Google Analytics calls a "bounce", the time on page indicated is completely inaccurate. This make sites that have the highest quality pages appear to have poor time on site and very high bounce rates. A visitor could sit on a landing page for two minutes (or hours) and "back out" and this is still called a bounce by Analytics; sorry it's not a bounce if you use Google's definition.
[support.google.com ]
Bounce Rate is the percentage of single-page sessions (i.e. sessions in which the person left your site from the entrance page without interacting with the page).
"Interacting with the page" is the key, Analytic's definition is farcical, the only default interaction is clicking on another page, an ad, or leaving the site. I find this misrepresentation very annoying.
Using analytic events you can correct the bounce rate, but the "time on page" data is still completely wrong. I've found a workaround that appears to accurately report the time on page for a bounced page. The workaround does not appear to affect other Analytics statistics other than correcting them.
In implementing my workaround I've also decided my definition of a "bounce" is:
1. less than 15 seconds on a page
2. and no user scrolling
If the user scrolls or views the page for more than fifteen seconds Analytics will no longer report a bounce. You can achieve this today with events, BUT, you still will not see an accurate "time on page". (Note: A page loading produces a scroll event, you must ignore this one event if your goal is to detect "user scrolling".)
The time on page correction trick It is very simple, if you know your visitor is truly exiting the SITE, call this code:
_gaq.push(['_trackPageview','/dummy/']);
AND, set up a subdirectory filter in Google Analytics for the "/dummy/" subdirectory.
Go to Admin, Filters, Filter Name: "TimeOnPageFix", Exclude, "traffic to subdirectories", "that are equal to", "/dummy/"
Now analytics will think it's seen the second page it needs, so desperately, to time the first page, and, pushing a trackPageview to a subdirectory that is filtered does not affect your analytics results. But the "time on page" data will now be correct (see Quirks). I have tested these revised "time on page" statistics to a limited extent and they appear to accurately reflect the true visitors "time on page".
Typically one can use the onbeforeunload event, set a flag in some code that tests whether a clicked link is staying on site or exiting the site. If the outbound link is staying on site (internal) do nothing in the onbeforeunload event, but if the link is exiting the site, then do the trick, _gaq.push(['_trackPageview','/dummy/']). I put a for loop after this to hold onto the CPU for a while to let the analytics code complete its transmission; this may not be necessary. Another possibility is using onunload after onbeforeonload, or settimeout, to delay exit, but debugging this kind of code is problematic because the browser is exiting the page! Also, full cross browser support is difficult for the onbeforeunload event.
At one point during this experiment I had code that was periodically sending an activity event when a visitor had a page open in their browser. In this case I saw times on pages of hours, obviously the visitor, was working with other tabs. I also have a few pages that visitors do truly spend hours using, in one session, and in those cases the javascript on the page is sending analytics "activity events" periodically.
The Quirks There's always a quirk when you try to do this kind of hack (actually the quirk was there already!). For the "time on page" to be accurately reported for a given page's statistics, one of your many visitors must click on a second page, what? Analytics seems to slam a zero time for a page view whenever the exit statistic is 100%, but after the page is viewed 5 or 10 or 20 times one of your visitors will likely click on a second page. So really you'll have to look at several days analytics results to see all the "time on pages" for your bounced pages.
I have some bounce pages that visitors truly use for hours, until I implemented this change the "time on page" would be reported as zero! For many of my more interesting pages the "time on page" reported has tripled or quadrupled.
I'm not sure about the user flow diagram it appears to work but I need to collect a lot more data.
Results Comparing a few recent days data to the data in the previous month yields virtually no changes in sessions or page views recorded, BUT, the "Avg. Time on Page" has risen from 2 minutes to 11 minutes, see how important those "bounce" pages are? And this is without forcing 100% Exits to less than 100%. For pages which I know from feedback, pages which visitors must study to use, times on page have gone from a minute or two to 30 minutes, which is Analytics default maximum time of a session.
One page that had many pageviews (sessions), seesion that all were reported as Exits (100% exit) as soon as one visits that page and then clicks on another page on the site, the reported time on page jumps from 0 ZERO, to 52 minutes! And I know the content of this page will make a visitor stay for long periods of time. (This is something you can fix just by forcing a none exit event, forcing 100% Exits to be less than 100%)
Another truly interesting stat is, over a period of days, there might be 1300 Pageviews, with 9650 scroll occurrences/events. This is not a count of javascript scroll events, but a count of the many times the user chose to scroll on various pages, again clearly indicating that when Analytics was reporting a minute or two on a page the data was wholly inaccurate.
I hope to discuss this from another perspective in the Google SEO thread.
