Another Web Log Storming update is ready.
+ Configure font for report list and tree
* Export reports to HTML now works again
& Extend max. clipboard and report lines to more than 9999
* Sample data problem
* Few other minor problems
As mentioned before, in 2009 we switched to subscription based upgrade policy. By buying a license or subscription extension you get free updates for one year. After that, you can continue using the last version you own (forever or for time being) or extend subscription right away. Because we wanted you to get used to this idea, we prolonged an implementation for a while, but now it’s time: version 2.6 won’t work if you bought your license before Sep 27, 2010.
If you update to v2.6 accidentally and you don’t wish to extend subscription, please bear in mind that this wasn’t our intention at all and that we took all reasonable measures to avoid such misunderstandings (blog, newsletter and a warnings throughout the application). In that case, you can download latest “last free for all v2.x customers” version from here.
Most important tangible change is introduction of Bounce rate metrics; now you can see how much visitors leave after visiting just one page. This metrics is included in the Overview report, but also on pages, referrer and search keywords reports. This way you can easily see how well specific page or referrer is performing.
Another important change is eliminating problems with Windows 7 64-bit. The problem didn’t happen on all systems and it was related to a third-party software protection system that we were using in combination with some anti-virus/firewall software. Well, it shouldn’t happen anymore, and if it does, by all means, please let us know. If your old registration data isn’t automatically updated, please try to enter your key again.
We also updated Operating System and Browser lists and fixed some cosmetic and minor bugs.
Several days ago we finally created a Facebook fan page. It still doesn’t contain much information and we are now awaiting more “Likes”. So, if you already like Web Log Storming, why wouldn’t you make it official? 🙂 In return, you will get a 20% discount for any of future purchases related to Web Log Storming (which includes new licenses and subscription extensions). This offer probably won’t be here forever, but once you get your coupon you will be able to use it anytime, so make sure you don’t miss it.
The goal is to somehow differentiate visitors that came from different AdWords campaigns, groups and/or ads. It’s quite easy, actually, as only thing you need to do is to append some query text to Destination URL like this:
If you append “?anything” to URLs (including question mark, without quotes), this information will be included in server log files, while visitors will see the same content as if query is not there. For different campaigns and ad variations append slightly different query, for example:
After traffic starts coming in, Web Log Storming will be able to analyze this information and include it in reports. Easiest way to this is to enter “adw=*” into Parameters | File | Query field (note there is no question mark here). You can also use Lock button to keep this filter active as you switch reports.
While this parameter (filter) is active, any report that you select will be based on AdWords visitors only, making it easy for you to see how they perform.
Another tool that you might want to use is View | Based on IP only main menu option. If you select it, sessions from the same IP will be grouped as one, allowing you to examine it as a returning visitor.
If you use Professional edition, you can also define Goals important for your business. Please read this article to learn how to do that.
With two Goals defined, this is what you’ll get if you choose Queries report:
As you can see, for each defined AdWords destination URL (campaign, group or ad), you get metrics that show how they perform against specific goals. In this example, campaign Test1 works perfectly for Goal2, while Test2 works better for Goal1.
Anyway, we are all probably sure that less people use proxies these days than few years ago, more people are on a broadband with fixed IP addresses and more people intentionally block cookies and analytics scripts. In other words, try this and you might be pleasantly surprised.
As you might know, we have released Web Log Storming v2.5 a day ago. This post is a follow up that explains few important changes.
Even though we’ve switched to optional yearly update policy starting with v2.0 (as it is and was indicated on the purchase page), we have decided to prolong activating it for a while. Main reason for waiting was to give you, especially to v1.x users, some additional time to get used to the idea.
Now that time has come. Version 2.5 now informs user about date when free updates period ends (see Help | About), but it will never cease to work. Next version, however, will cease to work for those who bought their licenses more than a year ago. You’ll have three options:
Of course, in case you decide to extend subscription months or years after the original one expired, your new free updates period starts from the date of the new purchase. On the other hand, if you decide to extend it before current one expires, new period will not start until the original expiration date.
Important: as version 2.5 is the last version that will be free forever for all v2.x users, we strongly suggest you to install it.
If you often use View | Human option, you might suddenly notice dramatically reduced number of visitors. Don’t worry, it doesn’t mean that your business is going downhill. 🙂 We’ve implemented smarter algorithm to detect which visitors / domains are behaving like spiders.
It would be easier for analysis if spiders and bots followed few simple rules: introduce themselves as such in User agent field, read and respect robots.txt file, etc. Although some do (like Google, Yahoo and similar legitimate spiders), some don’t care and/or are trying to full us in different ways (“referrer spam”, for example).
This more advanced algorithm tries to figure out if certain domains and visitors don’t behave like human beings. For example, if you get lots of hits on small number of different files from a single domain on regular basis over the time, it’s most probably a bot. Of course, exceptions are always possible (false negatives and false positives), but we think that we’ve managed to reduce mistakes significantly compared to previous version.
That said, if you notice some obvious false positive/negative, feel free to let us know. We will analyze these sessions and see what we can do to improve the detection further.
Web Log Storming v2.5 is available for download. This update contains several improvements and bug fixes:
Recently, a topic of conversion tracking came up in the professional forum. Specifically, one member asked how to include Google Analytics tracking code into third-party order pages to track conversions and original referring websites that bring customers to him. After that, another member complained that only about ~5% of purchases were registered by Google Analytics system, so he gave up. This means that ~95% of customers were completely ignored by stats, and you will agree that those couldn’t be spiders.
Setting up Goals to track conversion ratios in Web Log Storming is pretty much straightforward:
If you are partnered with third-party payment services to process your orders, you won’t be able to get raw log files to analyze them in Web Log Storming, but there’s a rather simple solution. Usually, partner services provide means to include some custom HTML into their standard order page.
<img src="http://<www.mywebserver.com>/goals/my-goal.gif" />
From this point on, set up Web Log Storming similarly as in previous example. Each time visitors hits the goal page on the partner’s website, this small image will be requested from your web server, which means that you will get this information in your raw log files, and the image itself will be practically invisible for users.
If your partner’s order pages are located on the secure server (which they are, I hope 🙂 ), browsers could show a not-so-nice warning about mixing up secure and non-secure elements. In this case, you will need to host this transparent .gif on a secure server too. If you don’t already have one, you can create a SSL certificate yourself or buy a cheap one here (under $10/year). Note that for this purpose it doesn’t have to be a super-secure server. You won’t transfer any of sensible data to it, so a formal SSL certificate will suffice.
Obviously, in this case, the HTML code should be changed to:
<img src="https://<www.mysecurewebserver.com>/goals/my-goal.gif" />
As your main website server and secure one will probably write log hits to different files, depending on your original configuration, you might need to add another Log file location in Web Log Storming’s File properties window.
Web Log Storming v2.3 is now available for download. Changes in this release contain several new features that will make Web Log Storming easier to use, some improvements and additions and, of course, few bug fixes. As this is a free update for anyone who bought v2.x, we strongly recommend you to download and install an update.
Recently I found few interesting questions about how to track custom variables with Google Analytics. The question well makes sense, even if your website is not a complex web application that your visitors log in to. “Simple” showroom websites could benefit from such kind information too, providing that you want to learn more about visitor behavior grouped by data not already included in stats. Here’s an example of how you can do this with Web Log Storming, but you might apply similar steps if you use some of other tools too.
Let’s say that you run online shoe-shop. At some point, you decide to present a simple survey to your visitors and put results into cookie information. In this case, you would probably be interested in demographic information such is gender, age, marital status, etc.
Disclaimer: I’m completely ignorant about selling shoes (Al Bundy would probably know better), so don’t mind if I completely missed what matters in this business. 🙂
First thing you need to do is to actually build a survey. How to do that is beyond scope of this article, so I’ll leave it to you. But all surveys have something in common: they contain questions. Let’s say that questions for this example are:
You get the picture. Put answers into a cookie and you’re ready for the next step.
If these individual answers stay in visitor’s local cookies, you won’t be able to use them. It’s actually easy to “trick” a web server to write them down for you, and here’s how.
First, create a transparent 1×1 pixel gif image and upload it to your server (for example: myvars.gif). For your convenience, you can get one from here (right-click on link and save image).
Now change your web pages (or just one of them, depending how your website is organized) to include code into header or footer, similar to this:
<img src="/path-to/myvars.gif?g=<?php $_COOKIE['gender']; ?>" /> <img src="/path-to/myvars.gif?a=<?php $_COOKIE['age']; ?>" /> <img src="/path-to/myvars.gif?s=<?php $_COOKIE['status']; ?>" />
You would probably want to replace $_COOKIE[ ] parts with your functions, but we’ll keep it as simple as possible here.
These images will be invisible to visitors, but your log files will from now on contain lines like these:
22.214.171.124 [18/Oct/2009:22:20:06 -0600] "GET /myvars.gif?g=female HTTP/1.1" 200 ... 126.96.36.199 [18/Oct/2009:22:20:06 -0600] "GET /myvars.gif?a=40 HTTP/1.1" 200 ... 188.8.131.52 [18/Oct/2009:22:20:06 -0600] "GET /myvars.gif?s=married HTTP/1.1" 200 ...
Note the emphasized parts behind question marks. Instead of placing an image for each variable separately, you can combine them into one request, so your get ?g=female&a=40&s=married. It’s up to you how you want to track them later.
Now we only need to extract these into a meaningful statistics.
As I said before, it might be possible to analyze this info with other products (although often with limited possibilities), but here we’ll show how you can do that with Web Log Storming. For purely selfish reasons, of course. 🙂
Next and even more important, you can set up a Query parameter to focus on specific groups and analyze them separately. With Web Log Storming it’s really easy to do that (see the screenshot):
It’s simple as that, but there’s more possibilities for advanced filtering by combining more than one group, comma separated. Here are few examples as an illustration:
There are numerous combinations and possibilities, and for more info how wildcards work in Web Log Storming, check this page in the user manual.
Note: if you decided to combine all variables into one request (ie. ?g=female&a=40&s=married), you’ll need to enclose filters in wildcard (asterisk) character, like this: *a=40*, +*g=male*.
Common sense tells us that our website should “push” male shoes to males and female shoes to females, right? But is it possible that it’s not the best choice? What if your analysis show that married middle-aged males often buy shoes to their spouses as a gift? You would definitely want to make it easier for them to do so.
Or maybe you discover that divorced people, regardless of age, are more likely to buy more expensive shoes, so shouldn’t you present them an appropriate offers? Or maybe this doesn’t apply to divorced people in their sixties? Maybe people in sixties are generally not interested in expensive shoes, regardless of marital status?
There is lot of questions which all make sense to me, but I’ll just stop – if someone told me month ago that I will spend this much time thinking about shoe market… 😉 Besides, I’m sure you understood the importance of visitor segmenting buy now and that you know what questions relate to you business.
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…
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).
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, …) .
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).
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.
You should really decide for yourself on this one… Point a) above (drilling down) should help you with it.
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).
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:
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.
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.
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.