Welcome!

ColdFusion Authors: Yakov Fain, Maureen O'Gara, Nancy Y. Nee, Tad Anderson, Daniel Kaar

Related Topics: ColdFusion

ColdFusion: Article

Banner Rotation & Tracking

Banner Rotation & Tracking

As the owner and operator of a large entertainment site (nyrock.com), I'm often faced with this problem - my ad broker is unable to sell advertising for a small but steady number of pages.

I considered using these pages to arrange banner swaps with other sites, but without a quantitative way to monitor the cross promotion, I couldn't expect to attract any serious players. Enter ColdFusion. With this powerful and effective tool, I developed a program to monitor unique clicks (by IP address) on banner ads. Like any truly obsessive-compulsive developer, after I mastered this process I decided to take things a few steps further. I developed a tracking system not only to monitor banner clicks, but to count how often banners had been viewed. Once this was accomplished, I added logic to allow multiple banners to be displayed in rotation on a single page. The finished product can be called from any HTML page through a set of hyperlink and image tags, as follows:

<a href=http://www.YourDomain.com/click.
cfm?domain=Advertiser target=_top>
<img src=
http://www.YourDomain.com/rotate.cfm?
domain=Advertiser width=468 height=60
border=0 alt="Click Me">

The most important piece of information for advertisers is the number of times their ad has been clicked. Hence, the first piece of logic I developed was a banner-click program. This piece of code is structured around the <CFLOCATION> tag, which proved to be an extraordinarily effective tool not only in this module, but also in several others that I'll discuss in this article. In fact, the tag is the driving force behind this entire set of programs.

The beauty of the <CFLOCATION> tag, I discovered early on, is that it performs a "soft" redirect, i.e., it allows users to employ their [Back] key should they want to return to the originating page. Many other redirection vehicles, such as the HTML-based META/Refresh tag and the JavaScript LOCATION command, aren't quite so friendly, throwing users into a loop of sorts when they try to back out of a redirected page. Another nice feature of the tag is its ability (when combined with an HTML <IMG SRC> tag) to populate a small piece of a page - a subarea, so to speak - that could contain random banners. I'll discuss this functionality when I describe the banner-rotation logic.

Before any coding could take place, of course, I needed to design a small database to hold click-thru and page-view data. In addition, user IDs and passwords had to be set up to allow advertisers to log in and collect their real-time stats. I established the following three tables within an MS Access database: Clicks (Fields: StatDate, Domain, IP_Addr, Clicks), Views (Fields: StatDate, Domain, Views), and Users (Fields: User_id, Password). One row in the Users table must be populated with a password and user ID for each campaign that will be run through this set of programs. The user ID must be identical to the domain, described in the next paragraph, for the programs to start collecting statistics. For example, a user ID of "jane_doe" is used not only to log in but also to allow the code to identify the advertiser's target URL.

The first piece of code I'll discuss -- the click-thru logic --- works as follows: the advertiser's banner is hyperlinked to a program named click.cfm. Appended to the end of the string is a parameter called domain. Based on this parm, the program checks to see whether the domain has registered any clicks in the database via the SQL count() function. If prior clicks exist for the day, the program increments, by one, the Clicks field in the database. Otherwise the program inserts the first record into the database, recording the day, domain and IP address (#CGI.Remote_Addr# -- for later use in the statistical reporting piece).

<CFQUERY NAME="Checkit" DATASOURCE="AdKnt">
Select count(domain) as KntNum from Clicks
where domain = '#domain#' ...
<CFIF #Checkit.KntNum# GT 0>
<CFQUERY DATASOURCE="AdKnt">
Update Stats ...

<CFELSE>
<CFQUERY DATASOURCE="AdKnt">
Insert into Stats ...

Once the stats are recorded, the program uses the #domain# parm again in a <CFSWITCH> statement to determine what URL the user should be sent to by way of a <CFLOCATION> tag. (Although this parameter allows the program to process more than one domain, the code does limit the number of domains that can be handled per page to a single account. I'll discuss this further at the end of the article.) It should be noted that all the action takes place behind the scenes. It's seamless and transparent, the way click-thru programs were meant to be. I should mention that in a real-world scenario you'd want to modify much of the code I'm discussing to be table based. For the purpose of readability, I hard-coded all routines in this article.

< CFSWITCH expression=#domain#>
< CFCASE value=" Advertiser ">
<CFLOCATION url = "http://www.Advertiser.com/">
</ CFCASE >
< CFCASE value=" AdvertiserTwo ">
<CFLOCATION url = "http://www.AdvertiserTwo.com/.htm">...

Banner Rotation
The meatier code resides in the program's banner-rotation logic. The main trick to getting this piece of code to work lay in a combination of the HTML <IMG SRC> tag, ColdFusion's Rand-Range() function and, once again, the <CFLOCATION> tag.

Upon examining a few existing CGI-based banner programs, I noticed that the programs had stuffed CGI code into an <IMG SRC> tag, which, of course, is generally intended to fetch images and display them in browsers. All things being equal, I thought, if CGI programmers can do this, why couldn't a ColdFusion programmer? After some quick testing, I found that indeed I could. This simple discovery is the key to the banner program. I developed the rotation and page-viewing logic in two programs, aptly called rotate.cfm and views.cfm. Each time a browser loads a page containing the banner code, the rotate.cfm program is called. This program uses ColdFusion's RandRange() function to determine a random number, and then uses the #inum# parameter to pass the value to the views.cfm program (along with the domain name parameter from the <IMG SRC> tag). The program writes the entire URL string to a variable using <CFSET> and then plugs the variable into the <CFLOCATION> tag. Why, you may ask, didn't I incorporate this logic into one source file? The simple answer is, originally I did but the program didn't work. Hence, I segregated the logic, whereupon it worked like a charm.

<CFSET #RandNum# = #randrange(1,10)#>
<CFOUTPUT>
<CFSET #URLstr# = 'http://www.YourDomain.com/views.cfm?inum=' &
'#RandNum#' & '&domain=' & '#domain#'>
<CFLOCATION URL=#URLstr#>
</CFOUTPUT>

Note: I should advise that you "seed" the RandRange() function with the Randomize() function since just about every manual I've read tells you to do so. Why RandRange() isn't smart enough to seed itself remains just one more great mystery of life.

Similar to the click program, the first thing that views.cfm does is make a record of the fact that the banner has been viewed on a page (known in Web lingo as a "hit"). You may note that I chose not to record the IP address along with the other page-view information. I did this to avoid creating a process that would quickly accumulate volumes of records into my database. (Instead of incrementing a counter field, each new page view would have generated a new record.) In a real-world scenario, however, you may want to include this piece of information since many advertisers request it - they tend to be a very demanding group.

Once the views.cfm collects all appropriate statistics, based on the #domain# parameter, it then performs its final task: determining which banner to display. First, the program examines the #domain# parm to identify the suite of banners from which it will make a selection; then it employs the #inum# parm passed from the rotate.cfm to isolate the choice to a single banner.

The program sends the #inum# parameter to a <cfswitch> tag and uses our old friend <cflocation> to deliver the graphic to the page. In this case the tag populates a small piece of the browser's window instead of actually navigating the session to a whole new page. Put simply, <CFLOCATION> is a nice piece of work.

<CFIF #domain#' eq Advertiser'>
<CFSWITCH expression=#inum#>
<CFCASE value="1">
< CFLOCATION url = "http://www.YourDomain.com/banner.gif">
</ CFCASE > ...

As we all know, anything that moves on the Web makes a big splash in the viewer community. (The first person to put a full-scale Chevy commercial on the Internet will no doubt be touted as a genius.) But while rotating banners may be fun to observe, they're not worth much without a statistical reporting package to provide advertisers with crucial data showing how many people are viewing and clicking their ads. Hence the KntRpt.cfm.,p> The first thing the stats program does is request a user ID and password from the viewer in login.cfm, which then passes control to the statistical reporting module, KntRpt.cfm. By making the user ID identical to the #domain# parameter used in the rotation and click code, this program is able to use the advertiser's user ID to access a set of data that pertains to his or her account. It then displays the account's daily, monthly and inception-to-date page views and clicks. In addition, since we have diligently stored IP information with each click record, the stats program is able to determine which clicks are unique and which have been generated by a user who is enamored of his left mouse key. An example of the click section of the report is displayed in Figure 1.

The program distinguishes between nonunique and unique clicks as follows: to calculate the former, the program just uses the SQL Count() function to add the number in the Clicks field, based on a given grouping as described above. To collect clicks by unique IP, the program counts the IP_Addr field instead. For example, if IP address 123.1.123.12 is clicked 202 times on May 12 (see Figure 2), it's only counted as one unique click (since it resides in a single record for that day). It counts as 202 nonunique clicks, however, since that's the value stored in the Clicks field.

To keep the report somewhat brief, the program limits daily stats to the current month only via a combination of ColdFusion's month() and now() functions in the SQL WHERE clause. For previous months it collects a cumulative number in one row by grouping on the month() function. For an inception-to-date number it simply eliminates all date screening from the SQL statement.

WHERE clause from daily report:
"WHERE Month(StatDate) =
Month(Now())..." GROUP clause from monthly report:
"GROUP by Month(StatDate) ..."

Page views are collected in a manner similar to that for click-thru stats; the exception is that in our current scenario we don't distinguish between unique and nonunique views. Once the SQL statements have populated all their respective buckets, the data is presented to the user via some simple HTML tables. To prevent ColdFusion from spilling error code onto the viewer's screen, if a campaign has yet to accumulate any clicks or views, the program wraps a couple of conditionals around the display code to ensure that the buckets are greater than zero before writing them to the page.

Currently the banner program handles one domain at a time by using the #domain# parameter to isolate a particular account. No doubt some readers will wonder why I didn't take my code one step further and design a way for the program to accommodate multiple domains within a single page, the way the large networks (DoubleClick, 24/7, BURST!, etc.) do. This would entail eliminating the domain parm and rotating not only single banners but multiple suites of banners, with each suite representing a different advertiser.

The simple answer is to use cookies the way the big boys do (AdForce, DoubleClick DART, et al.). This has become the de facto standard for addressing the stateless nature of the Web and it applies to this scenario as well. At the time of this writing I hadn't included this functionality, but look for it in my next article.

More Stories By Stuart Newman

Stuart Newman is the owner and operator of NY Rock (nyrock.com),
a New York-based
entertainment site.
In addition, he's
president of the
consulting firm of Scott Commmunications Inc., and a partner in
ECMedia.net, an Internet advertising start-up
venture.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Scott 05/16/03 11:26:00 AM EDT

this is a test....