» Web Log Storming Home » Articles » The Remedy for a Web Analytics Headache

The Remedy for a Web Analytics Headache

According to “The Web Analytics War Reader Survey” by Unica, as published on eMarketer website (The Web Analytics Headache), lot of marketers have problems with their current web analytics solutions. This is a breakdown of the results:

Could our Web Log Storming be the remedy for at least part of those? Let’s see…

1. Verify accuracy of data (41%)

This is a major issue, and, to be honest, we are glad so many people are aware of it. Second graph above shows specific reasons.

a) Can’t drill into the data to verify numbers (42%)

Web Log Storming is all about drilling into details. It allows you to to actually see list of sessions/visitors (filtered by any metrics) and all available details of each one of them (visitor data and individual hits). This allows you to react and easily exclude those you don’t wish to affect your statistics (for example, spiders, yourself, your employees, etc).

b) Marketing attribution issues (32%) and Campaign tracking code issues (25%)

These are actually related to other accuracy problems (due to JavaScript and code problems, hits that JavaScript analyzers are unable to track, etc). As web servers log every single request, the risk of losing data is minimal. In fact, most argue that log analyzers are useless because of this, as people are generally not interested in spiders and similar “dummy” traffic. I partially agree: other analyzers might be useless, but Web Log Storming’s ability to drill-down and easily filter out those is of utmost importance.

Back to the topic: with Web Log Storming you can define goals any way you like, as opposed to GA which allows you to assign a goals to pages only. Goal can be a page, sequence of pages, query, an image accessed from a third-party website (useful if you confide payments to specialized services), bandwidth usage, etc.

After setting a goal, every report shows conversion totals and percentages for each presented item (referrers, periods, pages, user agents, …) .

c) Issues with cross-site analysis (20%)

One solution for cross-site analysis is already mentioned in previous point: embed an image from your web server in a third-party web page (it can be white 1×1 pixel gif, invisible to visitors) and all hits to that page will be noted in your stats.

However, if you actually own and run several related websites, it would be nice if you could analyze them together. It’s not a problem for Web Log Storming. You should already have access to server logs, and all you need to do is to include them into the WLS project. It’s not even necessary for those websites to be on the same server – you can combine stats from IIS and Apache servers into joined reports. To easily distinguish hits from different websites, just use a Prefix option (/website1/index.html, /website2/index.html).

d) Can’t look up definitions of metrics and reports (19%)

In Web Log Storming, we tried to use as little technical terms as possible, and they are explained in a user manual page. By default, each report is described with one or two sentences at the bottom of the window, and user manual contains more detailed descriptions. Maybe it’s not enough, but we would like to hear any ideas for further improvements.

e) Issues with cookies (11%)

Web Log Storming doesn’t use cookies. But wait, don’t reach for a comment form yet: cookies do have their advantages over IP-based unique visitor detection, but vice-versa is true too. Which one gives better results? It probably depends on a website and profile of visitors. Here are few considerations to think about: more and more visitors use a broadband connection (with relatively static IPs), more and more visitors set up browsers to delete cookies, number of visitor that bring a laptop to another network is probably still outnumbered by visitors who use different computers on a different networks, etc.

You should really decide for yourself on this one… Point a) above (drilling down) should help you with it.

2. Not comprehensive/missing types of data (32%)

Some data is not possible to track with Web Log Storming, and it’s mainly related to client-side specifics, such is screen resolution, window size, JavaScript support, etc. This is purely because of technical limitation of server log files (this info doesn’t exist). If you really need them, you can always install some free JavaScript code.

3. Budget is too small to be useful (29%)

I must admit that I’m not sure if I understood this one. I suppose that it’s related to the fact that free stuff is rarely good enough and other solutions are too expensive to consider? Well, Web Log Storming is really not that expensive (some say it’s too affordable for the value it provides). There’s no recurring fees and, once you buy a license, you can use it freely forever. You get free upgrades for certain time and, after that period, you can stay with version you own without paying a single cent, unless you decide that improvements are worth the upgrade price (which is discounted, of course).

4. Page tagging difficulties or magnitude of effort (19%)

There’s no page tagging in Web Log Storming as it uses server log files, which almost all hosting companies provide (if it doesn’t, consider switching – seriously, as chances are that this is not the only problem you have with them). This is important, not just because for most people it’s easier to download log file than to edit pages or templates. Other benefits of not-tagging are:

• Log files (and thus statistics) exist even before you include tags.
• If you switch from one tag-based solution to another, you can kiss goodbye old data. If you switch from any kind of solution to a log-based solution, you still get all stats from the past. You’re not locked-in in any way.
• Code errors: omit a single but vital character and stats won’t work.
• Put a script code at the end of the page (as GA people suggests), and you risk that visitor will click away before page is fully loaded, resulting in lost hits.
• Put a script code at the beginning of the page and your website will become sluggish. Actually, total load time would be the same, but there’s more chance that visitors won’t notice it if code is at the end.
• Did you know that some people love to block Google Analytics and other similar tags?

5. Customer service issues (6%)

We are small company. Small companies, by definition, try harder. Every single customer and potential customer matters to us and we will commit any reasonable effort to make our software work for you in a way you want. We listen and welcome any new ideas and pursue any problem that you might have. Emails are responded by developers, not some independent (incompetent?) customer support service.

Yes, that’s a promise.

6. Vendor/solution/dashboard is too difficult to use (6%)

Not everyone can set up a separate job place for an analytics specialist (and, according to the survey, 72% of contenders don’t). Initially, we made Web Log Storming for ourselves, and made it reasonably understandable and easy to use for people who’s job title doesn’t contain “analytics” word. Part of this benefit lies in its interactivity, allowing you not to dedicate your life to predict what information you will need in the future. When you get a new idea, just dig out that information from existing log files. That makes Web Log Storming a perfect solution for small businesses – get the right information at the moment you need it.

Conclusion

If I would want to play silly, I would say that it’s now proved that Web Log Storming is 159.09% better than any other web analytics solution. But seriously, everyone should ponder all available options and choose what works best for them.

Web Log Storming is a server log file analyzer, and, according to some previous blog comments and feedback, that appears to be a deal-killer for some people. It’s understandable. Google’s marketing machinery is slightly stronger than ours, and nobody gets fired by recommending IBM, Microsoft or Google. Sure, JavaScript solutions have own advantages, but please, hold back from putting Web Log Storming in a same basket with other log analyzers, at least not for now. If you wish to disagree with this post, it would be reasonable if you download and install free 30-days trial first, before forming and sending an opinion. Any critics directly related to our product are welcomed.

Related articles

Which web log analyzer I should use?
10 strengths of web log analyzers compared to JavaScript based analytics
Busting the Google Analytics Mythbuster

Return to the list of articles