Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

Advertising -- suggestions

Quote Reply
Advertising -- suggestions
I asked this once before, and I'm asking again.. for a banner rotation program, what would you like to see, and how would you like it to work?

I don't want to debate the issue, I just want to know _how_ you would like banners, advertisers, graphics, etc, managed on your site if you had an integrated links/banner program.

_MY_ needs are not "normal" but it's easier to code in the flexibility early on, when designing the database, then to go back and try to do it later.

What features/fields do you need?
How do you want to group banners, ads, rotations, zones, cycles, etc?
What management tools do you need?
How do you want banners to come up on the site?
Do you want advertisers to have access to their banners/ad campaigns, etc.
Do you want it "advertiser" based, "campaign based", "zone based" or what?

Give specifics -- compare it to what you are doing now, and how you want it different.

Database design is serious stuff ---- and this is a _very_ complex task. I've been chipping away at it for almost 6 months. It's easy to get redundant data, cyclical tables, and poor design. It's not easy to do it right Smile

Writing the program is probably going to be the easiest part of the whole process, especially if I use DBSQL to proxy it. The _real_ hard part is the data tables and dependencies. If you don't believe me -- just try it!! Smile

Think about advertisers, banners, campaigns, zones, pages, locations, targeting, etc and how much data that entails, and how each piece of data should only be entered ONCE and propagated through the system as intended. It's _not_ easy! I get a headache (literally) every time I put more than about 20 minutes in on it.

Once the tables and dependencies are set up, getting the images to display is EASY!

So, this is where I need all the feedback on _HOW_ you want -- or need -- a banner display system to work.

((and if the database and dependencies/logic is set up right, the back-end should be portable across front-ends -- ie: PHP, Perl, or whatever, with minimal coding, since the _access_ would be via a simple SQL call from the small CGI triggered in the <IMG> tag for HTML, or with a PHP function call for PHP. -- the admin program would be the complicated part (making sure all the dependencies were set right) -- that, for now, will be perl based.))

Long, wordy, but at least I got it out!! Smile

POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: Advertising -- suggestions In reply to
Here is what would definatly be needed.

-> Advertiser Login.
-> Zones.

When Advertisers use more then one banner (say 3 different 468x60's) they can see which is the most effective....

-> Weightings

Other then that, you obviously need to be able to track the impressions and clicks.

Then just put plently of comments throughout the code so I can make it do some other stuff that only my site would need Wink

Michael Bray
Review your webhost or find a new one.
Links SQL User

Quote Reply
Re: Advertising -- suggestions In reply to
I agree with Michael about Zones and Weightings. I would probably place the order of importance:

1) usable throughout site (not just within Links)

2) Zones

3) Weightings

I imagine if you're going to spend the time putting this together, that #1 is a given, but just in case... As you said, there are not many good ad rotation options, so it would be great if your program was made to function throughout the site. This would mean making it callable by SSI, image tags, and possibly javascript and php.

My use of banners is a main 468x60 at the top of most pages, and a 100 or narrower banner in a different spot. My current rotation only allows for random selection of one campaign, so things are somewhat manual at the moment. I would like to be able to set up campaigns A and B, for example, where A is large banners and B is narrow banners and call them something like:

<!--#exec cgi="/cgi-bin/ads.cgi?pool=A"-->

Also, some of the banner programs I've tried make things far too complicated to really be functional. For instance, each aspect of the banner like image source, text link, height, width, etc., must be set as a separate field. This can be far too limiting for many banner configurations. Easiest to use would be if all of the HTML info for the banner can be entered into a single text box.

Easy to set up is always nice. Smile

Statistics don't have to be very complicated. Impressions and clicks ought to be sufficient. Advertiser log-in are not a priority to me, although they certainly have value.

Being able to select the cycles (i.e. how many days or impressions to run the ad) would be a nice feature that I don't have with my current program. I could easily continue to live without it, though...

Quote Reply
Re: Advertising -- suggestions In reply to
I think this is one of the only things links SQL is missing and it would be a great addition to Links SQL. But I would talk to Alex before you start though because he posted this in a forum about 2 weeks ago:

We are working on an integrated banner program for Links SQL, it's still in the design phase right now though. Any input on what you would like to see would be useful.


As for features:

-By User Information in the database
-Name, City or State, etc.
-By category or search term
-I think this needs to be improved allot more then how it is in adcycle. I have a advertiser with 2800 keywords so a list of words divided by comas just doesn't cut it. I think the best would be to have a list box and then be able to add to it or remove from it.

As for management of advertisers and campaigns I think adcycles system is great. Each advertiser has a ID with a user name and password. Then you can add campaigns for that advertiser. Then each campaign will have specified a banner, locations, targeting stuff, etc.

I think a nice feature would be multiple types of media each with a id and then the ability to add new types of media... some examples are:
-Text Links
-Different Banner Sizes
-Rich Media
(you could give each media a template and then new ones the person would make a new template)

Also I think Central Ads Regions would be nice. So that sections of the site could be excluded or a campaign could run in only one Region. They could be managed like the new Groups feature in adcycle but you should be able to name them and add new ones.

I like the idea of the script being built into Links SQL so back up and restore would function the same. Also the script needs something to prevent cache.

Hope this helps,
Quote Reply
Re: Advertising -- suggestions In reply to
I had a look at Central Ads program today and its stats are very good. I look forward to moving my advertising script over to SQL, as slowly but surely my entire site is getting rid of flat file junk Smile Just the ads and the forum to go, and the forum is going to be PHP/MySQL very soon (I just need to learn some more PHP first).

What I want to know is... will this be a standalone product, or will it be controlled through to admin.cgi ???

Thanks Wink

Michael Bray
Review your webhost or find a new one.
Links SQL User

Quote Reply
Re: Advertising -- suggestions In reply to
I'm not sure where alex is with the script, but there are features that are "basic" and features that are more than that. I'm in that "more than that" category.

I need a program that will set up advertiser accounts, then let them (or me) set up campaigns, then enter banners into a farm, and assign them to campaigns, then assign campaigns to rotations, and assign rotations to zones.

There are quite a bit of things to consider -- I have multiple sized banners, in multiple locations on different pages. Each page location needs to be (if you want) a different "zone". You want each zone to have different "rotations" or banner groups that can be assigned to it. On top of that, you want the advertisers to be able to group their banners into campaigns, that function as a single banner, but rotate through the campaign. It's not a simple targeting of the top banner space.

On top of all of this, you need to have some statistical package, tracking, and way for the advertisers to access their stats. You might even want to give advertisers a way to change their banners... Maybe not.

No program out there can do it all.

AdCycle is not bad, but it's not well designed on the back end. It uses too many hard-coded and inflexible assumptions.

POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

Quote Reply
Re: Advertising -- suggestions In reply to

I noticed you mentioned having several sizes of banners. CentralAd sets the 'Size' and 'Target' with each banner in the client account. This may not solve your particular problem, but it is handy --particularly the Target attribute.

In my case, I had clients requiring dedicated buttons with special sizes and placement, I purchased a second copy of CentralAd just to handle them and separate them from my banner queue. Expensive, but works great.

[This message has been edited by bjordan (edited February 19, 2000).]
Quote Reply
Re: Advertising -- suggestions In reply to
It's still more than that.

If you want a real banner management system, you have to take into account what a "banner" is. Is it just a specific graphic image, or is it that graphic image in a variety of sizes? If you assume a "banner" is a list of files that all have the same message, in different sizes, then you need to set up a "banner" edit that defines a banner as a NAME->linked_list

The "flexibility" issue comes in here, as do you define a "banner" as only one of each size? Based on a list of accepted sizes in the config file? Or do you just assume a banner is a name of a collection of files? The code I have can go either way, but for the initial versions, and simplicity, I've decided that a "banner" is a single message, in a single version, in multiple sizes. Different versions of that message would each be a different "banner", grouped by campaign.

Then, you have to define a "campaign". Assume a campaign is something the advertiser buys (either once, or on a recurring basis). It has a defined set of rules and banners. At this point, a banner and a campaign are both "size" and "zone" independent.

Now, the advertiser has purchased what they wanted, or rather provided the information needed to fulfill their wants.

You have to match them to a rotation, location, and pricing plan (that goes back to the campaign and ratios).

So, the webmaster now needs to define "zones" on the site. A zone is a banner location. In links, a zone on the category page can be either a "one" item thing, or a "multi" item thing, depending on if you use keywords to alter your category pages or multi-cat pages, etc.

Zones can over-lap, as well. For this reason, I think I'm going to further break it down into "locations" (a specific advertising location in a file) and "zones" a collection of one or more advertising "locations".

Once zones are set up, you have a plan for how you want your pages, your site, and your advertising display to look.

Now, the webmaster has one more thing to do, and that is to assign "campaigns" to rotations, and the rotations to zones.

A rotation is a collection of campaigns. Remember, an advertiser has banners, that are grouped into campaigns. So, the webmaster now organizes those caapaigns into "rotations" that figure all sorts of things ... this is a very complex idea. Not fully hashed out yet.

Once the rotations are assigned, the "advertisers" need to be linked to the "zones" and that is done by assigning rotations to a zone, or zones.

Now, in the display of the advertising, a zone can only display a banner if it has a matching "location" size. On top of that, you have to have active "campaigns" with unexpired "banners".

In the Admin, the admin has to be smart enough to know that when you assign a rotation to a Zone, that some banners _will_ display. If not, you'd have a "broken" site, and your advertisers would never get displayed.

For speed, you have to "compile" the cross of zones/rotations/campaigns/banners into a table that can be quickly accessed by a complex index key.

By doing the large bulk of the work once, during the compile, all the banner display program has to do is "ask" for a file that meets the criteria that was specified.

An indexed lookup is very fast.

The problems with most programs start from the begining.

They dont' define "banner" and/or "campaign" properly, or logically.

They concentrate on size, or location, or ratios, or other criteria that are EXTERNAL to the data definition.

Then, they fudge rotations and zones again, concentrating on information that is not part of the data definition.

"Campaign" is still my most undefined concept, and "rotation" is my most un-coded logic.

A "campaign" has to take into account several things, including the accounting. The rotation only specifies how it's going to show up, and with what other "campaigns", and in which zones.

A rule of thumb on database design is, if you design the database properly, the code almost takes care of itself -- ie: the data definition structures the information in such a way that each time data is added, it's turned into "information" by how it's stored, not what is done to it on the way out. The better the data design, the more ways you can massage the output to look the way you want.

So, when this database is designed, When an advertiser enters a new banner set, and assigns them to campaigns, then purchases "credits" for the campaigns, the stage is set for the webmaster to enter them into rotations which can be already set up based on how s/he wants the site to function.

All the page has to do is trigger a snippet of code to pluck a banner from the waiting queue. If the queue is empty, then a default banner/campaign is used. Every rotation has a default.

Then there is the whole issue of accounting Smile Does an advertiser just purchase a spot, or a number of rotations, or do they purchase an "amount" of advertising, and you can weight/assign it to different rotations and locations and charge a variable amount for each display?

Hope this clears up where I'm going with this, and why it's not so simple.

POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/

[This message has been edited by pugdog (edited February 19, 2000).]