WO2002039361A2

WO2002039361A2 - Method and system for tracking revenue of online advertising

Info

Publication number: WO2002039361A2
Application number: PCT/US2001/046801
Authority: WO
Inventors: Anthony Key Compton; Gary Stephen Gluck; Jonathan Reid Bartlett; Tamara Lee Westen; Lisa Wenninger; Warren Habib; Ajay Kamdar
Original assignee: Solbright, Inc.
Priority date: 2000-11-08
Filing date: 2001-11-08
Publication date: 2002-05-16
Also published as: AU2002227261A1; WO2002039361A8

Abstract

A system for automating the processes of monitoring contract terms, billing methods, and campaign delivery and performance, in order to track and calculate recognized, actual, and deferred revenue at various times during an online advertising campaign. The system also automates advertiser billing workflow through system initiated scheduled billing, discrepancy reporting and resolution, data exporting, and revenue reporting. The system accepts terms of a contract and advertisement performance data, and tracks and calculates revenue based upon the terms of the contract and the performance data.

Description

Method And System For Tracking Revenue Of OnUne Advertising Background of the Invention:
This invention relates to tracking performance of onUne advertising. Traditional advertising is bought and sold using audience and delivery estimates (e.g. newspape__circulation.num.bers). Qnline advertisingis differenLfrom "traditional" advertising in that advertising campaigns can be bought and sold on exact, performance-based metrics, such as per advertisement view or "impression", per click, or other viewer action.-
Under standard online industry practices, the revenue from performance-based advertising campaigns cannot be recognized until the contractual commitments have been satisfied. Other contracts for onUne advertising are sold as flat-fee sponsorships running for a specified period of time.

Revenue for these contracts can be recognized only when the campaign has gone "live" and the contracted time period has passed. In short, the revenue from these contracts is deferred until the terms of the contract are satisfied. Because delivery of Internet advertising can be exactly monitored, processes for determining revenue to satisfy standard accounting principles have been used, which differ from traditional advertising businesses. One such process is recognizing revenue upon delivery of campaigns sold and delivered as guaranteed quantities (e.g. ad impressions and clicks). If payment is made in advance for the campaign, the payment is logged as deferred revenue and not recognized until delivery of the campaign. Revenue for campaigns delivered within a set time frame, rather than as quantity goals, can be recognized when the time period passes.

What is needed is a method and system that tracks performance of online advertising.
Brief Description Of The Drawings
FIG. 1 presents a illustrative system diagram through which benefits taught from the principles disclosed herein can be obtained; and
FIG. 2 presents a flowchart depicting an illustrative process that is carried out in tracking module 40 of FIG. 1.
Summary of the Invention
A server having a contract module for capturing terms of a contract, a database for storing the terms of the contract and performance data, and a tracking module for calculating revenue based upon the terms of the contract and the performance data.
A method for tracking revenue of online advertising.

The method acquires contractual data pertaining to advertising campaigns, acquires performance data of the _ advertising camp_ign .and.fracl_ r[alpha]venu__based upon_evaluating.the per ormance .data. and the contractual data.
Detailed Description
The system is intended to be used in an online advertisement environment where various parties participate in an advertisement campaign. Typically, an advertiser of goods or services, enters into a contract with a publisher (e.g. a party that operates an ad server) to distribute ("serve") advertisements on various web site web pages at various times, and at a certain billing rate. Of course, the times, quantity of advertisements, and billing rates depend upon the agreed upon terms between the parties, which will vary from agreement to agreement.

More specifically, any party (user, e.g. pubUsher) interested in tracking the performance of the contract would use a tracking module 40, HG. 1, to automate the processes of monitoring contract terms, billing method, and campaign deUvery and performance, in order to track and calculate recognized, actual, and deferred revenue at various times during the campaign. Tracking module 40 also automates advertiser billing workflow through module initiated scheduled billing, discrepancy reporting and resolution, data exporting, and revenue reporting.
FIG. 1 shows components of a tracking system that incorporates an embodiment of a tracking module of the present invention. The tracking system resides in a programmed general purpose computer 10 that has a database 100, a communication interface 60, a contract module 90.

Computer 10 includes the ability to communicate over the Internet 70 and view data using a web browser. Operating in conjunction with the tracking system are ad server module 50, and financial modulel20.
Communication interface 60 provides two way communications between computer 10, ad server module 50, financial modulel20, and Internet 70. Both ad server module 50 and financial modulel20 reside in general purpose computers having the capability to communicate over the Internet 70, view data in a web browser, and send/receive email . 5 Financial module 120 is a commercially available software program for generating invoices and other accounting documents. Great Plains Software Inc. offers a software program known as "Great Plains" that may be employed to reaUze module 120.

Other commercially available software programs that can be used with .tracking module 40, for_example, a[iota]e__E.eachtree '.by.Peachtree_Software Inc. ancL.
10 "QuickBooks" by Intuit Inc.
Database 100 is coupled to contract module 90 and tracking module 40 for the purpose of storing and sharing data. Contract module 90 stores contract terms and information pertaining to a particular ad campaign contract, including line item details and information pertaining to ad flight instructions for use by ad server module 50.
15 All of the details that a user puts into a contract gets stored in database 100, via contract module 90. Tracking module 40 stores bilUng calculations, such as reahzed and deferred revenue data and other campaign billing information in database 100. Although a single database is used, multiple databases can also be implemented.

Contract module 90 captures the exact terms of an advertisement campaign
20 through data entry by a user and stores the terms in database 100. The terms of the advertising campaign can be billing rates and periods, to name a few, which are agreed upon by the contracting parties. Some example terms are: duration of the contract, starting date, completion date, bilUng date(s), billing rate, which party to bill, whether to bill on time or performance, contracted performance data, and a cost
25 model are entered into contract module 90. Contract module 90 processes the contract terms to determine a billing schedule, both of which are stored in database 100 for use by tracking module 40. The billing schedule is the period or periods that a bill is generated for the ad campaign and is dependent upon the particular contract.

The billing schedule is determined by, for example, reviewing the contract start and stop
30 dates, and billing period(s). The user also selects type of ad server that is being used[lambda]in the ad campaign. This selection notifies tracking module 40 of the data format that the ad server uses. Contract module 90 is coupled to the tracking module 40 so that the modules can function and communicate with each other. Tracking module 40 is structured to receive inputs and provide output to-and-from contract module 90, or
35 any other contract module sharing the same input output format. Additionally, a skilled artisan could vary the inputs/outputs and format, without deviating from the spirit of the invention. As mentioned above, the user enters the agreed upon cost model into contract module 90.

The cost model is a type of online advertisement billing calculation method decided upon by the contracting parties when negotiating the contract. The cost model determines the metric by which performance of the contract is measured and billed. There_are_variousJypesjof cost, models usedj r buying and^selting online _ advertising. For example, cost per-thousand impressions or ad views (CPM), cost per click (CPC), and cost per-action varieties ((CPA); e.g. user registration or download on the advertiser's web site), sponsorships, and email.
Contract module 90 generates an electronic contract or "insertion order" that is transmitted to the advertiser (or its advertising agency, if any). The contract module 90 captures and describes the campaigns and line items, with an amount expected due (contracted amount) for each line item and a total for the entire contract.

The invoice that the publisher submits to the advertiser or its agency for payment also shows campaigns and line items with a final amount due for the line items and a total amount due for the entire contract for the current billing period. Tracking module 40 calculates these amounts due. The line item amounts billed by the publisher on the invoice do not necessarily equal the "contracted due" amount of the line items on the contract, due to variations in how the ads in the campaign actually performed when the flights were called by the web publisher's ad server and published to the web site. Contract module 90 is a conventional software program and is commerciaUy available. Solbright Incorporated offers a software program known as "AdSales
Manager" that may be employed to reaUze module 90.

Other commercially available software programs that can be used with tracking module 40, for example, are available from Salesforce.com and Siebel Systems Inc.
Ad server module 50 hosts and manages online advertisements for web sites. Module 50 resides in a general purpose computer having the capability to communicate advertisements to various web site web pages over the Internet 70. Tracking module 40 is also capable of communicating with ad server module 50, so that the modules can function and share data with each other. One function that ad server module 50 performs is monitoring advertisement performance, for example, quantity of impressions dehvered to web site web pages. This data is made available for tracking module 40, which can be shared in various ways.

A user having a report or a disk with the data can directly enter the data into tracking module 40, via P T/U 01/46801
5 computer 10. Additionally, tracking module 40, can communicate with ad server 50 to acquire performance data via the Internet 70. Ad server module 50 is a conventional software module. Engage, Inc. offers a software package known as "Engage AdManager" that may be employed to realize module 50. _ _. - - Tracking module 40 is^apable-otcommunicating-with. ad servers-having -
10 various information reporting formats. As discussed above, the user (web site publisher) indicates the type of ad server. Because there is no standard format for producing performance data, tracking module 40 must be able to convert the various ad server formats to the format common to tracking module 40.

This format is a file containing ad server performance data, such as advertiser, campaign, dates,
15 impressions delivered, cUcks deUvered.
As mentioned earlier, ad campaigns can be structured to generate revenue in various ways. Revenue for ad campaigns that are sold and deUvered as guaranteed quantities, such as ad impressions or cUcks, can only be recognized upon deUvery of those quantities. If payment was received for such a campaign in advance, the
20 payment must be reflected as deferred revenue and not recognized until deUvery of the advertisement(s). Revenue for campaigns deUvered with no quantity goals, guarantees or caps, but is instead delivered for a set time frame can only be recognized when the ad is live and that time frame has passed.

To expand on the traditional methods of tracking performance for ad campaigns, tracking module 40
25 monitors contract terms, billing method, and campaign deUvery and performance, in order to track and calculate recognized, actual, and deferred revenue at various times during the campaign. Tracking module 40 also automates advertiser billing workflow through module initiated scheduled billing, discrepancy reporting and resolution, data exporting, and revenue reporting,
30 In response to user selected inputs, tracking module 40 acquires performance data from ad server module 50 for use in determining actual and deferred revenue, and for reconciling contracts at the end of predetermined billing periods.

Tracking module 40 also acquires data related to an approved and processed contract, and generates billable items for the contract at scheduled periods (weekly, monthly, etc).
35 Performance data from ad server module 50 is also acquired by tracking module 40, for use in these calculations.
Tracking module 40 monitors the billing dates of the contract to determine when to calculate revenue. This is achieved by checking database 100 for any contract having an "event" on the current date. If a contract is found to have an "event", such as a bilUng period has ended, tracking module 40 acquires performance data associated with the campaign from ad server 50, and applies the appropriate performance metrics to the data.

As mentioned above, the performance data is acquired one- of several ways.-It can-b .-acquired automatically-by tracking module_40 requesting the performance data from ad server module 50. It can also be acquired manually by the user manually entering the performance data into a user interface of tracking module 40, or upload the data in file format from disk.
Tracking module 40 determines revenue for bilUng periods ranging from monthly (straight-lined or prorated-daily), weekly, prepay, start-o -contract, or endof-contract. The billing period allows users the option to choose the date range for billing or invoicing the advertiser. The monthly straight-line billing period reconciles the contract every month, beginning in the month the first campaign begins. The bilUng amount is spread evenly across all months, regardless of the number of days in the month.

The monthly prorated daily bilUng period reconciles the contract every month, beginning in the first month the campaign begins. Billing is prorated depending on the number of the days in the month being reconciled. The weekly billing period reconciles the contract every week, beginning in the week the first campaign begins. The prepay billing period is billed immediately after the contract is signed. The start of contract billing period is billed immediately upon the first day of the first campaign in the contract.

The end contract billing period reconciles the contract and generates billing amounts upon the conclusion of all campaigns.
Additionally, tracking module 40 has the functionality to compile, calculate, and compare data from the contract within contract module 90 to data from how the campaign performed from ad server 50 or other data sources, as specified by contract module. One of these options is the "BilUng Period," which determines how many times tracking module 40 should request data from ad server 50 or other data sources and how long each period for performance is meant to be. Choices for Billing Period may include weekly, bi-weekly, monthly pro-rated, monthly straight lined, quarterly, annually, etc. When either of the weekly billing periods is selected, the user must designate which day of the week represents the last day of the billing period (this is the week-end day).

When either of the monthly billing periods is selected, the user 5 must designate which date in the month represents the last day of the bilUng period (this is the month-end day).
On the end-day of the biUing period (week-end, month-end, etc), the tracking module 40 processes all the contracts which were active within the BilUng Period just . ended._Tracking-module 40 processes those. confracts.depe[iota] ding_u[rho] n_the_parameters
10 and attributes of each line item of each campaign within the contract.

The most important attributes of the line item that affect how the tracking module handles it include start and end dates, cost model, quantity, and cost:
Tracking module 40 tracks and monitors contract terms, billing methods, cost models, and campaign delivery and performance, in order to calculate revenue.
15 Tracking module 40 is coupled to contract module 90 and database 100, so that die modules can function, communicate, and share data with each other. Additionally, tracking module 40 communicates with ad server module 50 via the Internet 70, or by sharing a data file on a disk, or by keyboard data entry. Module 40 acquires contract term data from database 100, and advertisement performance data from ad server 50,
20 using one of the functions described above.

Included in the contract term data is a cost model that is associated with the contract being processed.
As described earlier, the cost model is a type of online advertisement payment method decided by contracting parties when negotiating a contract. There are various types of cost models used for buying and selling online advertising. For example, cost
25 per-tihousand impressions or ad views (CPM), cost per cUck (CPC), and cost peraction varieties (CPA), such as user registration or download on the advertiser's web site, sponsorships, and email, etc.
In preparation for revenue calculations, tracking module 40 acquires the cost model from database 100 and associates the cost model with appropriate performance
30 metrics within tracking module 40.

Because each cost model has different contractual parameters (for example, cost-per-thousand-impressions or cost-per-click) each cost model requires different calculations to determine revenue. Each cost model is defined by predetermined mathematical formulas that are used to calculate deferred and recognized revenue, based on the requirements of the contract and performance
35 data. To give a fairly simple example: Cost-Per-T[iota]iousand-bnpressions (CPM) = (Rate x Quantity Delivered)/! 000. The "Rate" is the agreed upon billing rate for serving an advertisement. The "Quantity Delivered" can be the actual or agreed upon number of advertisements served to web site web pages, depending upon whether tracking module is calculating actual revenue or contracted revenue.

Tracking module 40 appUes the contract data, which is represented by variable "Rate", and the performance data, which is represented by variable "Quantity DeUvered," to the metrics to determine the Cost-Per-Thousand-Impressions. At the-time-of bilUng,. tracking module-ACLrec.onciles_ad.performance_ against contract guarantees by determining the relationship between line items which are booked on the contract and billed on an invoice, and flights which are scheduled in the ad server module 50 to meet the line item guarantee. The tracking module 40 reconciles actual ad delivery (summation of all flights for a particular Une item) to contracted commitment (line item guarantee from the confract).

This is necessary because a campaign may be negotiated and agreed in general terms, and must be set up for deUvery through ad server 50 in a more granular fashion, such as by an individual ad basis.
Additionally, tracking module 40 reconciles revenue at each billing period of the contract. As mentioned above, tracking module 40 monitors the billing dates of the contract by checking database 100 or any contract having an "event" on the current date. Using the performance metrics, contract and performance data, tracking module 40 calculates billable amounts and earned revenue. This revenue is the actual cost of the ad campaign to date, and is calculated using the method described earlier.

It should be noted that the actual revenue may differ from the expected revenue because some advertisements may not have been posted by ad server module 50 on the intended web site web pages, or there may have been server failures or other network problems, resulting in under or over delivery. The actual revenue, for performance-based contracts is based upon the number of advertisements actually served through ad server module 50. The actual revenue for time-based contracts is based upon the ad campaign being published "live" for the committed period, in other words, the ad was deUvered within the contracted time period.
Tracking module 40 calculates the expected revenue of the ad campaign for the billing cycle. The expected revenue is the confracted revenue of the ad campaign to date, which includes the agreed upon number of advertisements.

It is calculated using the method described eartier, except the terms agreed upon in the contract are used in the calculations, rather than actual performance data from ad server 50. Thus, the difference between the expected revenue and the actual revenue will depend upon the difference in actual and expected performance values, or deUvered time periods. Tracking module 40 compares the expected revenue to the actual revenue and determines the difference, if any, Une-item by Une item.
If the Reconciliation Method captured on contract module 90 and stored in database 100 for access by tracking module 40 is either performance-rule or performance-to-date[tau]ule7 then tracking-module 40-references-performance data- - imported from ad server 50 or another data source that is measuring the performance of the Une item for this advertising campaign.

For performance-rule, tracking module 40 calculates the billable amount using the formula indicated by the cost model in effect on the Une item, and plugging in the quantity actually delivered by ad server 50 or other data source, multiplying it by the cost defined on the line item and captured on the contract in contract module 90 and stored in database 100.
For performance-to-date rule, the same calculation is performed and compared to the value that would be billed if using the contract-rule Reconciliation Method. With performance-to-date rule, the billable amount must be less than or equal to the value calculated by tracking module 40 if contract-rule Reconciliation Method were employed.

Tracking module 40 calculates the billable amount up to, but not exceeding, the amount due based upon the contract alone for that bilUng period.
When contract-rule ReconciUation Method is in effect, at the end of the contract (defined as when the end dates for all line items for all campaigns are in the past), tracking module 40 uses performance data imported from ad server 50, or another data source, to determine what revenue can be recognized in accounting system 120, and to determine whether additional performance delivery is due to the advertiser because of under delivery of the ad campaign by ad server 50 or other delivery system. "Under delivery" means that the ad server 50 or other delivery measurement system delivered or served a smaller amount (of clicks, impressions, etc.) than the line item quantity captured on the contract within contract module 90.

For example, the contract specified 40,000 impressions and only 38,722 impressions were served by the ad server. If a campaign under deUvered, tracking module 40 communicates with database 100 and contract module 90 to have the discrepancy made up through either a "Make Good" (an online advertising industry term meaning a subsequent flight or flights scheduled in publisher's ad server 50 to deliver the quantities that are owed to the advertiser, as they were supposed to be delivered in a prior period) or a refund or credit to the advertiser's account. Over delivered amounts are ignored by tracking module 40 in terms of billable and revenue calculations; this is a standard practice within the online advertising industry, in which web publishers do not charge for delivery of advertisements over and above the amount contracted for by the advertiser (or its advertising agency).

Tracking-module-40 calculates- revenue -that can he-recognizecLin accounting module 120, based upon actual performance and/or passage of time (for sponsorships or other non-measured performance based contracts), regardless of which ReconciUation Method tracking module 40 used to generate biUable amounts.
After reconciling contracts, tracking module 40 inserts a discrepancy item into a billing work queue, which is then edited as needed and approved by a user, such as an accountant. The billing work queue comprises a list of records resulting from the data reconciliation process. The discrepancy item will show any discrepancies between the contractual and performance data, as well as the resolutions on those discrepancies being performed by tracking module 40 in accordance with reconciliation rules originally specified for that contract.

The user may approve the resolutions or edit them as needed, via tracking module 40. When approved, the final data as well as an audit trail of all changes are processed into a billable item and saved as a data file. Tracking module 40 provides for the capabiUty of exporting the data file to various types of third party accounting and invoice software.
Before exporting the data, tracking module 40 converts the data to either a Comma Separated Value (CSV) or a extensible markup language (XML) format data file. Converting algorithms for converting raw billables data stored in the database in database format to CSV or XML formats are known in the art. These file formats are accepted by most commercially available accounting modules, such as "Peachtree" by Peachtree Software Inc., and "Quick Books" by Intuit Inc.

One example of how fracking module 40 automates the entire process of collecting, compiUng, and calculating publisher revenues from online advertising campaigns is by accepting configurable parameters which guide the automated process. Ad server module 50 serves ads to web sites 80 and measure the performance of those ad campaigns. This ad server often requires a few days to complete the process of compiling data for a particular period. Tracking module 40 provides the functionality that the publisher may need to allow for the lag of those extra days before beginning the automated revenue calculations based upon contract data stored in database 100 from contract module 90. Tracking module 40 accommodates this 5 through a "Delay Reconciliation by Days" configuration function.

The user defines how many days ad server 50 is required to finish its processing and calculations, which the tracking module 40 uses to schedule the alerts and system events which are required to begin the reconciliation, compilation, calculation and - comparison-processes it uses..O-c[epsilon]dcidate-billable amounts andrevenue. .
10 Another example of how tracking module 40 manages onUne advertising bilUng is by referencing settings on the contract from contract module 90 which indicate whether performance data monitored, measured, and calculated by a thirdparty ad server is used for compiUng and calculating revenue within tracking module 40 (note that the third party ad server is not ad server 50).

Contracts configured
15 through contract module 90 can indicate that an ad server deployed by an advertiser (or its agency) for serving and measuring performance of the ad campaign is to be used to calculate biUable amounts that the advertiser or agency gets invoiced, and revenue amounts that the publisher receives. Tracking module 40 references this configuration setting through database 100 when set up through contract module 90,
20 and generates requests to the user for performance data from this alternate data source.
Tracking module 40 also functions to support the guideUnes for compiUng revenue consistent with generally acceptable accounting principles (GAAP).

These principles require that; persuasive evidence of an arrangement exists; delivery has
25 occurred or services have been rendered; seller' s price to the buyer is fixed or determinable; and coUectibility is reasonably assured. This is achieved by tracking module 40: retrieving evidence of the arrangement captured through contract module 90 and stored in database 100; retrieving proof of delivery from ad server module 50 and storing it in database 100; retrieving a seller's price from database 100, as
30 captured by contract module 90; and accounts deemed not collectable have holds placed on them and new contracts are not accepted by contract module 90.
The following discussion discloses an operational schema where a web site publisher operates numerous web sites or properties (examples: Yahoo main site; Yahoo Finance; Yahoo Sports; YahooUgans for kids;

Yahoo international sites for
35 local countries; etc.) and has numerous active contracts with advertisers to distribute ("serve") advertisements the various web sites or properties.
11 nA typical campaign for ontine advertising involves multiple ads (sometimes called "creatives") running on multiple web sites 80 for specific dates or date ranges. Each campaign is defined on the contract (as entered into contract module 90) as one or more Une items, with each Une item consisting of multiple flights. Each entry of an ad scheduled tQ_run_in the.publishe[iota]ls.a4seryer_50, toJ.e displayedjan a web site 80,_is called a "flight." (Other terms also exist and are used in the onUne advertising industry for flight, including "placement" and "run".) The web pubUsher may operate one or more of the web sites 80 running the flights of the advertiser's campaign.

The web publisher runs multiple campaigns (with multiple flights in each) concurrently for multiple advertisers, often including multiple campaigns from any one advertiser. To illustrate, a web publisher such as Yahoo! or AOL operates numerous separate web sites or properties. The publisher has hundreds or thousands of advertisers with active contracts at any given time. Each advertiser may have multiple campaigns running (e.g., Ford Motor Company may run separate ad campaigns for their sport utility vehicle and for their compact cars simultaneously, each with separate branding messages, separate advertisements or "creatives," and may even employ different advertising agencies to purchase ad space and manage the campaigns, etc.).

Each advertiser has its campaign running on one or more of the sites the publisher owns and operates, and the advertiser also has the campaign running on other sites that are not owned and operated by the publisher. Therefore, each publisher using tracking module 40, contract module 90, ad server module 50 and web site 80 has thousands of flights running thousands of ads on thousands of web pages. This is a very large amount of information to track, monitor, compile, calculate and compare, which, if left to a user to perform manually, would overwhelm the user and would inevitably result in errors in compiling and calculating the performance data and associated revenue for billing and reporting purposes.

Advantageously, tracking module 40 monitors the terms of the Une items on the contract as communicated by contract module 90 to database 100, and alerts a user (publisher) when performance data is required to be imported from ad server 50 or from another data source, and compares the aggregated performance of the flights to the line item quantity commitment sold on the contract and captured within contract module 90, determining the difference, if any, Une item by Une item. P T/US01/46801
Referring to FIG. 2, tracking module 40 acquires contract data from database 100, which was captured by contract module 90 (Block 200).

Online advertising contracts are negotiated by defining the terms under which the advertising campaign will run and how and when the advertiser's ads wiU appear on the pages of the publisher' s^web_site 80 A.ds_appear on web si tes 8p_when_ served or^published by ad server 50.) The publisher uses contract module 90 to capture the details as agreed upon with the advertiser (or its advertising agency if one is being used), including dates to run the campaign(s), web sites 80 to run on, targeting criteria to direct the ads at a particular demographic audience (which may include time of day or day of week that ad is displayed on publisher's web site, age or sex of viewer of the ad on die web page, type of computer equipment being used by viewer of the ad, interests of viewer, etc.), cost model (performance metric, such as CPM for impressions, CPC for cticks, CPA for actions, etc.),

quantity to be deUvered, and the cost for each unit of performance.
These details are keyed into the contract module 90 and stored in database 100 to be available for reconciliation within tracking module 40. The campaign details on the contract are referred to as "line items." These line items define the obligation of the publisher to pubhsh or "serve" the online ads on behalf of the advertiser, in exchange for the agreed price of the Une item on the contract.

The price is calculated by the contract module 90 using the cost model chosen by the user of contract module 90, such as CPM for an impressions-based Une item (sold, measured, and billed by how many ad views or "impressions" were delivered by the publisher's ad server to the pages of the pubUsher' s web site), CPC for a cUcks-based line item (sold, measured, and billed by how many viewers of the ad cUcked on that ad when it was displayed on the publisher's web site), CPA for actions (sold, measured, and billed by how many viewers of the ad performed an action defined by the advertiser in advance, such as downloading a digital asset such as software from the advertiser's web site, or registering as a new member on the advertiser's web site);

etc.
Online advertising contracts are sometimes referred to as "insertion orders" or "IOS" which is a term from traditional advertising (e.g., magazine publishing, wherein the advertiser's ad or "creative" was "inserted" into the copy or pages within the magazine). Each Une item on the contract entered through the contract module 90 represents one component or element of an advertising campaign. Each contract within contract module 90 has one or more campaigns, with one or more line items in each campaign.
When the contract is agreed upon between the pubUsher and the advertiser or its agency, the advertiser or its agency submits the ads to the publisher. The publisher sets<¯>up or configuresrthe-wayrthe-ads will appear-on the-pages- of its web site(s)-by - creating a campaign in the ad server 50.

Each campaign entered on the contract within contract module 90 becomes a campaign running within the pubUsher's ad server 50. Each line item entered on the contract within contract module 90 is broken down into one or more ad placements or "flights" which have one or more ads attached and which are set up within the publisher's ad server 50 to be displayed on the pages of the publisher' s web site 80.
At block 210, tracking module 40 uses the line item dates to identify whether the line item began and ended in the current billing period, or if it was carried over from the previous period, and/or if it will carry over to the next period, to determine quantities deUvered.

If the line item was to completely perform within the current period, then the tracking module 40 adds up the total quantity deUvered by the flights comprising that line item and compares that total to the line item quantity on the contract within contract module 90. If the line item was carried over from the previous period, then tracking module 40 accesses status information for the line item from all prior billing periods stored in database 100 and determines if any quantities delivered in prior periods are to be carried over and combined with the quantities delivered in the current period, by the flights that comprise the line item.

Similarly, tracking module 40 checks to see if the line item will continue in the next subsequent period to determine if any quantities delivered in the current bilUng period that exceed the quantity that was expected to be delivered for this period based on the Une item on the contract within contract module 90, can be carried over to the next billing period.
At block 220, tracking module 40 uses a cost model to determine how to handle the reconciliation of that Une item against the flights that comprise it. The cost model indicates whether the line item is being measured by impressions (ad views published by the ad server 50 and displayed to a viewer on the publisher's web site 80), by clicks (number of times viewers of the ad clicked on it), or by other viewer actions, as specified by the advertiser to measure.

Tracking module 40 determines which formula to use for calculating the total revenue due from the line item based on the cost model, and calculates total revenue due, block 230.
At block 240, tracking module 40 uses Une item quantity data from the contract module 90 to calculate billable amounts for contracts designated within confract<">rnod_le 90 as<¯>using confract- le[tau]recorrciliat_[sigma][iota]rmethod7andi;o determineif the Une item met delivery requirements for the billing period. Tracking module 40 uses line item cost from the contract module 90 to calculate billable amounts for all contracts, regardless of reconcitiation method employed on the contract.
Three reconcitiation rules are applied to each contract during the reconciliation process: contract-rule, performance-rule, and performance-to-date-rule. Contract-rule requires billing on 100 percent delivery rate.

At the end of the billing period or contract depending on the billing period, the performance is reconciled against the contract to determine the difference between what is being billed and the actual. Performance-rule, calls for bilUng solely on delivery up to the maximum doUar amount for any Une item. At the end of the billing period or contract depending on the billing period, the contract will be reconciled against performance data to determine the difference between what is being billed and what was expected to be billed. Performance-to-date rule, requires bilUng based on delivery up to the maximum dollar amount expected for any line item up through the end of the current billing period being billed.

Discrepancies are resolved per the reconciliation rules in effect for the contract.
For each confract that is active during the Billing Period that tracking module 40 is processing, tracking module 40 calculates the billable amount for each line item, which is the amount due that will appear as a line item on the invoice generated by accounting module 120. This billable amount is transmitted to the accounting module 120 by tracking module 40 through the Export process (described later). Tracking module 40 calculates the billable amount for the BilUng Period by first identifying the Reconciliation Method selected on the contract through contract module 90.

If the contract-rule Reconciliation Method is in effect, then tracking module 40 determines the billable amount for this Billing Period by dividing the line item amount on the contract by the number of bilUng periods in which the line item ran or is running.
For example, if a Une item is sold for 30 days from June 15 to July 14 and the Billing Period is monthly straight Une, then the line item is active in two distinct billing periods, the first billing period being 6/15 - 6/30 and the second being 7/17/14. If the line item amount on the contract is $1,000 (40,000 impressions sold at $25 CPM cost model, or 40,000 x $25 / 1000), then tracking module 40 determines that the contracted amount due for each Billing Period is $500 using the contract-rule ReconciUation.Method. _ _.

Once a discrepancy has been approved, as described earlier, the data from that discrepancy becomes a "Billable." A "Billable," is an item that may be acted upon and billed to an advertiser by the pubUsher. It holds all the relevant data necessary to create an invoice for the period in question. One use of a "Billable" is to be exported to financial module 120 for further processing into an invoice that can be sent to the advertiser.
At block 250, tracking module 40 exports the "Billable" to a third party billing system of their choice. This allows users who have legacy billing systems (which may also act as the bilUng system for other segments of the users' company) to continue using those systems for all product Unes, including tracking module 40. The billables data file is communicated from tracking module 40 to financial modulel20.

The final data comprises advertiser, campaign, bilUng period (dates), and bilUng amount. The data is exported to financial module 120 by either file transfer over the Internet 70, or by disk, or by manual data entry.
Tracking module 40 exports billables data to financial modulel20 for use in generating invoices for ad campaigns. Module 40 exports a file that can be imported ' into financial modulel20, where the file can be stored and further processed. Once exported to financial modulel20, the file can be opened and read, printed, formatted, and transferred into commercial software such as the spreadsheet program Microsoft Excel or an accounting package such as Oracle Financials, for generating an invoice. The above presents various principles and features of the invention through a description of a particular embodiment.

It is understood that skilled artisans can make various changes and modifications to the embodiment without departing from the spirit and scope of this invention, which is defined by the following claims. To illustrate, the above discussion is couched in terms of a network arrangement with the various modules interacting with each other over the network. It is clear, however, that the modules can be located in a single computer system, or that they can be combined to form larger modules that perform combined functions.

Claims

Claims:

1. A method of tracking revenue from an online advertising campaign comprising: acquiring contractual data pertaining to the advertising campaign; acquiring performance data of the advertising campaign; and tracking revenue based upon evaluating the performance data and the contractual data.

2. The method of claim 1 wherein the performance data is capable of being acquired from sources of various formats.

3. The method of claim 1 wherein a tracking period is determined by the contractual data.

4. The method of claim 3 wherein the tracking period is daily, weekly, monthly, or quarterly.

5. The method of claim 1 wherein the revenue is deferred.

6. The method of claim 1 wherein the revenue is recognized.

7. The method of claim 1 further comprising compiling revenue consistent with generally acceptable accounting principles.

8. The method of claim 7 further comprising transferring revenue to an accounting program.

9. The method of claim 8 wherein the accounting program is consistent with generally acceptable accounting principles.

10. The method of claim 1 wherein performance data is capable of being acquired from sources of various formats.

17

11. The method of claim 1 further comprising generating billable amounts from tracking revenue for import into financial management systems for invoicing and accounting.

12. A system comprising: means for acquiring contractual data pertaining to an advertising campaign; means for acquiring performance data of the advertising campaign; and means for tracking revenue based upon evaluating the performance data and the contractual data.

13. The system of claim 12 wherein the means for acquiring performance data is capable of being acquired from sources of various formats.

14. The system of claim 12 further comprising a means for producing an invoice based upon evaluating the performance data and the contractual data.

15. The system of claim 12 further comprising means for generating billable amounts, from tracking revenue, using generally acceptable accounting principles.

16. The system of claim 15 further comprising means for exporting billable amounts into financial management systems.

17. The system of claim 16 wherein the financial management systems are of various formats.

18. The system of claim 12 further comprising means for producing invoice data in a format capable of interacting with various financial accounting systems.

19. A server comprising: a contract module for capturing terms of a contract; a database for storing the terms of the contract and performance data; and a tracking module for calculating revenue based upon the terms of the contract and the performance data.

18

20. The server of claim 19 further comprising a communication interface for providing two way communications between the server and at least one second server, over a computer network.

21. The server of claim 20 wherein the computer network is the Internet.

22. The server of claim 20 wherein the second server is an advertisement server.

23. The server of claim 20 wherein the second server is capable of generating invoices.

24. A method of tracking revenue from an online advertising campaign comprising: receiving data related to contracts and quantities of advertisements delivered; and tracking revenue based upon evaluating the performance data and the contractual data.

19