First, be sure you have read the manual thoroughly, especially the Software and Hardware Requirements , Server Configuration Tips and Launching the Wusage Application sections.
THE BASICS
Download, UserName & Password, Using the Registration Key & Simple Mode Instructions
WUSAGE 8.0
Changes and New Features in Wusage 8.0
LOG INFORMATION
Log files: what are they, formats, invalid lines, processing, rotation, size, combining...
OPERATIONAL QUESTIONS
ADMINISTRATIVE QUESTIONS
QUESTIONS ON REPORTS
EMAIL REPORT QUESTIONS
ERRORS & WARNINGS
ISP MODE QUESTIONS
CGI QUESTIONS
MACRO QUESTIONS
UPGRADE QUESTIONS
THE BASICS:
Download, UserName & Password, Using the Registration Key & Simple Mode Instructions
Simple Mode
For complete instructions on
how to get started with Simple Mode, start here and if this doesn't do it you can
find more details on this page.
How do I download Wusage?
Here are some basics:
You will be prompted through questions about accepting the terms of our
licensing agreement. Click the appropriate responses for your situation.
Next UNIX users will need to use the commands found here to
unpack and untar
the program and then use the
./wusage command to launch the program. The program will give you a URL
to put in the URL field of your browser. Now you are ready to use Wusage. The Wusage interface
will prompt you and take you through some short questions. Please read questions and answer appropriately.
How do you get your user name and password back?
Go to where Wusage is installed then look here:wusage/data/.wup - open the .wup file with a text editor such as Notepad.
For earlier releases please contact us for more information. If you have issues and can't find the file, try this:
- Log in as the user you run Wusage as (important)
- Type:
cd ~
And press enter
- Type:
cat .wup
Properly Unlock Wusage For More Than 30 Days
You'll need to log in as the user who runs Wusage before unlocking.
Open Wusage from the account of the Wusage user. Then register the product.
If you are running Wusage as root, you'll need to log in using "su - root"
rather than "su root". This will load the root user preferences and set the
necessary home directory for Wusage to successfully unlock.
The issue is that you have not actually unlocked the software at all
for the particular Unix (or NT) account from which you are actually
running it. Unlocking it from another account will appear to work
but the software still times out. I definitely ran Wusage from the root
account, the same one as is run by the cron process.
Also, if you are using cron to schedule processes, make
sure the HOME environment variable is set consistently when running
at the command line and when running from cron. Remember that
cron doesn't always set it. If this is the case you need
to set HOME in a shell script, which then invokes wusage.
#!/bin/sh
HOME=/wherever/root/home/should/be
export HOME
/path/to/wusage -c /path/to/conf/file
Blank Reports or Invalid Lines
If you are getting blank reports or all lines are invalid when you run Wusage.
This sounds like a case in which the virtual server name Wusage is looking for
doesn't match what is in the logs, or the logs contain only a virtual server IP
that can't be resolved to a matching name. You can try setting the "one virtual
server name to analyze" field under "edit configuration" to the IP address instead.
This works for many customers with similar issues.
If you have W3SVC### in your logs then the issue is that you
need to put W3SVC10 in the "Virtual Server Name to Analyze"
field. If a user doesn't have server IP or server hostname fields,
then they will need to do this.
Wusage 8.0 will auto detect this provided that a reasonably
sane IIS environment exists and logs are being analyzed
on the server itself. There's nothing we can really do
about remote log analysis, except possibly much better
suggestion/warning messages to help the user figure out
what to change in the configuration. On the other hand...
If your logs contain website-identifying information like this:
I ran Wusage on an old log file, and now I have zero accesses.
Wusage normally creates reports through the most recent complete day or week, and will not generate those reports again. You can override this behavior using the -b and -e command line options, which are used to force wusage to start re-generating reports at an earlier date, or to stop well before the present date. If you inadvertently produce empty reports for the most recent several weeks or months, just use the -b option to specify a date from which wusage should start re-generating those reports, and specify the more recent logfile as well using the -l option. See the Command Line Options section for more information.
In order to rebuild the quarterly and summary do I use the update for time period feature?
If you have log data available for Month X of year 2000, you could perform an "update for time period" operation and specify the beginning and ending dates of Month X of year 2000. This will only work if log files actually exist for that time period and wusage has been told where to find them. If not, it'll blank the reports you have for that time period, so be careful.
I need to customize Wusage, can this be done?"
Wusage 7.0 and above create reports through a highly flexible report macro language. This approach provides far
more customization opportunities than were available in previous releases.
The extension (file type) of each HTML document produced by Wusage can be controlled using the
Extension for HTML Documents (extension) option.
Visit our Customizing Wusage Output
page to learn how to achieve your goals.
I am running Wusage but can't seem to connect to my browser.
Do you get the message: "Page cannot be displayed"?
1. Check your Internet connection for a proxy server.
2. Is the program actually running at the time you try to connect to it?
3. What URL does it tell you to connect to?
Try to start your browser, choose File->Open->Browse, and locate your report directory (wherever you told Wusage to put it). Open the file index.html in that directory.
Else try connecting manually with:
http://localhost:2396/
more on the issue...
You may have a proxy server configured, and your web browser
may be not configured to make an exception for the following
addresses:
127.0.0.1
localhost
Fortunately, both Netscape and Internet Explorer make it
easy to make exceptions for a few sites. I don't know why
they don't make exceptions for these two addresses already,
since any connection to them is, by definition, a connection
to the same computer! A proxy server could never find it.
In Netscape, you can add exceptions through the following
sequence of menus:
Edit->Preferences->Advanced (click the plus sign)->Proxies->
Manual Proxy Configuration->Exceptions.
If you are using "automatic proxy server configuration," you
will need to talk to your network admin about adding an
exception for localhost and 127.0.0.1. Ours is not the only
program that uses this standard feature, so hopefully they
will be agreeable.
For Internet Explorer, starting from your 'Start' menu,
go to:
Start->Settings->Control Panel->Internet->Connection->
Proxy Server->Check the "Bypass proxy server for
local connections" box.
I need to have definitions for the terms used in Wusage.
Wusage definitions can be found on our Wusage Glossary Page
WUSAGE 8.0
Changes and New Features in Wusage 8.0
I can't get good historical totals charts in Advanced Mode after upgrading, why?
Example to follow:
I need a way to be able to add a new account (in ISP mode) without manually going through an interface (either through a command line or through a script).
You're right. We need a command line option for this.
This should suffice to add an account. Of course you will be substituting
the actual account names and hostnames above. This isn't hard to script, but
we should make it even easier by adding a command line option. Take care to
follow step 7 properly -- append that line, don't overwrite the entire
.wup file!
An important catch: when you use ISP mode accounts, they will get
updated only by the daemon -- you cannot use the -c option to
expressly update them (never mix that type of command line
operation with ISP mode). However if you don't want the daemon
running all the time you can tell it to update all ISP mode accounts
and then exit by doing this:
Here's what has to be done:
1. Make one brand-new account manually (don't use one with existing reports)
2. cd to the home directory of the account wusage runs under
3. cd wusage-accounts
4. cp -r first-account second-account
5. perl -pi -e 's/first-hostname/second-hostname/g' second-account/wusage.conf
6. cd ..
7. echo "second-account second-account-password
/home/unixaccountname/wusage-accounts/second-account/wusage.conf" >> .wup
wusage -update-all-accounts
Where is the special image I need to install to get the screen resolution and color depth report?
Download it by clicking here.
THE IMAGE IS TINY AND TRANSPARENT, SO YOU WILL SEE AN EMPTY PAGE. THAT'S OK.
Then pick "Save As" from your File menu to save the image. Now follow the instructions
in our manual to CORRECTLY install the image so that it helps your web server collect screen
resolution and color depth information.
I am an ISP and unable to get the screen resolution and color depth report for all my sites, why?
Download it by clicking here.
THE IMAGE IS TINY AND TRANSPARENT, SO YOU WILL SEE AN EMPTY PAGE. THAT'S OK.
Then pick "Save As" from your File menu to save the image. Now follow the instructions
in our manual to CORRECTLY install the image so that it helps your web server collect screen
resolution and color depth information.
The image needs to be placed in their pages along with a bit of Javascript to collect
that information -- it's a trick to get the information into their log files. Of course
the program is still quite useful without any one particular feature.
I am unable to get the screen report and I don't understand it anyway?
You may be using the 'allow' option to allow only a few extensions.
This excludes GIF and the screen report never gets a chance to see
the accesses to the image. I recommend getting rid of any restrictive
'allow' list and taking full advantage of 8.0's support
for the new 'object types' (subreports) option instead.
Use the screen resolution
and report option and to break down the many different times of documents such
as images, audios, web pages and so forth use the
subreports option.
The screen resolution report is based on accesses to the
screen resolution testing GIF file. Normally browsers won't fetch
this more than once, but depending on where you put it (what page
you put it in...) and how your site handles caching issues,
it could be accessed a lot more. For instance, if your home page is
dynamic and people fetch it over and over in a single session, you'll
get a higher figure there. The relative percentages are still
reasonable, because screen resolution probably isn't linked to
how often people view the page containing the image (ie, those
variables are independent).
Does 8 support Microsoft Internet Information Services 5.0?
Yes, it is completely supported. If you are not running wusage on the server itself, then you
need to add W3SVC22 to your 'Valid names for this virtual server' list. Click "Edit Configuration",
scroll down to that entry and click 'edit now' and use 'add' to add W3SVC22.
If you are running it on the server itself, then it ought to be able to look it up as long
as you entered the domain name of the site properly at configuration time.
If you are using the default settings for what fields to include in the log files
in IIS 5.0 running Windows 2000. The Server Name may not checked, but Server IP may be. In
this case try adding the server IP address in the Virtual Server Name section.
If your logs contain website-identifying information like this:
www.xyzcompany.ca
However, your servernames list in your Wusage configuration
file contains only this:
webstats.xyzcompany.com
Which doesn't appear in the logs as the server being accessed.
You need to do this:
Edit configuration -> Valid Names For This Virtual Server...
And "add" an entry for www.xyzcompany.ca. Otherwise the program
reasonably assumes that the lines it's seeing are for a
different virtual site, and ignores them (which is not what you want...).
How in Wusage 8.0 do you specify the number of top docs, and doc by directories I want Wusage to show?
It's Changed -- do this:
Edit Configuration
Configure Reports
Object Types
Notice that there is a 'top n' field for each object type now. This has
replaced the old 'top' features. This way you can display, say, the
top 40 documents and directories but only the top 10 images. You can
edit these settings easily. If you're editing configuration files
by hand, try opening your configuration with the editor and re-saving
it to fully expand our new defaults into your configuration file, and
then find "subreports" in your configuration file to see how the
object types look to you hand-editing folks.
You want to look at your "subreports" option (if you're editing conf
by hand), or:
Edit Configuration -> Configure Reports -> Object Types
Here you can set the top # for *each* type of object -- page, image, etc. --
within the documents report. It's better, but it seems hardly anyone can
find it easily, so we need to better document it.
If you are upgrading from an old version of Wusage, your configuration file doesn't mention
this option. To list more directories, you need to edit the subreports option.
I suggest you use the user interface and its configuration editor and follow these steps:
edit configuration -> configure reports -> object types
Select the "pages" object type, click Edit, and then change
the number of pages (or folders) to be shown to the number you desire. Then
click "OK" all the way back out.
My top documents and/or documents by directories did not increase after I made the changes in the configuration editor?
Did you regenerate completely or at least update statistics to produce
a report that includes more levels? If the configuration file is OK you may have possibly
changed that setting and then looked at old reports that have not been rewritten.
If keepdailyreports doesn't agree with the number of daily reports you have,
then perhaps the overall limits are set up in ISP mode and you need to
remove those restrictions.
If I click on the 'back' key in your browser, you get a notice Loading Report Data, Please wait". But, nothing seems to happen.
A known issue, yes. Hitting "back" one more time works. This is an artifact of Javascript that we're working to resolve, otherwise we'll just display a more helpful message ("you may also use the back button at this time").
The directories report, the "/" link to 'objects by type' doesn't do anything. Should it?
If you're already looking at the top level it shouldn't change anything. Once you drill down to a subdirectory, of course, it does do something (it takes you back up).
The Site Navigation graph tells me "not enough data for a navigation map, is this correct?
This appears when the program can't find any nontrivial transitions --
page-to-page transitions which took place more than once.
We need to know more about your site to be sure. If we could see your
reports that would give us enough information to figure that out. Sometimes
the site just isn't popular enough to generate good data for that report;
other times, our definition of a 'web page' doesn't include the file
extension that web page URLs have on your server, in which case you need
to change our definition of a web page through the configuration editor:
edit configuration -> configure reports -> object types
If your site is dynamic and places unique identifiers of some sort in
every URL every time, then you will probably need to tell Wusage to
strip these out using a rewrite rule. Otherwise it won't be able to
recognize that the same page was accessed twice. If this makes no sense
to you, then your site probably isn't dynamic and you may simply not
have a lot of traffic for, let's say, an individual daily report that
the program was generating at the time it printed the message.
Wusage does not work with the logs I have.
My best guess here is that the server name you gave Wusage when configuring it to analyze doesn't match a server identifying field that actually appears on each log line. This often causes exactly the symptoms you describe. If that doesn't pan out, I could of course try it myself, using a short but sufficient excerpt of the log file.
I want to see more than 25 days in the Calendar, which I don't unless I choose 'ALL'.
I believe you are using ISP mode. When that is the case, you need to also consider what you have done on the "overall limits" page, accessible from the main "account administration" page. On this page global limits are set that apply to all accounts. I suspect the limit on daily reports has been set to 25. Alternatively, this may be the *only* place you have made the change. You also need to make it for the actual account in question through the "edit configuration" button. The overall limits page sets an upper bound only (to prevent clients from making unreasonable settings through their nonprivileged accounts).
I can't find were Wusage is archiving the logs to, are my log files lost?
Logs should be archived to:
\whereyouinstalledwusage\data\wusage-accounts\accountname\log-archive
If those are missing or empty, then the data is not available.
We don't have any reports of archived logs being lost -- only of
archived logs not being deleted on schedule, which meant that some
people had *more* backups around than they actually wanted.
I want to know how many times the java-applets we host (not the html-pages) are downloaded and does a users cache change this number?
1. Lots of people have Java turned off or not installed. This is
the biggest factor.
4. Suppose a visitor already downloaded the classfile yesterday, and the file therefore
already is on his computer, he will not download it anymore. Does this mean
this is not counted by Wusage?
Yes, it does.
5. Are requests counted?
It is still counted if the browser actually asks this question, yes.
However, sometimes caches simply say "it's only a day old and nobody
told me to consider it non-cacheable, so I won't even ask."
6.In the stats I do not see anywhere the distinction being made between an
actual download and only such a request without a resulting download.
If the browser doesn't make any new request from your server,
it's pretty hard to do anything about this.
You could use Javascript to finesse this perhaps, something like:
<script>
document.write("<applet code=REALURLHERE" + "?" + random(10000) + " ");
document.write("width=whatever height=whatever>\n");
document.write("</applet>\n");
</script>
This is off the top of my head; I haven't checked whether that's
the syntax to generate a random number in Javascript, but you
get the idea, I bet: stuff a random component into the URL so
that the browser thinks it's something new every time.
Wusage doesn't recognize the Graphviz program, why?
To install graphviz and get Wusage to recognize the location of this program follow these steps:
To restart the Wusage Service:
click start -->
click settings -->
click control panel -->
click administrative tools -->
choose services
scroll to Wusage
From the Action Menu, pick Stop
Click ok -->
Go to the Action Menu
Click Start
Now Wusage should be able to find graphviz.
Install the programs, let them pick their locations.
Then restart Wusage. If you are using the Wusage service then you must restart this as well.
Why is Wusage 8.0 "head'ing the gif's for my domains?
donottouch
/cgi-bin/scriptthatsendsemailwhenfetched #Leave this one script alone
*.cgi # Leave all .cgi files alone
/cgi-bin/* # Leave all cgi-bin directory contents alone
Releases earlier than Wusage 8.0 p14 can prevent this if they turn off
document titles and
download percentages in the Wusage configuration editor. You will lose those features but
the program will not fetch any documents. It is not possible to provide those features
without querying the server for information about the documents. Wusage is
smart enough to ignore its own accesses later when analyzing the logs,
provided that your logs include web browser information, which they should.
A new donottouch (documents that should not be fetched) filter
is available to Wusage 8.0 p14. This filter can be used to prevent Wusage 8.0 from attempting
to access certain pages, as it would otherwise attempt to do in order to determine their titles
and structure. Examples:
Wusage 8.0 p14 has a new mechanism for counting unique visitors. Why?
New configurations set up with 8.0 P14 or later will contain a
totalsgroup (historical totals)
option entry like this:
Also starting in 8.0 P14, the "users as determined by cookies" (users) report shows only cookies
which were logged at least twice. This mechanism excludes the very large number of "one-shot"
cookies logged in a single visit by users who do not actually accept cookies, which can cause
the web server to produce and log a new cookie for every access. This enhancement to the program
also saves memory. If you find that this results in a significant reduction in the figure you
were relying upon as a measure of unique visits, use the new "best method" pattern instead as described above.
In the absence of cookies, our visitor counting mechanism can only
count IP addresses. This can be defeated at times by the use of proxy
servers that rotate a single visitor through many IP addresses, such as
AOL; sites with a lot of AOL users need cookies to get better results.
However, our visit counting mechanism can do a bit better, by looking
at the many IP addresses that made only one access within a short window
of time and logically assuming that they are part of "obfuscated" visits
made by a smaller number of people, then determining the average visit
steps for less "stealthy" users and using this to project the visits
from stealthy users.
The same trick cannot be applied for unique visitors, because those
proxy server IPs are sure to get used again later in the day -- but this
is not true of cookies. So we recommend logging them to get "smart"
results for visitors as well as visits.
This may be more than you wanted to know, but the moral
is simple: use log user-identifying cookies whenever possible; Wusage 8
can make clever use of them to make reasonable projections about
the visitors who didn't accept them based on those who did. The same
is not always true when only IPs are available.
Wusage 8.0 p14 introduces a new mechanism for counting unique visitors by the best available
method!
visitors yeartoyear unique Unique Visitors (Best Method)
This special pattern produces a unique visitor count by the following highly sophisticated and
accurate method:
If the number of user-identifying cookies logged at least twice is equal to at least 5% of the
number of unique IP addresses, then the number of unique visitors is equal to the number of
cookies logged at least twice, plus the number of accesses made by users not accepting cookies
divided by the average number of accesses made by each user who did accept cookies. The resulting
figure is a highly accurate projection of the true number of unique visitors, including those
visitors who reject cookies and use other forms of identity-masking software. If cookies are
not available, or the number of cookies logged at least twice is less than 5% of the number of
unique IP addresses, then the number of unique IP addresses is reported as the number of unique
visitors. The unique visits figure is available for use in the historical totals option, as well
as in the executive summary (macro customers should see the epoch.rmc file provided with 8.0 P14).
I was wondering how often you updated the searchservertemplates section of your config files?
If you were to make a new configuration file with 8.0's editor, and then open and close the configuration once using "edit configuration", you would get to see a fully expanded version of our latest "searchservertemplates" data. We do expand this list from time to time. Our referring sites list for our own well-trafficked site isn't showing any significant search engines not included in our latest list (indeed, Google is now 65% of all search engine traffic to our site -- they have really taken over).
I can get output for my 95 domains individually but how do I get overall server output?
We don't currently have a report like that. Definitely in 9.0.
When I look at the monthly totals report wusage is projecting what the monthly total will be as stated in the heading, is this why there are percentages?
Yes, the values for completed time periods are final. Values for the reporting period
currently in progress are projections, except for user-calculated functions,
which are not scaled.
In reality the customer has transferred 13.195 GB's thus far this month which is the total number.
So in this case for the weekly report the 'Latest' number is projected since the week is not completed.
To be sure of the information go to the actual month and look at the summary report.
In this case the 46.181 number for Latest is the Projected monthly total.
In 7.1 we had server cookies on, before I move to 8, I need to understand why in 7.1 the reporting was so different.
The problem is that recent versions of Apache log a cookie on the very first access... the one when the cookie is set by the server. If the browser refuses the cookie, then this results in zillions of "one-shot" cookies, inflating the figure. In Wusage 8.0 P17 cookies were corrected to exclude one-shot cookies that almost certainly do not represent real visitors. A projection of the true number of visitors not accepting cookies is now available. Because Wusage 8.0 P17 knows all about this nonsense and corrects for it, single-shot cookies are ignored. And if you use the new special pattern to measure unique visitors by the best available method (in a totalsgroup): visitors unique Unique Visitors (Best Method) You will get a projection that includes a solid estimate of the visitors who refused cookies, based on average accesses-per-visit for those users who *did* accept them. To get detailed info on this feature please read the Wusage News page.
The "Optimization Settings Page" that is telling me to set the "DNS Server IP Address" for my Win98 machine but I don't know what to type in there. Do I need to do this?
Yes, you do need to enter the IP address or hostname of your ISP's DNS server on the optimization setting page. You will find the Optimization Settings button on the Account Administration page if you are using ISP mode. You may need to ask for this information. Or, if your machine is running in an office, you can just ask your system administrator. In Windows 98, unfortunately, applications cannot discover this on their own.
How do I make the scheduled updates feature work?
This depends on what mode you are using and on what operating system.
Go to the Account Administration Page if you are in ISP mode
and click on the Scheduled Updates button. Pick a time frame from the selection and click ok.
You will see your Scheduled Update time relected to the left of the button. Wait for the next
time you picked to pass and let Wusage run without interference. The first run may take
considerably longer. What makes Wusage run smoothly? Running it regularly, nightly may be
preferred, via the automatic scheduler.
If you are used to using
configuration files and the -c option, then use cron to schedule
that to happen automatically. That is use a cron job with wusage -c location_of_config_file.
Wusage doesn't seem to be keeping the correct number of daily reports?
If keepdailyreports doesn't agree with the number of daily reports he has, then perhaps he has the overall limits set up in ISP mode and needs to remove those restrictions. We may need to see your configuration file. I would suspect a problem with the overall limits settings. I would increase those settings and watch our Wusage news page for any software updates.
Wusage creates a log files that collectively take up a lot of disk space, can I delete the log?
...wusage8\data\wusage-accounts\other servers" is our log file archiving mechanism, trying to avoid deleting entries altogether that apply to other websites you are not currently analyzing, as a safety mechanism. It is safe to delete the contents of this directory if you don't need them. You may do so on a recurring basis with an "AT" job if you wish.
Can I combine the logs files for all my sites and get statistics?
We do offer a "manyservers" configuration file option which allows you to analyze many sites' log files as a single data set. However, this works only if each log entry includes the website name. The referring URL is not good enough; it must be a separate field. See our server configuration tips for more information about this. In a forthcoming major release (9.0) we are looking into providing ways for some part of the log filename to be understood to be the web server name, removing this restriction. The feature is not very often used but we recognize that some people find it valuable.
LOG FILES:
Formats, Processing, Size, Warnings, Combining, Rotation...
I am getting a log file format warning and Wusage doesn't process some or all of the log files.
Warning: poor extended log format configuration. This log file does not contain
username information for each access. The authusers report will not be accurate for
such log files.
These warnings -- not errors indicate that your logs could be better.
You need to configure your copy of Internet Information Server(IIS)
to log all available fields instead of just the very few
default handful of fields, which can indeed be dismal and of
limited value.
See the server configuration
tips section of our
Wusage Manual for details.
The acceptable log file formats are known as the "common" log file format
(most servers output this), the "combined" log format (a popular extension
of the common log format), the EMWAC log file format (some versions of the
EMWAC server for Windows NT output this), the Microsoft IIS log file
format, the "extended log format" defined by the W3C and implemented by
Microsoft IIS 4.0, and the WebStar log format used on the Macintosh.
Wusage recognizes certain variations on the common log format, including
at least one variation produced by the Oracle web server. Additional
fields after the regular "common log format" fields are also acceptable,
and Wusage can analyze these if they are formatted properly.
For best results, configure your web server to log in the common
log format, with the addition of the referrer and user agent fields. The
referrer field should come first, followed by the user agent field. Both
fields should be in quotes for best results, especially the user agent
field, which can contain spaces. If the user agent field cannot be
enclosed in quotes, configure your server to place it at the end of the
line after all other fields.
Wusage will also recognize a virtual server domain name field, if present,
and compare this to the (servername) option to determine whether a particular
access is relevant.
Below is an example of the common log format, extended to include referrer
and user agent information.
foo.bar.com - - [20/Apr/1997:16:48:44 -0700] "GET /boutell/index.html
HTTP/1.0" 200 5898 "http://www.altavista.digital.com/query" "Mozilla/3.01
(Macintosh; I; PPC)"
If you are still having issues please be more specific about exactly what figures you get for "invalid lines
ignored", "valid lines analyzed" and "valid lines skipped"?
Be sure to include:
Wusage Version, Wusage Patch Level and O/S.
The crux of my problem is whether or not Wusage decides to process the contents of a file.
I think you have occasional log file lines that are out of
line with the current date. Wusage trusts them and believes there
will be no more log data until that date arrives.
Are all of your servers Apache and/or IIS?
You may not need the sortlogs option in that case. On the other hand,
if some of your servers are Netscape Enterprise server, you definitely need it.
Sort logs is a 7.0 and up option only and it depends on your web server whether
this is an option you should use. You may not actually need the sortlogs option for
most of your data. Netscape Enterprise Server is the most frequent case that definitely requires it.
The log files I am processing are very large.
See our manual, particularly the
"many logs" page to learn more on the handling of large log files or many log files.
The issue with memory usage in our program is never how much
log data you present on a single run. It is, rather, the number
of unique items of various types -- IPs, cookies, URLs,
trails followed through the site, and so forth -- over
the longest time span that you have reporting turned on for.
If you only have daily reporting turned on, your memory
requirements will never exceed what is required to analyze
the unique items in a single day. If you have summary reporting
turned on, your requirements grow indefinitely. Wusage 8 makes
it much easier to understand that there is some historical information
available even without summary reports turned on, because there are
prominent links to historical charts. If you have
daily, weekly and monthly turned on -- a common compromise --
you're generally going to be fine.
What makes Wusage run faster?
Running Wusage on a regular basis, using the built-in scheduling mechanism.
If you are still having issues, contact us with you version/patch/o/s and let us know
how large the daily/current.epc and weekly/current.epc files are, and how large are
the log files are on a per-day basis.
When I use FTP to get my log files, Wusage shows a different directory structure.
This is starting from root on our side try clicking on home and then your user name. We hope to change it to go direct to the root of the user's specified FTP site - just like an ordinary FTP client. It's more obvious behavior.
I run a webserver where we have a custom log format that logs basically everything /except/ IPs or hostnames.
You can fake the missing fields by inserting "dummyhostname - -" at the beginning of each line. Check our examples under "server configuration tips" to get this exactly right. Basically you can stick in any plain text you want in the logformat string, so it's easy to plug in placeholders like this. Wusage, however, will be somewhat unhappy; it's going to assume this is one enormous visit all from one host. You can ameliorate that by systematically turning off all visit- and trail-related features in your Wusage configuration.
Can I combine NT and Linux log files?
One of the servers who's Linux server logs we analyze has an NT map server
which we host at a separate location on a separate IP address.
We would like to include the NT server logs in our daily traffic
report.
Create a new configuration file for this purpose,
and tell the program to obtain log files from the appropriate location.
Click Edit Configuration, then Log File Locations.
Use the Add button to add the additional sources of log data.
Wusage supports any number of log file locations for a single set of reports.
Can I analyze logs from several mirror sites as if they were a single site?
Yes, Click "Edit Configuration", then scroll down to "Log File Location" and click "Edit Now", then use the "Add" button to add each location you need logs to be fetched from. Or just mirror all of the logs into one directory, with separate names of course as you said earlier, and tell the program to analyze that directory. Analyzing logs from mirror sites as if they were one site is a standard, automatic feature of Wusage.
Log rotation is not working for me, why?
Built-in rotation is available only for "accounts" created through ISP mode (also accessible through the "change remote access settings" button in advanced mode). If you are trying to update statistics manually or working in simple or advanced mode, there's no built-in rotation feature for those scenarios. Go to this section of our manual on how to configure Wusage in ISP mode for specific details.
When Wusage parses the log that's currently active by the web server the cpu usage drops to 0 and the memory usage jumps to 80% of my available memory, hanging.
Wusage can run into memory issues quickly if the summary report
is turned on and the site is popular. Wusage 8 makes
it much easier to understand that there is some historical information
available even without summary reports turned on, because there are
prominent links to historical charts.
I suspect your summary report database has grown unpractically large.
If you have summary reports turned on this will eventually happen for
a popular site. The solution is to turn off summary reporting (and
possibly also annual).
Although we optimized as much as possible, the summary report does
have open-ended memory requirements as your site's database of, for instance,
visiting IPs grows with time.
Another possibility is that your work in progress databases may
be corrupt for one of the reporting frequencies (daily, weekly,
summary, etc.). You can address this by deleting the current.epc
files in these subdirectories of your report directory and trying
another update. However, this requires that you have log
files available going back to the start of the time period in
question. For summary reporting, unfortunately, if the database
becomes damaged you will only be able to go back as far as
your logs go.
If the issue is summary reporting, though, you'll probably need
to turn it off eventually in any case for a popular site.
OPERATIONAL QUESTIONS
I have a log.txt file that I would like to delete is this ok?
log.txt does become impractically large in some patch levels of 7.1. I recommend deleting it nightly, using a simple scheduled task or the Windows NT "AT" command. 8.0 produces a vastly smaller wusage-messages.txt file.
We bring in logs from "several* servers, can not having the *several* servers' time synced up cause a date problem on our reports?
Date problems will most likely be in the server's clock since the dates in the logs are what is relevant to Wusage. Please be sure you have the latest patch of Wusage for your operating system.
My CPU usage jumps when Wusage is running, can I prevent this or is this normal?
Normal during analysis, yes. It will certainly take a while when 8.0 is first set up to analyze a site with lots of existing log data.
Wusage 8.0 is hitting my server causing Wusage to slow down and almost stop, can I prevent this?
Turning off the documenttitles and downloadpercentages reports will definitely help. First, be sure you have set the optimization settings on the Account Administration page to reflect the correct speed of your Internet connection.
I get an Out of Memory Error, what can I do?
Wusage contains no arbitrary limitations on the
maximum size of a log file to be processed. However,
If your log is especially large, and especially when
the Summary Reports (summary), Quarterly Reports
and Annual Reports options are active, you may receive the following message:
This occurs when your computer does not have, or will not allocate, enough memory for Wusage
to successfully analyze your log.
Consider the following remedies:
Out of Memory! Wusage cannot continue without additional memory
or swap space.
Wusage will not show up in my browser and I get an Error: Bad HTTP request
Try connecting manually with this URL: http://localhost:2396/How do I connect users in ISP mode using Wusage 7.1?
It depends what operating system you are going to install this on. If it's
NT, you need to download it, run the install program, and if you desire to also
set the Wusage remote administration password through the GUI, and then give Wusage
the hostname of the server Wusage is installed it on so you can log in here:
http://hostnameofserver:2396/
Use the username 'wusage' and the password you have set if you have done this
for remote administration.
If it's UNIX, the situation is pretty much the same, except that he
downloads the appropriate .tar.gz file for whichever UNIX flavor this
is going to be, and starts the 'wusage' program like this:
./wusage -server
While logged in as a user that has read (and possibly write, for
log rotation) access to all log files. This command will print the
administrative password on first use, and must write that down and
give it to you. You then log in over the web, the same as with the
NT version.
Under UNIX, he must also make sure the wusage -server command is in
the boot-up sequence so that it is always available to talk to
you and your clients.
After that, it's time for you to start reading the
manual section on "ISP mode". You'll be adding accounts for
your clients, who will also log in using the URL above, and the passwords and usernames
you choose for them through our "add account" pages.
Contact us after reading the relevant
section in our Wusage
Manual.
I am running Wusage but I can't seem to connect to it using my browser.
You may have a proxy server configured, and your web browser may be not configured to
make an exception for the following addresses:
127.0.0.1 localhost.
Fortunately, both Netscape and Internet Explorer make it easy to make exceptions for a few
sites. I don't know why they don't make exceptions for these two addresses already, since any
connection to them is, by definition, a connection to the same computer! A proxy server could
never find it.
In Netscape, you can add exceptions through the following sequence of menus:
Edit->Preferences->Advanced (click the plus sign)->Proxies-> Manual Proxy Configuration->Exceptions.
If you are using "automatic proxy server configuration," you will need to talk to your network
admin about adding an exception for localhost and 127.0.0.1. Ours is not the only program that
uses this standard feature, so hopefully they will be agreeable.
For Internet Explorer, starting from your 'Start' menu, go to:
Start->Settings->Control Panel->Internet->Connection-> Proxy Server->
Check the "Bypass proxy server for local connections" box.
How & when does the cumulative summary update?
Cumulative summary includes only days that the program knows
it has seen all of the logs for. The program knows it has
seen all of the logs for a day when it sees logs for the
next day.
Wusage no longer runs automatically, we tried with the service itself and it fails to start too.
Try using the administrator's account in the service setup.
It sounds like it could be a permissions problem. Also, read the next FAQ for more information.
I'm trying to use the NT service, manually, all is well but if I leave it to the service, it does not run.
The service should be looking for
.wu.6k in C:\WINNT (if that is your NT install directory),
based on the result of a call to GetWindowsDirectory.
My best guess is that this is succeeding but you are using NTFS
and the file .wu.6k is not readable by the user SYSTEM,
which services run as.
Make that file readable by SYSTEM to fix the problem.
(I mention NTFS because the FAT file system doesn't have a concept of
file ownership; so our tests, mainly conducted on FAT filesystems,
may not have encountered this issue.)
WN 2K Issue:
This is on a 2k box with ntfs. The only place I found .wu.6k was
c:/documents and settings/administrator/windows. I copied the file
to c:/winnt and stopped and started the service; we'll see how that
goes. I had found several .wu* files but did not know what went where.
Does Wusage write to a database?
It writes to a proprietary work in progress database.
How much disk space does Wusage require?
Daily reports require a LOT of space for large or multiple site reports. If space is a concern we suggest turning on only monthly and quarterly reports. Don't turn on annual or summary as they require considerable resources to generate (summary requires ever-growing resources...). Wusage 8 makes it much easier to understand that there is some historical information available even without summary reports turned on, because there are prominent links to historical charts.
I haven't found anything in the docs about temp directory choice, please advise.
The environment is checked for this information in this order:
We don't set TEMP;
If a Windows user has a TEMP setting at all, the computer owner/user
set it up themselves and they know about it. However, most people don't,
so the program defaults to C:\WINDOWS\TEMP.
This is probably being set in C:\AUTOEXEC.BAT, where you could
easily change 'SET TEMP=whatever' to 'SET TEMP=C:\WINDOWS\TEMP'.
Wusage created many wuagexxx.xx temporary folders in my c:\winnt folder, is there anyway to set the temp folder to c:\temp or auto remove the temporary folder in c:\winnt?
Wusage should automatically delete its temporary directories but we do occasionally get reports to the contrary. So far all reports do say that the directories are, at least, empty. Wusage tries pretty hard to figure out where your temporary files ought to go! Here's what it looks for: 1. Any of the TMP, TMPDIR, tmp, tmpdir, TEMP, TEMPDIR, temp, or tempdir environment variables (upper and lower case accepted). If any of these are set it will use the directory indicated. 2. C:\WINDOWS\TEMP, if it exists. 3. If none of the above work, the result of the WIN32 GetTempPath function provided by Microsoft. This function tends to make lousy suggestions like the location you're seeing, so we don't use it except as a last resort. Your simplest solution is to create C:\WINDOWS\TEMP.
I'd really like to put its temp files in a different directory.
Set the TMP environment variable before launching wusage.
Do you have support for load balanced website's, meaning 2 log files per site?
Yes, just add more than one log file location via the "edit configuration" button. You can add any number of log file locations and Wusage will already read from them in parallel. Enjoy!
ADMINISTRATIVE QUESTIONS & ANSWERS
"I'm only interested in doing analysis of a single directory. How do I do this?"
Run the regular Wusage user interface and do the following: Edit Configuration Configure Filters Allowed Documents Add Item Then select "begin with" and enter "/directoryname" (where directoryname is the directory you want, of course) in the "this text" field, and click "Add Pattern". Click "OK" all the way back up to the main control page and you're done. Any future updates will consider only that directory. To regenerate existing reports that way, you muse use "Regenerate Completely".
"I can't get stats on search keywords and referring site information, why?"
Referring URLs are probably not being logged by your server in the first place. Turn this on in the IIS control panels. Switch to w3c extended log format if you haven't already, and turn on web browser/user agent information too if you haven't already.
Is there a way to change the defaults for the program without manually editing the config files?
If you're using ISP mode, you can use "copy account" to make a new account very similar to an existing one.
"I turned on DNS and a large percent are unknown, is this correct?"
Yep. There will always be many, many machines for which reverse DNS lookups are not available. Forward DNS (name to address) is easy, but reverse DNS is something lazy administrators, including some ISPs, don't bother with for individual workstations.
First Wusage was not working, now DNS is not working, we have a firewall?
Do you have a firewall? If so this may be the issue as business can't be done as usual. First thing is you may need to change port 2396 to other port in order configure Wusage correctly behind your firewall. To do this use the -p option when launching the program. Specifically: wusage -p portnumber What issues are you experiencing when launching Wusage? Please feel free to contact us if you have a firewall. Other thoughts: Some users have difficulty with the DNS Resolution (IPs->Names) (dns) option under Windows 95 or Windows NT. This option does work properly. However, there are bugs in Windows 95 and NT that can prevent them from working under the following circumstances:
- Windows 95
- There is a memory leak in the original version of Windows 95 which causes the operating system to run out of memory after enough socket connections have been used (this includes the sockets used for DNS lookups). Installing the latest Windows 95 service pack should help. Please see Microsoft's site for details. We do not provide Windows 95 upgrade support. This information is provided purely as a supplement to the documentation available on Microsoft's site.
- Windows NT
- Windows NT versions 3 and 4 have bugs which can prevent "reverse DNS" lookups such as those used in Wusage from working properly. It is our understanding that these bugs have been fixed in Microsoft's service pack 5 for Windows NT 3.5 and in Microsoft's service pack 2 for Windows NT 4.0. (Newer service packs, if you see them on Microsoft's site, should also take care of the problem.) See Microsoft's site for details. We do not provide Windows NT upgrade support. This information is provided purely as a supplement to the documentation available on Microsoft's site.
We are doing DNS resolution with the 'fast' resolution option, but the Top Visitor Domains report shows up with 100% of the Domains as "UNKNOWN".
The very old fast option, which was rarely understood and could not be used to generate the top domains report, has been removed. If encountered in an existing configuration file, The fast option did make this report show up with 100% of the visitors unknown. If we could deliver all of the possibilities of dns with the fast option, we wouldn't have a separate "on" option at all. Unfortunately, there's no free lunch; to look up *every* visiting IP to produce full domain reports, you must set dns to on.
DNS is not case sensitive. I recommend putting lowercase only in the list of matching domains.
Wusage approaches resolution by forking six child processes which each then sit down to process a great big heaping helping of log lines. Because DNS is an I/O bound operation (very much so -- it spends much of its time waiting for faraway machines), the overhead of multiple processes versus threads doesn't become an issue.
We want to change the directory depth to include other directories but not all other directories.
One simple way to do this for deeper directories is to change the directorydepth option to a larger value than the default, which is 2. This is why you currently only see two directories deep. To get to this in the configuration editor, do this: Edit Configuration -> Configure Reports -> Top Directories -> How Many Levels Deep (Directory Depth)? And change the setting to 3 or perhaps 4. Depending on the number of documents on your site there is a small chance that the reports will become impractically large. If you only care about *one* subdirectory, use the "allow" filter to specify this. To do that, follow these steps: Edit Configuration -> Configure Filters -> Allowed Documents Then use the "add" button and add a filter like this: /insidehere/News|/Jan2001|/insidehere/moreNews/* This matches both the home page and everything beneath it. You will still need to increase the directorydepth option. No other directories are considered at all if you go this route. You may wish to do all of this in a new configuration file, for which you must specify a new report directory. If you make such changes in an old configuration you must use "regenerate completely." Be aware that you must have log files going back as far as you might want reports to do that safely.
I would like to exclude my own IP from the wusage reports.
The Ignored Sites (ignoresites) option indicates which sites will be ignored by wusage. Accesses from sites which match any of the patterns listed for the Ignored Sites (ignoresites) option will be ignored completely by wusage. Each character of the site name is matched against the pattern.
An * in the pattern matches any number of characters in the site name. Patterns have additional features, including support for regular expressions; for more information about patterns, see the Patterns and Regular Expressions section of our manual. If the Ignored Sites (ignoresites) option is absent, no sites will be ignored.
Here is a sample:
ignoresites
#A pattern matching all sites in the boutell.com domain;
#useful to filter out local test accesses
*.boutell.com|boutell.com #Ignore all machines in this domain and also boutell.com itself.
208.27.35.* #Ignore all machines in this Class C network. Also ignore by domain (see above).
123.45.678.90 #To ignore a specific machine by IP. Also be sure to ignore it by hostname.
end ignoresites
Where does Wusage store the time/date info on when an update should be performed?
In the .wusagerc file in the home directory of the UNIX account you run the program from. The format is a little odd, but decipherable. Subject to change without notice!
Since I have 2 virtual servers providing log files, how can I activate the option for multiple virutal servers?
You want to blank out the servername option completely, and set the manyservers option. To be clear: leave servername blank, or remove the line for it entirely. Along those lines if you have several websites which have multiple domain names such as www.site.foobar.com, www.site.foo.com etc. There is a method that to make Wusage produce a report for all the domain names belonging to the particular site. It is the "manyservers" option in our configuration file editor ("Analyze ALL Virtual Servers Found In Log File").
I've set up the accounts and am using the ./wusage -server option but how do I see the actual stats of the virtual domains?
1. Set up a scheduled update for all accounts, from the administration page.
2. Wait for that time to come to pass the next day.
3. Open up any individual account while logged in as the administrator, by doing this:
Edit Accounts -> Open This Account -> View Statistics
I have different domain names that resolve to one IP address.
I understand. Wusage itself doesn't currently have an explicit feature
to do this, unfortunately, but I just put it on the to-do list
for version 8.0, because it makes great sense.
However, if you're using Apache, you can approach this by configuring your
server to create an additional log file which simply logs the virtual
server name (host field) requested by the client for each access. If you're
using UNIX, you could then easily use "grep" and "wc -l" (or a
simple Perl script) to get counts by virtual domain.
I wanted to change the Wusage user and location of the user directories so I changed the paths in the dot files of Wusage. Now Wusage no longer sees the user directories.
Don't try to change the paths in the Wusage dotfiles. Instead, make /root/wusage-accounts a symbolic link to the place you want. If you have changed paths in .wusagerc, change them back.
Do I need cookies to get good stats?
For the best visit and unique visitor figures, turn on user-identifying
cookies in your logs. With Apache, this is done using the mod_usertrack
module. Wusage will recognize these cookies and use them instead
of IP addresses to distinguish users quite effectively.
Highly recommended. See our "server configuration tips" manual
section for more information.
A cookie is a short piece of data, not code, which is sent
from a web server to a web browser when that browser visits the server's site.
The cookie is stored on the user's machine, but it is not an executable
program and cannot do anything to your machine.
Whenever a web browser requests a file from the web server that sent it a
cookie, the browser sends a copy of that cookie back to the server along with
the request. Thus a server sends you a cookie and you send it back whenever
you request another file from the same server. In this way, the server knows
you have visited before and can coordinate your access to different pages on
its website. For example, an Internet shopping site uses a cookie to keep
track of which shopping basket belongs to you. A server cannot find out your
name or e-mail address, or anything about your computer using cookies.
I just did an update on statistics and the web server logs were complete through 10am but the report has reported traffic through 6pm, an 8 hour difference, why?
Perhaps your log files are in GMT? In that case you need to use the offsethours option of Wusage to turn back the clock.
Wusage - possibly for performance reasons - does not read and respect the server time zone in each log file line, how can I correct this?
Perhaps your log files are in GMT or PST? In that case you need to use the offsethours option of Wusage to turn back the clock.
REPORT QUESTIONS
When I click the drop down list for annual reports and turn it on, they turning back to off after I exit Wusage.
This is probably a bug we're aware of but haven't been able to reproduce and fix yet: you need to go to ISP mode, then to the overall limits page, and remove the limit settings there. It shouldn't affect advanced mode and separate configuration files, but for some people it does.
What is the definition of a page view?
When a user types "www.yourdomainname.com" and presses the ENTER key, the page they get is what home page views usually reports. It does that by looking at the URL in the log file, removing any suffixes specified with the suffixes option under "configure filters", and then looking to see whether the resulting URL is just "/". That's considered a home page view. If this isn't how your site's home page (as you consider it) looks in the log file, adjust your suffixes option, or edit your historical totals option to match the URL you consider to be the home page. Page views to page X are equivalent to accesses to page X. *Overall* accesses to the *entire* site are a higher figure than page views to the entire site, because not everything on your site is a page (remember images, audio, movies, style sheets...).
How do I get referring urls, key search words and web browser information?
To get browser and operating system information you'll need to configure IIS to include this information in its logs. Tell your administrator/server to turn on "web browser" or "user agent" logging. This is in the IIS control panels. Switch to w3c extended log format if you haven't already, and turn on web browser/user agent information too if you haven't already.
If a single ip address looks at two different pages, a few minutes apart (within the default 15min visit length), isn't that two visits?
No. That's the point of visits: a single 'session' by a single person
is ONE visit to your site as a whole. Visits are synonymous with sessions.
A single session that touches on a particular document once is ONE visit to a particular
document. Whatever the context may be -- your site, a folder, one page --
a visit is ONE session that touches that context.
The goal of visits is to measure user 'sessions'. For most customers this
is the desired behavior.
While an access is a single request for anything on your server, a visit
consists of one or more accesses by a single visiting machine, with no
more than a certain time interval between. Visits are a much more
truthful count of distinct user experiences with your website.
Also, remember that Wusage 7.X does not display the current day *in progress* for
weekly reporting and up. Wait until the first update after Day X is over. Or look at the
report for Day X itself if you have daily reporting turned on.
I have a pdf file that says the Accesses are 314 the visits on the other hand are only 96, how many people have downloaded the PDF?
There were 96 user experiences that included looking at that PDF file. That's what the visit count is telling you. It's not possible to be absolutely certain that none of those people came back, say, three days later; the program would count that as a separate user experience. You cannot measure the number of unique people who looked at an individual document although we do try to track that for the site as a whole (many things make it difficult to get that figure 100% accurate).
Why don't my visits add up?
"What is the meaning of the statistic visits on each line of the 'Top
Documents Sorted by Access Count' as they seem to add up to much more than
the 'important total' statistics for visits, similarly for accesses."
You can not add up visits in this way. Here is why:
A visit touches on many documents. If a visit hits documents A, B and C,
that is one visit to each of those documents; it is also one visit to the
site overall.
A visit consists of one or more accesses by the same person with no
more than a certain time limit between accesses. If a visitor accesses
documents A, B and C with no more than 5 minutes between accesses,
that is one visit to each of those documents; it is also *one* visit
to the site overall. Home page accesses and home page visits are usually
similar figures, because most users won't access the home page twice
in a single visit; however, some do, and this is why the home page access
count is slightly higher than the home page visit count.
Wusage does not measure unique visitors on each page. It does measure
hits (accesses) to each page, and visits (sessions) that include each page.
It also does measure unique visitors overall.
A single visit consists of one or more accesses from the same computer with
no more than a certain time interval between, as determined by comparing the
IP address, web browser used, operating system used, authorized user name
(if present) and user-identifying cookie (if present); if a cookie is present
it overrides everything else. The time interval rule can also be overridden
if the referring URL indicated by the browser matches a page on your site.
The timeout interval, in minutes, is set by the trailtimeout option.
In other words, it's a sophisticated attempt to determine that a particular
person sat down, did some stuff on your site for a while, and then left;
that's one visit.
(Visits to a specific page are visits during which the visitor touched
that page at least once.)
The goal of visits is to measure user sessions. For most customers this
is the desired behavior.
Can you explain unique visitors, unique sites served and unique documents served?
The "unique visitors" figure represents the number of individual
personal computers which visited your site. Of course, the accuracy
of this figure depends on how it is computed.
If your site does not log user-identifying cookies, use our
"unique visitors (IP address method)" figure. The number of
distinct IP addresses is only a rough estimate of the number of
actual personal computers, because IP addresses are reused
by different ISP customers and, in some cases, more than one
IP address is used in a visit (as is true for AOL users).
If your site does log user-identifying cookies, refer to
"unique visitors (cookie method)" figure. If you do not see
this figure, or it is very, very low, your site does not
log cookies. See the "server configuration tips" section of our
manual for more information about how to enable this feature.
Unique Sites Served measures the number of unique IP addresses
used by personal computers that visited your server. This figure
is often used as a rough estimate of unique visitors, but be
aware that IP addresses are reused, and that sometimes more than one
is used in a single visit.
NOTE TO USERS: the term "unique sites served" is not used
by Wusage 7.0 and up. We do report "unique visitors (IP address method)"
(in 7.1 and up) and "Visitors came from X distinct Internet addresses"
(in 7.0 and up) in the executive summary, and these both refer to the same
thing as "unique sites served."
Unique Documents Served measures the number of distinct URLs
that your web server delivered. Each page or image may have been accessed
many times, but each page or image only counts once for this purpose.
Unique Documents Served is therefore an interesting measure of
the complexity of your site.
NOTE TO USERS: the term "unique documents served" is not used
by Wusage 7.0 and up. We do include the paragraph "the web server
delivered 28 unique documents one or more times each" in the
executive summary, and this is the same information.
Unique Trails Followed refers to the number of nontrivial routes
which were followed through the server. Each visit follows a
particular path through the site; the number of unique trails
indicates how many paths of at least three steps were found.
NOTE TO USERS: this is a Wusage 6.0 term. We don't use it in 7+.
What does the "accesses per day" chart display?
The "accesses per day" chart displays the number of accesses, bytes transferred, and visits made for each individual day within the reporting period (week, month, etc).
How do I get visits by country?
To get visits by country codes just edit your domaingroups option
settings. You can simply remove existing the continent groupings, or start
assigning country names to groups of just one domain. See the
configuration file editor reference.
Here is an example of one approach:
United Arab Emirates ae
Afghanistan af
This approach will work if you get rid of the continent lists and
just make a lot of these little one-shot deals.
*More on obtaining geographical locations with Wusage from states within
the US:
Some products do advertise such a feature, but in the end they base
their information only on the mailing address of record for the
Internet service provider the customer is calling. This does *not*
mean that you can tell what city they dialed out of; usually it's just
one address for, let's say, the biggest ISP in the US, producing a
totally misleading result. In the US, this results in the majority
of one's customers supposedly being from Virginia, when that only
means that they are AOL users.
The only way to get real demographic data is to obtain it from the
customers, or to join a cookie-tracking network that obtains it
from customers at some point and then shares it across the network.
This is a high-end, expensive solution and Wusage is not designed
for that purpose.
You can tell which ISP users come from if you turn on our DNS resolution
option, and set our 'subdomainlevel' option to 2; the dns option must be
set to 'on', (and IF you have 7.X - not 'fast'), and you must be prepared to
wait for the results to be fetched from many servers around the world when
you analyze a log with this option turned on.
What is the effect of the Documents Not Found report on other reports within the Important Totals?
None at all, because documents that are not found don't count toward those figures. The meaning of the statistic visit as it is referred to in the Document not found report, understanding that the visits are not counted in the other Important Totals reports is that a visit consists of one or more accesses by the same person (as determined by cookie, if available, otherwise by IP) with no more than a set time limit between accesses. See our Glossary for definitions terms used in Wusage.
Can you help me with the terms hit, access & visit?
I need help understanding the Executive Summary Report.
The Executive Summary - I'm not so much concerned with the information
contained in the Executive Summary report, because I do understand the difference between
"visit", "access" and "hit" terminology.
What I need to know from this information, is the
line that says Visitors came from 18 distinct Internet addresses.
We're using that figure as a rough number of unique users in a given period. the questions are:
is this really a reliable way to measure unique users vs. cookies?
Cookies are certainly better, as long as your server doesn't log cookies
unless they have actually come back from a browser. Some versions of
Apache log the cookie the first time, when it is set but not received
from the browser. Ugh! Then you get dozens of cookies for a single
non-cookie-accepting user, which can make a mess. Generally speaking
IPs aren't a terrible measure unless you have a lot of AOL customers.
Clicking on the report for a month gives an XX number of unique
Internet addresses for that period. but if you add the number of unique
Internet addresses for each week within that month, the figure is higher
than the monthly figure. we assume that's because the monthly figure is a
true number of distinct Internet addresses for that month, not simply a
total of the weekly figures within that month. is that correct
assumption? That's exactly right.
Why are only the top 10 listed on most reports?
All of these settings are easily changed through the configuration editor:
edit configuration -> configure reports -> pick the report and
click "edit now" -> change 10 to a higher number.
(You can also set it to ALL, but in some cases this produces huge reports)
Then "regenerate completely" (IF you have all of the log data still)
or wait for the next day's report.
Can the Visits data on the "Executive Summary and Totals" report be activated without also activating the trails reports?
Yes, you can do "trails off" if you like.
Why do I see zero accesses across the board when generating Wusage stats?
Your problems with zeroes are probably caused by stray log entries for future dates. That's very ugly; hard to prevent. Check your log files for anything of that nature.
My total hits from accesses by site when added up does not come close to my total home page visits.
Visits and accesses are very different things. An access (accesses and hits are synonymous terms) is a single fetch of any object on your site. A visit is an entire user session, made up of many accesses (usually). Also, home page visits (visits touching on your home page) would not be expected to be comparable to overall visits (for the whole site, whether they touch your home page or not), and certainly not to overall accesses (any hit on anything at all). Let me know if you have further questions.
In Wusage' "report of traffic by hour", which hour is intended?
Wusage reports the time stamps shown in the log file as-is without attempting to adjust them, unless you use our "offsethours" option to change this.
How can I change the Wusage Reports output format?
You might look at our report macro language; you can rewrite the macro set all you like to output anything that looks rather like HTML (such as XML).
I've set up several filters and they don't seem to be taking effect.
I want wusage to ignore all js, css, gif and jpg files so I went under Ignored Documents
and added a pattern of "*.jpg,*.gif,*.js,*.css" and when I generate stats they still
show up as the most common documents.
We use | to mean "OR", not a comma. Try that and you'll
have much better luck.
How do I interpet the effect if any on the total visits and pages viewed when dealing with the code red virus.
My web address is http://www.foobar.com
Among my web stats there is for some reason a frequent request
for a document that does not exist.
I have a page with the address http://www.foobar.com/IDA.HTM
but there is a frequent request for a /default.ida?XXXXXXXXXXX
(even more X's and a code on the end).
These accesses are typical of the Code Red Worm, a well-known computer
virus which attempts to attack IIS servers. If you are not running IIS,
you have nothing to worry about. If you are running IIS but you have
installed the appropriate upgrades (as Microsoft and others have
extensively publicized), then you have nothing to worry about there
either. These accesses come from other machines which are already
afflicted; they are attempts to subvert your server also, but if you
are not running IIS or have taken appropriate steps they will
not succeed in doing so.
Do remember that "404 not found" accesses aren't counted as valid accesses or visits to
my site.. The only circumstance in which they might be counted is if you have modified your
success codes setting from the defaults that we set up in all new
configuration files.
Among my web stats there is for some reason a frequent request for a document that does not exist.
I have a page with the address http://www.foobar.com/IDA.HTM but there is a frequent request for a /default.ida?XXXXXXXXXXX (even more X's and a code on the end). These accesses are typical of the Code Red Worm, a well-known computer virus which attempts to attack IIS servers. If you are not running IIS, you have nothing to worry about. If you are running IIS but you have installed the appropriate upgrades (as Microsoft and others have extensively publicized), then you have nothing to worry about there either. These accesses come from other machines which are already afflicted; they are attempts to subvert your server also, but if you are not running IIS or have taken appropriate steps they will not succeed in doing so.
I am not getting referring urls, keywords or search engine information in my reports.
You need to configure your copy of Internet Information Server(IIS)
to log all available fields instead of just the very few
default handful of fields, which can indeed be dismal and of
limited value.
Referring URLs are probably not being logged by your server
in the first place. Turn this on in the IIS control panels.
Switch to w3c extended log format if you haven't already, and
turn on web browser/user agent information too.
If you need to know how to configure your web server to produce user agent,
user-identifying "cookie", and/or referrer log information,
our server configuration
page will help you understand this process.
Please check to be sure you have the latest version and patch of Wusage
for your operating system before doing anything. To check go to
our download page and
look for your operating system under Wusage 8.0. Then compare what you see there
with what you see either on your GUI or use the wusage -v command to check.
In the Top Referring URLS by Document do the stats refer to unique visits from those referrers or do the numbers represent the number of accesses?
Accesses. However, the two figures would be extremely close, because a visit begins with a referrer anyway. Although occasionally a user will wander back out and return in time to be in the same visit, that doesn't happen very much -- referrer access counts are very close to what referrer visit counts would be.
How can I get fiscal reports?
Wusage will only produce an annual report for a calendar year.
To do what you want, you could set up a new configuration
(via advanced mode) with only "summary" reporting turned on,
and feed it only the log data for the appropriate fiscal year.
If you take this approach, do *not* use the date range feature
as this does not update the summary report -- use the regular
update button but make sure only the relevant log data
is available to the program at that time.
How can I get rid of my daily reports from last year without having to use the regenerate completely option?
Set the "keepdailyreports" option to something other than "all" then update the statistics (you do not have to regenerate from scratch).
In wusage 7.0 monthly reports what is the difference between "visits" and "accesses" on "Home page Access"?
A visit consists of one or more accesses by the same person with no more than a certain time limit between accesses. If a visitor accesses documents A, B and C with no more than 5 minutes between accesses, that is one visit to each of those documents; it is also *one* visit to the site overall. Home page accesses and home page visits are usually similar figures, because most users won't access the home page twice in a single visit; however, some do, and this is why the home page access count is slightly higher than the home page visit count.
In the executive summary the longest visit I show is over 1,000 minutes, is this correct?
A bot most likely came and crawled your site for a very long time. Something possibly like Alta Vista.
Is there some way to globally disable the pie chart business without editing all the templates in the "macros" directory?
Editing the macros is the way to go if you find that some of them can't
be set to nopie. This isn't as ugly as you may think -- it's actually
pretty easy to do. Except for the documents and directories reports;
I'll give you a hint there: of those .rmc files contain this line:
I saw where the "pies" were inserted via some
[@...-chart@] tags ?
I'm assuming I just take those out?
Yep.
Also make sure you are copying your modified .rmc files to your
report directory so that they will actually be used (there are
alternatives, see the report macro language section of the manual).
wl(subreportPie);
And deleting that line will remove the pie chart from those
particular reports. The other macro files are a lot simpler because
they are not javascript-driven.
Is there a way to track referrals with a tracking code that has a question mark?
Turn on the "keepqueries" option. Then you will see
full URLs including what comes after ?. Sometimes that
can mean a *lot* of unique URLs, of course. You might want
to try Wusage 8.0 and its CGI parameters and values report,
which is available even when keepqueries is off. To '
include a query string in page views such as:
http://www.yoursite.com/foo.asp?item=ski802880k2
in the list of patterns matching a page, which are separated by |. You'll
see this when you look at object types in the configuration editor,
or the subreports option when editing the configuration file by hand.
*.asp?*
I would like to know more about Top Trails Report definition and usage.
The top trails report shows the most commonly followed paths on your web server, including only those with at least three steps. It is not nearly as useful or understandable as the navigation graph included in Wusage 8.0, but it is somewhat useful. The three steps referred to are the three web pages, at least, touched in the course of the visit.
Can I put the reports from Wusage into an Excel spreadsheet?
Wusage does not export to Excel, except for the basic historical figures
for the major stats that are graphed over time; you can import the
tab-delimited spreadsheets "daily/database.dat", "weekly/database.dat",
etc. into Excel (don't modify them; copy them). You can not just get date *visit and
document/visit show up in database.dat file, database.dat will contain exactly what is in the
historical totals report, nothing more or less.
However, you can use the report macro language to create reports in many styles.
In general, Wusage 8.0 does not generate a lot of importable information.
You can always import the database.dat file and if you have
scheduled updates through the regular interface of Wusage then
they should go off automatically (no need to set up any
scripts of your own). A more complete set of Excel-friendly
files will have to wait for 9.0.
When you talk about access per hour you express the number with decimals, but not when you talk about accesses per day, why?
In a weekly report, accesses per hour are averages for that hour on each day of the week, thus a decimal point is needed. Accesses per day are the exact total for that day, and there's no such thing as half an access, thus no decimal point is needed.
EMAIL REPORT QUESTIONS
I get the e-mail reports that say: Note: the time period this report refers to is not yet over.
Ignore the "partial day" report and concentrate on the report for the complete day that arrives the following day. Wusage doesn't send reports until just after it has updated them and until Wusage knows the day is *over*. It doesn't know that until it sees the first data for the next day (that is, it doesn't know that you won't spring a little more data for that day on it on the next run, until it sees data for the next day).
Is there a default email.rmc that can be edited?
The standard .rmc files are in the macros subdirectory of the install directory. Use these as your starting points -- don't start from scratch! Copy them to your report directory to make them take effect.
Is it possible to design multiple email reports, with differing content for different departments within one organization.
Yes, each e-mail report may include different information than any of the other reports. You will need to put separate .rmc files in each report directory. To customize the subject line in the e-mail reports see the "report macro language" section of our manual. But to be more specific, edit your copy of email-epoch.rmc and insert [@top-url@] in the subject line. Then make sure you install your modified email-epoch.rmc correctly according to the instructions in the report macro language section of the manual.
WARNINGS & ERRORS
Warning: database from a computer with an incompatible double-precision format for numbers found. Ignoring database.
This message appears when trying to move a Wusage report directory from one computer to another that runs another operating system, or has a different binary format for numbers (a different kid of CPU). You can do that, but your "work in progress" databases will be reset to the start of the current day, week, etc.
I get an out of memory error.
Wusage 7.1 can run into memory issues quickly if the summary report is turned on and the site is popular. I suspect your summary report database has grown impractically large. If you have summary reports turned on this will eventually happen for a popular site. The solution is to turn off summary reporting (and possibly also annual). Although we optimized as much as possible, the summary report does have open-ended memory requirements as your site's database of, for instance, visiting IPs grows with time.
Another possibility is that your work in progress databases may be corrupt for one of the reporting frequencies (daily, weekly, summary, etc.). You can address this by deleting the current.epc files in these subdirectories of your report directory and trying another update. However, this requires that you have log files available going back to the start of the time period in question. For summary reporting, unfortunately, if the database becomes damaged you will only be able to go back as far as your logs go.
I get an error code - 43.
You're having difficulty with the program's attempts to automatically
launch your browser.
There's an easy workaround. Start your browser manually and open
this URL:
http://127.0.0.1:2396/
You can bookmark that for easy access.
I get an error code: 400.
Error code 400 is not "document not found." It isn't success, either. So Wusage does not regard the access as successful and does not record it as either a file not found or a file sent. More detailed reporting on individual error codes is something we'll consider for 8.0. If you feel you need more detail on this I would suggest using grep to grab all of the error code 400 accesses in your log file each night.
I am running Wusage but can't seem to connect to my browser.
Are you using a proxy server? Try connecting manually with this URL:
http://localhost:2396/
more on the issue...
You may have a proxy server configured, and your web browser
may be not configured to make an exception for the following
addresses:
127.0.0.1
localhost
Fortunately, both Netscape and Internet Explorer make it
easy to make exceptions for a few sites. I don't know why
they don't make exceptions for these two addresses already,
since any connection to them is, by definition, a connection
to the same computer! A proxy server could never find it.
In Netscape, you can add exceptions through the following
sequence of menus:
Edit->Preferences->Advanced (click the plus sign)->Proxies->
Manual Proxy Configuration->Exceptions.
If you are using "automatic proxy server configuration," you
will need to talk to your network admin about adding an
exception for localhost and 127.0.0.1. Ours is not the only
program that uses this standard feature, so hopefully they
will be agreeable.
For Internet Explorer, starting from your 'Start' menu,
go to:
Start->Settings->Control Panel->Internet->Connection->
Proxy Server->Check the "Bypass proxy server for
local connections" box.
What is the AF8 error I receive within my documents not found report?
Very likely you have a script or page which contains links to these unusual URLs. Otherwise there's no reason for you to get "404 not found" errors in your logs that make reference to them.
We are receiving the Error Can't write to file! Filename: \\\followed by the path.
We have found that most users have better luck using a network drive mount. Assign a drive letter to the mount in question and use that drive letter instead of a double-slash path. We're still working on this issue but there are serious questions about how passwords should be handled, etc. Network drive mounts solve the problem well.
I get the message: The configuration file /wusage/foobarconfig is locked.
Look for an already-running wusage process that may be in a wedged state
and kill that process. You may be trying to do a manual update while an update is scheduled
for that day or exact time period you are trying to access the program. Use either the manual
update process or the scheduled updates feature but not both. Please continue reading...
OR
Make the directory where the Wusage configuration file is located writable. Wusage needs
to create another file in this same directory and if the directory is not writable that
is not possible.
OR
A much less likely issue is that the directory where the configuration file is located
may be NFS mounted using a version of NFS that won't allow file locking
at all. In short, your operating system wouldn't
allow files in that particular directory to be locked at all. If this is the case
try keeping configuration files on local drives only.
(We, of course, should address this issue with a more specific error message.)
Warning: poor extended log format configuration. This log file does not contain username information for each access...
These warnings -- not errors indicate that your logs could be better.
You need to configure your copy of Internet Information Server to log all available fields
instead of a very tiny default handful of fields. The very tiny default handful of fields
is of limited value when trying to produce useful and complete statistical data regarding
your website. Be sure to enable the date field as well as bytes, referrers, user agents
at least, in your IIS logging control panel.
Please go to the section on acceptable log formats for more information.
I get Errors that say The description for Event ID ( 0 ) in Source ( Wusage ) cannot be found. WARNING: Wusage could not create the file C:\program files\Wusage71\data\.wusagerc.new
Make sure that directory, and all files in it, are fully readable and writable by the user SYSTEM.
I get the message: "Page cannot be displayed".
1. Check your Internet connection for a proxy server.
2. Is the program actually running at the time you try to connect to it?
3. What URL does it tell you to connect to?
Try to start your browser, choose File->Open->Browse,
and locate your report directory (wherever you told Wusage to put it).
Open the file index.html in that directory.
Else try connecting manually with:
http://localhost:2396/
ISP MODE QUESTIONS
How do I tell Wusage to do a manual update for all my accounts?
The command line options page can help you, but please be careful if you choose to use other options. It can be hard or worse to undo a combination of co-options that were not thought out fully as to their consequences. For other operating systems try C:\wusage71\wusages.exe -debug-service -update-all-accounts
Where does Wusage store the reports in ISP mode?
/home/unixaccountname/wusage-accounts/wusageaccountname/reports
This should not be changed, but if you need the information to physically
go somewhere else, you can make /home/unixaccountname/wusage-accounts a
symbolic link to somewhere else.
Wusage doesn't seem to show end users paths in ISP mode, why?
For security reasons we don't show the real paths when working with ISP mode accounts. This prevents your clients from learning about your file system any more than you'd like them to when they log into our web interface.
Should I use the ISP mode or create custom configuration files and report directories for each client?
You can either (a) use ISP mode as intended and give people their ISP mode account login information so that they can go to our web interface and see their reports that way, and not worry about putting them in your regular web server space at all, or (b) totally ignore ISP mode and start creating your own custom configuration files and report directories for each client, anywhere you want to put them. Advanced mode is a good place to start on that, and you can then use command line stuff like "wusage -c /path/to/conf/file" to update any given configuration. To summarize, you can create the accounts through the ISP mode administrative interface. Or you can ignore ISP mode and go for advanced mode, which allows you to put report directories and configuration files anywhere you want them and update them from your own scripts.
Will wusage save the logs at a different location so, we can delete them from the default folder.
Yes, Wusage can do log rotation if you tell it to do so through the ISP mode administrative pages.
Can I get administrative access when logging into Wusage remotely?
If you set up the software on the server, you can log into its interface on port 2396 (http://www.mysite.com:2396/) using the administrative username and password, which you can set once when using the software at the server. Then you have the same access you would if you were there. You can add accounts for clients as well to provide them with similar access.
How to connect users in ISP mode in 7.X.
It depends what operating system you are going to install this on. If it's
NT, you need to download it, run the install program, and if you desire to also
set the Wusage remote administration password through the GUI, and then give Wusage
the hostname of the server Wusage is installed it on so you can log in here:
http://hostnameofserver:2396/
Use the username 'wusage' and the password you have set if you have done this
for remote administration.
If it's UNIX, the situation is pretty much the same, except that he
downloads the appropriate .tar.gz file for whichever UNIX flavor this
is going to be, and starts the 'wusage' program like this:
./wusage -server
While logged in as a user that has read (and possibly write, for
log rotation) access to all log files. This command will print the
administrative password on first use, and must write that down and
give it to you. You then log in over the web, the same as with the
NT version.
Under UNIX, he must also make sure the wusage -server command is in
the boot-up sequence so that it is always available to talk to
you and your clients.
After that, it's time for you to start reading the
manual section
on "ISP mode". You'll be adding accounts for your clients, who will
also log in using the URL above, and the passwords and usernames
you choose for them through our "add account" pages.
Contact us after reading the relevant
section in our Wusage
Manual.
CGI QUESTIONS
Is there a way that I can keep track of accesses to my CGI programs and other dynamic pages?
In Wusage 8.0 and above, look at the highly useful CGI Parameters and Values report, which is useful with all types of dynamic pages, including PHP, ASP, etc.
I have questions on how to install Wusage as a CGI.
You may be able to get started with the program by untarring it on your own machine, uploading the 'wusage' binary to your CGI directory, renaming it 'wusage.cgi' and marking it executable, all without the use of telnet or ssh, if your FTP program offers the ability to set permissions. But we recommend installing it from the command line.
Why do I get an error when I try to run Wusage as a CGI?
If the error message is "set the home environment variable before invoking Wusage. No home directory could be identified for the current user. Wusage must be able to write to the user's home directory in order to store configuration information", the problem is that your CGI programs probably don't run as the same user that you typically log in as. If the error is something else, contact us for assistance.
We suggest creating a "wrapper" CGI program. This would be a simple shell script as follows:
#!/bin/sh HOME=A REASONABLE LOCATION CGI PROGRAMS CAN WRITE TO export HOME /path/to/wusageMark it executable, replace the above setting for HOME with a real one, and you should be good to go. In any case, you only need to start Wusage in this way once with version 8.0, which then begins to accept web connections itself on port 2396 (http://myservername.com:2396/).
Can wusage give us statistics on specific variables and the range of values that are being used in the URLs? Can we ignore some variables?
We're working on this for version 8.0. Some customers have had some luck with 7.x using the searchkeyword related reports with their own searchservertemplate settings to match their own CGI programs
MACRO QUESTIONS
Where you see "Web Server Statistics" we like it to say "My Statistics" can we can do this via configuration or do we use the macros and hand-editing the files?
First, copy the index.rmc off of the macro directory which was created during unpacking wusage, to the root directory of a given report. Then change 'Web Server Statistics' to title you want to see on the Calendar of Reports. Do this for each report you want to change.
How do I extract stats in a different format or make the reports have a different style?
Take a look at the "Report Macro Language" section of the manual. Also look at our e-mail reporting options, which generate plain text reports and e-mail them to you.
Do you have foreign language templates?
We do not have ready-to-go foreign language templates. You can certainly edit the macro files; see our documentation for important information about this, especially where to put your modified copies.
UPGRADE QUESTIONS
When upgrading wusage from 7.X to 8.0, will wusage 8.0 be able to restart from wusage 7.X report results?
For Windows you must say YES to the question "Do you want to import your Wusage 7.X settings?" (this question only comes up in WINDOWS Upgrades not for other operating systems).
Else, you can just drop a copy of 8.0 in as a replacement for 7.X, and it will read the existing
work in progress database. I recommend backing up your report directory first.
For Unix/Linux Kill all Wusage processes running
Get the new version of Wusage for your operating system
Wusage will reinstall the cron jobs and will do the rest for you.
The status of your registration will also be carried over, so you don't need to register again.
How do I back up Wusage so I do not loose all the accounts? I want to know before I upgrade.
To back up all of your Wusage data files, back up the following files (under UNIX):
/home/myaccount/.wup
/home/myaccount/.wusagerc
/home/myaccount/wusage-accounts (for 7.1 + only, this is a *large* directory!)
/home/myaccount/wusage-macros (for 7.1 + only!)
If you are running as root,
you will probably need to substitute "/root" for "/home/myaccount".
Under Windows operating systems, the situation is a bit different.
Back up this directory:
C:\wherever\you\installed\WusageX\data (X=the version number of Wusage you have before the upgrade)
That is, there is a 'data' subdirectory in the folder where you told Wusage to install itself; and that is the directory you must back up.
Can I move Wusage from my root account to a different user account?
You will also need to move the .wup and .wusagerc files from /root to the home directory of the account in question, and enter your registration key again. You will also need to change paths in .wusagerc, .wup, and the wusage.conf files in the subdirectories of wusage-accounts. This could get a bit hairy, and I apologize; it should be easier than it is. Please read the server configuration tips relating to the latest version of Wusage.
What issues are resolved in the latest patch of Wusage?
Info on the issues resolved in the latest release.
Download the latest version of Wusage.
How much is the upgrade? What do we do if we qualify for the educational/nonprofit discount?
About upgrading:
We highly suggest you obtain the latest version and patch of Wusage for
your operating system.
Get it here!
Wusage 8.0 is now available for Windows, and also for many UNIX operating systems.
SPECIAL WEB HOSTING PRICE: $295, for any number of customer domains analyzed on your company's
equipment at a single physical location, when installed by you. UNIX and Windows NT/2000/XP
users: also available with professional remote installation for $595.
Upgrade Information
All Wusage 7.1 customers who registered on or after September 1st, 2001, can unlock Wusage 8.0
with their existing key. In most cases the software will automatically detect this and you will
not need to unlock it again. For other upgrading customers, the upgrade price will be one-third
(1/3) of the regular price. Please feel free to order online when upgrading from an earlier version.
If a copy for your operating system is not available, feel free to contact
us with information about your specific needs. If the above link does not
work for you, send an e-mail to Contact us
For UNIX users copy the distribution files right on top of the old
files. The new version knows the registration status of your account.
If you are having issues launching Wusage please visit this page.
If you prefer to edit your configuration files or better understand
specific configuration issues please visit these detailed pages or try our
search engine located on our website.
If you need to order via snail mail then please fill out the
order form
and include it with your method of payment (P.O. or check).
For nonprofit or educational pricing we request you print the order form
on your institution letterhead.
Be sure to include a contact name, e-mail address and phone number.
Then bundle this all up and send it to our mailing address, which is:
Boutell.Com
Follow us on Twitter | Contact Us
Copyright 1994-2012 Boutell.Com, Inc. All Rights Reserved.
PO Box 63767
Seattle, WA. 98116
FAX: (208) 445-0327