Yes. That information tells you what isn't selling and, potentially, why. For example, let's say you tracked this information and noticed that there was a pattern of how people used their shopping cart.

1. Add item A
2. Add item B
3. Visit page 123
4. Remove item B
5. Add item C
6. Check out

I'd be a little curious as to why people always remove item B after visiting page 123, then add item C. It may be that you're not selling item B because there's a bad review on page 123. Or, it may be that page 123 says that item C is a better version of item B. Or, ... I'm sure you can think of other scenarios.

The point is that it isn't sufficient to know what items your customers buy. It is also important to know how they shop. And, a shopping cart gives you unprecedented access into the browsing habits of your customers.

Now, this idea has a few catches to it.

• You need the space to store this information. Not just the shopping cart itself, but what pages the customer views, when, and for how long.
• You need some algorithm(s) that will analyze this information for you.
• You need to actually look at the analysis.

Luckily, there's a pretty simple, if data-intensive, solution, and it may be one you have already partially implemented. Most web applications will track the following:

• every request they receive
• which user/SessionID made the request
• when the request was received
• when the response was sent
• if any errors were generated

This information is very important in terms of analyzing your application's performance. The error stuff is really useful for paging out to a support person in realtime when an error occurs. (I once called my director at 10am on a Sunday to ask him to try a page again after I fixed an error he ran into. He quickly stopped complaining about my "unnecessary development initiatives".)

To that, add the session state as it was at the end of the request and you have all the information you need to analyze the browsing habits of your customers.