Use Google Analytics on your blog? Check your bounce rate(drawingablank.me) |
Use Google Analytics on your blog? Check your bounce rate(drawingablank.me) |
"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.
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!
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.
Line 3435 (for me, I'm logged in) holds the answer.
Sorry, but I found your comment to be disrespectful to the article (dismissing what it says as some hands-in-the-ears denial") and wrong to top.
>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.
Still this is orthogonal to the article -- which discusses bounce rate and the way GA measures it by default.
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.
What you're speaking of is the inference that is often (incorrectly) drawn from bounce rate; owed to the misunderstanding of the precise definition.
> 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.
[1] https://support.google.com/analytics/answer/1009409?hl=en-GB
EDIT: I also disagree that the article's solution measures your definition of bounce rate.