zango and affiliate cookies
 

I have been reading through the zango threads, and there have been some great suggestions on the affiliate side to cope with such programs.

I wanted to start a discussion on what can be done on the affiliate program side to guard against this.

There was some suggestions before about maybe locking a cookie from being overwritten for x minutes.

problem with that, is that an affilaite page could have keyword that triggers a foreign popup, and an Affiliate cookie could be set with a pop-under, and with a cookie timeout lock, the affiliate click from the page wouldn't get recorded since the foreign page got in first.

i am designing a new affiliate system and this issue to protect affiliates is something i am particular concerned about and focusing on to create a solution.

so let's brainstorm!


Fight the hijaaaaacking!

First suggestion: Programs should look at the header info, and actively track affiliates that have higher than average Zango / toolbar user counts.

They may also want to track the number of Zango infested users that arrive with no refering page, a sign that they came in through a popup window.

Programs should make it very clear in their terms that they do no accept toolbar traffic. A list should be maintained and updated regularly to clearly indicate unacceptable sources.

Programs could also put a popunder or exit console with Zango removal instructions for the users.

Figuring out a way to specifically NOT pay for Zango created traffic would go a long way to removing affiliates from the buying cycle.

1) not sure what you mean by that.. by checking header, you mean to search for the web browser type of "zango" ?

2) problem is zango can get wise and then fake out the referer. i was thinking to reverse spider referring pages to find the matching link.. but any zango-like software could set themselves as a "legit" webmaster and get aorund this referer check.

links from emails have no referer.

3) something for programs to add to their TOS

4) would have to detct for the zango web browser identifier to potentially do this, but there will be other zango variants or they work around.

5) some fraud scrubbing to track behaviour of clicks that come in might reveal the fraudulent users of spyware/adware.. where by IP, if 2 diff links show up in a time frame, then it could be the adware that did the popunder, and te surfer clicking on the link from the affilaite.



great ideas, keep them coming.

Fight the sponge!

1) If the average Zango detection rate is, say, 1%, and you have some affiliates that have 10% in their referals, you have something to look at, especially if your ToS says "no toolbar traffic". Programs need to pay much more attention to the sources of their traffic.

2) Zango can't fake "from" information, as that would be a violation of their support of the Truste protocols. Attempts to hide themselves would give an indication that they have something to hide. A nice letter writing campaign to the FTC would follow.

As for links from emails, well.. do you support spam?

3) Programs need to keep the ToS up to date.

4) If you can spot even 10% of what goes through your program and try to teach them, it would likely be enough to tilt the numbers against the malware companies.

5) Velocity tracking on clicks is very important. One thing your affiliate program should pride itself on is not losing track of the surfer, and having an interface that doesn't allow the affiliate code to change on the fly. Cradle to grave tracking is an important thing, so that affiliate codes can't be replaced on the signup page, as an example. Going back and rematching join page hits with signups and looking at IP and other browser indicators is a good way to assure this isn't happening.

I'm not a good enough coder to know if it is even possible, but the first issue to tackle must be to prevent the scumware window having focus. If it is the first screen a surfer sees after clicking a link, the chance of the legitimate site getting full value from the surfer is greatly reduced, regardless of whether the scumware window makes a sale or who is credited for it. We have seen recently traffic generators (eg big TGP's) being targeted by scumware, so this is no longer just a question of protecting potential sales.

Otherwise, as regards cookies, wouldn't it be best not to use them at all, since they have other weaknesses, as well as their vulnerability to scumware?

If it is possible, I think this (also) needs to be dealt with from a different perspective, otherwise it becomes like the hitbot issue and unfortunately the smarter scammers always seem to have the time and resources to stay way out in front of those designing protection. Scumware is just one of several reasons why many sponsors should want to be able to identify traffic sources easily and there should be some way of letting them do this which does not depend on the unreliable methods associated with browser headers.

I don't buy into the excuse that sponsors cannot police their traffic, but I do accept that the current ways of doing so are tiresome and far from bulletproof. If someone could devise more efficient tracking, those who do not care would no longer have an excuse and those who want to, could police their traffic more efficiently and more effectively.

haha im such an idiot for not thinking about this first

My thought was the locked in cookie for a few mins, then checking ratios that suddenly drop , thus exposing zango affiliates but your way is much easier.
:thumbsup all sponsors should do this..

boomer:/logs# cat access.log | grep -i zango | awk {'print $1'} | sort -u | wc -l
93
boomer:/logs# cat access.log | awk {'print $1'} | sort -u | wc -l
15303

so 93 out of 15303 unique IP's had the Zango user-agent these "anti zango" scripts look for

is that really much to be worried about?

You should look for 'hbtools' in the user agent as well. It is the header that Hotbar adds. Hotbar has the same ad system that Zango has(as Zango owns them), but a different frontend for skinning your browser, email tools etc.

You could also look for "coolweb" and a few others... you might be surprised how high those numbers get in a very short time.

Even sponsors that claim "too much traffic to check it all" can find the way to take the time to match actual signups back and look at where the money is coming from. Don't worry about the 99.9% that doesn't buy, just worry about what actually spent money or joined or whatever it is that triggers a payout or affiliate credit.

It should be part of the anti-fraud package that all sites use. If programs did stuff like this, the file sharing systems, copyright violators, misleading advertisers, spammers, and SEO bombers would find themselves having to explain where their traffic came from. Suddenly actually running honest and real sites would be a benefit, not a handicap.

boomer:/logs# cat access.log | grep -i hbtools | awk {'print $1'} | sort -u | wc -l
55


I mean hotbar and zango together is about 150 thats about 1%

I recall a list here a few weeks ago of 20+ active scumware providers. Even by the most conservative estimates of their individual impact, the total effect is something else again.

We know that most of those arguing that the traffic involved is small, are merely attempting to whitewash the issue. What people who think that way so stay out of the argument altogether tend to overlook, is that many of the "business" topics around the boards represent webmasters trying to find ways to boost their traffic and/or sales by similarly small percentages.

If someone is concerned enough to want to find ways of boosting their traffic/income by a point here and a couple of points there, then logically they should be just as concerned about anything which works against them to a similar degree.

1) i agree, and i am designing this for a large program, so they want to be sure that affiliates will be protected and have the confidence to to promote the program with traffic. major overhaul of their affiliate program technology going with the "build" approach, and i wanted to get as much affiliate feedback to build into the system to give affiliates the commissions and tracking they deserve.

2) alot of spyware/adware that were dropped via DRM exploits probably don't care about TOS.. so those types can certainly fake out the referer with no retribution, especially if they are based in off-shore shell companies, etc. Hackers will break into any system eventually.. the goal is to be realistic that bullettproof is harder, but to atleast put some good defenses to avoid most fraud.

2a) some program owners support opt-in mailing, no one supports SPAM, it's illegal.


3) Yes, and that is for legal reasons so they can justly terminate bad affiliates.

4) yes, and a fraud watcher module is in the design to do datamining of hits and clicks and referers to set thresholds of suspect activity, that allows for the affiliate manager to see what is going on.

5) agreed.. one problem tho, is AOL IP's can change on the fly due to proxy-servers they use.. whereas IP for cable/DSL usually stay the same since the license is active. the biggest challenge is to ensure that the cookie doesn't get overwritten by a pop-up or pop-under, or that software on the user machine doesn't re-write the cookie on the fly.

software such as zango present a "man in the middle" attach scenario that is easier to manipulate the headers and data, vs network/routing which requires more physical access.

all of this stuff goes on the surfer's machine, and they don't see any harm or aware about pop-under or pop-over that shows them the same site or a diff site.. if they are interested and then buy, then they think that the installed program has value.

i think the biggest issue is like how i presented in my first post.. that a surfer visiting an affilaite webmaster page, could have an adware/spyware program popup/popunder a page with aff id embeded and could get the jump on the click... unless some means of tracking referer, or velocity of hits from same IP were used.. that's what i am trying to brainstorm.


Fight the white hat vs black hat!

what if it were a requirement that an affiliate had to register their domains that they use to promote a program, where maybe a specific file was placed by the webmaster that verified the website (google requires you to add a meta tag to be accepted into their webmaster tools program).

this could be cumbersome on the affilaite that has to plan ahead of launching a website to register with the program.

the AFF manager wouldn't have to do anything.. a spider would look for the specific page to confirm and this registration process could be deterant.

would this be a problem to do?

i can imagine if you have 1,000 websites, that all domains would have to be entered, and a file uploaded to each one for authenticaiton would be time consuming, but it is a one-time thing, and if this helps to ensure clicks get tracked and not hijaacked, might be a good trade off.

thoughts?


Fight the new ideas!

that would be true if you knew the signature to look for.. much like with anti-virus apps, new signatures will come out.. so zango or any other software could patch themselves on next update to change their signature.


Fight the can i have your autograph!

FTP: I as an example own many hundreds of domains (have owned thousands). Keeping a list completely up to date would be a burden, and would likely burden you own systems down. Whitelistings domains is a good way to a certain extent, but it can cause other issues and create work.

Part of the process of tracking, regardless of IP address, is to use all the tools that are at your disposal.

1 - Trace IPs... hey, why not?
2 - Build your tours with "pass forward" tracking devices on all clicks. Don't pass the affiliate code forward, but rather some other form of coding (so that it cannot be easily replaced by malware that replaces affiliate codes).
3 - use phpsession or similar type arrangements to track users within your systems.
4 - don't assume a user coming to your front page is a new session - check for an existing session for this user. That is the fastest way to avoid cookie / affiliate code write-overs.
5 - check to see if you have been framed / Iframes / img src'ed.

Combining those things together, plus other tools will normally allow you to keep track of a surfer right through your system, and also help you to identify and eliminate traffic leaks. The "pass forward" method on tours is particularly powerful, especially with a coded tracker, as it will really slow down code-replacers.

Variances between these things, comparing shifts in IPs, session variables, pass forward tokens, and even surfer cookies combined will give you some powerful tools to look for data slippage and loss.

fuck zango and anyone who supports them

My initial reaction is that it would be too cumbersome, in fact I have closed sponsor signup pages in the case of the odd one or two who do require something along the lines you have suggested. Most of my sites are largely dynamic and I don't want to be constantly concerned with whether or not a particular URL will/will not pass some kind of test.

As I said, I don't even know if it is practical, but I had in mind more something along the lines of my pages replacing a query string with their identity and this being passed along to the sponsor along with my ID, so that the two were then linked together in his database and so that the process was independent of browser capabilities and settings.

On the other hand, if I can find the time to identify and claim all my domains for Google, it isn't that big a deal to do the same thing for a sponsor. The question is, what would prevent me from having say 50 "legitimate" pages on a domain and then a few which I displayed for scumware captures? Would the sponsor be able to readily identify these "extras", because if not, even the minimal effort of identifying the domain would be a waste of everyone's time.

i wasn't suggesting that every page have a tag, that would alot of work.

i was saying that an affiliate would register their list of domains with the program of all the sites they would be using to promote, and to ensure identify/owner, that a text file like hello.html be put on the domain at the root, so that an automated process could just go out and check for hello.html on the domain list that was provided.

like i said, google requires that level of authentication, but you only have to do it one time.

the slightly cumbersome issue would be to put that file on every domain.

and the question is, would that be too combursome to an affiliate it was a way to potentially stop scumware from hijaacking their traffic?

I think such measure could really help in that area, but it comes at a cost of time.. and while some may jump on the idea and do it, if a greater percentage won't want to do it, then that means the idea won't work..

or maybe the middle ground, is to make it optional, that those that do could have better peace of mind that various efforts are going to help reduce the traffic hijaacking.


Fight the mandatory voluntary!

going on a slightly tangential path.... if/when the mandatory labeling law gets passed (its a rider on an appropriations bill), which requires every page to be labelled, it would be a significant issue to US-based webmasters in being able to find/track and label each page.

Fight the sky is falling v7.0