There seems to be some misunderstanding in these comments in how Google Analytics works:
"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.
As a person who's done GA implementations and subsequent reporting on around 100 websites this is correct.
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...
Regarding the multiple tab issue, you can use the Page Visibility API [1] to determine if the page is still visible before firing the timeout event. It's a pretty handy API for other things, too.
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.
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/
> 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 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.
This is a better approach, but I tend to open a page, see if it's an interesting topic in a few seconds, scroll to the bottom so that any images that don't load until you scroll to them get loaded and comments get loaded (for instance Disqus comments). After that I go back to HN and look for other interesting posts etc. Once I have more time or no internet connection I read the page.
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.
Only if you haven't read TFA and just wanted to add your uninformed opinion.
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".
You guys are arguing past each other. Your core disagreement revolves around the use of the term bounce, and is driven by the author's selection of title, implying that using adjusted bounce rate is the same as fixing your bounce rate. Hopefully we're all smart enough to see the difference.
The term bounce has a well defined meaning. People going away from your page, without reading it.
And it's not the parent that holds to that meaning, while I (and the article) distort it to mean something else.
It's Google Analytics that doesn't really measure bounce as people mean it. They measure not visiting a second page a bounce (!).
This is not the proper way -- and is probably used due to limitations in tracking ability for exiting a page. And while this might work for a site with a landing page -- where the content people look for will somewhere in another page, it doesn't work for a blog like site. If somebody reads my blogs main article for 10 minutes, that's not a bounce by any stretch of the word.
So what the author does is propose a way to fix GA to properly measure bounce rate the way men and god meant it.
He doesn't propose some alternative meaning for bounce rate.
If anything, that (using an alternative and not true meaning) is what GA does. GA redefines "bounce rate" by showing something which is not the bounce rate.
"Bounce rate (sometimes confused with exit rate) is an Internet marketing term used in web traffic analysis. 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."
If the wikipedia article represents the true meaning of bounce, then GA is (technically) correct. It's not about reading/not reading, but only about going to a different page. If a user does not view any other page within the same site, even if they stayed for 2 hours and have read the whole thing twice, then they still 'bounced'.
That said, I still agree with you that conceptually, you might want to measure engagement. And bounce == no engagement made (in this context). However this is a bit more difficult to measure. Even if someone stayed for 20 minutes and scrolled past a certain point, it does not necessarily mean they have read the content. It is a closer approximation perhaps.
I think you're using an unconventional definition of a bounce. For as long as I've been doing analytics (10+ years), a bounce has been defined as "a user visits one page, then leaves the site." The length of time spent on a single page was never incorporated in to bounce rate.
What you're speaking of is the inference that is often (incorrectly) drawn from bounce rate; owed to the misunderstanding of the precise definition.
No, that's not the definition of a bounce. From Google Analytics' own documentayion [1]:
> Bounce rate is the percentage of visits that go only one page before exiting a site.
That's all. That's all it can be, because computers cannot, by definition, know if a user read a page. One can compute a probability, based on things like scrolling speed and visible page elements, but that's hard to standarize under a single umbrella term.
Yup. For this example in particular, 15 seconds is barely enough to read through the first paragraph, nevermind decide if I want to finish the article.
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.
But is it juking the stats or adding another stat?
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)
What's the purpose of getting someone to read your blog post? Rarely is it just that. You'll want them to share/comment/subscribe/sign up for a trial/dive into finding out more about your product/buy. Doing these things will cause them not to bounce.
Just my opinion here but I think this is a bad idea. 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. By screwing with one metric, you're probably affecting several others.
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.
It doesn't make a lot of sense to count bounces when the visitor doesn't click on another page. The visitor may read the content, by happy with it, and then leave 2 minutes later. Why is that a "bounce"? I sure hope Google doesn't put a lot of SEO value on it, if that's the case.
Google does not use Google Analytics data for SEO purposes. What they measure are bounces back to the search result list. E.g. User clicks on a search result link, did not like what he saw and clicked the back button after 2 seconds to refine his search or choose another links rom the result list. This shows google that they sent the user to the wrong page (for whatever reason).
Exactly correct, backed up via Google's own search patents, statements, and third-party observations. Google has many ways without analytics to measure this.
That's the definition of a bounce. A visitor comes, they check out one page, they don't interact with anything (reading is not interaction), they leave. This might not be the most useful thing to know for many sites (a simple blog which doesn't have "recirculation" modules / isn't, like larger media sites, geared to having someone come and stay), but it certainly is a useful concept for media sites where pageviews are still king.
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).
They're the exception rather than the rule. The majority of the time you won't get any value from a visitor unless they complete an action while they're there. That's a bounce.
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.
This is a slippery slope. Because you'll end up touching that value until you're happy with the result. It makes that stat totally useless.
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.
This might work for blogs, But working for an e-commerce startup gave me a different experience. Conversion flow for our e-commerce site goes something like this[1]:
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 :/
The bounce rate supposedly affects PageRank. I'm not sure however if this fix also fixes the bounce rate Google uses internally for calculating PageRank.
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.
Yes, but google could still use the statistic information to adjust it's pageRank. We don't know. Though it would be easier to trick than the reference counting pageRank algorithm
This is a very interresting news if this is true. I'm managing a web site with one page containing article abstracts and references to pdf files. Our rank is surprinzingly not very good. I will try the proposed change and see if things get better. Articles are original content of scholar quality level.
Why in the world are you surprised the rank is not very good? If the site is one page + links to PDF's, you're unlikely to have a large number of inbound links, which means your pagerank is unlikely to get particularly high.
Indeed, according to http://www.w3schools.com/js/js_timing.asp, the first parameter of setTimeout should be a function. I don't know if "_gaq.push(['_trackEvent', '15_seconds', 'read'])" will be treated as a function.
Your analytics data. Google has repeatedly said that they do not use said information for ranking at all. You should use analytics for insight into you users, that's it. Use it however that best fits your needs.
I ran an A/B test with Clicky Analytics and the results were astounding. I have a 70% bounce rate with Google Analytics and a 20% bounce rate with Clicky.
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
I've been meaning to get around to implement something like this myself. There are a few other annoyances related to this in Google Analytics the author doesn't mention, such as Google recording the time of visit for one page visitors as 0 seconds.
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).
The Average Time on Page trend line should give you the information you need without resorting to this. If you have a call to action or a link to your main site on the blog, I wouldn't go changing the bounce rate metric.
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.
Also a helpful tip that we learned at our company. Sometimes, we log in additional information when a user gets to our site to understand things like load times or to log JS exceptions and such. If you are firing any background events, those will basically make every visit a "non-bounce" unless you mark those background events as a "non-interaction" event (boolean: true) to tell Google to ignore it for bounce rate calculations.
A tagging strategy has one purpose: to gather data for a reporting strategy. Why report on bounce rate where the expected use case is to "bounce" (follow link in, read, leave)? Surely the aim of blog reporting is to track visitor trends for overall audience growth/decline and topic popularity.
Good article, also instead of just knowing how many % of people bounced, you should know WHY the heck they left your site. A nifty tool that I ran into that helps with it: http://www.inspectlet.com/
Timeout sort of works - though I think adding a scroll down event gives you a better idea of whether people are reading your material - for the most part (crazy monitor sizes or short blog posts withstanding).
"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...