Cookie Question
 

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:


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)

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.

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

I'd love to hear from CCBill on this.

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....

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

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?

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.

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:

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.

Even after a reboot, by going to the HFS with 1140963 in the URL, I still get 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.

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

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.

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.

I was worried about you for a moment there. ;)
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.

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.

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.

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?

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.

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.

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.

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.

Is this thread sponsored by a collective of nats fans?
|couch|

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

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.

I think this situation needs a disclaimer. It presumes that poor ratios are the sponsor's fault, and does not take into account affiliates who
[i] don't understand what they are promoting [ii] list sites in unproductive categories [iii] throw a bunch of gagging midget tgp traffic at a foot fetish site.

If we could eliminate the politics, posturing and chest thumping, I think that we could all put those energies to better use- learning as much as we can about our products and our customers.

I actually thought about this as I was planning the version 2 of porngreen. I came up with the following, but it's probably not for programs who wish to use refer.ccbill.com links or have 0 knowledge on coding and whatnot..

I have something like
http://www.mypaysites.com/tour1/inde...ur_ccbill_code

Then on the tour, I carry that code in the links until the joinpage where I send the ccbill_referer (ref in the url) to the ccbill's page. Now, the obvious problem with this is that no cookie is set, so webmasters would be screwed over for returning customers. However, I also have an iframe on the indexpage of the tour that is linked to a blank page through refer.ccbill.com with the affiliates link. So that sets the cookie.

On the joinpage I have php code that checks for the presence of 'ref' value in the url, so if there's nobody who sent the visitor it uses the cookie.

What this does, and yes I've tested it, is that affiliates can continue to check their clicks through affiliateadmin as well as my own stats, they get credit for returning customers and the person who sent the last visitor gets credit for the sale.

Not sure I made any sense, but this is the way to do it so the last referer gets credit IF there is a referer, otherwise the webmaster whose link set the cookie gets credit. It's a bit 'hard' way of doing it, but it was pretty much the only way I could figure out how to do that. As far as I know my plan is rather foolproof. Prove me wrong and I'll fix it. :)

I personally chose to have all my sites under one master account (merged), just because I don't want people having to sign-up for 14 sites when they want to promote all my sites. As an affiliate, I also prefer that. If a sponsor has 5 sites, and I'd like to promote 3 of them, it's annoying to sign up 3 times. I'd rather sign-up just once and figure out my own way to track traffic rather than sign-up multiple times..but I'm retarded like that.

Also, if someone signs up to my affiliate program because he/she wants to promote site A, but has sites B-M as options as well, without having to re-signup.. I, as a sponsor, am more likely to see some odd hits to those sites as well. Also it is less confusing for the 'non-experienced' webmaster. If they choose to use my FHG/HFS import tool and it has galleries they haven't signed up for, I get immediately called a cheater and whatnot. Even if it's the affiliates fault for trying to import galleries he hasn't signed up for, then he comes to boards and asks why he doesn't get credit for this and that. Easier to have 1 affiliate id which gives credit for everything. No messing around.

Also, I have asked CCBill, and you can't (or atleast couldn't) track individual sub-account traffic if the accounts were merged. This was one of the reasons I chose to have my own stats coded so affiliates could track individual site performance, and still just sign-up once...My info may be outdated though.

Not really. You should be looking at individual sites in the program & not the entire program when it comes to what you're going to promote. If you have no idea what the individual sites are doing & the ratios for the entire program are bad (for whatever reason - and the reason is not important in this discussion) then you will probably not promote the program.

But, if you can look at the individual site stats, you might see that some are converting really bad & some are converting really good. Then you just drop the bad ones & continue to promote the good ones.

By not having multiple sites on sub-accounts in CCBill, the webmaster has no idea what's making sales & what's not, so in all likelihood, they will just drop the program.

I sorta understood it :)

You don't have to do that - that's why they have the sub-accounts. So for you, it'd be:
924961-0000
924961-0001
924961-0002
etc
Then each site has a sub-account & you & the webmaster can see which sites made sales.

Ahh.. that, yes. I do that..but I thought you ment CLICK tracking, not sales tracking. I'm pretty sure that if the accounts are merged, all hits show up under the account 0000 (and you can't change the sub-account in refer.ccbill.com links, it doesn't work like that. Or atleast didn't in 2003/04 when I asked about it).

Yeah - that's one thing I really wish CCBill would add - count clicks for the sub accounts instead of just the total that defaults to the 0000 account when you go & look at individual sales.

I'm glad to see you're doing some stats outside of ccbill, that's really been needed for some time now..

I don't like the iframe idea though. As an affiliate, I would send to the tour via the ccbill link. That also helps to build the trust factor as opposed to just trusting that you won't change something on your tour or that it breaks etc.

eg:

h ttp://refer.ccbill.com/cgi-bin/clicks.cgi?CA=xxxxxx&PA=XXXXXX&HTML=http://www.mypaysites.com/tour1/index.php?ref=your_ccbill_code

Have you confirmed that there's a timed out lockout on changing the cookie? It's become fairly common practice.. For example, topbucks has something like a 1 minute lockout or something like that.

I think the program can set whatever time frame they want for the cookies.

Feel free to do that if you'd want. BUT, I also made a consious decision to not use refer.ccbill.com links. It's rare, but the refer.ccbill.com server has been down for several hours, when the signup page of ccbill is not. What this means is that refer.ccbill.com links do NOT work, even though customers could sign-up. But as I said, nobody says you can't link like that. I personally don't see the point.

..also, if you think you're "safe" from tricks if you send via refer.ccbill.com links, you couldn't be more wrong. No matter what software, what kind of links, whatever the program is using there's a way to shave sales. Nats, mpa2/3, ccbill, whatver..all of these can be shaved with. Sorry if I broke your dreams of honesty, but if there's will there's a way, as sad as that is.

Example. Just place random ccbill_referer value in the joinpage. CCBill uses the passed value before the cookie. So doesn't matter if you sent your hit via refer.ccbill.com, if the paysite is crooked and changed the ccbill_referer value on their joinpage, you lose the sale.

You can't even check it. You can always go to the tour:
http://hairytriangle.com/tour1/index.php?ref=1234567 for example and see the sourcecode, go to the ccbill page and see if it's there, if it's on the source of my iframe on the indexpage etc..but how do you know the program keeps the joinpage static? They could use crontabs or something to keep the joinpage 'clean' 22 hours of the day, and for 2 hours they replace all codes with yours.. you'd never know if you didn't happen to check it just then... how sad is that?

No way to be sure.

*chuckle*.. yeah I wasn't actually saying that a program still couldn't fuck affiliates out of the sale, I'm well aware of all the tricks that one can pull... However, to the unwashed masses, it can at least communicate a "desire" to be trustworthy etc. If the program/person is a somewhat well known entity, then it's not really an issue.

But I've got one program that has done something similar and I simply don't trust them. Not because I think they're crooked, but more that they're not very technical and their sites often have "stupid" problems with them. So by linking thru the ccbill link, I should be able to still get the sale even if they screw up their code.

I've been told that Sparky has helped Emma take care of this problem |thumb