Being still less than a month old, it’s normal that I keep looking at this blog‘s stats quite often, and one of the most interesting bits — especially if you care about SEO — is the top search keyphrases list. I use both AWStats and Google Analytics for this site, and, concerning the former, I had been curious for a while about why the top search leading people to my blog was apparently for “chromebar“.
Now, I’m pretty sure I had never mentioned that term on this blog, so I thought AWStats might have been doing something wrong. A quick grep on my logs, and where “chromebar” came from became obvious: it’s from the StumbleUpon add-on for Google Chrome. The whole combination was necessary; StumbleUpon users with other browsers weren’t triggering anything like this.
Now, here’s what the “referrer” part of a hit from StumbleUpon, using Chrome with the SU add-on, looks like:
"https://www.stumbleupon.com/toolbar/litebar.php?device=chromebar&version=chromebar%202.9.8.1&ts=1301274701"
While a hit’s referrer from SU with another browser looks like this:
"https://www.stumbleupon.com/refer.php?url=http%3A%2F%2Fwinterdrake.com%2Fbad-comic-panels-3-its-a-membership-card-in-a-subversive-communist-front-organization%2F"
See the difference? The Chrome version has a query string: ?device=chromebar&version=chromebar%202.9.8.1&ts=1301274701 , while the other one doesn’t. And “chromebar” appears at the beginning of that query string.
Now, StumbleUpon is listed as a “search engine” in AWStats, in a file called lib/search_engines.pm , and that file optionally specifies which part of a query string (e.g. “q=“) from the referrer is the actual search. For some search engines, however, no such part is specified — meaning that they don’t provide it in the “referrer” part of the hit. Such is the case with StumbleUpon, where the query string part is an empty string.
But there seems to be a bug (or maybe it’s an intended feature?) in AWStats here: if no part of a query string is specified, and yet there is a query string, AWStats seems to use the first part it catches. As you can see above, that was ?device= , and it was always set to chromebar.
The easiest way around this problem (I don’t know if the AWStats authors will consider this a bug or not; I’ll try to report the problem in the near future) is to edit lib/search_engines.pm and add a non-existing query string part to StumbleUpon. Open that file with a text editor and look for this line:
'stumbleupon','',
and change it to:
'stumbleupon','qwerty=',
Presto! No more “chromebar” entries in your stats in the future. (It won’t delete current entries, though, unless you clear your AWStats cache files for that month and generate new stats.)
There are other people with the same problem; see https://sourceforge.net/projects/awstats/forums/forum/43428/topic/4034713/index/page/1
Hi,
thanks for the link over there. 🙂 I keep forgetting to report this problem to the AWStats developers (and suggest an addition to the bots list so it recognizes Bingbot)… I’ll try to do it tomorrow.
Might you also comment sometime on the difficulty of printing all 8 (or so) pages of AWStats when AWStats has been opened in Chrome? It comes out as a monochrome plot and only then after one has selected the appropriate pages and printed ‘selection’. This is the case even when printing as a PDF. However if trying to do this using IE then it all seems fine. Very odd.
Many thanks
Patrick
Nice detective work! I came across the same thing and your explanation & solution are excellent.
Of course, the irony being that you are now actually ranked for chromebar. hah. 😉
Glad I found your article on chromebar search. I was wondering the same thing? I don’t mind it at all. I find a lot of my visitors come fro SU so I don’t get what the fuss is all about?