Question to CCBILL affiliates

I forwarded this thread to a programmer we've used.

-btw long time ago ccbill default cookie storage was set to 3 days so it would be replaced at 12am (ccbill reporting last minute is 11:59 pm)

We have been set at 150 days until cookie expiration for at least a decade.

First link clicked should get credit.

but for me ccbill id on join form changes every time the link changes. And today the LAST link clicked got credit.
I know that should be the FIRST link. For now rules changed?!

I contacted ccbill. one man from their support said that it should be FIRST link. And confirmed this twice. We made experiment a few days ago. And yes, FIRST link got credit. No matter how many different links we clicked... only the FIRST link's ID appeared on the join form.
Yesterday we made experiment again and the LAST link got credit. Another man in ccbill support said that it works correctly, and the LAST link should get credit.
1) Different information from 2 ccbill support team members.
2) Different link behaviour in 2 days of 1 week.

And the lack of sales for the last times I think caused by this.

Sorry to bother but in my opinion, the last click should get credit because that's the link which a customer decided to join.

There are scammers who embed spammy cookies in browsers.
If the last link doesn't override, oh man, scammer wins!

I have asked this question myself in the past, but never really got a satisfactory answer.

My senario was that if I sent the surfer to a site with my cookie, and then while at the site they saw a link to a review of the site and thought, Hmmm, just check the review before I commit, incase this site is known for screwing with my card info, they click the review link, come back with a cookie from review site, and I dont get credit.

To me, thats a traffic leak from the site itself, but many people assured me it didn't work that way. To this day (having retired) I still dont know for sure - Everyone gives a different answer.

Phuck Yeah!

But that is 6 of one, a half-dozen of the other.

Some days, you could be the first click, other days you could be the most recent click.

I've wondered about the same scenario with (e.g.) Chaturbate. What happens if a Whale buys a new computer, (Or maybe, they get a new tablet or phone.)

And then they create a new account for whatever reason. There is no cookie at all on the new Device. But they know about Chaturbate because they have that other Whale account with my cookie.

I don't earn on the new account from the new Device, because the member didn't click on anything, they manually typed the url from memory.

It should be the last click, otherwise people can steal sales by "cookie stuffing".

If it is the last click it could be stolen/rewrited.
It should be the first click and it shouldn't be rewritable.

Do you know what cookie stuffing is? A scammer affiliate could potentially place 100K cookies per day. For visitors who did not even click any link. With a first-cookie-wins approach, this scammer affiliate will get all the sales, even if the user didn't click anything on the site.

(Of course cookie stuffing illegal, affiliates have been sentenced to jail time in the past -> Clickticker | Affiliate Tracking Platform )

In my opinion, last click should get the sale, as that's the link that convinced the surfer to join.

We totally agree.
Actually this happened recently with Adult Force products.
We offer review-site discounts but a surfer emailed us that the discount price was not applied. It might not "cookie stuffing" but the surfer had to delete cookies manually.
(The surfer joined the site at regular price, which we didn't deserve a sale via our link )

if you test now what result will you get?
last click or not?

This. I always thought it was last click. But if it's not, that explains why you have to be on page 1 to get any CCBill sales.

WHAT THE FUCK... You mean someone is surfing porn, gets CCbill cookie (whatever way, legit or not), then comes to my site, clicks CCbill link on my site, buys from my link, and I get 0?! My cookie does not count because the previous one counts? How is this logical?! And how is this fair?!

I dont know about CCBill but we always operate the first click as thats how the user found out about the site. He might go off and look at other stuff (reviews of the site etc) but its still the first click that gets the credit. You cant refer a user that has already been referred

Are you sure they have not switched to using session cookies as that would explain why only the last click would get the sale ?

New different answer from ccbill

Why don't you try something like this -

1. Use browser secret mode.
2. Click any ccbill affiliate link which offer regular price.
3. Close the tab.
4. Find a ccbill affiliate link which offer discounts. (the same site, of course)
5. Click it and see if the discount is applied.

This could prove that the last link overrode the previous link code, I guess....

In a perfect world yes!.. but unfortunately we don't live in one :D

Cookies are one of the most unreliable ways of tracking affiliate traffic and this thread is proof of it. Guys who run programs should have realized it long time ago ....

Just wondering is CCbill redirects/Cookies are legal these days in Europe. Think GDPR ... just saying, when is the visitor's consent given?

Cookies are the core of any affiliate tracking platform, not just adult programs. Of course good platforms (such as NATS) also have additional layers, which will help identify users who cleared their cookies etc.

There are many issues with cookies, but there isn't really a magic solution which is better.

All that said, I also have concerns about how good CCBILL's affiliate tracking is.

Not sure why you say this, but 90% of my affiliate sales have always come from non-cookie promotions like vanities, white labels, redirects, referrer based tracking, etc. Cookies are obsolete, nobody needs them from my point of view.

NATS isn't a software for affiliates. It never was. It's a script that allows programs to track their sales better. It wasn't designed for affiliates to get credit.

Referrer tracking - it works for IDENTIFYING the visitor, not to keep TRACKING them.
Referrer tracking without cookies = you don't get credited if the user closes the browser, reopens, and enters the domain.

Redirects - Maybe I misunderstand what you mean by this. If you have an URL that redirects to an URL with Affiliate Parameters, that's the same on the sponsor's end as the visitors clicking a link. You'll also lose the sale on browser close / domain type-in unless cookies are utilized.

Vanities - do you mean a special url/domain that redirects you to a final URL? Same as above.

--

Basically all of the three above utilize or substitute Affiliate URL Parameters. These things IDENTIFY the user as yours when they first hit the site.

But what happens if the user leaves before registering, and then types in the domain again? There is no referrer information anymore. Sometimes no URL parameters either. How will the site know that it's your user who came back out of nowhere? The answer is COOKIES. The user's browser saved your affiliate ID, and it silently sends it together with every page load. This is called a Cookie. Cookies KEEP the user as yours. All of the solutions above use cookies to keep tracking the visitors after the first visit. Cookies make sure that if the visitor closes the browser, reopens, types in the domain, you will still get the sale.
The alternatives to cookie tracking: IP tracking (not reliable by itself), Flash cookies (maybe not anymore), permanent URL parameters (won't survive a plain type-in), browser fingerprints (probably the best of all of them, but I'm not sure how many platforms use them - it's not easy stuff, and maybe they don't mind a few affiliate sales being lost...)

Cookies have indeed become less efficient because people care more about their privacy, but they're still the best.



Whitelabels - you are right about this, this solution is pretty much perfect. It's great where it's an option. I wouldn't expect the majority porn sites to start offering whitelabels though. It goes against branding, they want to have their own watermarks on the pics,videos etc.

Man, you have no idea what you are talking about. Referrer tracking verifies the origin of traffic, ie the domain name and there are many ways to store or utilize that information. In most cases you won't need to as there are ways to capture leads with free registrations, etc. It's very effective.

Redirects and vanities just make sense when they are hard coded, no need for parameters to be passed on.

In both cases spammer can't overwrite cookies with stuffing.

Go back to school!

Exactly. You brought it up as an alternative to cookies. It's not. Referrer tracking can only track the origin of the first click.

No, there aren't many ways. Not until the user registers. I have actually looked into how the HTTP protocol works and how you can identify users from the server side. Have you?

Re-read what I wrote: But what happens if the user leaves before registering...
If the user registers, there is of course no need for anything anymore. From a technical point of view, a free join and a credit card joins are the same. Cookies are used to tie the user to your affiliate in the timeframe AFTER the first click and BEFORE the free or paid registration.

They're nice tools I agree, but they aren't any better at tracking than URL parameters. I guarantee you these programs also use cookies for that. You just don't know, because you don't really understand how they work.

Cookie stuffing is just a name. Doesn't really mean that if you take the cookies out of the picture they can't still silently mass-open links. It would work the same even if a program uses some other method to track the users before they register.

If it's "first click wins", a fraud affiliate can still have users auto open his links in mass amounts and block subsequent affiliate clicks from getting the visitor's sale.
If it's "last click wins", someone else can still take the sale from you if the user left the page without signing up.


I agree with you that with Pay Per Lead programs, there is less importance of returning visitors, and therefore cookies too. It's easier to get them to enter their email right away. But we're in a general discussion here, not just Pay Per Lead.

You seem to think cookies are something that were created for affiliate tracking. They were not, they are a core feature of HTTP that pretty much every single website uses for keeping users logged in.

Practically every site on the planet uses cookies ???

Reminds me of a complaint I once made to CCBill. I made a test purchase that wasn't credited to my affiliate account. They said I should clear all my cookies and run the same purchase again. Having too many cookies seems to make affiliate tracking more difficult ... another reason to not rely on them.

I think it was Shap who once posted his experiences with affiliate tracking and he believed around 20% of sales weren't tracked or something along the lines. Too me that is a huge number.

Cookies don't get lost. (You can delete them manually or set the browser to delete them after you quit, but those things don't happen in the middle of a test join session) (Or you can block them altogether, but then websites stop working properly.).
Also, too many cookies cannot cause any problems. Maybe they explained it poorly.

There are two possibilities:
1. CCBILL or the program was using the "first cookie wins" approach, and you already visited the site in that browser (working as intended)
2. CCBILL's system is buggy


I also think that many affiliate sales get lost, but cookies aren't really the culprit. Sometimes it's inevitable because it's impossible to detect that it's the same user that came back, sometimes it's the poor coding of the affiliate program.

To be honest you would loose a lot more than 20% if you DONT use cookies

There really isnt any alternative to cookies when it comes to tracking large amounts of affiliate traffic. Hence why ccbill, google etc use them

They can be persistant (so they work even if the user closes and re-opens the browser), they are pretty secure as they can only be read by the domain that sets them (so much harder to spoof than simple IP tracking or url session variables)

I cant remember where but i read somewhere the other day that google recommends a maximum of 20 cookies per domain although browsers will accept a lot more than that. I think we use 8 or 9 but that includes login authentication, affiliate tracking, search preferences etc

I'm not sure which way they count them, first click or last click to pay. But I have noticed that I seem to get an error after visiting a number of paysites that track with ccbill.

You can test this yourself by going to a site like signbucks, choosing just the ccbill programs, and then clicking on the visit site and clicking thru to ccbill's join page. After hitting 40 or 50 sites that actually run thru ccbill for the cookie tracking, I always get a (http 400 - bad request) error when going to the ccbill join page, I then have to shut down my browser and sometimes I have to clear my cache/cookies to get it back to working

So maybe there can be too many cookies ??? It's a reproducible effect that I can make happen over and over again, so it wasn't just a one time fluke.

Then I got to thinking about how many surfers probably hit that many different sites in a surfing session, and also get a 400 error when trying to go to the join page.

It does appear that the new flexforms do not have this same bug, only the older jpost join pages, so 1 good reason to switch over to flexforms

I stand corrected guys. There is such a thing as too many cookies for one domain, never came across it before.

Browser Cookie Limits

According to this, currently Chrome can have 180 cookies per domain, Firefox 150 per domain, Internet Explorer 50 per domain, Safari no limits.
They recommend staying under 50 per domain and max 4KB per domain.

It's a per domain limit. So NATS programs and most others, have no chance of reaching the limits, as each program uses a different domain.
It could come up sometimes with CCBILL as they place all sites under their own domain.

My guess is your browser is sending a very big request because of all those cookies and CCBILL's server isn't set up to handle a request this big properly.

I don't think those limits above are really threatening for tracking normal users, they are quite high. I'm actually more worried about whether they always place the cookie. With the old join pages, you can check for the "ccbill_referer" field in the join form, which should have your affiliate ID. I found it to be missing many times.
This cannot be checked at all anymore in the new FlexForms join pages.

Has anyone looked into using HTNL5 local storage for storing affiliate codes? It would be harder to use because it's not sent in the header so you'd need Ajax to store and retrieve it, but it's not affected by the user clearing cookies or using private browsing, and there's much more space than there is for cookies.

Sounds like a good idea to me! Even if just as a backup next to cookies. Because of the clearing cookies / private browsing stuff that you mentioned.

The limited cookie space is not a big issue in my opinion. If a big aggregator like CCBILL *knows* that the limit *could* be reached, they should just improve their system. They could stop adding individual cookies for each website visited, and identify the visitor with one Id. One cookie identifies a visitor, eg. ccbillVisitorProfileId.
The rest of the information connected to this visitor can be stored on their server (ie. for 57 CCBILL sites visited, 57 Website-ActiveAffiliateId-Expirations stored.)

But maybe they already do this by now, I have no idea.

Yep you would think that would be the way to go but the problem with that approach is the load on the server end.

If youve got say 100,000 users visiting say 1,000 ccbill affiliate websites then thats already 100 million bits of data you have to store on the back end server. Almost all of which is going to be unused unless the user actually joins a site

Obviosuly with cookies all that workload is placed on the client end

True. I guess they could just do it for the few users who get near to the cookie storage limit of the ccbill domain. Probably 0.1% or 0.01%

Or yeah, use local storage like suggested above!