Banner Exchanges Unmasked

Almost every Webmaster has tried a banner exchange at least once. While many have ideas about what they might expect the exchange to provide, only a few know how these exchanges really work. Only these few can evaluate the benefits the exchange promotes against the information that remains undisclosed to public. The purpose of this article is to make the 'black box' of banner exchange more transparent to those who want to know.

To begin, let's sum up the main features a typical Webmaster is likely to consider attractive in a banner exchange network.

The most popular seem to be:

• Extensive reach
• Tight quality control
• High exchange ratio
• Good targeting
• Handles multiple banner sizes
• Provides detailed statistics
• Fast (or at the very lest flawless) ad loading

Let's review each of these in turn, and find out what can potentially lurk behind each seemingly attractive feature.

Extensive Reach and Tight Quality Control

These two features are closely related. Quality control becomes extremely time consuming and costly as the network (and, respectively, its reach) grows.

It's not difficult at all for the banner exchange owner to verify banner placement of their ads on the static pages of several dozen sites. But when the sites number in the hundreds, an advertiser’s banner may be spread across many thousands of pages. How often can a single person (or two) check them all, even if, between the hours of 9 and 6 they do nothing else?

The calculation is not difficult. Let's assume that it takes the banner exchange owner half a minute to check the page. That makes 120 pages per hour or 960 (or 1,000 at the very best) during the working day. For a network with, say, 100,000 Web pages, one QA staff member will only be able to check a particular page about tree times a year… Not frequent enough to maintain any real quality control. Four staff members will lower this frequency to once a month -- still not enough! In fact, only when the banner exchange has 16 full time QA staff members can the network owner have the right to claim that banner placement is under constant monitoring.

Definitely, manual labor needs to be enhanced by automated controls, but any script -- even the most intelligent -- can be fooled with enough skill, knowledge, time and patience. Thus, to achieve tight quality control levels, manual checks are irreplaceable. More sophisticated methods such as, for example, double random sampling can save a lot of moderator effort. However, such techniques require staff to code and support them, as well skilled specialists to interpret the results and direct the QA checks further. Thus, whether the exchange owners has 16 moderators with decent scripts, or top-notch scripts, a skilled administrator and 4 or 5 moderators, the expense of running the system is likely to be considerable.

Few networks will make their reach data publicly available, however, there is still a way to evaluate it. All you need to do is to find out what software a particular exchange employs, and what hosting option they use. The use of standard, publicly-available cgi scripts based on a MySQL database signals that the network may be incapable of achieving decent reach and effectively managing campaigns at the same time.

Need proof? Let's look at the numbers.

Let’s assume that at peak load the network needs to process 1000 impression requests per second (which is quite common for a network that provides 30 million impressions daily). In this case, about 50,000 connections must be open and served flawlessly at any given moment.

What might this mean in terms of standard scripts and hosting options?

First and foremost, it means that the system kernel has to be optimized to enable the handling of such a large number of requests at one time. The base configuration of any OS simply cannot handle that many file descriptors simultaneously.

Second, most publicly available scripts use the default configuration apache server, which can only handle up to 256 connections simultaneously. Is this enough to provide decent reach? It’s doubtful. Moreover, apache forks on a response, taking up to 1MB of memory per copy (i.e. per request). Is this kind of space likely to be available from that network’s particular provider?

Cgi request processing under a standard SQL server puts additional strain upon a banner exchange. Find out where the exchange is hosted and ask the provider's support team how many times per second you might be allowed to run your cgi script. It's almost safe to predict that the figure will be something like 10 per second at the most for co-located exchanges, though options may vary significantly for those with dedicated hosting. Compare these values with those presented above, and draw your own conclusions.

The issues of reach and quality control can be partially addressed if the exchange owners increase the number of servers they use and implement some kind of balancer software. However, in the case of banner exchanges, such techniques can result in a lot of extra (and irresolvable) problems in the long run.