I only know of two real ways to do this.

1) Embedding the session id in the URL:

You can implement this one in two ways, or some combination thereof. The first way is manual, where you assign a template variable to contain the id and manually include it in every URL. This generally sucks from a designer's perspective. The second way is have something that automatically adds it; depending on the languages and technologies you are using, it's usually fairly easy to do, but some things can prevent it.

This technique has several flaws, the most major of which is security. People, in general, don't think of URLs as something to be security concious of and will probably freely share them. If their session id is stored in the url and someone else uses it, they'll probably have access to what ever sensitive data was stored in the session. You can try to prevent this by adding checks based on originating ips of the sessions but that runs the risk of screwing, or at least annoying, people behind a rotating proxy, for example, AOL.

2) The second solution is to just use cookies. They're simple, incredibly easy to use, and already handle all of the above security concerns. The only down side is that occasionally they won't work, but really, the percentage of people who have actually disabled cookies is so small it's probably not worrying about. In general, if they want to use your service and cannot do it with out cookies, they'll turn cookies on.

To summarize, if you just want to track each user on your site much like amazon does, you should probably use session ids in the url. It doesn't need to be secure but does need to work for most everyone. If you have secure data you're protecting via the session id, you probably want cookies, much like amazon does when you actually log in to your account.