AdForce On-Site V1.0
(was Remote Ad Serving (RAS) )
Market Requirements Document
V2.0.3
Fifth Draft
Prepared by:
Eduardo F. Llach - Dir. Prod. Marketing
Purpose of this Document................................................................................................................. 2
Required Input.................................................................................................................................. 2
Background...................................................................................................................................... 2
Definitions......................................................................................................................................... 2
Functional Requirements.................................................................................................................. 4
Schedule Requirements................................................................................................................... 7
|
Distribution list: |
Distribution list (cont.): |
|
Harish Rao |
Changes: Updated 10/29/98 – EFL Updated V2.0 – 5/25/99 – EFL Updated V2.0.1 – 5/25/99 – EFL Updated V2.0.2 – 6/2/99 – EFL Updated V2.0.3 – 7/19/99 - EFL |
This document identifies a market requirement for serving ads to large clients who:
· Include more than 4 ad tags per page or,
· Include HTML text mentions and/or Rich Media or,
· Want an API to insert ad tags into their dynamically generated ads or,
· Have sponsorship ads which are not changing frequently and would like to have a more efficient and possibly less costly solution for serving them or,
· (for V2.0) Want to pass ‘private’ data used for targeting, but which needs to be kept w/in the site’s network.
· Are not satisfied w/ the browser based serving model normally used by AdForce.
A large client is defined as having more than 5 Million ad impressions a day. AdForce Remote Ad Serving (On-Site) uses an ad tag insertion mechanism to include the appropriate adforce tag within the client’s HTML document before it is served by the client’s web server to the user’s browser.
The On-Site Architecture will also be compatible w/ distributing On-Site with Proxy servers such as Inktomi’s Traffic Server. Under these circumstances AdForce’s On-Site is working w/ an equivalent Web Server to provide ads that are targeted to local, demographically or data targeted ads based on information passed by the Traffic Server.
· Executive Management, Marketing, Sales, Operations & Client Services – Please indicate whether requirements reflect the business need.
· Development – Please scope the effort needed and schedule this functionality.
· API – Application Programming Interface – Allows the site’s programmers to integrate On-Site w/in their page generation systems
· Creative – the actual ad file – the GIF banner, html, Java applet, video etc.
· Private Site Data – Data that is proprietary to the web site serving the pages, data that can be used for targeting ads. This data can be demographic profiles, zip code, user behavior profiles, etc. Web sites are sensitive to letting this data out, yet they want to ‘monetize’ it by creating a higher CPM inventory of targeted ads. To meet their requirements we need to provide a ‘local’ solution which they can use to pass the data, keep it w/in their network and yet be able to serve targeted ads.
· Server plugin - A mechanism used by web servers to add programmable functionality. We will use it to insert ad elements into an HTML Web page.
· tag – an html instruction (e.g. <A HREF>, <TABLE>, <IMG SRC=>, etc.). In the case of advertising, a tag is a fragment that specifies the source of the ad and instructs the browser how to display it (source, size, border, link, alt text, etc.)
·
Static Ad – an ad which changes less than 1
every 1,000 impressions. An ad, which does not require any sophisticated
targeting or IMS management.
· Dynamic Ad – non-static ad.
Background
This mechanism has proven to work well for banners that are dynamic, changing the content served at least once every 100 page views. AdForce’s data center has proven it can scale up and the response perceived by the User has been adequate.
There are several problems when you have more than 4 adforce tags per page being served from a central location.
1. Our analysis shows that the combined time for setting up serially 4 or more connections between the browser and our central ad server are making the pages render too slowly.
2. The tags are usually read serially due to our use of I-Frame and JavaScript, which allows us to handle a variety of browsers but causes a serial loading of the tags. Normally the browser can read three ads in parallel, but in the case of JavaScript the process is reduced to one ad read at a time.
3. We can’t optimize the tags to the actual browser loading the pages since we can’t tell the browser type. The server serving the original page can tell the browser type, yet that information is unavailable to AdForce’s centralize server.
4. Large clients are putting price pressure, yet we are running against unmovable costs such as the needed bandwidth to serve and ad, which doesn’t come down dOn-Sitetically as our volume increases.
5. Large clients tend to have pages divided into banner space (dynamic ad) and sponsorship space (static ads). The pages tend to have 1 or 2 banners and 2 to 8 sponsorships.
6. Currently we estimate that at least 60% of a large site’s inventory goes unsold, a good portion of that inventory is filled w/ either ‘house ads’ or barter inventory. The site does not want to pay our normal prices for this, they will pay for the scheduling and reporting services, but not 20 to 30 cent CPM.
7. AdForce serves dynamic ads very well, our whole infrastructure is designed for them. The On-Site mechanism should only insert the appropriate AdForce tag, based on the browser, that then calls our centralized ad server.
8. AdForce serves static ads inefficiently, we have an elaborate mechanism for rotating and targeting banners, for counting, for inventory management, for reporting, etc. The dynamic ad mechanism uses re-directs, which slow down ad retrieval. Yet for static ads you only need to schedule them, count and handle click-throughs. Correlating the banner ad w/ the static ads in the page can do static ad counting. Another feature of static ads is that they should be cached, especially since we can use the banner or the On-Site mechanism to count them.
AdForce is finding it increasingly difficult to ‘own’ all of the ad targeting data, contracts like the one with 24/7 and others are forcing us to create new methods for targeting ads, not necessarily based on the cookie user ID. We will need to learn to use ‘shared’ data for targeting, and use ever more abstract forms of user data, which are coming from other sources.
Competitive Landscape
AdForce is competing against DoubleClick, Netgravity, Accipiter, RealMedia, all of which either have local (site-side) solutions or are developing them.
The site-side solution has several drawbacks (see site-side vs. centralized white paper), but it has the following key benefits which are compelling to large websites:
· Ability to easily integrate into the web site’s application server infrastructure, so ads can be inserted into a dynamically created page using the site-side server’s API
· Ability to pass private data to the site-side server and have complete control of the data
· Ability to completely manage all the data created by the ad server, no issues w/ site domain names, site cookies, etc.
· Ad Counts that match the web site counts. In reality these may not be as accurate a representation of what is really happening as AdForce’s counts, but they will be consistent w/ the web site counts. This matchig of counts makes it easier for the site to manage tight inventories and make last minute and real time changes in campaigns.
Note: Need to check NetGravity’s API to see if we can be consistent – facilitate the move for sites from NetGravity to AdForce On-Site…
The following sites are candidates for AdForce Remote:
· Customers:
· Prospects: CNN, LookSmart, C|Net, Lycos, Deja, Go2Net
CNN has stated that they will not work w/ us unless we support some form of local ad serving.
Objectives / Goals
1. Reduce latency of full page load (including ads) for a page w/ 4 or more ads.
2. Reduce ad delivery costs to AdForce – this is post installation costs and does not assume that we will charge less for On-Site delivered ads, just that we should experience a lower cost of delivery.
3. Improve user experience:
· more ads fully rendered (text mentions and HTML ads),
· more options for Rich Media ads targeted to the particular browser,
· less browser / tag errors (mostly due to browsers which have bugs associated w/ JavaScript)
4. (for V2.0)Target ads using locally provided private data, staying w/in privacy constraints.
5. Provide server side solution required by several of our current and prospective customers.
6. Provide sit-side ad insertion option, to counter our competitor’s benefits (real or perceived)
Requirements
On-Site is a solution that would solve a number of the challenges described above.
The basic assumptions are:
· Web site’s pages/content is ‘programmed’ with the tags indicating the standard AdForce tag information (Request type, Tag Version, Network ID, Content Unit ID, Ad Size ID, Border/Width & Height) . This ‘programming’ can take two forms:
· Call via server side include or plugin syntax. The page is ‘tagged’ using this syntax.
· Call via C or C++ API, where the logic is kept within the application server’s page description language and the application server calls AdForce’s On-Site system passing the relevant information.
· On-Site interprets the On-Site tags and returns the appropriate ad tag for image, HTML code, JavaScript or Java Code that implements the ad.
·
The On-Site at the customer’s site will be able to be
updated w/ the appropriate information to serve up and replace the On-Site tag
w/ the HTML, GIF image call, etc.
The Overall Requirements are:
1. Seamless integration w/ centralized ad management, IMS and reporting
2. Significantly lower overhead for maintenance and operations (as compared to typical on-site servers)
3. Support of process API (C, C++, Java, Pearl)
4. Support ‘end to end integration’, which can include a SSI or NSAPI interface for various Netscape and Apache servers.
· Conversion process for new NSAPI – SW upgrades – Extensible API
5. Performance Guarantee (needs to be defined – will have to wait until Beta deployment)
· How many ads per second ( From Web server, how many pages, and how many ads per page – average & peak)
· Max. latency per ad request (which could be a request for several ads)
· Under what conditions (machine, OS, web server type…)
6. Will comply w/ secure serving requirements for HTTS URL.
· (V2.0) May need to comply w/ secure serving’s protected protocol requirements (Need to see if this is needed)
7. Seamless Reporting
8. Counting of ads – will not be AIB complaint – Need to indicate method used for counts in Reports
· (V2.0) Reporting will separate On-Site counts vs. Browser fetch counts.
9. Text mentions inserted
10. Serve multiple Ads per page
· Lower response time for serving multiple ads
· Lower costs for serving multiple ads
11. Minimal requirements from customer’s IS dept when installing On-Site at their site.
12. Diagnostics system to alert of any issues w/ On-Site (both to customer ? and to AdForce)
13. If the solution is a software only solution, require that AdForce On-Site runs on:
· OS: SUN solaris, BSD. Web Server: NSCP
· (V1.5) OS: Lynux. Web Server: Apache
· (V2.0) OS: NT. Web Server: IIS
14. If the solution includes a ‘gateway’ (i.e. hardware) then:
· Ethernet plugin compatible.
· Monitoring diagnostics.
15. Fail-over recovery, which inserts standard AdForce browser pulled ad tags. Insert appropriate tags depending on browser, including the tag for the dynamic ads
16. Fail-over recovery of all parts of the On-Site architecture.
17. We will still do our needed cookie setting and tracking. We may use cookie matching mechanisms.
Issues
1. QA concerns – deployment at User’s site – Testing at
user’s site.
2. Easy testing of On-Site system at customers site,
Response Time
Our current response time for serving 1 or two ads per page is adequate, but for serving 4 or more ads per page we are not performing to the levels required by our customers.
There are a few specific issues to address:
· Perceived time to load a page. The customer is most sensitive to seeing a blank page with just a banner and no content. They are most unhappy if they have to first wait for the ads to load and then their content.
· So the perceived time is the time from request to having some or all the desired content rendered.
· If the ads load in parallel and some load while the User is reading the content, that is preferred.
· The total time to completely load a full page, ads included is less relevant than the perceived load time.
Under the current mechanism, there is:
1. T1 – Setup HTTP connection between User’s browser and AdForce HTTP Server
2. T2 – Issue request for Ad
3. T3 – Send the Ad or information requested
4. T4 – close the connection between User’s browser and AdForce HTTP Server.
For every ad request T1 – T4 is executed twice.
1. Once to determine which ad to serve, the result being a redirection to our image servers or possibly our partner (i.e. for some rich media, such as InterVU). In this case T1+T2 >> T3+T4
2. Second time to deliver the needed ad image from our Image Servers. T1 + T2 < T3 + T4, in the cases where the ad is using more than 15K images.
Multiple Ads on a Page
When more than one ad is requested from AdForce using Javascript, each ad must be delivered completely before the next can begin. If the ads are selected at page generation time, then the browser only needs to make image requests, which can be made more quickly.
AdForce Remote must be able to accept a request for several ads in a single call, resulting in the Web server including the creative tags in the page. The image requests then take place as they currently do or they may be fulfilled by image servers on the Web site.
Figure 2: Timing Comparison
We have made commitments to customers re: On-Site