Cookie Question

[Greenguy]

Ok smart people - help me with this one

Go here & click on bottom banner so that you go to the paysite:
http://messy-fetish.com/hfs/657101/c...ered/index.php
657101 is the webmaster code carried over, correct? Verify this by going to the join page (where you put in all your info) and view the source.

Ok - now go here & do the same thing:
http://messy-fetish.com/hfs/1140963/...ered/index.php
Why is the code on the banner 657101 & not 1140963? Go to the join page & look at the source:
<input type=hidden name=ccbill_referer value='657101'>

So why does the 1st webmaster (657101) get credit, even though the 2nd webmaster (1140963) made the sale?

Is there a way to overwrite cookies that programs are not using?

Is this something we should be concerned with as far as uncredited sales? It's my opinion that the 2nd webmaster should get credit for the sale since the surfer went thru them & bought the membership.

(and I'm not picking on Emma's program - I tried a couple other CCBill programs & had the same results on the join page)

[cd34]

I think this is a somewhat recent change in that a cookie must 'age' before ccbill replaces it.

The benefit is that if you send a surfer to a site, and a toolbar that was voluntarily installed by millions of the surfing public opens a popup window to that sponsor, rather than the new cookie winning, the old cookie wins. I don't know what the overwrite timeout is for ccbill, but, I would think this is a relatively good thing as a sale would still be gained by the first person referring if the 2nd referral came minutes later.

The flip side to this is -- ccbill has always been vulnerable to another way of doing this that certain TGP gallery submitters have employed which is almost invisible to the surfer.

Now you know why there are so many threads saying 'spam me with ccbill sponsors'... because they intend to overwrite those cookies with their voluntarily installed toolbar.

I would suspect that ccbill has put that protection in place to help the webmaster rather than to harm them. The second guy sort of gets lost in the collateral damage which is regrettable, but, it does end the effectiveness of certain toolbars.

[Greenguy]

Now that's really fucking interesting - and quite the conundrum if that's the case.

I'd love to hear from CCBill on this.

[emmanuelle]

I see other upsides:

Situation 1- The program owner is kept honest. I cannot overwrite your cookie with one of my own. The integrity of the program cannot be compromised in this manner, which is good for all programs using Ccbill's affiliate system.

Situation 2- Your links plant a seed in a surfer's mind, but he loses the site. Eventually he stumbles across it again and joins- you still get the credit.
The counter argument of course is that the 2nd person sent the sale, but who really was responsible?

I think you have to take the good with the bad sometimes....

[Cleo]

Personally I think this sounds like something that has been needed.

[Greenguy]

OK - how about this scenario:

Assuming you clicked on the 1st link up top, go to this HFS:
http://www.big-tits-gallery.com/hfs/...gela/index.php
This is a completely different niche, but the 657101 account is on the banners.

Let's say that you like this site & decide to join. Should 657101 really get credit for this sale?

[Cleo]

At least someone has to actually click on the banner to write the cookie instead of a cookie being written by a dirty paysite tour.

[cd34]

Originally Posted by Greenie

Assuming you clicked on the 1st link up top, go to this HFS:
http://www.big-tits-gallery.com/hfs/...gela/index.php
This is a completely different niche, but the 657101 account is on the banners.

That isn't the result I get. It follows through properly for me with 1140963 getting credit.

There have been sponsors that had something like:

ErrorDocument 404 http://refer.ccbill.com?blahblahblah

And then didn't have a favicon.ico. Surfer bookmarks (or surfs with Firefox/Mozilla) which grabs the favicon.ico, 404 is generated, redirected to the ccbill code which sets the sponsor's code. Likewise, any missing image in the tour, etc would do the same.

[Greenguy]

Originally Posted by cd34

That isn't the result I get. It follows through properly for me with 1140963 getting credit...

Even after a reboot, by going to the HFS with 1140963 in the URL, I still get <input type=hidden name=ccbill_referer value='657101'> when I go to the join page.

I didn't post my 2nd example yesterday, but it was done via some AFDollars HFS (99.44% sure that there is no cookie set until you get to the tour)

I tested one with my code:
http://amateur-facials.com/freesites/38/?581222
and then a different HFS with a different code:
http://amateur-facials.com/freesites/37/?123123
581222 was on the join page.

This morning I did the "different paysite" test with them:
http://www.localfoxes.com/freesites/without_you/?123123
and again, 581222 was on the join page.

Now the links to the paysites on their HFS are standard/default CCBill link codes:
http://refer.ccbill.com/cgi-bin/clic...ocalfoxes.com/

So it's not just a "cookie on the HFS" problem.

?????????????????

[Useless]

Did you clear your cache and cookies before this test? A reboot won't clear cookies. If you review other peoples' work and click on their sponsor links, you're getting cookie'd with their aff code. So you may already be cookie'd for that paysite.

[Greenguy]

Useless - I know I'm already cookied for the paysite - that's my point!

With both these examples, if the surfer went to a paysite in the progrma thru me 1st & then to another paysite in the program thru your code after that, I'd get credit for the sale - and that's not fair.

[Useless]

Originally Posted by Greenie

Useless - I know I'm already cookied for the paysite - that's my point!

I was worried about you for a moment there.

Originally Posted by Greenie

With both these examples, if the surfer went to a paysite in the progrma thru me 1st & then to another paysite in the program thru your code after that, I'd get credit for the sale - and that's not fair.

I feel much the same way, but I also wouldn't want to see cookies set for quick expiry either, which is probably the only way to alter this scenario.

[Greenguy]

Originally Posted by Useless Warrior

...I feel much the same way, but I also wouldn't want to see cookies set for quick expiry either, which is probably the only way to alter this scenario.

I'm thinking that there has to be a way to overwrite the cookie OR in the case of 2 different paysites, set a cookie for each.

[Toby]

Some months ago, well before Zango hit the news, I emailed and specifically asked a CCBill about affiliate code cookies being overwritten. At that time I was told that the affiliate code cookie would be overwritten by the most recent referral link.

Jump forward to today, and I'm getting the same results as Greenie. Obviously something has changed at CCBill.

[cd34]

on the last example, you are correct. CCBill appears to maintain 1 cookie per Sponsor program/Master account.

The HFS maintains what appears to be the proper code, but, when you hit the refer.ccbill link, they only set the cookie on the first visit. I would imagine this is to prevent cookie stuffing and ccbill should be able to give details about this behavior.

[Greenguy]

Originally Posted by cd34

...The benefit is that if you send a surfer to a site, and a toolbar that was voluntarily installed by millions of the surfing public opens a popup window to that sponsor, rather than the new cookie winning, the old cookie wins. I don't know what the overwrite timeout is for ccbill, but, I would think this is a relatively good thing as a sale would still be gained by the first person referring if the 2nd referral came minutes later...

I doubt very heavily that the numbers I'd like to see even exist, but it'd be interesting to see what the numbers are as far as Zango (or any toolbar) users compared to the number of cookies that used to be overwritten.

Either way, someone's getting fucked out of sales & that's bad.

Maybe it's time that CCBill (finally) redesigned their referral system and got rid of the cookies?

[cd34]

any way you track the sales, you have a fundamental problem:

Webmaster A refers surfer, cookie (or IP tracking or whatever gets set)
Webmaster B refers surfer, cookie (or IP tracking or whatever gets set)

The change that you are noticing appears to be whether Webmaster B overwrites Webmaster A's cookie.

On one hand, Webmaster A could be legit, Webmaster B could be a user-installed toolbar, in which case Webmaster A should get credit

On the other hand Webmaster A could be legit, Webmaster B could be legit, and Webmaster B should get credit.

The advantage that you used to have with smaller programs is that the cookie would get set by ccbill with some expiration time -- and a typein to the main domain wouldn't reset that cookie. Most sponsors nowdays reset the cookie at the time of the typein. If a surfer bookmarks the webmaster tour (where the url doesn't have the webmasters ID), the ccbill cookie which has an expiration date could credit the webmaster if it hasn't expired.

Which of those two scenarios do you want? When you have two clicks in relatively rapid succession, who should win?

And remember, you're not just dealing with toolbars.... there are other ways to stuff cookies with ccbill that have the same effect -- without needing a toolbar or any nasty coding and a relatively complex way to determine if that particular stuffing took place.

[Toby]

Originally Posted by cd34

On one hand, Webmaster A could be legit, Webmaster B could be a user-installed toolbar, in which case Webmaster A should get credit

On the other hand Webmaster A could be legit, Webmaster B could be legit, and Webmaster B should get credit.

OR...

Webmaster A is a less than honorable TGP or LL owner using unscrupulous means to pre-set cookies for many sponsors, and Webmaster B is a legit submitter sending traffic to one or more of those same sponsors.

Bottom line, tracking cookies are way too easy to abuse.

[cd34]

Originally Posted by Toby

Bottom line, tracking cookies are way too easy to abuse.

Its not just cookies -- any tracking method you use will have the same potential for abuse.

cookies, IPs, browser hash, some combination of the above. Anything that you use to try to establish a surfer's identity can easily be stuffed to create that 'last seen from webmaster B'.

Long long ago, tours had the webmasters url in a query string, no cookie was set, and you didn't get a chance at a signup from someone that bookmarked a tour. In that case, the console that pops up over the tour that you sent the traffic to would get the credit.

From a tracking perspective, this scenario will always be a conundrum.

[tickler]

Originally Posted by cd34

on the last example, you are correct. CCBill appears to maintain 1 cookie per Sponsor program/Master account.

And we know that a lot of ccBill sponsors only use Master accounts with destination URLs anyways, and not individual sub-accounts per paysite.

Really makes it a pain trying to figure out which sites are converting.

[Greenguy]

Originally Posted by tickler

And we know that a lot of ccBill sponsors only use Master accounts with destination URLs anyways, and not individual sub-accounts per paysite.

Really makes it a pain trying to figure out which sites are converting.

That's another pet-peeve of mine as well - I wish these programs would learn how to set things up properly.

[emmanuelle]

Is this thread sponsored by a collective of nats fans?

[Useless]

Originally Posted by emmanuelle

Is this thread sponsored by a collective of nats fans?

We'd like to be able to overwrite cookies, not set them for a 5 second life span.

[Greenguy]

Originally Posted by emmanuelle

Is this thread sponsored by a collective of nats fans?

Actually, what tickler brought up isn't a bash on CCBill - they tools/options are there to set things up properly. It's more of a bash at the uneducated program owners that throw multiple sites on the same sub-account.

[tickler]

Originally Posted by Greenie

Actually, what tickler brought up isn't a bash on CCBill - they tools/options are there to set things up properly. It's more of a bash at the uneducated program owners that throw multiple sites on the same sub-account.

emmanuelle:
Just to clarify what Geenie said, and some thoughts for the sponsors that don't use the sub-accounts.

If I see too low conversions, I will probably end up dropping the sponsor!

If there is no way for me to tell that there might be a prime site in their mix, that is converting at 1:50, when all I see as an affiliate is something like a 1:5000 conversion ratio.

Dropping the sponsor ends up being money that I could be missing out on making, and also money that the sponsor ends up not making because I(probably many others) stop sending traffic.