Purpose
Right now scoop is a pretty complete system. Users can setup and run
sites with (relative) ease. But if a user wants to sell ads from their
scoop site, they have to custom code a system for accepting ads, choosing
which to display, and keeping track of how many times each was displayed.
This ad system would be built into scoop, and take care of all of that
for the user.
Description/feature list
Ad Submission
There should be an easy way for potential advertisers to get their ads
on a given scoop site. A page would be set up to take all of the necessary
information for a given ad. Most likely split up into 2 pages, where
in the first page, they would give contract name, email, phone, snail
mail address, business name. On the second page they could upload the
ad, any related code to go with it (javascript, java, flash, whatever)
and submit the ad. Maybe not allow them to get to the second page w/out
a valid email. Perhaps a user account on the site, tagged 'advertisor'
that will add a link to a stats page about their submitted ads?
The site administrator would be able to set what type of ads to allow,
as well as the messages to give to the potential advertisors. If you
only allow gif/png/tiff/jpg ads, then only allow them an upload link. If
you allow javascript, give them room for N chars in javascript (settable
in a var), if you allow java as well, give them an upload link for the
.java file. flash, for the .swf file, etc.
There will be a field for a url for the ad to link to, as well.
Advertisors should be able to submit as many ads as they want. They
will get a short description detailing the pricing of ads on the site
(set in a var :)
Also, it will tie into the redhat credit card verification system.
http://www.redhat.com/software/ecommerce/ccvs/ to take the credit cards
and payments. (opinions on how to bill? Through cron? by hand?)
Ad Display
Boxes will be used to display ads. Perhaps a syntax like the following:
|BOX,ad_box,<banner or box>[,optionalAdvertisorID]|
the optionalAdvertisorID would be for perpetual ads, like the case of the
VA hosting logo on kuro5hin.org. There might be a need for other
arguments as well, to that box, but that will be dealt with later.
Ads will be displayed in a round-robin fashion. They will be marked
with the last time displayed, and the one with the oldest last time displayed,
of a given type (banner or box), will be shown.
Ad Administration
- Approval
Ads will not start displaying on the site until a site administrator
approves the ad. The administrator will be able to preview the ad, without
running any of the code, or with running all of the associated code, at the
admin's discretion.
- Listings
The administrator will have a list, similar to the Story List and Poll List,
that will show each ad's ad id, the submitting business, a link to a preview
page, the number of times its been shown, and a link to detailed information
about it. Also a checkbox beside it, to enable or disable the ad (similar to
the rdf admin tool). The ad info row will show up in a different color if
the ad is pending.
Admins will be able to sort ads by most shown, by ad id, by contact/business
name, or by least shown.
- Ad Detail
In the ad detail page, admins will see all of the info in the listing for
that ad, as well as CPM (cost per mil), estimated amount they owe, and
links to other ads by the same business/contact.
There will also be a small
form, where the administrator can generate either an html or text report,
of the amount of ads shown, and the cost to the advertiser for any date
range given. Scoop will keep track of how much you've billed each advertisor,
when, etc. Also will be able to give a summary of past billings, on a per
month basis (i.e. Jan, 45000 impressions, $10000000 charged)
- Variables
Admistrators should be able to set:
- The type of ads allowed to be submitted (java/flash/javascript/gif/etc)
- Number of ads per advertisor
- Max size of ad images
- CPM
- Allowed types to submit (banner, box, etc)
- any others suggested
Details
Storage
Ads images will be stored in a specified place on the hard drive, similar to
caching. Ad code will be stored in the database.
Caching
Ad id's and last view might have to be cached, or stored in a circular array,
so as to alleviate strain on the database for each page view.
Anything else?
So what do you think? I welcome all input, please tell me what you like and
don't like. What seems feasible or not. Features that you would like, and
stuff that isn't necessary.
-Andrew
