hug <contact_info@sig_line.clickit> wrote in
news:4slg12hs0l9r96gt7dho2jnqdjobid0b9j@4ax.com:
I'd like to recommend the following:
http://www.karlcore.com/article/id/26/

As the article states, server logs are an inappropriate data source and you
can't get any sort of reliable usability data from them. If you want real
usability data, you need to actually watch users.




--
Karl Groves
http://karlcore.com
http://chevelle.karlcore.com

Accessibility Discussion List: http://smallerurl.com/?id=6p764du

And lo, hug didst speak in alt.www.webmaster:
Not really. That is what Cookies are for, storing identifiable user
information. However, there are limits to their abilities.

Not at all. If I have a cookie from your site, then go back, at least
with Opera the page will be reloaded from memory and a request (plus
cookie) will NOT be sent to your server. Therefore, I am now not on any
page your stats-analysis algorithms can track.

Godaddy, for example, is troublesome in this regard as for certain
operations it expects you to take a certain path. If I decide to go back,
the shopping cart path is broken and I need to start over. You definitely
don't want to do this.

Sure, but I hope you aren't storing the contents of the shopping cart in
the cookie itself, these should be stored in a database and retrieved
based on a "unique passphrase" contained in the cookie.

Then the simplest method would be to have a separate column of the
shopping cart database record every REQUEST_URI, in order, to which the
client sends the cookie. It won't be 100% accurate, but there are your
shopping cart paths, all ready for you to parse using another script.

I believe the point I (and others in this thread) are trying to make is
that you can never *attain* 100% accuracy in user tracking with *any*
tools because the very nature of HTML makes it stateless.

Just do the best you can, and forget about perfection. At least in this
area

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#search - Orca Search: Full-featured
spider and site-search engine

hug wrote:

No one has mentioned this yet... The IP changes come from AOLs usage of HTTP
proxies. At least several years ago it was common knowledge (at least I
knew it...) that all AOL users are forced to use a small number of HTTP
proxies. Your observation suggests that this is still the case today. The
IP changes are probably caused by a load-balancing system that routes every
request to a random proxy machine.

And it is not just AOL that does such a thing. There are many office/company
networks that require the usage of a HTTP proxy for outgoing connections.
And once a single machine gets too small to handle the traffic, multiple
machines with different IPs and some form of load-balancing is used
(routing each request to a random proxy is easy to implement and
sufficiently good).

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

Karl Groves <karl@NOSPAMkarlcore.com> wrote:

Read the article a while back. Yes, server logs are pretty worthless
for usability studies. But you don't actually have to be in the
user's physical presence to watch him, watching remotely via some
instrumentation will get the job done without seeing him pick his nose
while he types. I've posted what the data I get looks like, but I
guess you didn't read it.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

GreyWyvern <spam@greywyvern.com> wrote:

I read it. I disagree with about half of it. However you are certain
that you know what I am doing so discussing it is pointless. Thanks
for trying.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

On Wed, 15 Mar 2006 11:05:36 -0700, hug
<contact_info@sig_line.clickit> posted something that included:

Cookies are generally untrustworthy, but AOL is especially
untrustworthy when it comes to cookies.

If you are going to use cookies, you will want to disable the AOL
cache, or they won't work reliably. This is more difficult that it
might seem, since AOL has their own idea about how different headers
should be interpreted.

They've got a site explaining the AOL way of doing things.
http://webmaster.info.aol.com




--
AmishHosting.com

And lo, hug didst speak in alt.www.webmaster:

Did you really? Did you read the part where I was trying to help you with
a possible way to (sort of) track your customers using a cookie you have
set? All I said was that it wouldn't be totally accurate, but it may be
enough for what you need.

Just trying to be helpful.

Grey

--
The technical axiom that nothing is impossible sinisterly implies the
pitfall corollary that nothing is ridiculous.
- http://www.greywyvern.com/orca#search - Orca Search: Full-featured
spider and site-search engine

GreyWyvern <spam@greywyvern.com> wrote:

Yes Grey, I read it, and I really do appreciate your trying to help.
I am not using *any* cookies, or *any* javascript. *Everything* is on
the server. There really is only one problem that I am looking for a
solution to: if a user sends a link to one of the pages he receives to
someone else, there currently is no way for me to tell whether a GET
for that page is the original-guy or the pal-guy except for the
ip-address, which I assumed to remain consistent throughout the
session. <slap_forehead> I know that I can do it with a cookie, and I
know that I *do* *not* *want* to use a *cookie*. Currently there are
no cookies, and no client-side scripting in use, and I want to retain
that situation; it *majorly* pisses me off when the settings in some
guy's browser make my code look broken. If you have a suggestion that
might work *strictly* server-side, I'd love to hear it. If not I'll
keep thinking about it. <shrug>

--
http://www.ren-prod-inc.com/hug_soft...action=contact

Paul Ding <lancastir@paulding.net> wrote:

Yep, like not being enabled on somebody's browser for starters, I
totally agree.

Why does that *not* come as a surprise? <g>

Freakin' dumbass AOL, it figures.

I absolutely want to continue avoiding all use of cookies if possible.
I'll check that link, maybe it will contain some hidden clue. Thanks
much.

--
http://www.ren-prod-inc.com/hug_soft...action=contact

Paul Ding <lancastir@paulding.net> wrote:

Thanks again for that url, Paul -- very useful.

Karl, if you're reading this, apparently there is an HTTP header
called "Cache-Control" that you may find interesting based on some of
your previous comments; Grey may also find it interesting:

"Cache-Control: no-store This object may not be stored in
any cache, even the requestor's browser cache."

--
http://www.ren-prod-inc.com/hug_soft...action=contact