Cookies are (according to M$) considered 3rd party if they are set from a different domain
(in a frame, pixel, ...) then the "main" domain in browser window.
A quote from http://support.microsoft.com/default...;en-us;Q299331
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>When you use services from Web site "A" by using a frameset (or portal) on Web site "B", cookies that Web site A tries to set may be blocked at the default medium privacy level. In the preceding example, Web site A is in the third-party context. The medium privacy setting blocks third-party cookies that do not have a compact policy (a condensed computer
-readable privacy statement) or third-party cookies that have a compact policy that specifies that personally identifiable information is used without your implicit consent.<HR></BLOCKQUOTE>
I've read quite some articels on this issue when IE6 came out, but can't find them now...
Basically it comes down to this: Cookies set with a pixel from a different domain (or in a frame with src set to a different domain etc.) ARE considered 3rd party and you need a compact private policy in order for IE6 to accept them (I was wrong before, YOU (your server) need it, not the affiliates ... what was I thinking
). So if your affiliates put your pixel on their site the cookie set is considered a 3rd party one.
If your server returns a good CPP string I guess you could make it work, but you wouldn't be able to track which links (banners) are performing well and which not. You also wouldn't be able to count clicks and I don't think affiliates would like that (if you would count clicks you would use a redirection script - this script could also set a cookie so why bother with the pixel then?).
I think the standard way of doing it is still the easiest way. If there was an easier way I am sure networks would use it.
YOURsoft affiliate software
Join YOURsoft "affiliate program for affiliate software