Let's discuss cookie/ip hash time-outs for revshare programs

fiddy timed out cookies

I'm thinking something like this is ideal and fair for affiliates:

1. Cookie set for 7 days and also url based tracking.
2. Ref code from url always has priority over cookie.
3. No ref codes overwritten when the surfer comes from your base url. (thus the affiliate with the cookie set gets credit)
4. Last cookie set overrides previous cookies. (some potential for abuse but it is hard to stop.

I DON'T believe a surfer coming from google should automatically result in an affiliate cookie being overwritten. That really sucks for the affiliate. As long as #2 applies if a surfer gets sent directly by an affiliate and they do an impulse purchase, it won't matter if a CJ site is hijacking cookies.

To help prevent the CJ cookie hijacking you could also track that data. If it is found that 99% of an affiliates signups are coming from cookies as opposed to ref based url impulse buys this should be a red flag that they are up to something and should be investigated further.

Just some ideas.

You can help stop it by putting in cookie delays. Like if surferA gets a cookie, and returns say 2-5 minutes later with a new cookie, you keep surferA's cookie.

Outside of that, I don't know if it's possible to stop.

I have seen a TGP, do this on all gallery links. When they are clicked, a new window opens the gallery. However the TGP opens an ajax window behind a div layer, which loads the sponsor that belongs to that gallery link.

Ajax can then tell when the browser window is active again, reloads the sponsor, and the cookie is set back to the TGP owner. (the tgp can set a cookie to track returns too) The loads/clicks are broken up to the sponsor because it's done on each gallery click, which is several different sponsors.

I have also seen the direct iframe/frame load of this, which shows jacked up referral numbers, making it pretty easy to spot.

The goal is to target the returns/type-ins to the sponsor, that's a lot of possible traffic to the correct type of webmaster.

Great post...thanks, very much appreciated.....I'm keeping notes on
a bunch of stuff that gets mentioned in this thread and will use that
to improve our system before we're going live......thanks again on all your
thoughts...it helps us a LOT!

Not sure if I understand correctly....what we do now is upon a hit we set
a cookie and a server side store encoded hash string of the same data as
is set in the cookie added with some additional info that increases being able
to accurately match info.

If any of the cookie data doesn't match up with server side stored info
that belongs to that cookie, the cookie data is being ignored for tracking
and the server side info is being used instead. Plus we get alerted of
possibly something fishy is going on.

Amongst the additional data that we store is the referrer where the hit came
from when the cookie was first set. So in case the cookie gets jacked. It will
get detected as the referrer data won't match up with the stored info. So
both cookie as server stored data are being set/stored at the same time.
And system will only reject cookie if referrers are identical but other data doesn't match...

In case of different referrer both cookie and server stored data will be reset
with new data. In case of another affiliate sending surfer with previously stored other affiliate cookie

It's what the market will bear, the affiliate resellers that is.

The closer should always get the sale.

dammit I have to run out. Thread is bookmarked, I'll defenitely get back to this
thread as it contains a lot of valuable info.....thanks everybody we got some
great input already