CCBill's affiliate tracking cookie needs major tweaking
 

I've been working with ccbill affiliate progs for a long time and my experience shows there is a real big problem with the cookie mechanism for crediting affiliates under the following condition:

"A surfer who surfs porn alot has a lot of ccbill cookies on their machine from various sites. Since there is some sort of upper limit on cookies (my assumption) I've seen cases where you can go through the referer tracking code a million times and it will not store the new ID if there are already too many cookies in the user's system. For some reason, IE doesn't seem to expire these fast enough (especially if someone is really surfing lots of porn through promo sites)."

Not sure if there is a solution, but this is the 1 case where I'm sure some affiliate can lose money.

Yes, but you can earn some extra $$$ on it too

ooohhhh nooooooooooooooooooooo

that's what I've been saying for years!

never promote a ccbill program unless you get 70%+ payouts.. you're loosing 30% of your traffic and probably also the same amount of sales... which is all to the program owners advantage as he gets credit for the sale!

This is ok with ARS as the code covers all the sites but this is not true with ccBill so it is way less likely you would make extra cash on this.

I'm not 100% sure this isn't bullshit, at least the 30% part.

I help to run a ccBill program, which I also promote as an affiliate.

I don't really see that happening, and I have admin access to both stats panels. Unless you have the same level of access to ccBill admin panels, please advise as to where this information comes from or if it's just speculation on.

The reason I say this, is because the front end of my sites send to my ref code, and the affiliates have a seperate page to send to with no traffic leaks.

I don't see sales for my sites without anyone to pay the sale to. It's either my sale, or a webmaster sale. Not a program sale.

:2 cents:

http://wp.netscape.com/newsref/std/cookie_spec.html

There are limitations on the number of cookies that a client can store at any one time. This is a specification of the minimum number of cookies that a client should be prepared to receive and store.

* 300 total cookies
* 4 kilobytes per cookie, where the name and the OPAQUE_STRING combine to form the 4 kilobyte limit.
* 20 cookies per server or domain. (note that completely specified hosts and domains are treated as separate entities and have a 20 cookie limitation for each, not combined)

I could see it could happen, but I think 30% is excessive speculation.

Yes, so basically if a server has already 20 ccbill cookies, the 21st cookie will fail to register. So unless they are expired in a timely fashion, you won't get credit for surfers who have visited lots of sites in a short period of time...

ok, I just tested how the CCBill cookies work. They ONLY set 2 cookies which it stores the LAST used link code info in.

So the 20 cookies limit is not relevant since CCBill only use 2 cookies to store the info in.

Thank you :-)

pretty sure the newest cookie overwrites the oldest cookie when the limit for a domain has been reached anyway

My bad. The data in the cookies stays the same, no matter what link code you use. So it's probably just some type of session name, so all data is stored on CCBill's end.

I am not 100% certain but pretty sure things work this way -
You give the surfer a ccbill cookie - Surfer visits said site and joins - Your cookie scores the points -
Should that surfer go to another ccbill site where a site cookie is not lodged, you score a bonus sale - Should the surfer be carrying a cookie from another referrer when he visits this other site, the other referrer gets the sale

The fact that so many ccbill cookies are lodged onto any surfers machine is fantastic testament to the amaount of ccbill programmes that set cookies up for life time -

Which means...?

Thousands of ccbill programmes ARE NOT shaving.

On the affiliate programs I have worked on their was never any client side cookies. The webmaster's ID would be retrieved from the URL and it would be passed server side between all webpages visited by the surfer, so cookies were never used at all, each click passed along the relevant information.

Personally I hate cookies with a vengenace and I try to avoid them in any and all contexts.

I don't understand.

How can this be true if there are only two cookies that are on the machine at any point in time?

Is it two cookies per CCBill site?

There must then be another explanation why in IE 6, sometimes when I have 20 ccbill cookies, every click tracking code thereafter does not set the cookie for that site I'm visiting.

I believe the cookies are set per partner_ID, so if you visit 20 DIFFERENT ccbill-processed adult sites, then you will have 20 cookies (please let me know if I am wrong on this).

From what I can see on the signup page, the referer field is ONLY set if a cookie is on the client's system - therefore CCbill does NOT as far as I know keep records on the server-side.

Either way, this phenomenon is a source of lost sales (for affiliates) but of course makes sponsors happy. My opinion it needs to be corrected, possibly getting a cookie count and using a second server, etc...

Here's an example where this can be very common: a review site. A surfer can easily accumulate 20 cookies from 20 different sponsors within the 3 day period it takes to expire it - end result - no credit for signups.

A cookie's expiration date is set is down to the conf of the programme - from 1 day to life (Till the surfer clears his cache)

How can this be true if there are only two cookies that are on the machine at any point in time?

Each cookie has different info - So there can be many ccbill cookies on the same box - Likewise with other trackers such as sextracker etc.

Either way, this phenomenon is a source of lost sales (for affiliates) but of course makes sponsors happy. My opinion it needs to be corrected, possibly getting a cookie count and using a second server, etc...

I think it probably works both ways - But do agree, a better method is needing to ensure an affilate collects only his own sales.

Id doesn't really matter HOW many cookies a surfers browser can hold.. that be 1 or 300.. the issue is COOKIES...

A real good chunk of surfers have cookies turned off... 30% is a pretty safe asumption... so 30% of surfers sent to a ccbill program relying only on ccbills own cookie tracking are never tracked upon signup.

Want to contradict me? Wannt share some stats? Show us all your OWN sales NOT sent from an affiliate WITH referring urls from where the surfer originated and I am pretty certain you will see that you, as a program owner, have been getting quite a few signups that were supposed to have been affilate sales.

Not saying YOU as a program owner are doing anything wrong, the error is on ccbills end. But, you could be proactive and pay out 70%+ to counter the known error... I would never ever ever ever promote any pure ccbill proggy and be satisfied with less than 70%.. in their terms, 70% equals roughly 50% in real life.

I've used ccbill plenty, even promoted ccbill programs, and know plenty of webmaster program owners using them... so ;)

C'mon prove me wrong :)

I certainly agree many surfers have cookies disabled - But where do you get your figures from?
My own opinion - Less than thirty - Much less - However, yes, we programme owners do benefit this way.
I would not deny that.

To counteract that, we ssi all hits across our xits, 404's right down to our dump site, so affilates have better chances to sale somewhere on our sites -
We pay 65% or 30$ joins - Not one cent higher because it would be foolhardy to commit an unrealistic figur to rebilling that may never happen ($30 joins I am talking of)
65% will also remain the same - By the time you look at incurred costs such as hosted galleries, I am certain you would NOT even slightly dream of paying 70% yourself should you be running a programme)!!!

65% is not a bad figure either.. you're on of those that run a good ccbill show :)

My criticism is aimed at those trying to lure webmasters in with a 50% ccbill payout - ok, numbers fluctuate and results vary, but 30% of surfers having their cookies disabled or are blocking 3rd partie cookies and yadda yadda is not a far off number.

30% of surfers with cookies disabled is high, although I will do some research.

The reason is that I extrapolate indirectly from 99% of users using IE6 suggests from my stats that most are probably people using the default IE6/Windows combo. Cookies are not generally disabled. Usually more sophisticated users disable them so that would just be 1% of surfers. I would estimate it's probably no more than 15%.

CCBill sets 2 cookies, no matter how many CCBill link codes you go to:

0CCC_CTP_NFO_PA
0CCC_CTP_NFO_CA

They have an expiration time of 5 days.

The CCBill cookie is not a 3rd party cookie.

I never said it was ;)


At any rate, there are multiple plugins surfers have installed that disable cookies for them, besides IE. Firewall software, Spyware tools and what have you...

I know that 30% is not a far off number so research all you want, won't make ccbill tracking any better, will it?

i read somewhere that 30% of experienced surfers (1h surf per day) has cookies turned off
who gets those sales ?...

Word !


I have separate pages for my affiliates with no traffic leaks ! :)

Yes this is true, however, cookies have name-value pairs. So the two cookies can store ONLY up to 20 different values for each cookie so the problem I brought up still stands - it is an issue ccbill needs to fix or figure out a solution for.

Have you even bothered to look at what their cookies look like?

What do you mean with this?

You can store what ever yout want in the cookies as long as the value is less to 4k. So you can store 4096 characters in it. But that's not even an issue here.

Lets start with the cookie "0CCC_CTP_NFO_PA".

After I hit the first CCBill link code, the value is "CLICKS2xxOBGVQpcB**".
After I hit a different CCBill link code, the value is "CLICKS2xxOBGVQpcB**"
Same thing when I hit the 3rd, 4th and 5th link code.



Lets look at the second cookie "0CCC_CTP_NFO_CA".

After I hit the first CCBill link code, the value is "CLICKS2zxKAElsicJSQ7FnmZrVe9dMa09lelGk9RoimO0vUqU VjGWUAQta1hHokuE9t".
After I hit a different CCBill link code, the value is "CLICKS2zxKAElsicJSQ7FnmZrVe9dMa09lelGk9RoimO0vUqU VjGWUAQta1hHokuE9t"
Same thing when I hit the 3rd, 4th and 5th link code.