Banner

Management
System phase 1
Logical Design
02/2008
 Created By:
Alexander Dubinsky

Table of Updates
V Updated
Date Updated by Comments
er. Sections
1.0 Alex Dubinsky New Document
V Updated
Date Updated by Comments
er. Sections

Related Documents
# Name Type Author Document Content
Requirement Presentation Alexander Requirements
 s_HighLevel analysis + high-
Dubinsky
Design_1 level design
Etgerter e er

Document Approval
Ver. Role Date Approved By Notes
1.0 CTO Shlomi levi
 R&D
1.0 Eyal Tzelnik
Manager
Team
1.0 Eli Shemesh
Leader
 Contents
Table of Updates 6
Related Documents 7
Document Approval 8
Contents 10
1. Introduction 18
1.1. Background 18
 1.2. Design Goals 22
1.3. Terminology 23
2. Architecture 27
2.1. Introduction 27
2.2. Technology 29
2.3. Component model overview 29
2.4. Deployment model overview 33
2.5. System operation overview 35
3. System Interfaces 37
 3.1. Back Office 37
3.1.1. Libraries 37
3.1.2. Advertisers management 41
3.1.3. Campaigns management 41
3.1.4. Banners management 50
3.1.5. Reports 54
Impressions/clicks log 54
Impressions/clicks summary by campaigns/banners/advertiser 55
In next versions other reports will be added (according to specific client requirements
and according to our design – similar to Google AdWords). 56
3.2. Banner Provider 56
3.2.1. Pages for web applications 57
3.2.2. Web Services for all applications 61
4. Data 64
4.1. Introduction 64
4.2. Banner media files 65
4.3. Database 66
 4.3.1. Advertisers – Campaigns – Banners 67
4.3.2. Customizable features library 70
4.3.3. Banner and it’s features 72
4.3.4. Campaign and it’s features 72
4.3.5. Logs and counters to store impressions and clicks 72
5. Technology 75
5.1. General Overview 75
5.2. Main Hardware 76
5.3. End User Equipment 77
 5.4. Data Base Hardware 77
5.5. Development Tools 78
5.6. Maintenance Tool 78
5.7. End User Software 79
5.8. Backup and Recovery Tools 79
5.9. Data Security Tools 80
5.10. Testing Tools 80
6. Implementation & Deployment 81
6.1. Overview 81
 6.2. Physical Design 82
6.3. Implementation Phase 82
6.4. Testing 83
6.5. Guidance Phase 83
6.6. Assimilation 84
6.7. Maintenance 84
6.8. Risk Management Plan 85
7. Open Issues and Decisions 86
8. Appendices 88
 1. Introduction

1.1. Background
Many Infinity IT projects require banner managements system (EMN, Atomynet, Truvel).

Universal Banner Management System required to be integrated into other projects and provide flexible and
targeted rotation of different banner types in different “zones”.
System should allow “targeting” – presentation of the most suitable banners according to user profile or page
content.

System should be scalable and flexible and developed as a product to support easy extension for future needs.

See Requirements_HighLevelDesign_1.pptx for more information about requirements.

********** On the first stage decided to develop simple system according to the basic requirements only, but
plan and develop infrastructure allowing future extension of the system.

Basic system requirements displayed below:

uc BasicUseCase

Prov ide conditions and user BannerManagementSystem

Publisher Application data and receiv e suitable
banner

«flow» BannerProv ider BackOffice

Conditions are
zone (top, bottom, ...),
size,
format (GIF, FLASH, IFRAME, ...),
background color, etc.

«flow»
 1.2. Design Goals
On the first stage decided to design and develop simple system according to the basic requirements only, but
plan and develop infrastructure allowing future extension of the system.
Stage 1 requirements are:
• Only basic requirements (Manage banners, campaigns, define targeting rules, provide banners for
publishing applications.)
• Basic targeting (keywords/tags only)
• Single login for each advertiser
 • Client-side - Web Service (or JavaScript) access only, no .NET controls
• No upload wizards
• Basic Web UI
• Basic reporting without analytics , graphs etc.

1.3. Terminology
Advertisers includes all information about the advertiser including: company name, description, web site,
contact, contact's email, login name/password for viewing statistics, address, telephone, and fax information.
Banners are assigned to each advertiser. An unlimited number of banners can be specified for each advertiser
and this includes information such as: banner ad description, target URL, image URL, text to display when
mouse is hovered over image, height, width, border, alignment, optional text to display underneath, and whether
or not to launch a new instance of the browser when the banner is clicked.

Campaigns are simply a group of banners specific to an advertiser. A campaign includes the following
information: campaign name, advertiser, included banners, banner weighting, start/end date, type of campaign
(Flat Rate, CPM, or Per Click), quantity purchased by advertiser, cost, days of week to display campaign, and
daily start/end time.
Publisher is an application providing placeholders for banners.

Targeting is determining where and when the advertising is delivered using criteria like audience segmentation;
geographic selection by DMA, zip and area codes; time of day and specific days; browser type and operating
system; and keyword.

Banner Physical properties are size, media type, zone etc.

Banner/Campaign Targeting properties are target auditory description – age, interests, keywords, location etc.
 2. Architecture

2.1. Introduction
Banner Management System will be developed as an ASP.NET web application, multi-layer, data-connected.

System will have web GUI (BackOffice) for banners and campaigns management, administration and reporting.
System will have interface (Web Service, special web pages) allowing other applications to send banner request
(size, type etc.) and receive corresponding banner. This interface will also register banner impressions, clicks
and perform redirection. (Banner Provider).

System will store its data in database.

 2.2. Technology
Application - ASP.NET 2.0 + Web Services + JavaScript.
Database – MS SQL Server 2005.

2.3. Component model overview

System basic components structure is displayed below:
class 1BasicStructure

Banner Management System

PublisherApplication

Zone=FrontPageT op; Size=480x60;

Page Keywords="Football;Israel;"
BannerProv ider
Placeholder phisical data and User data
Page::Banner
placeholder
Banner + properties
BMS Interface

BackOffice

Receive banner
requests from
client Banners and
applications, campaigns
provide banners management,
administration,
reporting using
Web GUI

Publisher
System will have layered architecture for future scalability and flexibility:
cmp Layers

«execution environment»
MS SQL Serv er 2005

Database

«execution environment»
IIS + ASP.NET
Strongly - Typed
 2.4. Deployment model overview
System will be customizable and will be able to serve different publishing applications. Separate system
installation will be used for separate application groups with different requirements etc. For example one
separate installation will serve EMN, other separate installation will serve Atomynet. System may be installed on
the same server with the publishing system or separately on another server:
uc BasicDeployment

Client Application Web

Serv er

ASP.NET app

Banner Management System Serv er

Client Application Web

Serv er HTTP request for banner «execution environment»
media URL, request for SQL Serv er
JavaScript file and HTT P
PHP app request for redirection when
BMS Database
banner is clicked

«execution environment»
IIS+ASP.NET
2.5. System operation overview
1. System users (administrator or advertisers) will upload banners using Back Office. For each banner
they will set banner name, URL, size, zone and other properties.
2. System users will create campaigns using Back Office. For each campaign they will set campaign
name, expiration conditions, and targeting conditions.
3. Publishing applications (applications like web sites, windows applications, other applications) will get
banners using Banner Provider. They will provide a request containing required banner size, zone,
 targeting information and receive suitable banner. Banner Provider will also register each banner
impression or click.
4. System users (administrator or advertisers) will get impressions/clicks reports using Back Office.
 3. System Interfaces

3.1. Back Office

Back office will allow advertisers, campaigns, banners, users management and administration, and banner
impressions/clicks reporting.

3.1.1. Libraries
Used to manage libraries. Only for application administrator.
Status library:
Banner/Campaign customizable properties library:
 3.1.2. Advertisers management
Manage (create, update, delete) list of registered advertisers. Only for application administrator.
Present a list of advertisers (Id, name, status, etc.).
Allow changing name, status, managing advertiser’s login account (name/password).

3.1.3. Campaigns management

Manage (create, update, change status) list of campaigns for currently logged in advertiser.
Campaigns list:
Campaign screen:
 3.1.4. Banners management
Manage (create, update, change status) list of banners for currently logged in advertiser nad /or selected
campaign.
Banners list:
Banner screen:
 3.1.5. Reports

Impressions/clicks log

Date & Advertiser Campaign Campaign Banner Id Banner Client Event

Time Id Id name name IP (Impression or
(click
 Impressions/clicks summary by campaigns/banners/advertiser

Selected report aggregation: campaigns or banners or advertiser

campaign or banner or advertiser name Date Number of Number of
impressions clicks
 In next versions other reports will be added (according to specific client requirements and
according to our design – similar to Google AdWords).

3.2. Banner Provider

Banner provider module allows other applications to send banner request (size, type etc.) and receive
corresponding banner. This interface will also register banner impressions, clicks and perform redirection.

Banner provider will serve both web applications and windows applications, both server-side and client-side of
these applications.
 3.2.1. Pages for web applications
1. Page which will provide JavaScript which will take care of banner placement and rotation.
GetBannerPlaceholderJS.aspx?FeaturesRequest
FeaturesRequest specifies list of features for banner selection – banner should comply to the features.
FeaturesRequest format is a list of name=value parameters, where name is a feature group name and value is_
delimited list of specific features inside the group.
For example, client web application will put the following code on a web page as a banner placeholder:
<script
src="http://www.infinityit.com/BannerMS/GetBanner.aspx?Size=480x60&Zone=WebFrontPageTop
&KEYWORDS=ISRAEL_HEBREW_STUDENTS" type="text/javascript">
</script>
Then Banner Management System will find banner and generate and return JavaScript code which will place
this banner on the page.
The generated javascript will perform document.write of the following text (for example):
<a href=”www.infinityit.co.il/BMS/BannerRedirect.aspx?BannerCampaignId=235”>
<img src=”www.infinityit.co.il/BMS/GetMediaFile.aspx?BannerCampaignId=XXX” >
</a>

Approach is suitable for all web applications, used by most banner management systems.

2. Image / media file retrieval page

GetMediaFile.aspx?BannerCampaignId=XXX
Page which returns response containing image or other media file body itself. Instead of providing direct link to
the image like www.domain.com/BMS/banner.gif, it is better to provide link to aspx page which will control file
retrieval and will be able to register the impression and save other information.

3. Redirection page
BannerRedirect.aspx?BannerCampaignId=XXXX
This page will be used for banner links – when banner’s target URL provided to the client application will contain
this page and banner Id. When banner is clicked, this page will find specific banner and campaign, register click
and redirect the request to real banner’s target URL.
For example, HTML placed/generated for client application web page could be:
<a href=”www.infinityit.co.il/BMS/BannerRedirect.aspx?BannerCampaignId=235”>
<img src=”www.infinityit.co.il/BMS/GetMediaFile.aspx?BannerCampaignId=XXX” >
</a>

3.2.2. Web Services for all applications

1. Get banner image URL and redirection URL , without targeting

int GetBannerUrlSimple(string SizeTag, string ZoneTag, out string MediaURL, out string TargetURL)
Client application provides required size code and zone code, receives banner image URL and redirection URL.
Then client application may insert banner into web page, e.g.
<a href=TargetURL><img src= MediaURL ></a>

2. Get banner image URL and redirection URL , with targeting and additional parameters
int GetBannerUrl(FeaturesList FeaturesRequest, out string MediaURL, out string TargetURL)
Client application provides list of suitable features, receives suitable banner image URL and redirection URL.
Then client application may insert banner into web page, e.g.
 <a href=TargetURL><img src= MediaURL ></a>
FeaturesRequest format and specification will be provided later.

3. Get banner image body and redirection URL , with targeting and additional parameters
int GetBannerMedia(FeaturesList FeaturesRequest, out string MediaBody, out string TargetURL)
Client application provides list of suitable features, receives suitable banner body (media file contents in
hexadecimal) and redirection URL. Then client application may insert banner body into application and provide
TargetURL. Suitable for Windows applications.
 4. Data

4.1. Introduction
Data involved into the Banner Management System is:
1. Banner media files
2. Information about advertisers, campaigns, users etc.
3. Banner Logs - Information about impressions and clicks
 4. Application logs – information about errors, exceptions, warnings etc.

4.2. Banner media files

System fill store uploaded banner media files in one specified folder. Files will be stored in their initial format.
File name will be <original file name>_[<number by order>].<original file extension>. <number by order> section
is optional and will be used only if file with such name already exists.
 4.3. Database
Information about advertisers, campaigns, users etc. and also Banner Logs - Information about impressions and
clicks will be stored in database. MS SQL Server 2005 database server is selected.
4.3.1. Advertisers – Campaigns – Banners
class CampaignsDB

Banners

«column»
*PK BannerId: int
FK BAdvertiserId: int
BannerName: nvarchar(50)
BannerStatusId: int CampaignBanners
BannerMediaPath: nvarchar(256) Multiple banners
BannerMediaUrl: nvarchar(256) may be assigned
«column»
BannerTargetUrl: nvarchar(256) to specific
(CBBannerId = BannerId) *PK CBId: int
BannerTextUnder: nvarchar(100) 1 campaign. One
FK CBBannerId: int
banner may be
FK CBCampaignId: int
0..* assigned to
«FK» CBBannerStatusId: int
multiple
+ FK_Banners_Advertisers(int) campaigns.
«PK» «FK»
+ PK_Banners(int) + FK_CampaignBanners_Banners(int)
4.3.2. Customizable features library
uc FeaturesLibDB

Features

«column»
*PK FeatureId: int
FeatureParentId: int
* FeatureName: nvarchar(100) Hierarchical
FeatureIsSystem: bit customizable
FeatureDescription: nvarchar(100) features library
FeatureAttributes: nvarchar(100)
FeaturePriority: float
FeatureXMLTag: nvarchar(100)
FeatureOrder: float

«PK»
4.3.3. Banner and it’s features

4.3.4. Campaign and it’s features

4.3.5. Logs and counters to store impressions and clicks

 5. Technology

5.1. General Overview

Fill out this section once you have completed filling out all other sections of the chapter.
For example:
The hardware and software requirements are dictated by the company's constraints and
include the following:
Microsoft environment.
The database is MS SQL Server.
For more details, please refer to the main system document.

5.2. Main Hardware

Enter the HW list, e.g. servers, firewalls, load balancers etc, as prepared by the IT
department.
 5.3. End User Equipment
Enter the HW the user of the system/module will require.

5.4. Data Base Hardware

Microsoft SQL Server 2005.
 5.5. Development Tools
For client - Microsoft Visual Studio 6 – Visual C++
For server - Microsoft Visual Studio 2005 etc.

5.6. Maintenance Tool

Source safe ??????
 5.7. End User Software
Enter end user software to be used, e.g. Internet Explorer 7 etc. Enter “None” if no such
equipment is required.

5.8. Backup and Recovery Tools

Enter backup and recovery tools to be used, e.g. data tapes etc. Enter “None” if no such
equipment is required.
 5.9. Data Security Tools
Enter data security equipment to be used, e.g. application Firewalls, SSL certificates etc.
Enter “None” if no such equipment is required.

5.10. Testing Tools

Enter data security equipment to be used, e.g. Mercury Load Runner etc. Enter “None” if
no such equipment is required.
 6. Implementation & Deployment

6.1. Overview
Fill out this section once you have completed filling out all other sections of the chapter.
This chapter will describe the managing, planning, developing and maintenance phases
of the project.
 6.2. Physical Design
<Name>, <position>, is in charge of the physical design phase.
The phase’s estimated completion date is <date>.

6.3. Implementation Phase

<Name>, <position>, is in charge of the implementation phase.
The phase’s estimated completion date is <date>.
 6.4. Testing
<Name>, <position>, is in charge of the testing phase.
The phase’s estimated completion date is <date>.

6.5. Guidance Phase

<Name>, <position>, is in charge of the guidance phase.
The phase’s estimated completion date is <date>.
 6.6. Assimilation
TBD

6.7. Maintenance
TBD
 6.8. Risk Management Plan
TBD
 7. Open Issues and Decisions
List of open issues and their decisions:
Assigned Completio
# Open Issue Decision
To n Date
888 should supply to
IM Client API for
request user poker
data
 8. Appendices
List of appendices and relevant documentation that is not part of the main document