(1) I’m not sure I understand the syntax for the SSI call. How does it work?

With the release of WebAdverts 3.00, SSI tags are no longer the “preferred” method of calling the script. However, they still have their uses.

Setting up SSIs (server-side includes) correctly can sometimes seem more an art than a science. Calling a script in an SSI as a full URL sometimes works, as does calling it via a relative path name based upon the location of the calling page.

What I usually have the best success with myself, though, is calling a script in an SSI via a “pseudo-full” (start it with a slash) path name based on the “primary” directory of the domain, regardless of the location of the calling page. Thus, for example, if the script you wish to call has the URL address “http://www.foo.com/adverts/ads.pl,” the SSI which calls it from any page, anywhere on that site, should be “<!–#exec cgi=”/adverts/ads.pl”–>.”

(2) I can run ads.pl from the command line, and it works fine. But when I try to call it via SSI, it doesn’t work. What’s the problem?

If, where the banner should be on your page, you see an error message along the lines of “An error was encountered while processing this directive,” you probably just don’t have the SSI “aimed” correctly. See the answer to the previous question for a few tips that might be helpful.

If, on the other hand, you see nothing where the banner should be, the SSI directive probably isn’t being processed. You can check this easily by viewing the source of the page. If you can actually see the SSI tag, it wasn’t processed.

There are several different methods by which SSIs can be enabled on your pages, but not all of them will work on all systems. You’ll need to talk to your system administrators to find out, first, if you can use SSIs on your pages, and second, how to enable them if they’re allowed.

(3) I keep getting “File Lock” or “File Permission” errors. Why?

Presumably because the file or directory in question doesn’t exist or doesn’t have the correct permissions set. The various text files have to be world-writable, as does the directory in which advert data files are to be stored.

(4) I’m getting an error message saying the script can’t access the “adcount.txt” file. No such file was included in what I downloaded. What’s the message mean?

The adcount.txt file is one of the data files that the script creates. The error message means, quite simply, that the script for whatever reason isn’t able to write to the data directory you’ve defined. Check the things that the error message tells you to check. Make sure that the directory actually exists and is set world-writable, and that you haven’t made a mistake in defining its path in your configuration.

(5) I’m trying to run the script on a Cobalt RAQ server, but whenever I try to set the administrative password, I get bounced back to the main user intro screen. What’s going on?

A number of folk trying to install WebAdverts on Cobalt RAQ servers have reported having this same problem. It seems that for some reason, the server isn’t sending information input into a form, back to the script. You should be able to get around the problem simply by defining $admin_cgi with only a file name, rather than with a full URL. (In other words, instead of defining it as “http://foo.com/cgi-bin/ads_admin.pl,” define it just as “ads_admin.pl” instead.) I’ve no idea why that works, but it seems to.

(6) The script runs sometimes, but other times I get server errors. My error logs show “null filename used at line X” errors. What gives?

These errors are apparently the result of incorrect processing of the script files. The variables are defined in the ads_settings.pl file, which is “required” by the main script. The server should process the content of the settings file before proceeding onward with the processing of the main script; if it doesn’t, it may encounter references to variables which (so far as it’s aware) haven’t been defined, even though they are in fact defined in the settings file.

This misbehavior, which fortunately seems to be quite rare, can apparently be resolved by changing the way the server handles CGI scripts.

More specifically, in the Apache httpd.conf configuration file, make sure the server has been instructed to use “AddHandler” rather than “ScriptAlias,” “SetHandler,” or another option. Include the following lines in the httpd.conf file:

Options +ExecCGI
AddHandler cgi-script .pl

If you’re not the server administrator, you of course won’t be able to modify the httpd.conf file yourself. However, on many systems, a local directory’s .htaccess file can override the httpd.conf settings, so you can probably include the above lines in a .htaccess file in the directory containing your script files, and still solve the problem.

Check with your server administrators for more information.

(7) What sort of load can WebAdverts handle, anyway?

If you’re asking about total banner exposures, there’s no absolute answer to this question, of course; a lot depends upon the speed and overall load on your server. However, as a general rule, the practical limit of version 2.15 (the end of the 2.XX series) seemed to be in the neighborhood of 100,000 exposures a day, though I knew of folk using it (on dedicated servers, of course) with little or no trouble to serve half a million or more exposures per day.

Version 3.00 is much more efficient than 2.15, especially when dealing with large numbers of accounts. However, no real “benchmarking” has been done yet.

If you’re asking about total number of accounts (or exchange members), you’ll probably find that to be mostly a matter of personal taste. The script can handle a very large number of accounts; however, the admin interface tends to get unwieldly once you’ve got more than a few hundred accounts in the rotation. I’ll see about addressing that problem in future upgrades.

(8) I’ve heard that some ISPs have banned WebAdverts. Why?

The long-obsolete version 1.52 was notoriously inefficient, especially when used to run banner exchanges. The newer versions of the script have improved things dramatically. Unfortunately, one ISP (and only one, so far as I’m aware) is still basing its policies on the performance of the three-year-old version of the script, and has shown no willingness to acknowledge that things have changed.

(9) The script doesn’t seem to run very efficiently. What can I do to improve matters?

If you’re still using a 2.XX version of WebAdverts — or, even worse, a 1.XX version — you need to upgrade. If you are already using the current version, and are having a lot of problems with inefficient operation, the most likely cause is usage of an inefficient DBM (database) module. The script will automatically utilize the best such module available on your server, but if all you have available is the default module that gets installed with Perl, you’re going to have problems, especially if you’re showing a lot of banners. Ask your server administrators which modules you have available, and see if you can get them to install for you the Berkeley DB_File module, which is pretty much universally regarded as by far the best of the lot.

(10) I’m trying to use the non-SSI version, and I’m having trouble getting the banners to display properly….

It might be that your display script simply isn’t running properly. Try calling it directly, and see what happens. If you get an error message, you need to find the configuration error. If you simply get a blank page, odds are, you don’t have any banners actually eligible for display. Go back to the admin program and check your accounts, to make sure at least one of them is set with a weight of 1, and is not dependent upon reciprocal displays to earn exposures. (Alternately, at the very least, make sure your $defaultbanner variable is assigned with the name of one of your accounts, and not with the URL or path to a banner graphic.)

If, on the other hand, running the display script directly shows you a banner, then the problem is most likely a typo or other error in the HTML code you’re attempting to use to call it.

(An additional possibility, related to question #10, below, is that when you call the script directly you’ll see “header” information rather than a banner. In that case, as per the answer below, the simplest solution is probably just to delete the relevant “print” statements from the script.)

(11) I’m seeing “Content-type” or “Status” lines printed next to my banners. How do I get rid of them?

Those lines are, by defined standards, necessary (or at least advisable) header information. However, in some cases, NT servers don’t seem to understand how to send them properly. (I’m not sure why, but then again, I’m not terribly familiar with non-standard servers, anyway.) In version 3.00, I’ve made a few adjustments which, I’ve been told, should eliminate the problem. Whether they actually do eliminate it or not, remains to be seen.

(12) The script allows me to designate either a maximum number of impressions or a maximum number of click-thrus. Which should I use?

(OK, I know, this question doesn’t really have to do with using WebAdverts, per se, but I wanted to throw it in, anyway.)

<SOAPBOX>

Most sites which sell banner space do so on the basis of the total number of impressions (that is, on the basis of how many times the banner will be displayed). WebAdverts can also expire banners based on the number of click-thrus; however, I would strongly advise against selling banner space on a “per click-thru” basis.

Think about it. When was the last time you saw a magazine or newspaper sell advertising at a cost which was based on the number of people who responded to the ad?

Your job, as the advertising medium, is to provide exposure. It is the job of the banner’s designer to ensure that the banner elicits interest. Whether or not people will click on the banner has very little to do with you. The money you make should thus be based only on how well you get the banner out in front of those who might be interested in the advertiser; it should not be based on how well someone else designed the banner itself.

As well, selling on the basis of click-thrus invites advertisers to take advantage of you. It’s not hard at all to design a banner which is designed to improve product “branding” — that is, to make people more familiar with the product name — but which is not designed to actually encourage click-thrus. Such a banner in a per-click setting is a bonanza for the advertiser, and a rip-off for the site owner.

</SOAPBOX>

(13) WebAdverts shows lower banner exposure counts than it ought to, given how many times my pages are being loaded. What gives?

If you’ve enabled IP logging (in a pre-2.10 version), then you’ve also instructed the script not to count repeat views or clicks from a single IP address within a certain amount of time. If your site attacts visitors who hang around for a while, this can result in a significant decrease in your total exposures counts. Disabling IP logging will obviously solve the problem; upgrading to the current version of the script is an even better idea.

In the newer versions of the script, you can still instruct WebAdverts not to count multiple exposures to single addresses, but it’s your choice, not the script’s.

Another factor which can contribute to apparent undercounting in the newer versions of WebAdverts is the built-in “spider filter.” Exposures to (or click-thrus from) known “spider” programs, e-mail harvesters, link checkers and the like will not be counted, since they’re actually meaningless.

(14) WebAdverts shows higher banner exposure or click-thru counts than it ought to. What gives?

Without knowing what information you’re comparing to the WebAdverts counts, it’s impossible here to provide a definite answer as to the reason for the discrepancy. However, the bottom line is that, thanks to browser caching and related issues, there is no way to count banner exposures from outside of the script which will actually count all exposures. The exposure count provided by WebAdverts is accurate; attempts to verify it from outside, unfortunately, are not.

For example, if you or an advertiser look at the number of times a particular banner graphic was loaded, you’ll find it to be lower than the number of times that WebAdverts says the banner was shown. The reason, of course, is that many of your visitors who saw the banner more than once loaded it on repeat viewings from their own brower’s caches, and not from the server.

(Similarly, since WebAdverts when called via SSI simply records that it sent the generated IMG tag to the browser, and has no way of knowing whether or not an image was actually loaded from the server and/or displayed, views which are blocked by “ad blocking” software will unfortunately still be counted as exposures.)

Similarly, if an advertiser has a banner leading to a special page that can only be reached by clicking on the banner, the number of times the page was loaded will likely be at least a bit lower than the number of click-thrus reported by WebAdverts. If some of your visitors clicked on the banner more than once, they probably loaded the page on their repeat visits from their own caches, and did not issue repeat calls to the server.

If an advertiser looks at his “referer” data to see how many visitors he’s getting from your site, he needs to take into consideration that a lot of browsers don’t provide referer data.

Again, without knowing exactly what information you or your advertisers are looking at, it’s impossible to say for sure what is the cause of the discrepancy. But the fact that a discrepancy exists is not inherently surprising, and does not indicate any problem with WebAdverts’ data.

(15) Can I have banners automatically refresh after a certain amount of time, even if the page isn’t reloaded?

You can’t do this directly. A CGI script can’t keep sending “new” data to the browser; it runs, sends its output, and is done. So WebAdverts can’t, on its own, keep sending new banners to your visitors. However, if you put the banner in a frame by itself, you can use JavaScript or <META> tags to force your visitors’ browser to reload the page every so often, thus pulling a new banner for display.

Of course, if you’re displaying banners via IFRAME tags, setting banners to rotate automatically — at least for those visitors browsing with MSIE — is no trouble at all, as is explained in the documentation file.

(16) On some of my pages, banners don’t show up when the page is first loaded, but show up if it’s reloaded. Why?

This problem occurs only in MSIE (Microsoft Internet Explorer), only on pages generated by a CGI script in response to a form submission, and only if the banners are displayed via IMG tags. It’s presumably the result of a bug in MSIE. It’s easily worked around, though, by not using simple IMG tags for your banner displays. (As is noted in the script’s documentation, using simple IMG tags is generally a bad idea, anyway. See the answer to question #16 for more information as to why.)

(17) I’m having problems with MSIE users being sent to the wrong destination when they click on banners. What can I do?

CGI-generated images aren’t supposed to be cached. Unfortunately, MSIE ignores this fact, and tends to cache them anyway. Extensive investigation has revealed that while some tricks — such as use of “expires:” headers — can reduce the frequency with which MSIE caches those images, nothing can stop MSIE from caching them.

This is a problem in WebAdverts, of course, since when a visitor returns to a page he’s already seen, MSIE is likely to display a banner drawn from its cache rather than one requested from the server. As a result, the banner being shown may not match the banner which WebAdverts’ records indicate is the banner currently being shown to that visitor on that page, and as a result, if the visitor clicks on it, he’ll be sent to the wrong destination.

The best solution is to avoid using simple IMG tags whenever possible. Call your banners via SSI, IFRAME and/or JavaScript tags, instead. That’ll eliminate the problem by avoiding the whole caching issue complete.

(18) AOL users are getting “Invalid Destination” errors when they click on banners! What can I do?

Like the MSIE caching problem, this problem seems to be related to a browser bug, and thus, isn’t something that either WebAdverts or you can fix directly. But you can work around it.

The problem only seems to affect users of some specific versions of AOL’s browser, and only occurs when (a) IMG tags are used to call banners, and (b) the banner destination page is supposed to open in a new window. So, first, you’ll want to use SSI, IFRAME and/or JavaScript tags to call your banners, and utilize simple IMG tags only as a last resort. (As was discussed above, that’s a good idea, anyway.) And second, make sure that the IMG tags you do use, have in their link tags a TARGET attribute of “_new” (or no TARGET attribute at all), instead of a TARGET attribute of “_blank” (or another specific window reference).

(19) I don’t want to have to create separate IMG tags (with new page numbers) for each banner call. Do I really have to?

If you’re using IMG tags, you have to include a “page=” designator. And if you include the same such designator in each tag, you’re likely to see some visitors’ browsers just displaying the same banner from cache over and over again.

But, of course, you don’t have to use IMG tags at all.

(20) How can I track click-thrus in Flash ads?

Because Flash ads (and other types of “advanced” media) are objects in the browser, they take away the browser and the HTML’s ability to redirect the click to where it needs to go so that the clicks can be tracked. In other words, for site foo.com to be able to track a click on a flash ad, the person who clicked it first needs to be transparantly sent back to foo.com before being sent to the actual destination of the link. To do that with Flash, the Flash ad itself needs to be set up properly. Here is a document (in MS Word format) explaining how to do that.