The “correct” answer varies according to the situation; primarily the most desired statistic and the availability of resources to gather and process them: eg:
Server Side
Raw web server logs
All webservers have some facility to log requests. The trouble with them is that it requires a lot of processing to get meaningful data out and, for your example scenario, they won’t record application specific details; like whether or not the request was associated with a registered user.
This option won’t work for what you’re interested in.
File based application logs
The application programmer can apply custom code to the application to record the stuff you’re most interested in to a log file. This is similiar to the webserver log; except that it can be application aware and record things like the member making the request.
The programmers may also need to build scripts which extract from these logs the stuff you’re most interested. This option might be suited to a high traffic site with lots of disk space and sysadmins who know how to ensure the logs get rotated and pruned from the production servers before bad things happen.
Database based application logs
The application programmer can write custom code for the application which records every request in a database. This makes it relatively easy to run reports and makes the data instantly accessible. This solution incurs more system overhead at the time of each request so better suited to lesser traffic sites, or scenarios where the data is highly valued.
Client Side
Javascript postback
This is a consideration on top of the above options. Google analytics does this.
Each page includes some javascript code which tells the client to report back to the webserver that the page was viewed. The data might be recorded in a database, or written to file.
Has an strong advantage of improving accuracy in scenarios where impressions get lost due to heavy caching/proxying between the client and server.
Cookies
Every time a request is received from someone who doesn’t present a cookie then you assume they’re new and record that hit as ‘anonymous’ and return a uniquely identifying cookie after they login. It depends on your application as to how accurate this proves. Some applications don’t lend themselves to caching so it will be quite accurate; others (high traffic) encourage caching which will reduce the accuracy. Obviously it’s not much use till they re-authenticate whenever they switch browsers/location.
What’s most interesting to you?
Then there’s the question of what statistics are important to you. For example, in some situations you’re keen to know:
- how many times a page was viewed, period,
- how many times a page was viewed, by a known user
- how many of your known users have viewed a specific page
Thence you typically want to break it down into periods of time to see trending. Respectively:
- are we getting more views from random people?
- or we getting more views from registered users?
- or has pretty much every one who is going to see the page now seen it?
So back to your question: best practice for “number of imprints when a user goes on a page”?
It depends on your application.
My guess is that you’re best off with a database backed application which records what is most interesting to your application and uses cookies to trace the member’s sessions.
http://stackoverflow.com/questions/3673556/what-is-a-best-practice-method-to-log-visits-per-page-object