RE: Demographics

>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Subject: 	Re: Demographics
>
>Paul Leach:
>[...]
>>It is alleged that some advertisers want to pay content providers, not
>>by the "hit", but by the "nibble" -- the number of people who actually
>>click on the ad to get more info.
>[...]
>>What I'm looking for are comments on the privacy concerns with such an
>>approach.
>
>I don't think that a two-way referer field can solve the nibble count
>problem.  For it to work, two-way referer would have to be enabled by
>default, but for privacy reasons, it would have to be disabled by
>default.

I think you've got this wrong, but it doesn't matter -- I think your
proposal is cleaner. (Both proposal are just ways that the site declares
that it doesn't care if the referer info is disclosed to the target.)

>  My proposal is to add no extra mechanism, and to rely on
>schemes that embed the referrer in the URI like this:
> 
>    http://www.blah.com/index?from=site1
> 
>By having the above URI point to a CGI script which returns a 302
>redirect to the real home page http://www.blah.com/ , this scheme can
>be made to act in a cache-friendly way, especially if the 302 can be
>cached by proxies which report hits.

If the 302 is cached, then the referrer info will be lost. Unless you
mean that the cache reports hits on cached 302 responses? I hadn't
thought about this, but I guess that it would probably fall right out...
it might be important to be clear that hitcounts should be reported in
this case, though.

For ads that are placed on a lot of sites, this would result in a lot of
cached 302s for the same underlying page.

However, you've made me realize that caches completely break my original
scheme....

If fact, "Referer" makes it very hard for a cache to be semantically
transparent: if a cache was trying to be semantically transparent, the
presence of "Referer" on a GET request should cause a cache to do a
conditional GET on the Request-URI.  The only way to avoid this would be
to remember each different value of Referer: had been seen and to report
hit counts on each of them (somehow). Not only is this more complex than
using cached 302s, it also would result in exactly as many remembered
Referers as cached 302s in your proposal.
> 
>In my opinion, HTTP already supports nibble counting in an adequate way.
>There is no need to add a new mechanism.  The gains which could be had
>by adding a new --working-- mechanism would not outweigh the cost of the
>mechanism and its introduction.

I agree. I do think it needs to be explained, because it isn't obvious
(wasn't to me, anyway, so I'll put such an explanation in the draft,
with credit to you (if you don't mind).

Paul

Received on Wednesday, 10 July 1996 11:23:56 UTC