ok the way it works is like this :-Zug wrote: ↑August 23rd, 2023, 1:15 pmSo this would explain why ccbill stats do not show referring urls when you request to see that data.tacnet wrote: ↑August 22nd, 2023, 10:33 pmIt shouldn't matter which one you use. Most sites will have a bit of code in their .htaccess that says if the url starts with http:// then redirect to the exact same url using https://
But ccbill dont appear to be doing this. With their links it looks like you HAVE to use http because https simply doesnt work.
Typically, when one site sends traffic to another, information is sent that identifies the originating site as the source of the traffic. So the receiving site can see where the traffic came from. This process stops when traffic flows from an HTTPS site to a non-secure HTTP site. This DOESNT mean you are not getting credited with the clicks because your affiliate details are stored in the URL itself (eg with ccbill links CA=920029&PA=2635627 identifies you as the affiliate)
What it does mean is that ccbill cant tell where the traffic came from. So you could have the same ccbill link on domainA.com, domainB.com and domainC.com but ccbill will have no idea where the click came from (and therefore neither will the merchant). They just know its a click from somewhere with your affiliate ID. Its sloppy and it means their traffic reporting cant be that great but it will work
So for NATs sites, just use whatever link they give you (probably https) but for ccbill, it looks like you need to stick with http
My question is, even if most sites have that bit of code in their htaccess that forwards to https; does it still cookie the affiliate's referral link? Redirecting to the exact same 'page url' is fine, but, it's no use if it doesn't forward to the exact same url along with the affiliate's referral link code.
All of this would be cleared up if all sponsors would just provide affiliates with the https code instead of providing http codes. However ccbill's processing url is another story.
IMO all sites should be using https. Regardless of whether or not they request personal user data like email or anything else. I have noted some webmasters that do not use https say they don't need it if they are not requesting personal user data.
Paysite owners should all be using https on all their pages and provide affiliates with https links to all of their promo pages. If they don't they should not be allowed to process signups. Yet most pay sites still do forward to https, but some provided affiliate links are only using http. Which, at least to me, makes things a little sketchy.
Times are tough enough as it is without having to worry about this minuscule 'thing' with https from ccbill or any other sponsor program. Regardless if it matters or not. Right is right and fair is fair to all affiliates work and their general viewing traffic Affiliates should not have to worry about this or worry about double checking tracking cookies between http and https links.
Here's another provided affiliate link code that forwards to https:
http://www.gammae.com/blazingbucks/trac ... r=&buffer=
Does it cookie the http then forward to https, or what is the deal? What should affiliates link to? .. I shouldn't even have to ask the question.
You link to ccbill and they set the cookie with your affiliate ID. The cookie can ONLY be read by ccbill.com. In other words, the merchant site cannot see or affect the cookie in any way, its only once the user gets to the check out form (which is also hosted on ccbill.com) that the cookie can be read
So the merchant site can do whatever it likes (eg forwarding you the https or even send you to a completely different site/page) and it wont affect the cookie
The downside is that because you are linking to ccbill via http and not https, ccbill cannot see where the traffic came from. So they cant show you which banners or pages are working best for you. Infact, they cant even see which domain the click came from
The same problem occurrs if you are trading traffic with a site that's on http. Because the referral data doesn't get passed from https to http, there is no way for them to know how much taffic you are sending
Now the IS a way round this but its seen as a potential security risk. In the <head> tag of your page you can add this code :-
Code: Select all
<meta name="referrer" content="unsafe-url">Hope that makes sense
