Explanation of www usage report
Explanation of www browser report
Explanation of www error report
Your counter doesn't agree with your usage report?
About VNI's www reports
Vineyard.NET commercial www customers receive regular reports from our http (Hyper-Text Transfer Protocol) server. These reports provide a great deal of detailed information about your site. In general every customer receives a weekly usage report, a weekly browser report, and a daily (if your page generates any errors) error report.
Our regular dialup customers using personal.vineyard.net do not receive www reports.
In general, when your account is created, we configure the reporting facility to mail reports to both the owner of the account and the designer. The addresses to whom the reports are sent can be changed per your request. Custom reports are also available.
Explanation of www usage report
The VNI www usage report collates all the requests made of your web site. Unfortunately, this is not as straight forward a report as one might hope. Allow me to provide definitions for a few terms in common usage, some of which are particularly vernacular (ie. these definitions may not be useful in general conversation).
- A web page is the data displayed by a single web address. A page has nothing to do with any specific physical dimensions (8 1/2 x 11", or 640 x 480 pixels, or some such). A page might be made up of several components (images, includes, etc.). A page does not include the data available from any links which might be listed. Those links represent other pages (unless, of course like this one, the link simply refers to back to point somewhere on the same page).
- A web site is a collection of web pages, all of which are accessible from the address of a single page. The scope of a site is purely subjective but the contents of a site is often recognized as all the files whose addresses are subordinate to the address of the site itself. One can think of the entire VNI web site as being every address beginning with http://vineyard.net.
- A hit on your site is the request for download of any file contained within your site. If your main index contains 5 gif files, then every time someone requests the page, the server will record 6 download requests (6 hits). One is for the index page itself, and the other five are for each of the images requested in turn by the page.
The usage report is divided into a number of sections. At the top of your report (following a short note from us) is a concise list of general statistics about your site (in this example: http://vineyard.net/vni/)
Date: Sun, 18 Feb 1996 17:19:04 -0500 (EST)
To: vni
Subject: WWW report for /vni
From: "Vineyard.NET"
The following report is generated automatically by our web monitoring
program. If you would like more information, or if you do not
understand something, about this report, please ask your authorized
Vineyard.NET Web consultant. Alternatively, you can send us mail
directly at vni@vineyard.net.
Thank you.
========================================================
HTTP Server General Statistics
Server: http://vineyard.net/ (NCSA)
Local date: Sun Feb 18 17:19:03 PM EST 1996
Covers: 12/01/95 to 02/18/96 (81 days).
All dates are in local time.
Requests last 7 days: 338
New unique hosts last 7 days: 41
Total unique hosts: 1020
Number of HTML requests: 4579
Number of script requests: 0
Number of non-HTML requests: 3034
Number of malformed requests (all dates): 0
Total number of all requests/errors: 7613
Average requests/hour: 4.0, requests/day: 95.2
Running time: 2 minutes, 28 seconds.
Most of the items in this section are fairly apparent. Note that this example is a bit different from what you will usually see because it covers a period of 81 days. Our current reporting mechanism ages the data weekly (1 min past midnight Sunday morning) and we are currently keeping four weeks of old data. So your reports will typically announce that the time covered is 29 days (by the time the report runs, data for a small fraction of the 29th day will have collected).
As described above, a request might be called a hit. And you will note that there are a variety of requests. HTML requests is the count of files containing html data (.html, .htm, .shtml). Non-HTML requests is everything else (.gif, .jpeg, .txt, .asc, etc.). Script requests are the number of scripts that were executed from your site (probably 0). Malformed requests are those which failed for some reason (you want this to be zero).
Hosts refers to the names of the machines from which the requests have come. The number of unique hosts is probably the closest you will get to an accurate answer to the question: "How many individuals have seen my site?" But since different individuals can request your page from the same host machine, this number is not a true indicator.
The next section is a histogram of the total number of requests to your site plotted weekly. Histograms are sometimes more revealing of trends than plain tables of numbers.
HTTP Server Weekly Statistics
Covers: 12/01/95 to 02/18/96 (81 days).
All dates are in local time.
Each mark (#) represents 50 requests.
----------------------------------------------
Week of 11/27/95: 302 : ######
Week of 12/04/95: 609 : ############
Week of 12/11/95: 739 : ###############
Week of 12/18/95: 571 : ###########
Week of 12/25/95: 571 : ###########
Week of 01/01/96: 834 : #################
Week of 01/08/96: 697 : ##############
Week of 01/15/96: 799 : ################
Week of 01/22/96: 703 : ##############
Week of 01/29/96: 761 : ###############
Week of 02/05/96: 776 : ################
Week of 02/12/96: 251 : #####
----------------------------------------------
The next section of the report is a break down of the number of requests per individual file.
HTTP Server Request Statistics
Covers: 12/01/95 to 02/18/96 (81 days).
All dates are in local time.
Sorted by number of requests, 127 unique requests.
# of requests : Last Access (M/D/Y) : Request
----------------------------------------------
1418 : 02/17/96 : /vni/search.html
691 : 02/17/96 : /vni/
636 : 02/17/96 : /vni
592 : 02/17/96 : /vni/mail.html
374 : 02/17/96 : /vni/partners.html
255 : 02/17/96 : /vni/usenet.html
228 : 02/17/96 : /vni/government.html
219 : 02/11/96 : /vni/index.html
210 : 02/17/96 : /vni/rates.html
I lopped off most of this section of the example report, but you can see how this section becomes very useful if you have a complex site. Generally, you can expect that the main index of your site will receive most of the requests, some folks won't find it interesting enough to bother going any further. In this particular case, it seems as though our search area is more popular. Note however, that /vni/, /vni, and /vni/index.html all result in a request for the same file even though they are different addresses; so when you total those up (691 + 636 + 219 = 1546) the truism still holds.
The fourth part of the report lists the same requests according to the domain name from which the request originated. There is a VNI FAQ about the Domain Name Service (DNS) which talks a bit about what the name service is and how it works. To help understand this section of the report it is worth talking a bit about the structure of the Internet's system of domains.
Much like the file system on your hard drive, the domain name structure is laid out like a hierarchical tree. At the top is the root domain '.'. Right below '.' are ones you are more familiar with: .com, .edu, .net, etc. Each of those in turn are subdivided: .net.vineyard, .net.tiac, .com.microsoft, etc. In the national domains (like .us), they tend to take the hierarchy quite a long way: .us.ma.oak-bluffs.ci.
Some readers might by now be wondering why I am writing these names backwards. After all, you are used to writing machine names in e-mail addresses in the reverse order (vni@vineyard.net not vni@.net.vineyard). I should apologize, because this is simply one of those strange computer conventions. The machines don't care what order the domains are written in as long as the names follow the conventions of the immediate context. This means that you will frequently see them written forwards or backwards depending on which was more feasible for the programmer who wrote the program. In fact, it is more easily argued that the convention used for e-mail is the one which is backwards.
HTTP Server Domain Statistics
Covers: 12/01/95 to 02/18/96 (81 days).
All dates are in local time.
2 levels, sorted by number of requests, 29 unique domains.
# reqs : # uniq : Last Access (M/D/Y) : Domain
----------------------------------------------
5036 : 246 : 02/17/96 : .net
4241 : 26 : 02/17/96 : .net.vineyard
1194 : 280 : 02/17/96 : .com
664 : 192 : 02/16/96 : (numerical domains)
471 : 68 : 02/16/96 : .net.tiac
359 : 155 : 02/16/96 : .edu
258 : 40 : 02/12/96 : .com.aol
164 : 1 : 02/05/96 : .com.mckinley
81 : 33 : 02/09/96 : .ca
66 : 27 : 02/11/96 : .org
62 : 1 : 02/07/96 : .com.atext
51 : 19 : 02/04/96 : .com.compuserve
51 : 2 : 01/15/96 : .com.dec
41 : 19 : 02/16/96 : .com.netcom
35 : 6 : 01/12/96 : .ca.direct
34 : 12 : 01/29/96 : .se
34 : 4 : 18/02/95 : .com.voicenet
32 : 8 : 02/01/96 : .gov
28 : 3 : 02/07/96 : .jp.or
28 : 3 : 02/07/96 : .jp
27 : 8 : 02/10/96 : .net.shore
27 : 2 : 01/21/96 : .com.infoseek
This section of the report sorts all of the requests to two levels of the domain names of the host computers requesting files at your site. In the above abbreviated example, note that .com was the third largest requestor of files with 1149. This is the total of all the requests from the .com domain. The .com domain is further subdivided in this report into all the secondary .com's (.com.aol, .com.mckinley, etc.). If you took all the secondary .com's and summed them up, it should equal the single listing for the whole .com domain.
Take a look at .jp. .jp is the national domain for Japan. While it is true that 3 separate hosts requested data from us, they all came from the same secondary domain .jp.or; so the numbers for .jp and .jp.or are identical.
Also of interest is the activity from .com.mckinley. While quite a few separate requests came from that domain, they all came from the same host (the second column is labeled "Unique hosts"). I would guess that someone from McKinley found some items of interest, but all the activity probably came from a single individual.
Explanation of www browser report
The VNI browser report lists all the requests made of your site according to the browser the viewer was using. By far the most popular browser used to look at data on VNI is Netscape's Navigator (identified by the name Mozilla). But Navigator is hardly the only one in use.
In fact, Microsoft erred with their Explorer. Most versions of Microsoft IE prior to 3.0 identified themselves as "Mozilla" so that sites with special Netscape-only pages would work with the Internet Explorer. Well they quickly discovered that in reports like this one, they ended up promoting Netscape's product over their own.
Date: Sun, 18 Aug 1996 15:36:37 -0400 (EDT)
To: vni
Subject: WWW Browser report for /vni
From: "Vineyard.NET Browser Monitoring System"
Status: U
WWW Browser Report:
Number of requests serviced by Vineyard.NET during time period: 347314
Number of requests for /vni: 3487 ( 1.0%)
>>> All numbers that follow are for the /vni directory <<<
Number through proxy gateways: 122 ( 3.5%)
(Note: Requests through proxy gateways may be cached. Thus, each
of these requests may represent many more actual hits.)
BROWSERS BY BRAND:
Mozilla (Netscape Navigator) 3187 ( 91.4%)
Wobot (mckinley.com) 79 ( 2.3%)
Explorer 53 ( 1.5%)
BackRub 43 ( 1.2%)
IWENG (aol.com) 27 ( 0.8%)
NetCruiser 25 ( 0.7%)
MetaCrawler 20 ( 0.6%)
SPRY_Mosaic 9 ( 0.3%)
aolbrowser 7 ( 0.2%)
WB 6 ( 0.2%)
Enhanced_Mosaic 5 ( 0.1%)
LineMode 4 ( 0.1%)
libwww 2 ( 0.1%)
Mosaic 1 ( 0.0%)
When designing a good page, it is important to remember that the exact same page will appear very differently to different browsers. This report can help you decide which browsers (if any) you might consider tailoring your design for.
The second section is an elaboration of the first section. It takes the same data and spreads it out according to the version number of the browser as well as its brand name. There are a LOT of separate versions of Navigator in use...
BROWSER BY VERSION REPORT:
BackRub/0.6 36
BackRub/1.0 7
CCommandLine/4.0D 5
DLL/v1.1d 1
Enhanced_Mosaic/2.00 5
Explorer/4.40.308 53
FM/2.14 1
GNNworks/v1.2.0 2
IWENG/1.2.003 27
InterGO/1.3 2
LineMode/3.0 4
Lynx/2 2
Lynx/2.1 1
Lynx/2.3.7 2
Lynx/2.4 1
MetaCrawler/1.2b 20
Mosaic/2.0 1
Mozilla/0.9 9
Mozilla/1.0N 7
Mozilla/1.1 7
Mozilla/1.12 22
Mozilla/1.12APPLE 1
Mozilla/1.12I 1
Mozilla/1.1N 546
Mozilla/1.1NOV 1
Mozilla/1.1PE 20
Mozilla/1.2 67
Mozilla/1.22 481
Mozilla/1.22ATT 25
Mozilla/1.22KIT 6
Mozilla/1.2N 10
Mozilla/2.0 498
Mozilla/2.01 478
Mozilla/2.01DT 1
Mozilla/2.01E 30
Mozilla/2.01Gold 28
Mozilla/2.01KIT 6
Mozilla/2.02 510
Mozilla/2.02E 4
Mozilla/2.02Gold 49
Mozilla/3.0b3 3
Mozilla/3.0b4 69
Mozilla/3.0b4Gold 21
Mozilla/3.0b5 34
Mozilla/3.0b5Gold 4
Mozilla/3.0b5a 81
Mozilla/3.0b5aGold 114
Mozilla/3.0b6 11
Mozilla/3.0b6Gold 22
Mozilla/3.0b6aGold 1
Mozilla/3.0b7 20
NT/1.1 2
NetCruiser/V2.1 1
NetCruiser/V2.1.1 24
SPRY_Mosaic/v7.36 3
SPRY_Mosaic/v8.32 6
WB/2.1b 5
WB/3.0e 1
Wobot/1.00 79
aolbrowser/1.0 1
aolbrowser/1.1 6
libwww/3.1 2
Explanation of www error report
Your counter doesn't agree with your usage report?
Counter images are generated by Common Gateway Interface (cgi) scripts. The scripts generally perform 2 tasks: a file with a number representing your hit count is incremented, and an image is generated with that number for display on your page.
Such counters are inherently inaccurate. The "count" number is only going to increment when the cgi is actually executed. Since the cgi is tagged on your file as an image, if someone views your page with a browser that cannot view images (or if they simply have the images turned off) the cgi script will not be executed and consequently the hit count will not be incremented.
Frequently, web designers make use of counter routines that reside on machines at great distances away from their host machine. This slows the download of the page, and sometimes causes the counter to skip counts when the counter machine is unreachable.
You must also be careful if you call the same counter cgi from multiple locations in your web pages. It is quite easy to set calls up so that hits on different pages are counted in the same file (this is probably not what you want). For example: If you use our counter, you are expected to pass a file name to the cgi script. The script creates a file by that name and proceeds to use it as the counter file. If you use the same file name as someone else, (using the filename "counter" is a bad idea) then both your calls and the calls by the other user will be incrementing the same counter.