When it comes to identifying a particular visitor to your site across multiple visits there is really only one way to do it - get them to register with the site and login each time. While this doesn't guarantee that it is the same person each time (since they could share the login details so as to share the account) and it doesn't guarantee that you can match up every visit (since they could potentially create multiple accounts), it is as close as you can reasonably get to identifying the same person across multiple visits.
Such a self registering login is essential for the operation of sites where you need to identify each particular user. This includes such sites as forums, blogs and survey sites where each interaction needs to be matched to the person who made it.
Sites such as financial institutions and paid membership sites can and do go one step further. With these sites either the institution creates the account for you or where self registration is allowed either a payment is required or additional identifying information is required as a part of the setup. The owner of the site either ends up with enough information to specifically identify the person who the account belongs to or they have received a payment for allowing the access (or both).
Whatever level of information or payment is required to obtain a login on a particular site, once you log in the site should be able to keep track of your interactions with the site. This is after all the purpose of providing the login in the first place. People don't log into sites where they don't want their activities on the site tracked.
The simplest way for a site to track you once you have logged in is to use a session. This keeps the information that needs to be passed back and forth between the server and the browser to a minimum as only the session id and the specific information relevant to the current request need to be passed. Everything else can be held on the server and identified when needed using the session id. The session id itself can either be passed using a session cookie (where it gets passed back and forth between the browser and the server without the browser needing to save it to a file) or where cookies are completely disabled it can be passed in the querystring on the end of the URL.
The decision that one of these sites then needs to make is whether to hold the information in session variables on the server where the pages can access them for as long as the session lasts but where the information will be lost as soon as the session ends or whether to store the information more permanently in a file or database on the server. Which of these approaches to take will depend on just how many screens are involved in a particular transaction.
Where each transaction consists of exactly two screens the information obviously needs to be saved. If the system didn't save the information at the end of the transaction then it would be as if the transaction never happened.
Where a transaction consists of around three to five screens it is quite reasonable to keep the information in the session between screens and only save it at the end of the process. The entire transaction should be able to be performed in a couple of minutes and if there were any problems in the process leading to the user having to start over then it isn't going to inconvenience them too much.
As transactions involve more screens then it takes longer for them to be carried out. Surveys and tests are examples of transactions which can take a significant amount of time to get to the end of the transaction. It can be particularly annoying in these cases for someone to almost get to the end of the transaction and then have a problem just before the information gets saved. This leaves the person with nothing to show for a significant amount of their time. They are left with a choice of either forgetting all about that particular process or of starting over again and hoping that it doesn't crash again. In some cases the fact that they started the transaction is recorded and they either can't re-enter the transaction or are treated as having failed the prior attempt. With long transactions like this it is far better if the information gets saved along the way so that the particular transaction can be restarted from close to the point that was reached before the crash. Some surveys make it obvious that they have taken this approach by advising you that you can take a break from the survey at any time and that you can restart from where you are at by re-entering using the same link you used to enter it the first time.
Some particularly long surveys (and some tests) take the approach of breaking the transaction up into several smaller transactions. At several spots through the process the information gets saved before you move on to the next part. This is better than nothing but can be particularly annoying if there is a crash just before one of the sections is marked as complete.
Deciding on just how often to save information can make a big difference to how a given site is perceived - particularly to those who experience crashes when they are interacting with the site.
This article written by Stephen Chapman, Felgall Pty Ltd.