SETTING UP NON-ROTATING BANNERS:

Though the primary purpose of WebAdverts is, of course, to rotate
banners, it will occasionally happen that you want to show one and only
one banner in a particular location.  You could do this by setting it
up in a zone by itself, but there’s an easier say.  Simply add an extra
entry (“setdest=<ID>”) to the QUERY_STRING.  (The QUERY_STRING is the
part of a URL following the actual page name, separated from it by a
question mark.)  For example, if you wanted to always show an ad named
“rugrats” in a particular spot, you could reference the script as
follows:

http://foo.com/ads.pl?setdest=rugrats

(If you’re adding QUERY_STRING elements to IMG tags, you need to be
sure to add them both to the image call and to the link tag:

<A href=”ads.pl?banner=NonSSI;page=01;setdest=rugrats”>
<IMG src=”ads.pl?page=01;setdest=rugrats”></A>

===========================================

RUNNING A BANNER EXCHANGE:

If you’re running a banner exchange, you’ll want initially to set up
each member’s account as you would an account for a normal advertiser.
Assign the “display ratio” as appropriate, so that a certain number of
banner display’s on the member’s site will generate an exposure of that
member’s banner on someone else’s site.

Once you’ve completed entry of the member information, you’ll see on
the response page an example of the HTML code which should be inserted
on that member’s pages to display banners.  (That same info is visible
any time the member checks his own stats.)  The HTML code provided will
allow the script to keep track of which member’s site displayed the
banner, as well as, of course, of what site the user should be sent to
if the banner is clicked.

If you desire to do so, you can allow members to enter or edit their own
information.  If you’ve set the $AllowUserEdit variable to 1, anyone
will be able to create a new account simply by entering a new name and
password, or to edit an account, so long as they know the correct
password.  The edit screens in this case are “stripped down” versions
of the full administrative edit screen; users can only edit their name,
e-mail address, site URL, banner URL and password.  When a new account
is created by a user in this way, it is first put on a “to be approved”
list on the main admin screen.  Until the administrator approves it (by
“editing” it, with or without actually making any changes), it will
*not* appear in the actual rotation, though the new member may begin
immediately to accumulate credits by displaying banners on his own
site.

Note that you should always have at least one non-exchange banner in
your rotation.  What I mean by that is that there should be at least
one banner which is *not* displayed solely on the basis of a specified
display ratio.  (You can use the spot like LinkExchange does, to
advertise the exchange.)  Even if you’ve specified a “default” banner,
it’s still a good idea to have at least one banner in the exchange
which is *always* available to be displayed.

===========================================

“ZONING” BANNERS:

WebAdverts allows you to set up “zones” for your banners, in order to
ensure that certain banners are seen only on certain pages.

Assume, for example, that you want to treat your main page as one
“zone,” and all your other pages as a second zone, since you plan to
charge advertisers more to appear on your main page than to appear on
your other pages.

You could do so by setting up two configuration files, “zone_A.pl”
and “zone_B.pl.”  In the former, you’d define $advertzone as “A”
($advertzone = “A”;), and in the latter, you’d define it as “B.”  Your
main page would then include a tag calling zone_A.pl, while your other
pages would include tags calling zone_B.pl.

(Note that zone names can consist of any series of alphanumeric
characters.)

Unless you’re using SSI tags, though, you don’t actually need to set
up multiple configuration scripts.  In fact, if you do so, you’re
actually doing things the hard way.  You can specify a zone in the
QUERY_STRING, just as you can call a specific banner (as discussed
above):

http://foo.com/ads.pl?zone=A

You can also designate that a banner call should show banners from
more than a single zone, by listing all the relevant zone names,
separated by “plus” signs:

http://foo.com/ads.pl?zone=A+B

When you enter new accounts, you would define the adverts’ zones as
either “A” or “B,” as appropriate.  Those accounts assigned to zone A
will show up on your main page; those assigned to zone B will appear on
your other pages.

If you want a particular banner to be able to appear in *either* zone,
either define its zone as “A B” or leave it undefined.  (Any banner with
no zone defined will be shown in *all* zones.)

Note that all of your accounts still comprise a single list, and can
still be maintained with a single admin script.

Note that the lack of a zone definition constitutes a “wildcard” zone
definition.  A banner not assigned to any specific zone(s) will be
available for display in *any* zone.  Similarly, a banner call which
does not specify any specific zone will be able to draw banners assigned
to *any* zone.  If you want *all* of your banners to appear only in
certain defined locations, you need to be sure (a) that all of your
banners are in fact specifically assigned to the appropriate zone(s),
and (b) that all of your banner calls are in fact specifying the zones
from which their banners are to be called.

If you want to be able to show *all* your advertisers on a single page,
create a config file with the $advertzone variable defined as “showall”
($advertzone = “showall”;) or just add “zone=showall” to the URL of
your banner call.  All of your current banners (those which have not
expired and which have a non-0 weight) will be displayed.  (Note that
if you’ve defined $RequireMember to 1, you’ll need to make sure your
“ShowAll” banner calls, just like any others, reference a valid account
name, even if it’s only your “default” account!)

Finally, you can also show all of the banners defined to a specific
zone, and only that zone, by combining “showall” with the specific
zone’s name.  For example:

http://foo.com/ads.pl?zone=showall-rugrats

(The “zone=” designations, like all other QUERY_STRING elements, by
the way, can be included on IMG tag, IFRAME tag, and JavaScript tag
banner calls.)

===========================================

USING ZONES IN A BANNER EXCHANGE:

Zones themselves work the same regardless of whether you’re using SSI-
or IMG-based calls.  However, while with SSI-based calls, the manual
assignment of zones for banners works fine, if you’re running a banner
exchange, things are just a bit more complicated.  You can’t expect your
members to “pick” zones appropriately at random; you need a way to let
them know which zones exist and to allow them to select appropriately.

Hence the @zones variable.

If you leave this variable unassigned, your banner exchange will be
untargeted.  All banners (unless you, as the administrator, specifically
assign them zones) will be eligible for display on any page.

If, on the other hand, you assign a value to this variable, you
introduce targeting — which can be used to split banners and pages into
categories based on topic, age-appropriate content, or whatever else you
come up with — into your exchange.

Let’s say you’ve set up four zones, “G,” “PG,” “R” and “X.”  You’d
define the @zones variable as follows:

@zones = (‘G’,'PG’,'R’,'X’);

Now, when you or a member add or edit an account in the exchange,
you’ll be able to select the zone or zones in which the banner can be
displayed, as well as the zone (unfortunately, only one) from which
banners will be displayed on the member’s page.  When the account data
is displayed to the member, the appropriate CGI script will be
referenced in the “cut and paste” HTML code presented.

===========================================

INCLUDING BANNERS IN CGI OUTPUT:

Including WebAdverts banners in the output of other CGI scripts is
quite simple.  All you need to do is include a tag — JavaScript,
IFRAME or IMG, as you prefer — on that script’s output page.  As
usual, the former two are to be preferred.  Certain versions of MSIE
(the world’s most popular buggy browser) will *not* display a banner
on a CGI-generated  page, when called via an IMG tag, until and unless
the page is refreshed.

===========================================

USING “RAW MODE” BANNERS:

“Raw” mode allows you to actually specify the particular HTML code that
WebAdverts should insert on your pages.  If you want to include in the
rotation a banner from an advertiser who requires certain HTML code or
banners from a network such as LinkExchange, this is how you do it.
Note, though, that if you do so, what you enter in the “raw mode” text
input box will be copied exactly onto your pages when the banner is
called.  The ability to include “raw” HTML can be handy, but use it
carefully.  It would be quite easy to “screw up” your pages if the HTML
inserted here is incomplete or incorrect.

Generally speaking, if you utilize “raw mode” for your banner entries,
whatever you input will be copied *exactly* onto your Web pages.
WebAdverts will be able to track the number of times the banner was
displayed, but nothing more.  You won’t get click-thru data.  But
there are a few tricks available to allow you to let WebAdverts modify
this supposedly unmodifiable text.  Some banner exchanges utilize
a numbering system to keep track of separate banner calls.  (WebAdverts’
own “page” designations in IMG tag calls serve as an example of this.)
If you wish to put such a number in the raw mode entry, simply include
“<RAND>” where you want a random “page” number inserted.  And if you
want to be able to track click-thrus as well as exposures, include
“<URL>” immediately before the destination URL in the HTML entry.  This
will insert a “pass-thru” reference to your WebAdverts script and enable
WebAdverts to log the click-thru before sending the user on to the
banner’s real destination.

As an example, let’s assume that you want to include banners from an
outside banner exchange, which happens to utilize WebAdverts, in your
site’s normal advertising banner rotation.  If the code with which you
were provided by the exchange looked like this:

<A href=”http://foo.com/ads.pl?member=rugrats;banner=NonSSI;
page=01″>
<IMG src=”http://foo.com/ads.pl?member=rugrats;page=01″ WIDTH=400
HEIGHT=40 ALT=”Foo Exchange”></A>
<BR><SMALL>Foo Exchange</SMALL>

Then inputting the following into the “raw HTML” text input box for the
account displaying the exchange’s banners would allow you to track the
number of click-thrus, as well as ensure that each time the banner is
called, a new page number is used and thus a new call is made to the
remote host server:

<A href=”<URL>http://foo.com/ads.pl?member=rugrats;banner=NonSSI;
page=<RAND>”>
<IMG src=”http://foo.com/ads.pl?member=rugrats;page=<RAND>” WIDTH=400
HEIGHT=40 ALT=”Foo Exchange”></A>
<BR><SMALL>Foo Exchange</SMALL>

Note the placement of the <RAND> tags and the <URL> tag.  Note also that
the <URL> tag isn’t a guarantee; even if you include it, you may still
not be able to track click-thrus.  LinkExchange, for example, makes use
of IFRAME tags; since those are actually just “windows” to their own
server’s display of a banner, there’s no way the WebAdverts script can
modify it and thus track clicks.

===========================================

SENDING E-MAIL NOTIFICATIONS:

If you have a file called “welcome.txt” in your data directory,
you’ll have the option each time you add or edit an account of sending
the contents of that file as a “welcome” e-mail message to the account
holder.  An example “welcome.txt” file is included in the downloadable
program package.  The <–UserID–>, <–Password–> and <–HTMLCode–>
“comment” tags are, of course, replaced by the program with the actual
information for the particular user being e-mailed.

Similarly, if you have a “reject.txt” file in your data directory,
you’ll be able to send the contents of that file as an e-mail message
to the account holder of any new account that you choose not to allow
into the exchange.

If you’ve defined an e-mail program, your advertisers or exchange
members will also be able to have their passwords automatically sent to
them from the main entry screen, in case they’ve forgotten them.  This
should cut down the volume of your “help me” mail messages just a bit.

===========================================

GENERAL SECURITY NOTE:

The directory containing your data files should be password-protected
or (better yet) should be located somewhere inaccessible to browsers.
You probably don’t want random passers-by snooping about in your
advertisers’ or exchange members’ data.  This is especially important
if you’re running an exchange in which members can update their own
information, as if someone can read the data files, they can read
the individual members’ passwords, as well.

===========================================

“REGISTERING” WEBADVERTS:

WebAdverts was originally released as shareware rather than as freeware,
and still expects a registration code to be entered.  To remove the
“unregistered version” notice from the admin display page, simply type
in the code “frtytw” on the registration information page.

This documentation assumes that you have at least a general familiarity
with setting up Perl scripts.  If you need more specific assistance,
check with your system administrators, consult the WebScripts FAQs
(frequently-asked questions) files http://awsd.com/scripts/faqs.shtml
or ask on the WebScripts Forum http://awsd.com/scripts/forum/