GoFuckYourself.com - Adult Webmaster Forum

GoFuckYourself.com - Adult Webmaster Forum (https://gfy.com/index.php)
-   Fucking Around & Business Discussion (https://gfy.com/forumdisplay.php?f=26)
-   -   Let's discuss cookie/ip hash time-outs for revshare programs (https://gfy.com/showthread.php?t=812830)

ServerGenius 03-05-2008 01:54 PM

fiddy timed out cookies :thumbsup

signupdamnit 03-05-2008 02:00 PM

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. :2 cents:

TheDoc 03-05-2008 02:01 PM

Quote:

Originally Posted by ServerGenius (Post 13875418)
We don't use refferer matching to credit webmasters. We compare cookie
data with the hash data we store serverside....this also includes referrer
info from when the cookie was set.

That said....what u-bob mention did get me thinking....and I'll have to further
investigate to be sure we're not vulnerable for such type of an attack. I can't
say we're not at this point.......so THANKS u-bob for the insight...I hadn't
thought of this myself yet.... :thumbsup

I will get back on this with an answer on how we think to tackle this problem :winkwink:

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.

ServerGenius 03-05-2008 02:03 PM

Quote:

Originally Posted by signupdamnit (Post 13875535)
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. :2 cents:

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! :thumbsup

ServerGenius 03-05-2008 02:13 PM

Quote:

Originally Posted by TheDoc (Post 13875543)
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.

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

Juilan 03-05-2008 02:22 PM

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

BradM 03-05-2008 02:27 PM

The closer should always get the sale.

ServerGenius 03-05-2008 02:27 PM

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 :thumbsup


All times are GMT -7. The time now is 04:10 AM.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc123