Web Analytics logging via JavaScript

   —   
As you may have noticed, websites that get a lot of traffic from RSS readers, anonymous crawlers, "check if site has changed" browser plugins and other non-human tools have somewhat skewed Web Analytics statistics. If that is your case, you should continue to read this article about JavaScript Web Analytics logging, which removes this inaccuracy.
The system provides two different ways of logging Web Analytics. The first is direct logging on each request, which means that visitors request a page and the request is logged before the page is returned to the visitor. Using this direct method, you can log even users who do not use JavaScript. However, this method filters out only "honest" web crawlers that properly send their unique user-agent with every page request. Because the system is not generally able to recognize malicious crawlers, RSS readers and other bots on the server side, they are logged as valid visitors. The second method is a newly added feature that solves this problem and logs Web Analytics via JavaScript, which filters out all non-human tools, but adds few minor disadvantages.
 
One of those minor disadvantages is that the server is requested twice, instead of just once. However, this behavior was load tested and we didn't find any performance issues, because there is no additional logic behind the web service request (meaning that all operations called by the additional web service are skipped in the first request anyway). Another disadvantage might be that users with disabled JavaScript or with browsers not supporting JavaScript won't be logged into Web Analytics, but such users typically represent not even 1% of all visitors, so it shouldn’t be a problem. The biggest issue might be when switching to JavaScript logging on sites that log a lot of custom Web Analytics. These will not switch automatically, so you may need to rewrite the logging of the custom analytics to use JavaScript. Otherwise the statistics might be a bit off (this depends on the character of the custom analytics).
 
How does the JavaScript logging work? With direct logging, there is just 1 client request and 1 server response. JavaScript logging leverages an Ajax snippet that is included in the first server response, so if the client supports JavaScript, they process the script and send another request to the web server, which logs the hit. After the second request, the code-behind does the same thing for both methods, so the only difference is the added JavaScript layer. Some Web Analytics aren't affected by using the JavaScript method, either because it wouldn't matter or it wouldn't work anyway. Specifically, these statistics are search crawlers, invalid pages, aggregated views (RSS) and banner clicks. Browser capabilities on the other hand are always logged using JavaScript because of the nature of the source data (browser details need to be pulled by JavaScript).
 
So when should you use logging via JavaScript and when direct logging? In most cases, you should use JavaScript logging, since it provides more accurate statistics for public websites. Though, there might be a few cases where direct logging should be preserved (such as intranets, sites with a lot of custom web analytics, or simply any solutions where the disadvantages overcome the accuracy advantage).
 
The default method is JavaScript logging, although if you are applying the hotfix that adds this method (7.0.17 or newer), your existing websites will still use the direct method by default.
 
If you want to switch to JavaScript logging, use the website setting located in the On-line marketing -> Web Analytics section called “Log via JavaScript snippet”. If you cannot see this setting, make sure that you have version 7.0.17 or newer installed.
-jv-


See also: Web Analytics dev guide overview

Applies to: 7.0.17
Share this article on   LinkedIn

Comments