"The Average Time on Page trend line should give you the information you need without resorting to this." Incorrect, if no further events or pages are clicked, time on site is ALSO incorrect.
"You'd have to research to make sure that your hack isn't also artificially inflating the number of pageviews, increasing the pages / visit and artificially deflating the Avg Visit Duration." This hack is tracking via events, not pageviews. The last item would be the opposite, it would increase the average time on site, not decrease it. However, that is another Analytics issue.
"Firing on timeout is not the ideal way as the general pattern tells us people open multiple tabs which they may or may not read." This IS true and a valid way of measuring. Though some might still prefer a time based approach.
This repo https://github.com/rockymadden/gap explains most of it.
Lastly, see Google's own word on this (tl;dr it's perfectly valid): http://analytics.blogspot.com/2012/07/tracking-adjusted-boun...
On a side note, a tangential GA issue was recently discussed on HN and nearly everyone had a misunderstanding of how GA worked in that thread too... sometimes I'm worried that developers will get wise to analytics and I'll be out of a job, and then I come here and my fears allayed.
The thing is, GA is very simple and it all works together. I'll leave the below link here, because I think a lot of people could get value from it...
[1] https://developer.mozilla.org/en-US/docs/Web/Guide/User_expe...
A better way is to trigger events based on scroll, that way you can better tell if there's been actual engagement on the page. I personally use this jquery based scroll tracking script for GA by Rob. http://robflaherty.github.io/jquery-scrolldepth/
This is what I was thinking. I do this all the time. However, I have to question your statement all the same. Yes, this is something I do. But, I'm a software developer. Assuming that the general population of internet users follows my personal usage patterns would seem to be a bad idea. Being a web analyst, are you saying that you've conducted studies verifying this pattern?
Regardless, triggering based on scroll seems like a sounder approach. Thanks for the pointer.
So I think doing something like checking if the tab/page is active (http://stackoverflow.com/a/1760268/2227792) would work more accurate, though only when an internet connection is present.
However, if the post was really interesting I might look for what other posts the author has made or for an about page about the author. I'm not sure however if there is a timeout after which preforming an other action is seen as a "bounce".
It makes me wonder how relevant a bounce rate is on something like a blog-post, I think refer-less visits are more interesting as they come from users that have bookmarked your post and visit it again at a later moment.
He specifically talks about blogs and explains why this works.
Because on a blog, the first page IS the very page people want to visit.
And they can spend several minutes in it (to read the latest entry) and then leave without visiting any other page. And that's not a "bounce" by any stretch of the imagination.
This behavior (counting a single page visit, however long, as a bounce) is fixed with the proposed change.
It's not "changing the meaning of bounce rate to ease your mind" (what BS), it's "changing the meaning of bounce rate to reflect the use case of your specific type of site".
On every site you want to know how long the user views a page. It's no different with blogs but it's a different concept.
The writer would be better off treating the bounce rate as an indicator of users who are engaged enough to hit the archives after reading a post, rather than juking the stats.
Post fix it seems to me that he has 3 numbers, the number of people who loaded them page, the number who spent enough time to read the first 'graph, and the number engaged enough to move into the archives…*
Pre fix, he only had the first and last numbers.
Personally I'd be tempted to use the page visibility API, and a number of timers, and really track who's reading 1 'graph or 3 or the whole article. But I sure don't think collecting more data, is juking the stats.
* Although this last number doesn’t seem to be accessible except via your vistor flow page. (Or I couldn’t find it)
Fiddling this metric is a fudge.
But let's assume that it isn't just about reading the article. Even some your examples could lead to a bounce:
* Sharing is pressing a button and doing stuff on another server, no activity for GA on this blog -> bounce
* Commenting can also lead to a bounce, if using an Ajax-commenter (think disqus)
* Buying and a trial probably won't be on your blog, but on another system -> bounce. Well, maybe, I admit that this isn't necessary.
Better to just leave it as is and do a better job interpreting the data. If you run a blog, you're simply going to have a high bounce rate. But as long as your avg visit time is still high, you can interpret the data in a positive way and effectively ignore the bounces.
But even on a simple blog, bounce rate is a useful stat. Many bloggers don't just want people to come from Hacker News and stay for one article, they want these visitors to click around to related entries after they are done reading. Bounce rate gives a good idea of whether this is happening or not (unless you automatically count almost all visits as non-bounce by triggering an event after a brief time interval).
blog.yourcompany.com isn't doing it's job unless it engages someone enough to share the content / comment / find out more about the product and on...
StackOverflow have established dominance in organic search and buckets of engaged users: not many sites are in the same position.
Track any other action a user takes in-page like sharing/commenting with a GA event.
I use different metrics to analyze engagement in blogs (like frequency, time on page, etc) and use the standard Bounce Rate to measure how likely is for people to go see more posts, or the "about me" page. If you have a 25% of people going to check out more of your work or who you are, I think it's a hell of a good thing, even if that gives you a 75% bounce rate.
Landing Page/Category Browse Page -> Product Page -> Checkout
Typically visitor will go back and forth between product pages and category browse pages (or simultaneously using multiple tabs). Any visitor not visiting a Product page is consider a bounce. It does not matter how much visitors paginate or browse the category pages if they do not visit product page they will not convert.[2]
I think bounce rate, conversion rate and any other fancy metric you use depends on your business, website, type of product, target audience, pricing, etc. As a startup the best thing to do is continuous experimenting untill you find the right success formula that works for your particular situation.
[1] Yes for e-commerce site with a few or one product this flow does not apply, Also this is for physical products with longer sale cycle with average order size between $800 - $1000.
[2] Yes we tried a lot of experiments, including adding direct path from Browse/Landing Page to Checkout. That particular experiment was a failure as it created clutter in the browse page and reduce product views and hence the conversion. I guess some day I will gather my thoughts and write about all the experiments we did and still doing.
> It represents the percentage of visitors who enter the site and "bounce" (leave the site) rather than continue viewing other pages within the same site.
So.. why are you changing that? If someone comes to your site, reads an article and leaves, that;s still a bounce :/
Also, you should put that code in a function closure rather than calling new Function():
setTimeout(function(){_gaq.push(['_trackEvent', '15_seconds', 'read'])}, 15000);Huh? Who said that?
AFAIK, PageRank is independent of GoogleAnalytics and does not examine bounce rate (which it cannot know). PageRank obviously works for the majority of webpages that do NOT use Google Analytics for example.
If that was true, it would be a standard trick to send a tracking event at load time to zero the bounce rate and improve pagerank.
http://www.youtube.com/watch?v=CgBw9tbAQhU
tl;dr NO.
MDN is nice: https://developer.mozilla.org/en-US/docs/Web/API/window.setT...
And if you are using DuckDuckGo... "!js setTimeout" will redirect you to MDN.
Word on the street is that Google Analytics is most certainly not designed for you - the website owner. It's designed for them to track what is useful to Google, which is why it's free. We all know Google makes bank on our data, so it's just another way to compile data without offering much service.
I suggest also installing Clicky Analytics and comparing. Would be interesting to hear results from other people
The implementation he describes here is just a 15 second ping. I was thinking about tying it to a scroll event and sending the ping if the user scrolls down (maybe a certain distance). This is actually a meaningful event in the context of a blog (since it likely means they are reading the article).
If you have a product and are advertising on AdWords, you can spend a lot of time dialing in your ad phrases. With a blog, you have a free test platform right there! Create a side bar widget that emulates the AdWords look and feel, and start A/B testing your ad text.
Step 1: Change the way you measure bounce rate
Step 2: ?
Step 3: Profit
thanks!