Web Site Hit Counts

by Ed Sawicki
Tailored Computers

February 11, 2008

In Web parlance, hits are the number of visitors to your Web site. Counting hits may be important to you for numerous reasons. For example, you can see how well a new marketing strategy or advertising campaign is working. In addition to just getting the number of hits, you can also see where the visitors are located. This is possible by translating the visitor's IP address to a geographic location.

You can count hits in two basic ways. Each has its problems.

Server-side Counting

The simplest and best way to count hits is to do so at the Web server. All Web servers keep a log of all Web pages that are accessed. The log can be used to derive a hit count.

There are three classic problems with measuring hits at the Web server: caching, NAT, and log access.

Caching

Most Web browsers have a cache. If the browser has visited a site recently, it caches the pages. If the browser visits the site again, it will display the pages in the cache instead of fetching them from the Web site again. You probably don't view this as a problem. In fact, you might see it as a benefit by not counting hits from the same computer more than once. This solves the problem of a user hitting Refresh numerous times and incrementing your hit count. However, caches exist in other places.

Many companies install shared caches. A shared cache is one that all computers in an office share. If any computer visits a Web site, the shared cache stores the pages. If any other computer in the office visits the same Web site, the cache supplies the pages. You may have many people in the same office visiting your Web site but your Web server will only see one hit.

NAT

Network Address Translation (NAT) allows a group of computers to access the Internet using a common IP address. If more than one of these computers access your Web site, you'll see hits coming from the same IP address. You might not view this as a problem since the group of computers are typically within the same company. This will most frequently mean that the computers are geographically close to one another. If you're looking at hit reporting to see where your visitors are geographically, this information will still be largely correct.

Web Log Access

You might not be able to count hits because you may not have access to the Web server's log. If you've subscribed to a service that offers you your own Web site and email for a very low price, such as $5 to 20 per month, you don't have your own Web server. You're sharing a Web server with other people. Unless the provider has broken out your Web activity from all others and provided it to you, you won't have access to any logging information.

Client-side/Javascript Counting

The problems of caching, NAT, and access to the log can be solved by moving hit counting to the client-side - to the Web browser. You stick some Javascript into one or more of your Web pages. Each time the page is viewed, the Javascript sends information about the client to a site that counts hits. This can be the same Web server that supplied the content or another server.

The problem with this method is the Javascript. Many people who are concerned about their privacy and security do not want Web sites planting agents on Web pages that report back information that could be personal. Many of the attacks on the Internet today use Javascript as part of the attack. How is someone to know the difference between hit counting and some more nefarious purpose?

Many people configure their Web browsers to disable Javascript from running. Those who are serious about their privacy and security will avoid visiting Web sites that use Javascript.

Conclusion

Pick your poison. Both methods for counting hits do not ensure that all hits will be counted. You'll never have an exact count. My preference is the simpler of the two - measuring hits at the Web server. It's transparent to visitors and doesn't alienate those concerned about their privacy and security.

Back