WO2006041754A2

WO2006041754A2 - System and method for increasing pay-per-download revenues

Info

Publication number: WO2006041754A2
Application number: PCT/US2005/035398
Authority: WO
Inventors: Ned Rhinelander
Original assignee: Cnet Networks, Inc.
Priority date: 2004-10-04
Filing date: 2005-10-04
Publication date: 2006-04-20
Also published as: WO2006041754A3

Abstract

A system, method and software for offer selection handling, including receiving a request for a web page, wherein the request includes an identification of content associated with the web page, the content includes offers associated with respective items and to be displayed on the web page, and the offers include an advertised form of the respective items; determining candidate offers associated with the identification of the content, wherein the candidate offers include respective items associated with the candidate offers; assigning respective weights to the candidate offers, wherein the respective weights are based on past user interest performance of the items associated with the candidate offers and/or revenue producing performance of the items associated with the candidate offers; selecting a predetermined number of offers from the candidate offers, wherein the selected offers are selected from the candidate offers having highest respective weights; and rendering the selected offers on the web page.

Description

SYSTEM AND METHOD FOR INCREASING PAY-PER-DOWNLOAD

REVENUES

BACKGROUND OF THE INVENTION FIELD OF THE INVENTION

[0001] The present invention generally relates to the field of pay per download systems and methods, and more particularly to a system and method for increasing pay per download revenues.

DISCUSSION OF THE BACKGROUND

[0002] In recent years, Pay Per Download (PPD) systems and methods have been developed. However, there is a need for significantly increasing revenue generated from the corresponding Pay Per Download programs.

SUMMARY OF THE INVENTION

[0003] Therefore, there is a need for a method and system that addresses the above and other problems. The above and other problems are addressed by the exemplary embodiments of the present invention, which provide system, method, and computer program product for offer selection handling. hi an exemplary embodiment, a novel weighting algorithm is applied to determine offers to display, such that the number of clicks users make on Pay Per Download (PPD) offers, advantageously, are increased, resulting in significantly increased revenue generated from the corresponding Pay Per Download programs.

[0004] Accordingly, in exemplary aspects of the present invention there is provided a system, method, and computer program product for offer selection handling, including receiving a request for a web page, wherein the request includes an identification of content associated with the web page, the content includes one or more offers associated with respective items and to be displayed on the web page, and the offers include an advertised form of the respective items; determining candidate offers associated with the identification of the content, wherein the candidate offers include respective items associated with the candidate offers; assigning respective weights to the candidate offers, wherein the respective weights are based on at least one of past user interest performance of the items associated with the candidate offers, and revenue producing performance of the items associated with the candidate offers; selecting a predetermined number of offers from the candidate offers, wherein the selected offers are selected from the candidate offers having highest respective weights; and rendering the selected offers on the web page.

[0005] Still other aspects, features, and advantages of the present invention are readily apparent from the following detailed description, by illustrating a number of exemplary embodiments and implementations, including the best mode contemplated for carrying out the present invention. The present invention is also capable of other and different embodiments, and its several details can be modified in various respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

[0007] FIG. 1 illustrates an exemplary pay per download page;

[0008] FIG. 2 illustrates further features of the exemplary pay per download page of FIG. 1;

[0009] FIG. 3 illustrates exemplary relationships and functions with respect to elements of FIGs. 1 and 2;

[0010] FIG. 4 illustrates an exemplary architectural overview;

[0011] FIG. 5 illustrates exemplary runtime components;

[0012] FIG. 6 illustrates an exemplary internal server structure;

[0013] FIG. 7 illustrates an exemplary offer selection handler;

[0014] FIG. 8 illustrates an exemplary data warehouse structure; [0015] FIG. 9 illustrates exemplary database cardinalities;

[0016] FIG. 10 illustrates exemplary back-end processes;

[0017] FIG. 11 illustrates exemplary user interfaces;

[0018] FIG. 12 illustrates exemplary data warehouse processes;

[0019] FIG. 13 illustrates exemplary offer expander processes;

[0020] FIG. 14 illustrates an exemplary data warehouse schema; and

[0021] FIG. 15 illustrates exemplary database table relationships.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] The exemplary embodiments provide an exemplary application (e.g., referred to as the Rubies application) on a pay per download web site. Rubies can be initially deployed on the pay per download web site's Post Download Page (PDP) with the goal of significantly increasing revenue generated from the Pay Per Download program (PPD). The exemplary embodiments do this by increasing the number of clicks users make on PPD offers, and thereby increase the number of initiated downloads on offered products, hi turn, more completed downloads (CDLs) and more revenue can be generated from Pay Per Download (PPD) clients.

[0023] Advantages of an initial application on the pay per download web site, for example, include:

[0024] Simplicity: The launch application employs creating Rubies opportunities on a single page type, the PDP page. PDP pages also receive a great deal more traffic than product detail pages (e.g., reviews.cnet.com). A larger volume of data increases the likelihood of initial success by improving the statistical significance of the results.

[0025] The pay per download web site can have a far smaller number of products to promote, and those products can change less frequently. This helps increase the likelihood of initial success in two ways: [0026] Statistical significance: For the launch application, the pay per download web site can be promoting approximately 300 items (e.g., products) through Rubies offers, which is a relatively small number relative to SSA. Each individual offer and resulting item should receive enough impressions to provide us with statistically significant results.

[0027] Scoping: Because product turnover on the pay per download web site can be lower than with SSA, a much less sophisticated scoping procedure can be used. This should provide significant time savings.

[0028] Disadvantages of an initial application on the pay per download web site, for example, include:

[0029] Burnout: potential for declining yield over time: Because offer turnover will be lower on Download than on SSA, there may be increased risk of declining user interest in the promoted products and effectiveness of optimization. However this concern is speculative, given (among other factors) the high volume of new monthly users to the pay per download web site.

[0030] The exemplary embodiments can provide a minimum feature set so as to produce a statistically significant improvement in completed downloads. Accordingly, the platform accordingly to the exemplary embodiments can be configured to be robust enough to rapidly scale (e.g., days or weeks, as oppose to months) along several dimensions within the pay per download web site application, including:

[0031] Number of items and offers.

[0032] Capacity for offer candidates within a given offer pool to be input from a variety of sources (e.g. Product db, content db, XML files, etc.).

[0033] Capacity to generate multiple offers (or "offer types") for a given item within a single offer pool for a given unit.

[0034] Complexity of the scoring algorithm; number of data sources employed by the algorithm. [0035] Ease and efficiency by which new offer candidates can be added or removed to/from the offer pool (e.g. administration tools).

[0036] Ease and efficiency by which items' weight can be manually adjusted to induce desired results.

[0037] Ease of control over offer creative.

[0038] Increasing frequency of updated algorithm output into the Rubies targeting system.

[0039] Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views, and more particularly to FIG. 1 thereof, there is illustrated an exemplary an exemplary pay per download page. As shown in FIG. 1, the PPD and DLX programs can both utilize the same unit on the PDP page, Unit #1.

[0040] hi an exemplary embodiment, two units can be utilized on the PDP page to promote PPD and DLX clients' pay per download web site directory listings. The basic differences between these two client programs are:

[0041] PPD is a performance program. Clients pay the service provider (e.g.,

CNET Networks) for every completed download we deliver, at an agreed upon cost per download and a spend cap for the term of the contract. The download files are hosted and logged on file servers (e.g., CNET Networks' file servers, ftp.download.com. Kontiki, etc.), reported on through Data Warehouse (DW) tables and processes, and billed through SFA and RPS systems.

[0042] DLX is a high-value fixed-placement media program. Clients pay for various fixed inventory (e.g., units) that appear throughout the pay per download web site. DLX placements (e.g., units) are sold on a per category and subcategory basis.

[0043] hi an exemplary embodiment, when DLX campaigns are sold, the campaign can include uninterrupted PDP inventory for one week in the subcategory where the associated product is categorized. This "roadblocks" certain inventory (nodes) from being available for PPD scheduling. With the remaining inventory, Download staff then make weekly programming decisions for optimizing PPD revenue based on a yield calculation and ranking system generated by the DW, called the PPD Master View. More on the existing yield calculation and ranking system follows in this document.

[0044] Since DLX placements are guaranteed and fixed, an exemplary implementation can be configures to allow Download staff to continue to schedule DLX promotions through existing tools (e.g., Comet) into the Post Download pages at ontology nodes where they have been sold, overriding the Rubies systems use of Unit #1. In a further exemplary embodiment, the Rubies weighting system can be employed to essentially "override" any other offers from showing up in the target unit while a given DLX offer was targeted for that unit. Advantageously, this method can allow for optimizing yield among various offer types or creative treatments for individual DLX items.

[0045] In an exemplary embodiment, scheduling capabilities for Unit #1, for example, can include offers being manually scheduled on a weekly basis through content programming tools (e.g., Comet and Pacman X-). Offers (e.g., HTML creatives) can be scheduled to any node in the Downloads ontology and can, upon publishing, cascade down from the ontology node where scheduled to child leaf nodes and product pages categorized to each leaf node— wherever no other offers have been scheduled.

[0046] For example, an offer for Product A can be scheduled to the

Downloads>Windows node in the Downloads ontology. A second offer for Product B can be scheduled to the Downloads>Windows>Internet>Chat node in the ontology. If these are the only two offers scheduled, the first offer for Product A can show up on all PDP pages for all nodes of the Downloads ontology, except those categorized to Downloads>Windows>Internet>Chat and all its child nodes (where the offer for Product B can show up).

[0047] Advantageously, such an exemplary system allows for robust and comprehensive targeting of offers throughout the Download catalog, from top-level Downloads ("run of Downloads") to the individual product level. [0048] In an exemplary embodiment, scheduling offers into Unit #2 can include offers in Unit #2 being generated by a content macro that pulls in products from the Download Product database that meet the following criteria:

[0049] Set in the product database as a PPD product (product-specific attribute).

[0050] Products are categorized to the same ontology node on which Unit #2 is being displayed.

[0051] In an exemplary embodiment, a rule can be provided in the macro that disallows a product from being offered on its own post download page.

[0052] FIG. 2 illustrates further features of the exemplary pay per download page of FIG. 1. As shown in FIG. 2, two units can be provided and that can be Rubicizing on the PDP page.

[0053] In an exemplary embodiment, two separate offer pools can be provided, wherein one unique pool is provided for each of the two units. Corresponding items can come from a universe of Download product records (e.g., in the X Product database) that can be designated specifically for Rubies. The items can be identified uniquely from one another by the Product ID (PID) and/or Product Set ID (PSID) for each record. The product records can include attributes (e.g., name, description, version number, sub-subcategory ID, etc.) that can be used to generate offers and offer creatives based on Offer and Unit requirements. The specific attributes for offer creatives are further described.

[0054] In a further exemplary embodiment, items can be taken from a larger universe populated by varied sources, such as other product subsets, content database items, and/or other sources desired by the Download business to be input into the Rubies application.

[0055] In an exemplary embodiment, the DW can be configured as the system of record for items, taking input from any number of sources to create item pools, and utilizing DW processes and data on those items that feed into the Rubies application. [0056] In an exemplary embodiment, items for Offer Pool #1 can include items (e.g., products) specifically designated in the Download Product DB for Unit #1. These products can be specifically enabled through a DL product database administration tool (e.g., Pacman) to be available for Unit #1. Business rules can be provided that stipulate that only PPD products can be introduced into Offer Pool #1. However, in further exemplary embodiments, the flexibility to easily introduce other non-PPD products into the offer pool for Unit #1 can be provided. For example, this can be used to drive users to highly relevant products that while not in the PPD program, may be otherwise highly valuable for the business to promote. Accordingly, the exemplary architecture for Rubies can be configured to allow the business to introduce items from sources other than the DL Product database into Offer Pool #1.

[0057] Such desired flexibility can dictate corresponding algorithm configurations for Unit #1 (e.g., if a product introduced into Unit #1 doesn't have a cost per download or spend cap value). For example, a new product introduced that does not have an actual cost per download and/or spend cap value can be assigned a default, either systematically or through manual administration, and the like.

[0058] In an exemplary embodiment, items for items for Offer Pool #2 can include items (e.g., products) specifically designated in the Download Product DB for Unit #2. However, unlike Offer Pool #1, products for Offer Pool #2 can be limited to any PIDs designated in the Product DB as being active in the PPD program.

[0059] In an exemplary embodiment, the subset of PIDs for Offer Pool #2 can be systematically determined by looking up PSIDs with valid Pool (e.g., Product Order Order-Line) mappings, which can be recorded in a table that the DW accesses to generate PPD reports. However, there are often multiple live PIDs associated to a given PSID and Rubies offers can employ PIDs and not PSIDs. For example:

[0060] PSID 12345 is active in the PPD program, and:

[0061] PSID 12345 has two live PIDs associated to it: PID 678 and PID 910.

[0062] PID 678 is the correct active PID for the PPD campaign.

[0063] PED 910 is a second PID that is not billable. This product record can have a flag set in the product database that marks it as "exclude from PPD." The PID exists so that the publisher can drive his/her own users to the service provider (e.g., CNET) to download the product (and thereby grow download counts used in our most popular lists) without paying for the resulting downloads.

[0064] Accordingly, the correct PID associated to a given PSID mapped in the

Pool table can be deduced or looked up by a corresponding process, such that Rubies offers for Unit #2 always direct users to the correct PID for a given PPD campaign.

[0065] If a systematic process of deducing the correct PID to use for a given

PSID adds too much scope, optionally, items for Offer Pool #2 can be manually flagged through the Pacman tool as being available for Unit #2, in similar fashion to how Unit #1 items can be set up. However, this is less desirable for the business as it would require manual administration of hundreds of PIDs, and hence additional workflow steps in the management of PPD campaigns.

[0066] In an exemplary embodiment, there are no cross-pool constraints regarding items. For example, it can be acceptable that if in a single instance of the PDP page loading, a given item can potentially show up in both Unit #1 and Unit #2. While individual items can exist in both offer pools, any offers for a given individual item that exist in both offer pools can be considered unique from one another for Rubies offer optimization and reporting purposes.

[0067] In an exemplary embodiment, rules for both Units can be set up such that no offer can appear on its associated product's own PDP page in Unit #1 or Unit #2. For example:

[0068] When viewing the PDP page for Product ABC, no offer for Product

ABC should appear on the page in either Unit #1 or Unit #2.

[0069] In an exemplary embodiment, Unit #1 can be configured to surface one offer at a time. For example, to generate creative for Unit #1 the following attributes can be employed:

[0070] Product ID (e.g. 10239810).

[0071] Ontology ID (e.g. 2048). [0072] Destination link, generated from Product ID and Ontology ID (e.g., download.com.com/3000-2048-10239810.html). Offers for Unit #1 can link to the product detail page (e.g., page type 3000).

[0073] Other attributes employed for tracking (e.g. site ID, tags, etc.).

[0074] Offer-specific HTML creative. This is where offer-specific creative can be created and managed as bulk HTML (e.g., headline copy, descriptive copy, images, etc.).

[0075] In an exemplary embodiment, other offer-specific attributes (e.g., a thumbnail image) can be employed as new offer creative types are developed for Unit #1. As these are introduced into the offer pool for Unit #1, these can be considered as unique offers in the offer pool, even if two or more separate creative types map to the same item.

[0076] In an exemplary embodiment, Unit #2 can be configured to surface four offers at a time. For example, each offer can employ the following attributes:

[0077] Product name (e.g., Site Spinner).

[0078] Version number (e.g., 2.02).

[0079] Product ID (e.g., 10239810).

[0080] Ontology ID (e.g., 2048).

[0081] Destination link, generated from Product ID and Ontology ID (e.g., download.com.com/3000-2048-10239810.html). Offers for Unit #2 can link to the product detail page (e.g., page type 3000).

[0082] Other attributes employed for tracking (e.g., site ID, tags, etc.).

[0083] In an exemplary embodiment, in the case of Unit #2, the HTML creative shell can be considered as part of the Unit, rather than as an attribute of the offer, as multiple offers can be displayed in Unit # 2 at the same time. Whereas with Unit 1, the creative HTML shell can be better included as part of the offer, allowing multiple and different creative treatments for the same items to be run through Unit 1 as part of the same Offer Pool. [0084] In further exemplary embodiments, different or additional units can be introduced into PDP (e.g., as dictated by a page redesign) and as desired for application throughout the rest of the Download web site.

[0085] In an exemplary embodiment, an exemplary Rubies Algorithm is provided. The Algorithm terminology/Notation includes:

[0086] RPK:

[0087] RPK stands for Revenue Per Thousand Offers.

[0088] Estimated revenue received over a given time period for every thousand offers served.

[0089] Optimizing RPK is akin to optimizing yield and it is what the algorithm attempts to do.

[0090] RPK can incorporate an element of user interest (e.g., an Offer's RPK goes up when users click on it more often) as well as a revenue element (e.g., an Offer's RPK goes up if it's associated CPD rate is higher).

[0091] Shares:

[0092] The proportion of future delivery each Offer will receive.

[0093] Shares are determined in a way that attempts to optimize RPK.

[0094] Total of all Shares for a Unit = 100%.

[0095] Weights:

[0096] Weights are the means by which Shares are calculated.

[0097] For example, if:

[0098] There are 3 Offers.

[0099] Offers #1, #2 and #3 brought in $2000, $3000 and $3000, respectively,

(e.g., 3 Weights for 3 Offers). [00100] Using these Weights of $2000, $3000 and $5000, shares can be calculated for each Offer, as follows:

$2000

Offer #1 =20% =

($2000 +$3000 +$5000)

$3000

Offer #2 =30% =

($2000 +$3000 +$5000)

Offer #3 =50% = ^

($2000 +$3000 +$5000)

[00101] CPD:

[00102] CPD stands for Cost Per Download in the Download PPD program.

[00103] It is the Cost to the Publisher or participant in the program. It is the revenue per download the pay per download web site makes.

[00104] All Offers optimized by the algorithm in the initial application need to have a CPD rate associated with them. Standard PPD Offers do have such a rate, but DLX and PPD remnant Offers do not. The pay per download web site and/or the administrator will have to estimate a value for these Offers.

[00105] In an exemplary embodiment, the exemplary algorithm seeks to increase revenue associated with Completed Downloads (CDLs) for which the pay per download web site is compensated by publishers. This can be done by serving Offers with higher than average RPK more frequently than Offers with lower than average RPK (e.g., wherein how much "more frequently" can be configurable).

[00106] For example, assuming:

[00107] SafeGuard Pop-up Blocker (e.g., which is in the Windows>Internet subcategory) brought in $4.00/1000 Offers, when SafeGuard Pop-up Blocker was served to Units within the Windows > Internet subcategory.

[00108] SafeGuard Pop-up Blocker also brought in $2.00/1000 Offers when it was served to Units within the Windows > IS/IT subcategory.

[00109] In both subcategories, the average Offer brought in $3.00/1000 Offers.

[00110] Accordingly, the exemplary algorithm will serve SafeGuard Pop-up

Blocker more frequently in Windows > Internet than in Windows > IS/IT, because it performs better in the former (e.g., $4.00/1000 Offers) than the latter (e.g., $2.00/1000 Offers) relative to the average for each subcategory (e.g., $3.00/1000).

[00111] In an exemplary embodiment, optimization can take place at the

Subcategory level of the ontology (e.g., Windows>Internet). The Subcategory level can be employed in order to provide some level of initial "targeting" (e.g., it will serve the best performing Offers within the Subcategory, not the best performing Offers on all of Download), while providing a large critical mass of data. Going to the Sub-Subcategory level involves cutting the data into smaller buckets, which provide greater "targeting," but less data per Offer.

[00112] The present invention includes the recognition that there are pros and cons to calculating weight (and targeting offers for rotation) based on an item's association to a parent subcategory (e.g., Windows>Internet) versus calculating weight based on an item's actual and more-targeted categorization (e.g., Windows>Internet>Chat). For example, a chat application offered in, for example, the Windows>Internet>Chat sub-subcategory may produce better yield than the yield produced when that same offer runs in a less relevant category, for example, the Windows>Internet>Download Managers subcategory. However, while a better yield may be provided by making offer associations at the sub-subcategory level, if weight is calculated based on a product's association to a parent subcategory (e.g., Windows>Internet vs. Windows>Internet>Chat), there will be more traffic and offers on which to generate relevant statistical results.

[00113] In further exemplary embodiments, incorporation of the targeting information associated with the Sub-Subcategory level (e.g., called "Level 4" in the DW) can be employed with no loss of statistical significance.

[00114] In an exemplary embodiment, the following parameters can be employed to choose the Offer(s) displayed at run-time, for example, including:

[00115] Site and ontology subcategory of Unit making request (e.g., CNET

Downloads > Windows > Internet).

[00116] Unit information, which can include information necessary to create and populate the unit, for example, including: [00117] # of Offers/Unit.

[00118] Display properties.

[00119] Other parameters can be requested for tracking, reporting and analysis purposes.

[00120] In an exemplary embodiment, algorithm administration can include the ability to assign even-weightings to a fraction of the pool. For example, on a per Unit/per Target basis, the Captain/Administrator can assign a coefficient called Percent_Optimized (e.g., between 0% and 100%) that can be used to determine the percentage of the overall pool that is served from an even distribution versus the percentage of the pool that was optimized, wherein 100% would imply each impression and every Offer was being optimized, and 0% would imply that each Offer had the same probability of being chosen and that NO optimization was occurring.

[00121] In an exemplary embodiment, there are the following uses for such functionality:

[00122] For example, this coefficient can be set to 0% for an initial period (e.g.,

7 days) to allow the application to collect roughly the same amount of data for each Offer. After this initial period, the coefficient can be set to 100% and the normal functioning of the algorithm can commence.

[00123] If tests are to be conducted on the benefits of different optimization schemes, they can be conducted in a relatively unbiased manner by allocating a fraction of the pool to be used for test purposes (e.g., If Percent__Optimized = 80% then 20% of the pool can be used for test purposes).

[00124] hi an exemplary embodiment, the ability to suppress an Offer/Taking an Offer down once its spend cap is hit can be provided. Such functionalities can be aimed at preventing an Offer from showing, and can be implemented in either (or both) of the following exemplary methods:

[00125] Pool scooping:

[00126] The DW tracks the progress of products against their Spend Caps.

Once a Spend Cap is hit, a Suppress field can be automatically switched from FALSE to TRUE. An Offer with a value of TRUE in the Suppress field can be automatically excluded from Rubies pools.

[00127] Algorithm:

[00128] Another (perhaps preferable) alternative is to pass the Suppress field along with the Offer into the pool. Then the algorithm can make use of the field to prevent the Offer from showing (e.g., giving it a 0% share) when Suppress = TRUE. A benefit of this approach is that the Offer would appear in tracking and reporting for the pool over the entire period the pool was active rather than "disappear."

[00129] hi an exemplary embodiment, a manual override of suppress function can be provided. For example, the administrator can upload a file to be able to change the value of Suppress back to FALSE, if he or she wishes to allow the Offer to continue to show despite having hit its cap. The corresponding table can be in the following format:

[00130] In an exemplary embodiment, a manual "boost" function can be provided. For example, the administrator can increase or decrease an Offer's share by changing an Offer's "Scalar." An Offer's Scalar has a default value of 1, and it can range from 0 to any positive value. Values for a Scalar of less than 1 reduce an Offer's share, values greater than 1 increase an Offer's share, and a value of 1 leaves the share unchanged. The scalar operates on an offer's final weight and potentially has a great deal of influence over an Offer's final share and should therefore be used with care.

[00131] In an exemplary embodiment, a minimum weight can be provided. For example, the administrator can have the ability to assign a minimum weight (not share) to Offers at the Unit/Target level. This minimum weight can be used ensure that even poor performing Offers can get some exposure. This is beneficial because it allows Rubies to detect statistically significant changes in an Offer's performance and increase its share if appropriate. Additionally, it ensures enough Offer variety to prevent "burnout" of more popular Offers.

[00132] This value, Min_Wt, can be maintained by an advertising technician

(Ad-Tech). The values Min_Wt can take on can best be explained by an example, as follows:

[00133] Offers can be ranked (and served) on the basis of their normalized

RPK. For example, values such as $13 RPK and $2 RPK can be scaled to between 0% and 100%, with 0% corresponding to the Offer with the lowest RPK and 100% to the Offer with the highest RPK.

[00134] The administrator might want to set a minimum weight corresponding to Offers in the 20^th percentile of RPKs (e.g., Offers would never get less weight than Offers in the 20^th percentile). To do this, Min_Wt can be set = 1+20% = 1.2. In an exemplary embodiment, the Min_Wt's value can range between 1 and 2, inclusive.

[00135] In an exemplary embodiment, new Offers can be handled in a manner similar to Minimum Weights. For example, if the administrator wanted to assign the "average" weight to new Offers, they can set New_Offer_Wt = 1.50. This value would be maintained by the Ad-Tech working with the administrator.

[00136] In an exemplary embodiment, the administrator can be able to modify the number of days of history used in the calculation of RPK. Initially, RPK_DAYS can be set to 7, but the flexibility to experiment with different time frames can be employed.

[00137] In an exemplary embodiment, the Multiplier can be used to increase the proportion of delivery assigned to Offers with above average performance at the expense of Offers with below average performance. For example, it allows the administrator to "double-down" (or triple, quadruple, etc.) on the best performing Offers. This value can be assigned on a per Unit/Target basis and can be maintained by the Ad-Tech.

[00138] In an exemplary embodiment, an Override can be provided as a means to assign an Offer a specific percentage of inventory.

[00139] In an exemplary embodiment, the number of days an Offer is "New" can be configured. For example, the administrator can have the ability to set the number of days (New_Offer_Days) that an Offer runs (Active Days(offer)) before it serves based on its performance.

[00140] In an exemplary embodiment, a Base Weight can be employed. For example, the administrator can have the ability to alter the Base_Wt (e.g., set to 1.50).

[00141] In an exemplary embodiment, the "state" of the algorithm can be logged once a day.

[00142] The details of the exemplary algorithm are as follows:

[00143] First, calculate RPK for each Offer in the pool, which can be done once a day, as follows:

For all Offers o in Unit u in last RPK_DAYS

Revenue for Offer o = (Initiated Downloads Associated with Offer o) X (CPD for Offer o)

RPK(o) = RPK for Offer o = [(Revenue for Offer o)/(# of times Offer o served in last RPKJDAYS)] x 1000 Next Offer

[00144] Next, normalize the RPK values arrived at in the last step, and which employs three intermediate values:

Max_RPK = max[For all RPK for all Offers] MinJRPK = min[For all RPK for all Offers] MeanJRPK = mean[For all RPK for all Offers]

For all Offers o in Unit u in last RPKJDAYS, calculate NormalRPK(o) IF (RPK(o) >= Mean_RPK) THEN

NormalRPK(o) = [ [(RPK(o) - Mean JRPK)/(Max JtPK - Mean JUPK)] + 1 ] x 0.5

ELSE NormalRPK(o) = [ [(RPK(o) - Mean_RPK)/( Mean_RPK - Min_RPK)] + l ] x θ.5

END IF Next Offer

Next, calculate final weights:

For all Offers o in Unit u in last RPK_DAYS

/*Need to, at least conceptually, calculate 3 intermediate values per Offer/*

/*Poor_Performer(o) determines whether or not Offer o's performance would give it a weight below the minimum./*

/*If it does, the minimum weight would be subsituted for Offer o's performance- derived weight./*

{IF (l+NormalRPK(o)) < Min_Wt THEN

Poor_Performer(o) = TRUE ELSE

Poor Performer(o) = FALSE END IF}

/*New_Offer(o) determines whether or not Offer o has been active long enough to use its performance-derived weight/*

/*or if it should be given the weight for new Offers (New_Offer_Wt)/*

{IF ((Active_Days(o) < New_Offer_Days) THEN

New_Offer(o) = TRUE ELSE

New_Offer(o) = FALSE END IF}

/*If Suppress(o) is TRUE then Offer(o) isn't shown at all and gets a 0 weight and 0% share./*

/*If Supρress(o) is FALSE then Offer(o) takes a weight based on the values of

Poor_Performer_s New_Offer/*

/*and NormalRPK. Suppress(o) defaults to FALSE and flips to TRUE if Offer o's spend cap is hit or /*

/*if the business user sets its value to TRUE through an upload/*

/*This gives us three logical values: Suppress(o), New__Offer(o) and

Poor_Performer(o)/*

/*Generally speaking they are presented in order of precedence/*

/*If Suρpress(o) = TRUE, wt(o) should = 0 regardless of the values of the other two/* /*If Suppress(o) = FALSE and New_Offer(o) = TRUE, wt(o) = New_Offer_Wt, regardless of the value of7* /*Poor_Performer(o), etc./*

{IF (Suppress(o) = TRUE) THEN

Wt(o) = 0 ELSE IF (New_Offer(o) = TRUE) THEN

Wt(o) = New_Offer_Wt ELSE IF (Poor_Perfomer(o) = TRUE THEN

Wt(o) = Min_Wt ELSE

Wt(o) = 1 + NormalRPK(o) END IF}

/*Next, scale the Offer's weight by dividing it by a base weight and by raising that ratio to the value of/*

/*the Multiplier. Larger values of the Multiplier increase the share that goes to better performing Offers/*

Multiplier

/*Base_Wt is a value that is configurable by the administrator on a per Unit/per Target basis/*

Next Offer

[00146] Finally, using the weights calculated in the preceding step, calculate shares, as described below, hi an exemplary embodiment, each Offer can have part of its total share optimized, and a part that is not optimized based on the Percent_Optimized constant set by the administrator. For example, if there are 100 Offers, and if Offer 5 has a share that would ordinarily give it a 5% share and if Percent_Optimized were set to 80%, then the final share for Offer 5 would be:

Final Share = C ^' ^^^Q*}^"'²⁶^ + (Percent_Optimzed)x(lnitial Share)

[00147] For this functionality to be useful, each impression/instance of an Offer is logged as either Optimized or Non-Optimized. Accordingly:

First, calculate the sum of all weights:

{Total_Wt = 0

For all Offers o in the Unit u

Total_Wt = Total_Wt + Wt(o) Next Offer}

Next, calculate the number of eligible (Suppress - FALSE) Offers: {Eligible_Offers = 0 For all Offers o in the Unit u

Eligible_Offers = EligibleJDffers + DF(Suppress = TRUE, THEN 0, ELSE 1) Next Offer} Then calculate shares: For all Offers o in Unit u

/*Need to calculate Optimized Share, Non-Optimized Share and Total Share/* /*O_Share(o), NO_Share(o), Share(o)/*

{IF (Suppress(o) = TRUE) THEN

NO_Share(o) = 0 O_Share(o) = 0 Share(o) = 0

ELSE

NO_Share(o) = (l/(Eligible_Offers)) x (l-Percent_Optimized) O_Share(o) = (Wt(o)/Total_Wt) x (Percent_Optimized) Share(o) = NO_Share(o) + O_Share(o)

END IF} Next Offer}

[00148] In an exemplary embodiment, the following attributes can be tracked:

[00149] # ofOffers in Pool.

[00150] Which Offers are in Pool (tracked even if Suppressed or otherwise got

0 impressions). [00151] Whether or not each impression was optimized or not.

[00152] Active Days for each offer.

[00153] Initiated Downloads Associated with an Offer.

[00154] Offers per Unit.

[00155] Node ID.

[00156] Site ID.

[00157] Page Type ID.

[00158] In an exemplary embodiment, the items can be products in the

Downloads product database, and administered through the Pacman tool. Creative attributes for those products' associated offers can be stored and administered as product-specific attributes.

[00159] In an exemplary embodiment, for any new product record attributes that are employed by Rubies, a Rubies attribute grouping can be created as part of the product record, where Rubies-specific attributes can be created. This new attribute group can be surfaced in the Pacman tool, wherein business users can control the specific attributes included in the grouping through the Pacman tool. For example, the following new attributes can be employed:

[00160] Flag to enable specific PIDs as being available for Offer Pool #1.

[00161] Creative text required for Unit #1 offer.

[00162] Flag to enable PIDs as being available for Offer Pool #2.

[00163] In an exemplary embodiment, should other new Rubies product attributes be employed as per detailed Rubies system design, they can be put into this attribute grouping.

[00164] In an exemplary embodiment, the Rubies application can be configured to allow Download staff to continue to schedule DLX and other promotions through existing tools (e.g., Comet and Pacman) into the Post Download pages at ontology nodes where they are scheduled to run, overriding the Rubies systems use of the page real estate otherwise reserved for Unit #1. Download staff can place to-be-determined tracking elements in these (e.g., manually) scheduled non-Rubies promotions so that the lost inventory can be tracked within Rubies reporting.

[00165] In an exemplary embodiment, reports out of Rubies/Data Warehouse can fall into the following general categories:

[00166] Primary DW Rubies Performance reporting:

[00167] These reports can focus on the performance of Rubies overall, Rubies units, and individual PPD items. Use thereof can be to monitor performance and facilitate adjustments to manual boosts, exclusions, spend caps, etc.

[00168] Metrics: Impressions, Clicks, CTR. Dimensions: item, Rubies overall/within individual units, day, ontology-based subcategory.

[00169] Impressions for overridden traffic— i.e., exclusive DLX placements.

[00170] If a certain percentage of pool were to run "non-optimized," all of the above metrics for both optimized/non-optimized.

[00171] Metrics: Delivery Share (Itemlmpressionsi/Unitlmpressions).

Dimensions: item, subcategory.

[00172] Metrics: Algorithm status: on/off, Manual boost: on/off, Suppress flag: on/off, Rubies-minimum weight: yes/no, Number of Downloads remaining under cap. Dimensions: item, unit, day.

[00173] Logged once per day.

[00174] Logged real-time.

[00175] Metrics: Actual Revenue based on Rubies-specific PPD conversion rates. Dimensions: Rubies overall/unit/item, unit, day.

[00176] Same for "Product Set."

[00177] Internal Rubies Engine/Algorithm reporting:

[00178] These reports will focus on the internal machinations of Rubies overall and specific Rubies units. Use thereof can be to monitor and/or tweak the inner workings of algorithm and scoping queries. [00179] Initially, these reports need not employ have GUIs and can take the form of automatic spreadsheet dumps. As such, they can be point-in-time snapshots without dimension.

[00180] Metrics: Various algorithm internals: CTR, calculated RPK,

Normalized RPK, share. Granularity: item, subcategory.

[00181] Some metrics, such as share, may become meaningless as the algorithm gains complexity (e.g., if new shares are calculated at runtime rather than once per day).

[00182] These metrics need not be available historically.

[00183] Metrics: Number of Items in pool, Number of Items considered for pool. Granularity: unit.

[00184] For Rubies overall, these metrics would represent the Number of Items post-Scoping query and the Number of Items pre-Scoping query (e.g., the Number of DL Items in DW Product Database), respectively.

[00185] For individual units, Number of Items in pool would be result of individual Scoping queries (e.g., if one unit pulled in only Auction PPD items). Number of Items considered would be, by definition, the Number of Items in pool for Rubies overall.

[00186] If necessary, approximations for these numbers can be inferred from delivery information (e.g., how many items showed non-zero delivery for Unit X).

[00187] These metrics can be available historically.

[00188] Standing DW Attribute-based reporting:

[00189] These reports can provide the Rubies administrator with information about item performance versus specific user/content/item attributes. These can be full, GUI-supported DW reports. Use thereof can be to monitor value of attribute's inclusion in Rubies algorithm.

[00190] In an exemplary embodiment, attributes that factor into the Rubies algorithm can be supported. In further exemplary embodiments, attributes can be added if they show CTR-improving performance in reporting. [00191] Metrics: Traffic, clicks, CTR. Dimensions: item, subcategory.

[00192] This report presumes nothing about Rubies units. While these exact numbers can be available through summary versions, conceptually, the focus here is on subcategory.

[00193] Similarly, a standing report such as the following can be provided:

[00194] Metrics: Traffic, clicks, CTR. Dimensions: item, AMTM.

[00195] Exploratory DW "Self Serve" Attribute-based reporting:

[00196] This represents a capacity rather than any actual reports. Rubies can allow an administrator to access Traffic, Clicks, and CTR data by item against a variety of possible user/content/item attributes. No GUI need be supplied. Access may take the form of pSQL or another query-based language. Use thereof can be to explore which attributes could potentially improve Rubies algorithm performance.

[00197] Examples of attributes that may be probed in this way—in essence,

"auditioning" to be made formally-reported attributes (e.g., non exhaustive list):

[00198] Sub-subcategory of Post-Download page (e.g., viewed content).

[00199] Time of day.

[00200] Geo information: DMA, State, Country ... etc.

[00201] User Registration information: age, occupation, gender ... etc.

[00202] Manufacturer of item.

[00203] Manufacturer of product (e.g., viewed content).

[00204] Item description/creative qualities: "New", "Free!", Flash, color ... etc.

[00205] Age of item, in number of days since listed (e.g., either on the pay per download web site or in PPD program).

[00206] If sessionized:

[00207] Length of User session.

[00208] Number of times an item has been viewed. [00209] Initial search term.

[00210] Referring site/host.

[00211] In an exemplary embodiment, sessionizing reporting can be provided.

[00212] FIG. 3 illustrates exemplary relationships and functions with respect to elements of FIGs. 1 and 2. In FIG. 3, the relationships between Rubies concepts are summarized, and are detailed, for example, as follows:

[00213] creative: A Rubies content block.

[00214] aggregate creative: A creative which has one or more slots, into each of which a subcreatives is placed.

[00215] item: An object whose advertisement (ad) appears (e.g., as a subcreative) in an aggregate creative. The item may be a product, computer, whitepaper, downloadable file, music file, etc.

[00216] offer: a single display form of an item. This allows the same item to have more than one advertising message. The system optimizes not only on the underlying item, but the message as represented by the offer.

[00217] subcreative: An independent block of content which appears in a slot within an aggregate creative. A subcreative is a displayed incarnation of a particular offer.

[00218] container: The part of the creative which surrounds the subcreatives.

[00219] scheduled: Assigned to appear at a particular "location" on the site. A location simply specifies to where/whom to serve the creative; it can be a combination of ontology, geotargeting, user targeting or other Madison targeting criteria.

[00220] unit: An instance of a scheduled creative. Analogous to a segment in

Madison.

[00221] creative definition: The text which defines how a creative will be assembled and rendered. Ia the case of conventional (e.g., non-aggregate) creatives, the creative definition could simply be HTML markup which is passed through to the user agent verbatim. For more complex creatives, e.g., aggregate creatives, the creative definition might be a simple HTML-like template language, or even a full- fledged scripting or programming language, such as perl, php, JSP, and the like.

[00222] offer pool (pool): The set of candidate offers which may flow through the slots of a particular scheduled container.

[00223] offer scoping query: The rules which govern which offers participate in each scheduled container's offer pool.

[00224] runtime offer scoping: The optional reduction of the offer pool at runtime, e.g., by random sampling. Runtime scoping may be necessary to help the server scale up to very large pools.

[00225] offer selection: Choosing offers (at runtime) from an offer pool; these offers will then be used to fill the creative 's slots for the current request.

[00226] runtime: The processing of a live request for a creative.

[00227] offer selection function: The logic which determines which offers to select for each runtime request.

[00228] weighting function: Logic which indicates how likely to succeed each offer would be if it were selected for inclusion in a slot in the current runtime request. The weighting function is called repeatedly by the offer selection function during runtime request processing.

[00229] offer selector: Code which implements a offer selection function.

[00230] targeting: The method of specifying selection—outside of Rubics—of a creative.

[00231] operational data: Data which is neither derived nor imported from other sources, and which can be entered directly into Rubies (e.g., manual boost).

[00232] offer data: The attributes associated with each offer, that are needed to produce displayable subcreatives from the offer; for example: product photo, street price, destination URL, etc.

[00233] performance data: Counts of impressions and clicks for each offer, broken out by all targeting attributes. Impression and click counts can be filtered. [00234] In an exemplary embodiment, a goal of Rubies can be to serve a multi- offer unit on a page that is dynamically created, with offers selected from within the business unit's product catalog and flexible enough to optimize against user response and product popularity.

[00235] Rubies was conceived as a way to deliver a more relevant experience to end users. The idea being that the more relevant that the content is for the user's goals, the better one is able to drive leads or otherwise optimize business goals.

[00236] There are other "personalization" efforts on the web and even within service providers (e.g., CNET). Rubies is focused on providing a high-performance platform that initially implements a simple optimization algorithm, but wherein the platform can scale to increasingly sophisticated usage.

[00237] FIG. 4 illustrates an exemplary architectural overview, hi FIG. 4, a high-level view of the exemplary system is provided, with a description of each component, as follows.

[00238] Offline Components:

[00239] A goal of the exemplary system is to keep runtime processing as simple as possible, so the offline components run periodically and summarize data from many sources, presenting it to the server in the form of data and configuration files.

[00240] Rubies DB:

[00241] The Rubies DB can be thought of in logical, not physical terms, in the sense that it can include a DW component, a non-DW component, and/or flat files, and the like. In an exemplary embodiment, one may opt to store everything in a DW database for convenience or choose to break out these components into separate data stores.

[00242] There are various types of data in the Rubies DB, for example:

[00243] Offer data - is a collection of offers which Rubies is currently serving.

It includes offer attributes which are used either for targeting (e.g., topicld, price, etc.) or for display (e.g., image URL, click destination, etc.). Offer data can come from site databases, and a new feed (e.g., to get more attributes) can be employed when a new unit comes online.

[00244] Performance data - represents the past performance of each candidate offer in each pool in which the offer participates. For example, one may track the performance of the Dell Optiplex 2040 against every taxonomy node in which it appears. Performance data comes from a summarizer process, the input to which is the Rubies event (e.g., impression, click, etc.) tracking logs.

[00245] Operational data - is Rubies-only data which need not already exist in a site-side database. For example, if one were to add a "manual boost by product" feature, the manual boost data can be considered operational data, since "manual boost" is not an intrinsic product attribute (and hence it doesn't make sense to store it in the product catalog).

[00246] Madison Database:

[00247] Since Rubies units can be scheduled in Madison, Rubies processes can read from Madison to determine the list of currently-running Rubies creatives.

[00248] Offer Exporter:

[00249] The offer exporter moves data (e.g., primarily offer data) from the

Rubies DB to the server's rendering handler. It packages together the offer data, which the rendering handler employs at runtime in order to assemble each request's subcreatives.

[00250] Delivery Controller:

[00251] The delivery controller is the "brains" of the Rubies server; it moves data from the Rubies DB to the server's selection handler. The delivery controller packages performance data and operational data in such a way that the selection handler can read it and calculate candidate offer weights efficiently.

[00252] IMP + CLK tracking:

[00253] Events (e.g., impressions and clicks) can be logged, so that Rubies can measure the performance of candidate offers. This logging can initially be configured through the DWs facilities, but in further exemplary embodiments can be configured into its own logging/summarizing subsystem.

[00254] User Interface (UI):

[00255] The UI can include manually-updateable files and database tables.

[00256] Reports:

[00257] Reports provide the Rubies administrators with enough information to determine which offer attributes Rubies should optimize on (and how to optimize those attributes). Reporting facilities can draw upon the available DB report capabilities wherever possible.

[00258] Trainer:

[00259] The trainer is a placeholder for a pluggable component, which helps the Rubies administrators automatically determine (and set) the best configuration parameters for each optimized attribute.

[00260] Runtime Components:

[00261] At runtime, Rubies requests can come from either the ad client (e.g.,

MAC) or from the ad engine (e.g., MAE). In further exemplary embodiments, requests can come from other sources as well (e.g., directly from JSPs). Advantageously, the Rubies protocol can be configured as an open protocol.

[00262] The Rubies server can be configured as a platform based modular component architecture. For example, the Madison Service Model (e.g., MSM) application framework, upon which the Madison Ad Client and Ad Engine are built, can be considered.

[00263] FIG. 5 illustrates exemplary runtime components. In FIG. 5, the numbered circles trace an exemplary sequence of requests, wherein:

[00264] 1. Browser makes request for a page from the web server;

[00265] 2. For each Rubies unit in the page, the MAC calls out to the Rubies server;

[00266] 3. Rubies responds with a Unit; [00267] 4. The page is returned to the browser; and

[00268] 5. A tracking image embedded in the Unit causes the browser to hit a logging server.

[00269] In an exemplary embodiment, the Rubies server can be configured such that applications other than the MAC and ad engine are able to make requests for optimized units.

[00270] FIG. 6 illustrates an exemplary internal server structure. In FIG. 6, a high-level view of the Rubies server is provided, with a description of each component, as follows.

[00271] hi an exemplary embodiment, the Rubies server can be configured as a

Madison Service Model (e.g., MSM) Controller and can be housed within an Apache module. The controller's configuration can pull in a series of handlers, each one of which performs a specific task. The steps involved, for example, can include:

[00272] Accept request.

[00273] Lookup — round out the incoming data, for instance using IP address to determine the user's Country. The Madison Ad Engine does similar fast lookups by using a Berkely Database.

[00274] Map - By using the MSM, the Rubies server gains the ability to use the same powerful mapping configurations employed by the ad system.

[00275] Select Offer — The offer selection handler is responsible for choosing a set of offers from the entire pool of candidates. It does this by examining each candidate offer, and assigning them run-time weights based on the current request's parameters (e.g., where on the site the requesting page is, the user's demographics, etc.).

[00276] Render Output - The rendering handler assembles the final creative output text. It resolves run-time variables and constructs the subcreative text for each offer that was selected by the selection handler. It then inserts each of these subcreatives into its corresponding slot in the container. The output of the rendering handler is what gets returned as Rubies 's response text. [00277] Send response.

[00278] In an exemplary embodiment, multiple server processes (e.g., on multiple machines) can be employed for performance and fault tolerance. The Rubies server may be configured to consume relatively large amounts of RAM in order to perform as quickly as possible.

[00279] FIG. 7 illustrates an exemplary offer selection handler. In FIG. 7, the details the types of activities associated with the heart of Rubies - the offer selection handler, are described. A description of each step follows, keyed to the letter points in FIG. 7. The selection algorithm works, for example, as follows:

[00280] 1. An incoming request and its associated parameters (e.g., including unitld) are passed into the selection handler (point A).

[00281] 2. The offer pool for the request's unit is retrieved (point B). If performance demands employ the use of caching, a lookup can be done to retrieve a cached weighted random set, effectively skipping to step 6 below.

[00282] 3. Loop through each offer in the pool, though some offers can be selectively skipped offers in some cases (e.g., a product can be skipped on its own product detail page).

[00283] 4. For each offer, call the pool's weighting function wt(i). As input, wt(i) takes the request's parameters. The function can also perform lookups into in- memory data structures (point C).

[00284] 5. Construct a weighted random set from the values returned by wt(i)

(point D).

[00285] 6. Randomly select the requested number of offers from the weighted random set, wherein this can be subject to any high-level constraints imposed by the administrators (e.g., not-same-merchant) (point E).

[00286] 7. Send the set of selected offers on for rendering (point F). [00287] The offer selection function is an advantageous concept. At a high level, it can be thought of as a formula that predicts a user's interest in an offer from incoming parameters. A simple example might be:

weight = (l+clickRate(offer))^ΛscalingFactor

[00288] The system, however, can be configured to support "functions," which can include full-fledged programmatic logic, for example:

If(offerId = pageSku) { weight=0 } else { weight=(l+clickRate(offer))^ΛscalingFactor }

[00289] Initially, since functions need not change frequently, they can be hardcoded into application-specific handlers. In further exemplary embodiments, a function compiler for more general support of function updates by an Administrator can be provided.

[00290] It is envisioned that functions may get quite complex, iterating over thousands of offers and doing several lookups per offer to generate a weight. Accordingly, techniques can be employed to preserve runtime performance, such as caching, splitting the pool, backend pre-processing, and the like.

[00291] FIG. 8 illustrates an exemplary Data Warehouse structure. With FIG.

8, a high-level overview of the DW impression and click tracking functionality is described, as follows.

[00292] Webserver:

[00293] Impressions and clicks generated from Rubies offers are tracked by the

DW apache servers. Offer impressions are tracked in aggregate with a single call to a transparent 1x1 pixel gif (e.g., in dw.com.com). The offers are expanded in batch processing to multiple line offers. Clicks are tracked using an http redirect. The click is logged to the (e.g., DW com.com) server first, and the user is forwarded to the click destination. It is expected that initial approximate volume of traffic will be about 5 MM impressions, resulting in a tolerable 20 additional r/s for the DW webservers, based on a current pool size. New machines can be added to the pool to scale.

[00294] In addition to the application specific dimensions like pool, unit, item, and offer, DW expects to log site specific information, such as site, page_type, ontology node, and edition, as well as standard clickstream fields, such as IP address and user-agent, and the like.

[00295] Logfiles:

[00296] Logfiles for impressions and clicks can be rotated hourly and collected using a data warehouse log collector. Log collection can be a monitored operation and someone on pager duty can respond to problems.

[00297] ETL:

[00298] The log collection process hands the raw logs files to the Extract,

Transform, and Load (ETL) process. The ETL takes place in a very fast clustered parallel processing environment, wherein data is first translated into the parallel processing application's native format. The ETL can be scaled by adding new machines to the cluster. Each step in the ETL can be monitored and can alert on failure.

[00299] Extraction:

[00300] The first step in log processing is extracting the useful information and writing that information to a format understood by the DW batch processing applications. Part of the extraction process for Rubies can be expanding single unit impressions into multiple offer impressions. The grain of the atomic data is thereafter an offer.

[00301] Transformation:

[00302] The transformation step assigns Data Warehouse keys to enterprise dimensions, such as site, edition, and page type. All of the dimensionalization DW performs on page dimensions can be made available to the Rubies flow.

[00303] In an exemplary embodiment, Rubies impressions and clicks can be sessionized. Sessionization is a transformation step during which events are sorted by user and time and assigned to sessions, representing continuous interaction with the site for a given user. For example, the session ends when the user is inactive for more than 30 minutes. Page events, redirect events, and non-billable leads can be sessionized. hi contrast, billable leads need not be sessionized.

[00304] Because sessionizing can be employed, answers questions about the context of Rubies interaction during a session can be provided (e.g., how many times in the session did a user see a unit before he or she clicked). Also, metrics that line up with other session-based reporting can be delivered (e.g., mean conversion/session on the pay per download web site). On the other hand, sessionization entails events passing through a single once-a-day step, and ties the Rubies data-flow to the SLA for activity on the site (e.g., Delivery of data by 9 AM PT).

[00305] Load:

[00306] The load step writes the transformed data set to tables (e.g., FACT tables) in the Atomic Data Warehouse (AWH).

[00307] DW DB:

[00308] The DW DB refers to the X Atomic Warehouse instance. Data retention requirements are further described. Data online in the AWH can be backed up through the preservation of files from the load step, according to a retention parameter, and a day of data can be reloaded in hours.

[00309] Facts:

[00310] Rubies can have logical offer-level facts for impressions and clicks.

The flow from FACTS and DIMS to ITEMS in the DW DB box represents pulling items for potential offers (e.g., the top 100 downloads over the last 30 days). The idea is that this would be a batch process refreshed once a day.

[00311] Dims:

[00312] The DIM object represents non-Rubies dimensions that exist in DW, including, site, ontology, page_type, and edition, as well as concrete instances of what Rubies would regard as an offer, such as products, games, software downloads, whitepapers, and news stories. Generally, the item entity described by Rubies is analogous to an asset in the X publishing system, but there are exceptions. The flow from DIMS to ITEMS represents a query for item attributes.

[00313] Items:

[00314] In an exemplary embodiment, DW can become the authority for the

Rubies ITEM-space. The reason for this is that Data Warehouse imports and tracks activity on logical items from everywhere in the enterprise, so DW is a logical place to generate a unique identifier for a Rubies item. For example, one can query the DB to pull the 20% of SSA products that get 80% of the activity on the site as a kind of "pre-scoping' query. This set of products can be assigned item ids, and exported to Rubies, where scoping can transform items into offers. The creation/refresh of ITEMS can take place daily once the scope was defined; the creation of offers can likely be transactional.

[00315] Offers:

[00316] In contrast to Items, Offers are an application-specific entity, and so

Data Warehouse can import this entity from Rubies.

[00317] Reporting:

[00318] Basic types of reporting can be provided, including a collection of standing reports that include aggregations for Rubies specific dimensions, as well as site dimensions - impression and click level reporting by site, ontology, pagetype, etc., for items or offers. Another type of reporting is more a "self-service" environment, for example, wherein Rubies experts can measure the potential effectiveness of adding "megapixels" to the optimization algorithm. The expected self-service workflow is approximately 1) the data is explored through a flexible interface supplied by DW, 2) the new attribute is auditioned in Rubies, and 3) if desired, the exploratory report can be automated.

[00319] At a high level, the focus can be on a standard set of aggregations for standing reports, as well as an interface for expert users to explore the data. The interface can expose derived attributes, such as CPU speed and megapixels that for items are only relevant for a subset of all offers. [00320] The following is a description of the Rubies database architecture and schema. The notations used, for example, include:

[00321] Column types of "id" denote an int which is also a foreign key where applicable.

[00322] Primary keys are denoted in bold type.

[00323] Table names in ORANGE indicate Rubies platform tables.

[00324] Table names in CYAN indicate Rubies application tables.

[00325] Table names in GREY indicate DW tables, which are read by Rubies operational processes.

[00326] FIG. 9 illustrates exemplary Rubies cardinalities. In an exemplary embodiment, the physical database structure can include the following logical databases:

[00327] DW AWH₅ DIM.

[00328] Rubies Atomic (can be a part of existing DW AWH).

[00329] Rubies Summary (can be part of new schema in the SWH instance).

[00330] Rubies Operational. For example, initially a temporary Rubies ops schema can be created in a DW oracle dev environment, and then the tables from this temporary schema can be migrated to an environment more appropriate for further testing and development.

[00331] Rubics_DIM Tables:

[00332] The Items dimension table:

[00333] Items is the base table for Rubies Items; all Items ever created are inserted into this table and a unique item id is assigned. Namespace, asset type, and asset are a composite key.

[00334] Rubies Item Attribute Tables:

[00335] Example: PPDJJnit lJtems:

[00336] Example of an application specific view:

[00337] Unit (see: Unit table in next section)

[00338] Pool (see: Pool table in next section)

[00339] Offer (see: Offer table in next section)

[00340] Not shown - DW DIMs Site, Ontology, Editions, PageTypes, etc.

[00341] Rubics AWH:

[00342] Offer Impression and Click Facts:

[00343] Event level grain for offers. Multiple rows derived from a single gif call for impressions. The fields are grouped by type, and the different types have alternating white and grey backgrounds for readability.

[00344] Rubics_SWH: [00345] Rubies Item Node Detail Day: [00346] Provides: Application requirements: [00347] Impressions, Clicks, CTR. [00348] By Item, Unit, Day, Overall, ontology-based subcategory. [00349] If a certain percentage of pool were to run "non-optimized," all of the above metrics for both optimized/non-optimized.

[00350] Plays the role of page_detail for pages in DW. Can build reports from this table or other rollups from here. This is still a low level of detail, but the rollup of impressions and clicks can reduce millions of rows to hundreds of rows for the downloads application.

[00351] Rubics Unit Day:

[00352] Provides: platform requirement: Impressions and clicks by unit.

[00353] Rubics_Offer_Unit_Day:

[00354] Provides: platform requirement: Offer Performance by Unit (Drill from

Units -> Offers).

[00355] Rubics_Offer_Pool_Day:

[00356] Provides: Platform requirement: Offer Performance by Pool (Drill from Pools to Offers).

[00357] Rubics Day:

[00358] Provides: platform requirement: Rubies-wide Impressions and clicks.

[00359] Rubics_Top_Offers :

[00360] Provides: platform requirement: top 20 offers per unit. This is a Unit- level rank.

[00361] Rubic DL Overrides:

[00362] Provides: Impressions for overridden traffic--i.e., exclusive DLX placements - method: can create an offer that can be used for overrides.

[00363] Delivery Share:

[00364] Provides: Application requirement:

[00365] Delivery Share (e.g., Itemlmpressionsi/Unitlmpressions).

[00366] Dimensions: item, subcategory (e.g., through ontology).

[00367] Assumes:

[00368] Delivery share calculated on the fly at whatever level is requested - site, category, sub-category.

[00369] PPD Conversion:

[00370] Provides: Metrics: Actual Revenue based on Rubies-specific PPD conversion rates. Dimensions: Rubies overall/unit/item, unit, day.

[00371] Same for "Product Set."

[00372] Method: track with a tag. Can look for the tag in the lead event. Can embed unit id in the tracking. Join to product_offer_map for CPD and spend_cap.

[00373] Database Schema: Rubies Operational:

[00374] DW (SWH) Tables/Views:

[00375] Operational Tables:

[00376] Function Factor Tables:

[00377] FIG. 10 illustrates an exemplary Rubies back-end. FIG. 11 illustrates exemplary Rubies interfaces.

[00378] In an exemplary embodiment, two logical UIs are employed: one to enter/edit product data, and one to enter/edit Rubies offer data. Physically, these can in fact be the same UI (e.g., PACMAN), but this can be an application-specific detail.

[00379] The UIs read from and write to the site product DB .

[00380] hi an exemplary embodiment, as shown in FIG. 10, an exemplary DW import process:

[00381] Reads ALL products from the site's product DB(s), and stores each product's dimensions in the AWH (point A).

[00382] Mirrors Rubies data (e.g., id, name) about Offers, Pools, Units, etc. back into the DW for foreign key and reporting needs (point B).

[00383] Feeds daily snapshots of operational data (e.g., function inputs) for historical recording (point C). hi an exemplary embodiment, filed-based and DB- table based inputs can be employed.

[00384] Item Factory:

[00385] Converts each new product into a corresponding Item, and updates existing Items if their product attributes have changed.

[00386] Rubies Sync: [00387] Mirrors DW Items into Rubies.

[00388] Offer Creation:

[00389] Converts Items to Offers. Application-specific logic dictates the semantics of the conversion. For example:

[00390] Which fields (attributes) are copied over from Item to Offer?

[00391] How many Offers do we make for each Item, and, if more than one, how do they differ?

[00392] Offer Export:

[00393] Creates data files for the Rubies server to read. The server can use this data to assemble subcreatives at runtime. Manual override files are taken as inputs, in addition to the Operational Data.

[00394] Optimization Flow:

[00395] ETL

[00396] Populates DW Item Event Fact table from webserver logs.

[00397] Summarizers:

[00398] Process Events and calculate performance metrics, e.g., click-through rate for offer X in ontology A:B:C.

[00399] Delivery Controller:

[00400] Interfaces:

[00401] Rubies Calls

[00402] Rubies "ad calls" can look like Madison ad calls:

I <!-#MAC_AD adcall=""-> |

[00403] The supported parameters can be:

[00404] RUBICS UNITJD.

[00405] page/env parameters: [00406] BRAND.

[00407] NCAT, PTYPE, et al.

[00408] RUBICS_UNIT_TYPE_ID.

[00409] RUBICS_CONSTRAINTS.

[00410] SAVE, USESAVED, etc.

[00411] Backplane API:

[00412] The Backplane provides an API to the application-specific components, which is used for setting return values, registering files to push to the server, etc.

[00413] API calls can be namespaced, e.g., rubies: :setStatus().

[00414] registerFileForPush (applicationld, directory, fileGlob, destinationName) .

[00415] registerOffer (applicationld, offerld).

[00416] setStatus (applicationld, statusCode).

[00417] Handler API:

[00418] Each application writes its application-specific modules (e.g., Delivery

Controller, Offer Exporter, etc.) within the following framework.

[00419] The module can expose the following well-known entry points:

[00420] initialize (applicationld).

[00421] run 0-

[00422] terminate ().

[00423] Delivery Controller Config.

[00424] Delivery Controller Output Files: [00425] The Delivery Controller files enable the server to make the following connections:

UNIT_SPACE (et. al) -» UNITJD -» POOL_ID + FUNCTION JD

POOLJD -> candidateOfferList | cachedWRS

FUNCTIONJD -> LOOKUP _VALUES

FUNCTION ID -> FUNCTION HANDLE -> handlerCode

[00426] Mappings From Unit to Function/Pool:

[00427] The Delivery Controller creates a set of MSM mappings which allow the server to look up functionld from unitld.

<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE mappingConf SYSTEM '_MAPPER_DTD_DIR_/mappingConf.dtd'>

<!-- $Id: UnitToFunctionMapping.conf,v 1.22003/10/1022:24:20 ronr Exp $ -> <!-- $Source: /cvs/main/ad/madison/mac/conf/ UnitToFunctionMapping.conf,v $ — >

<!~ $Name: $ ->

<!— Rubies Unit-to-Function Parameter Mapping — > <!-- Maps Unitld to Functionld — >

_<-!__ ***************** __> <!.. *** WARNING *** -->

<!- THIS IS A GENERATED FILE; DO NOT HAND-EDIT! -->

_<;| ***************** >

<!.. *** WARNING *** --> <! ***************** __>

<mappingConfname='UriitToFunction' version='2.3'> <mapping name='Rubics Unitld to Functionld'>

<!— DL vertical unit — > <mapentry id='0'>

<if-match key='RUBICS_UNIT_ID'>2</if-match> <action key='RUBICS_POOL_ID'>104</action> <action key='RUBICS_FUNCTION_ID'>355</action> </maρentry>

<actionkey='RUBICS_FUNCTION_ID'>0</action>

[00428] Pool Offer Lists:

[00429] This file tells the server which candidate offers are in each pool. xml rubies

<! — file created 04/21/2004 10:09:37 PDT by rubicsadm on clO-rubadml --> pool (poolld, poolHandle) offer (offerld)

[00430] Function Selection:

[00431] Mapping file which maps FUNCTIONJD to FUNCTION_HANDLE

(Function handlers can trigger off FUNCTION H ANDLE).

[00432] Function Factor Declarations:

xml rubies

<!— file created 04/21/2004 10:09:37 PDT by rubicsadm on clO-rubadml --> function (functionHandle, functionld) parameters param (name, type)

[00433] Function Factor Values:

[00434] A set of files exists in /var/opt/rubics/$INSTANCE/data/ named functionFactors_$FUNCTION_HANDLE.xml, for each function, which contains lookup values for each function's terms:

<defϊnes>

<!— DL vertical unit — > <mapentry id='0'> <if-match key='OFFER_ID'>15</if-match>

<action key='_ERROR_TEXT'x!- COULD NOT MAP ${OFFERJD||...} TO FUNCTION FACTOR VALUES -x/action> </default> [00435] Offer Exporter Config:

[00436] Offer Exporter Output Files:

[00437] Offer IndexList:

[00438] This file (/var/opt/rubics/$INSTANCE/data/offerIndexList.xml) is created by the Backplane, and contains a master list of all offer index files that the applications have created:

xml rubies

<!— file $FILENAME created 04/21/2004 10:09:37 PDT by rabicsadm on clO-rubadml -> param (name)

CDATA

<! — <param name='fileRoot'>/var/opt/rubics/$INSTANCE/data/offers</param> --> application (applicationHandle, applicationld) offerlndex (fileName)

[00439] Offer lndex:

[00440] A set of files exists in

/var/opt/rabics/$INSTANCE/$APP_HANDLE/data/ named offerIndex_$APPLICATION_HANDLE.xml, for each application, which contains a list of all current offers:

xml rabies

<!— file $FILENAME created 04/21/2004 10:09:37 PDT by rubicsadm on clO-rubadml -> param (name)

CDATA

<! — <param name='fileRoot'>/var/opt/rabics/$INSTANCE/data/offers</param> -> application (applicationHandle, applicationld) sendVar (localSource, localName, remoteSource, remoteName) offerList offer (offerld, fileName) [00441] Offer Data:

[00442] For each Offer, a file in /var/opt/rabics/SlNSTANCE/data/offers/ named o$OFFERID.xml:

xml rabies

<! — file SFILENAME created 04/21/2004 10:09:37 PDT by rubicsadm on clO-rubadml --> offerDetail (offerld, itemld, offerType) sendVar (sourceType, sourceVarName, destType, destVarName) <!— <sendVar sourceType='literal' sourceVarName=' 12345' destTyρe='reqmap' destVarName='OFFER_ID'> -> data

<! — platform data — > offerld  CDATA offerName <!-- OFFER_NAME -> CDATA offerTypeld <!- OFFERJTYPEJD -> CDATA itemld <!-- ITEMJD -> CDATA

<! — application data, e.g. — > param name=' [VARNAME] ' CDATA

[00443] Current SendVars can include:

[00444] <sendVar localSource='literal' localName=' 12345' remoteSource='reqMap' remoteName='OFFER_ID'/>.

[00445] ITEM_ID.

[00446] In an exemplary embodiment, tracking of links on the site to the data in the Rubies atomic schema can be provided. For example, this can be accomplished using existing components. New code can include an update to the gif inserter to generate the cnet pageview id and a module to expand offers. The rest of the flow can use existing scripts. A successful implementation of the Rubies ETL results in impressions and clicks tracked (e.g., through dw.com.com) getting loaded into the AWH daily. For example:

[00447] 1. the system can track the following for all impressions and clicks on a subcreative: [00448] a. item - in tracking string.

[00449] b. offer - in tracking string.

[00450] c. pool - in tracking string.

[00451] d. unit - in tracking string.

[00452] e. position in unit - implicit for offers, explicit for redirects.

[00453] f. optimization on/off- in "algorithm_id", if available.

[00454] g. anonymous user id - captured in cookie, if com.com.

[00455] h. ip address - part of the clickstream data.

[00456] i. site id - in tracking string.

[00457] j. page ontology - in tracking string.

[00458] k. edition id - in tracking string; edition subject to transparent edition rules.

[00459] 1. page type - will get this from the pageview_id.

[00460] 2. The system can track impressions and clicks for known robot user agent strings using the IAB robot list, updated lx/month. Internal traffic can be dropped. Behavioral filtering can be inherited from the sessionizer.

[00461] 3. hi addition to impressions and clicks, generic events (e.g., mouse overs, video starts) on offers can be tracked.

[00462] 4. Post-click events can be tracked (e.g., tags can be used in the destination redir url).

[00463] 5. Details of the algorithm that was used to deliver a subcreative can be tracked. Algorithm traceability can be on at least a daily basis, and hourly or instantaneous can be provided. This could be used, for instance, to determine how well optimization is working, and may be useful in an assisted "learning" module.

[00464] 6. Subcreatives can be traceable to the item/product they represent.

[00465] 7. Logging of the tracking information can be done in one step for the unit rather than one step per offer. [00466] 8. Impression numbers can be counted using a 302-style method comparable with existing DW and ad methods.

[00467] 9. The system can keep track of how many offers were in each pool and should take a daily snapshot of offers in the pool.

[00468] FIG. 12 is used to illustrate an exemplary fairly well-isolated flow within the greater Rubies system (for simplicity, DIM is not shown). In an exemplary embodiment, the interface for the pageview_id can be the DW_PAGEVIEW_ID note apache sub-process env table. The DW image inserter module can be extended to create the pageview_id in the environment for each page request. Handlers invoked by ssi calls, like the image inserter or ad client, can insert that id into the name value pairs of the gif call or redirects.

[00469] pageview_id definition:

[00470] fields in the id:

[00471] byte 0-3 serverjp.

[00472] byte 4-7 time__t current time.

[00473] byte 8-11 conn_rec->conn_id.

[00474] byte 12-13 static counter++; initialized to 0 and rolls over at 65535.

[00475] In an exemplary embodiment, these 14 bytes are then base64encoded using a NULL key and the trailing = sign is removed to give a base64 number, length 19.

[00476] In an exemplary embodiment, Offer Tracking can include:

[00477] Example:

http://HOSTNAME/rubicsimp/c.gif? ts=TIME

&edId=CNET_EDITION_ID

&onId=CNET_ONTOLOGY_NODE_ID

&sId=CNET_SITE_ID

&poolId=RUBICS_POOL_ID

&umtId=RUBICS JJNITJD

&alg=RUBICS_ALGORITHM_ID

&pvId=CNET_PAGEVIEW_ID

&off=RUBICS_OFFER_ID,RUBICSJTEM_ID

&off=RUBICS_OFFERJD,RUBICS_ITEM_ID\

[00478] Values:

- multiple offers permitted

- LINK_POS infered from the order of the offers. (First is 1, second is 2, etc.)

- dw_pubsys_id is supported for third party tracking

[00479] In an exemplary embodiment, Click Tracking can include:

[00480] Example:

httρ://HOSTNAME/rubicsclk? edId=CNET_EDITION_ID

&onId=CNET_ONTOLOGY_NODE_ID

&sId=CNET_SITE_ID

&poolId=RUBICS JPOOLJD

&unitId=RUBICS_UNIT_ID

&alg=RUBICS_ALGORITHM_ID

&pvId=CNET_PAGEVIEW_ID

&offId=OFFER_ID

&itemId=ITEM_ID

&linkPos=LINK_POSITION

&destUrl=FULLY_QUALIFIED_DESTINATION

[00481] Values:

dw_pubsys_id is supported for third parties

[00482] ClearGif Handler:

[00483] Config Changes:

[00484] Log impressions to a separate file — dw config change:

CustomLog "j/bin/sh. -c 'exec /usr/sbin/cronolog -z GMT

/var/opt/httpd/ PORT_/logs/rabics.imp/hostname -s\%Y%m%d%H'" clearFormat env=rubicsimp

Set up the handler:

SetEnv rubies 1

SetEnv special_log 1

SetHandler cleargif-handler

<ifinodule mod_oid.c> Ontology off

</ifmodule> </location>

[00485] Add entry to log the DWJP AGEVIEWJD note.

[00486] Rubies Redirector:

[00487] Log redirects to a separate file:

CustomLog "|/bin/sh -c 'exec /usr/sbin/cronolog -z GMT

/var/opt/httpd/ PORT_/logs/redir.^Λhostname -s\%Y%m%d%H"' leadFormat env=rubicsclk

SetEnv rabicsclk 1

SetEnv special_log 1

SetHandler dwredir-handler

<ifinodule mod_oid.c> Ontology off

</ifmodule> </location>

[00488] Distributor:

[00489] Can use the existing Distributor to pull log files from the webservers to the DW env.

[00490] Translator:

[00491] Can use the existing Translator for the impressions and clicks.

[00492] Translator can remove traffic from a known set of IP addresses (e.g., CNET internal impressions).

[00493] OfferExpander: [00494] FIG. 13 illustrates an exemplary offer expander that can be used for gif calls. The offer expander turns one gif call w/many offers into many gif calls with a single offer each. Can push all the data through, and have a no-op for redirects.

[00495] One way to do the etl is to re-use existing components. In order to include offer processing in the existing framework, a step between translator and categorizer can be provided that can expand the offer impression gif into several loglines. This component can take as input a line from translator, and for each offerid tuple in the name-value pairs, can create a copy of the logline with one offer id. These loglines can be written to the categorizer operator.

[00496] On the other hand, because these are separate logfiles, this also can be handled with dedicated components. The existing Categorizer can be moved into this framework as well. The reasoning for this would be to move away from the framework of the "legacy" categorizer, which makes it difficult to code logic based on > 1 input field, something that it turns out happens frequently enough to make categorizer hard to manage.

[00497] Interfaces:

[00498] The interface to the OfferExpander can be defined by the Translator output schema. The input/output schemas can match exactly, wherein as far as categorizer knows, the input is from translator. The difference between the input/output is that one record coming out of Translator going into the Expander can have multiple offers in the Name Value string, wherein coming out of the expander, there is only one offer per record.

record { delim="\t",final_delim=end }

(

Name Values : string; anon_cookie: string[max= 19]; bytes:int32 {default=0}; client_ip:string[max=l 5] ; client_ip_addr:uint32; event_dt_ht:timestamρ; event_dt_ut:timestamp; filenameExtension: string; global_clc:int8 {default=0}; global_id:string [max=16]; hub_id:int8; is_cookied_user:int8; is_reg_user : int8 ; machine_name:string; method:string; outbound_email_id:int64 {default=-l } ; pageHost:string; page_url:string; pathname: string; protocol: string; query:string; referrerExtension: string; referrerPath:string; referrerProtocol: string; referrerQuery : string; status:string; user_agent:string [max=250]; )

[00499] Algorithms:

[00500] 1. Read the name- value pair field from translator.

[00501] 2. Parse the offer id list from the call (e.g., remove it from the field list).

[00502] 3. For each offer: [00503] a. add the offer id, (item id) to the NVPs for that line.

[00504] b. copy the rest of the fields from the translator into output fields.

[00505] In an exemplary embodiment, the offer can be added to the output schema, with changes the interface of the existing components.

[00506] Categorizer:

[00507] The click categorization can be implemented using a separate ini file with the existing library.

[00508] Categorizer output fields, from name value pairs can include:

[00509] itemjd

[00510] offer id

[00511] pool_id

[00512] unit_id

[00513] link_position

[00514] alg (state - weighted/uniform to start)

[00515] anon cookie

[00516] client ip

[00517] site_id

[00518] ontology node id

[00519] edition_id

[00520] page type

[00521] In an exemplary embodiment, the categorizer can flag impressions and clicks for known robot user agent strings.

[00522] In an exemplary embodiment, sessionization can include:

[00523] Add session id to input stream.

[00524] Behavioral filtering is provided at this step. [00525] Add new event handling for Rubies impressions, clicks, etc.

[00526] In an exemplary embodiment, data model or file layout can include:

[00527] load dims step - ini files

[00528] new translator ini files for offers and clicks

[00529] new perl component for offer expansion, ini files

[00530] new categorizer ini files

[00531] dimensionalization step

[00532] sessionization

[00533] prepare load config files

[00534] load facts config files

[00535] In an exemplary embodiment, a set of new attributes can be created along with the existing attributes to accommodate the needs of displaying data at employed levels. The attributes can be in a new folder called Rubies.

[00536] Rubies Offer: This attribute can be formed by Rubics_Offer_Id as the

ID and Rubics OfferJSfame as the description.

[00537] Rubies Item: This attribute can be formed by Rubics_Item_Id as the

ID and Rubics_Item_Name as the description.

[00538] Rubies Pool: This attribute can be formed by Rubics Pool Id as the

ID and Rubics_Pool_Name as the description.

[00539] Rubies Unit: This attribute can be formed by Rubics_Unit_Id as the

ID and Rubics_Unit_Name as the description.

[00540] Rubies Offer Rank: This attribute can be formed by Rank as the ID.

[00541] Metrics:

[00542] A set of new facts/metrics can be created to accommodate the needs of displaying data at employed levels. All the metrics can be in the new folder called Rubies. [00543] # of Rubies Clicks: This metric can be in the form of sum(clicks) from all Rubies fact tables.

[00544] # of Rubies Impressions: This metric can be in the form of sum(impressions) from all Rubies fact tables.

[00545] # of Rubies Initiated DL: This metric can be in the form of sum(initiated_downloads) from all Rubies fact tables.

[00546] # of Rubies Completed DL: This metric can be in the form of sum(completed downloads) from all Rubies fact tables.

[00547] CTR: This metric can be in the form of sum(clicks)/sum(impressions) from all Rubies fact tables. It can be displayed in % with 2 decimal points.

[00548] Delivery Share: This metric can be in the form of sum(impressions- item level)/sum(impressions-unit level) from all Rubies fact tables. It can be displayed in % with 2 decimal points.

[00549] Web Based Reports:

[00550] Rubies Daily Performance Summary: This report can reside in the new Rubies Platform Reporting folder of PXDW application. Users can be prompted at report execution for Date(s) and Rubies Unit(s). Users also can be prompted to include Date and Rubies Unit attributes in the result or not. The finished report can include:

[00551] Date(s)

[00552] Rubies Unit(s)

[00553] # of Rubies Impressions

[00554] # of Rubies Clicks

[00555] Sort: Date - ascending

[00556] Total: Grand total at the top

[00557] Top 20 Daily Click Rates: This report can reside in the new Rubies

Platform Reporting folder of PXDW application. Users can be prompted at report execution for Date(s) and Runbics Unit(s). The finished report can include the top 20 Rubies Offers per Rubies Unit per day based on value of CTR:

[00558] Date(s)

[00559] Rubies Unit(s)

[00560] Rubies Offer(s)

[00561] # of Rubies Impressions

[00562] # of Rubies Clicks

[00563] CTR

[00564] Sort: Date — ascending, CTR — descending

[00565] Total: Grand total at the top

[00566] Cross Reference Performance: This report can reside in the new

Rubies Platform Reporting folder of PXDW application. Users can be prompted at report execution for Date(s), Site(s) and Page Type(s). Users can also be prompted for attribute(s) to be included in the report. Available attributes can be Day, Rubies Item, Rubies Offer, Rubies Unit, Rubies Pool, Site, Subcategory, Ontology_node, Page Type and Edition. The finished report can include:

[00567] Date(s)

[00568] Any attribute(s) selected by user

[00569] # of Rubies impressions

[00570] # of Rubies Clicks

[00571] CTR

[00572] Sort: Date - ascending

[00573] Total: Grand total at the top

[00574] Overridden Traffics: This report can reside in the new Rubies

Platform Reporting folder of PXDW application. Users can be prompted at report execution for Date(s) and Rubies Unit(s). The finished report can include:

[00575] Date(s) [00576] Rubies Unit(s)

[00577] # of Rubies Impressions

[00578] # of Rubies Clicks

[00579] Sort: Date - ascending

[00580] Total: Grand total at the top

[00581] Delivery Shares: This report can reside in the new Rubies Platform

Reporting folder of PXDW application. Users can be prompted at report execution for Date(s) and Subcategory(ies). The finished report can include:

[00582] Date(s)

[00583] Subcategory(ies)

[00584] Rubies Pool

[00585] Rubies Item(s)

[00586] # of Rubies Impressions

[00587] # of Rubies Clicks

[00588] Delivery Share

[00589] Sort: Date — ascending, Delivery Share — descending

[00590] Total: Grand total at the top

[00591] Rubies PPD Conversion: This report can reside in the new Rubies

Application Reporting folder of PXDW application. Users can be prompted at report execution for Date(s) and Rubies Unit(s). User can also be prompted if to include attributes Rubies Unit and Rubies Offer in the report. The finished report can include:

[00592] Date(s)

[00593] Rubies Unit(s)

[00594] Rubies Offer(s)

[00595] Product Set

[00596] Spend Cap [00597] # of Rubies Impressions

[00598] # of Rubies Clicks

[00599] # of Rubies Initiated Downloads

[00600] # of Rubies Completed Downloads

[00601] Estimated Revenue

[00602] Revenue per Impression

[00603] Sort: Date - ascending, Estimated Revenue - descending.

[00604] Total: Grand total at the top

[00605] PR Email Reports: Rubies performance emails. The emails can be created upon request.

[00606] DW Backend Enhancements:

[00607] Fact Table and Views:

PT_RUBICS_DAY

PT_RUBICS_DL_OVERRIDES

PT_RUBICS_ITEM_DELIVERY_SHARE

PT_RUBICS_ITEM_NODE_DETAIL_DAY

PT_RUBICS_OFFER_POOL_DAY

PT_RUBICS_OFFER_UNIT_DAY

PT_RUBICS_PPD_CONVERSION

PT_RUBICS_TOP_OFFERS

PT RUBICSJJNITJDAY

PT DL RUBICS OFFER UNIT PERF

[00608] Dimension Tables and Views:

DIM.PT_UNITS

DIM.PT_POOLS

DIM.PT_RUBICS_OFFERS

DIM.PT_RUBICS_OFFER_POOL_REL

DIM.PT_RUBICS_OFFER_TYPES

DIM.PT ITEMS

[00609] In an exemplary embodiment, the Rubies Download PPD Offer

Creation is part of the Rubies Download PPD application's backend system, and has the responsibility of creating/updating download ppd offers (and setting up offer - pool relationships) in the Rubies Operational database from data in the Download Product Database.

[00610] At a high level, data of all in-scope product of each download ppd unit is imported daily from the Download Product Database into DW SummaryWareHouse (SWH) Database. Offer Creation then creates/deletes Rubies download ppd offers in the Rubies Operational DB. In addition to the mode that adds new offers and removes out-of-scope offers, there is a 2^nd mode of OfferCreation that updates the current in-scope offer with data from Product Database, a use case for this is fixing offer text typos during the day.

[00611] Static mapping in Offer Creation

[00612] From SWH Views to Rubies Units: This maps each of the Views exposed in SWH to the corresponding Rubies units by "unit handle." Ideally this should not change among different environments.

[00613] From SWH Views to Rubies offerTypeld: This maps each of the

Views exposed in SWH to the corresponding Rubies offer type Id. Ideally this should not change among different environments.

[00614] "Full" mode: hi full mode, OfferCreation has the following tasks:

[00615] 1. resurrect offers of items that moved back "in-scope"

[00616] 2. creates offers for newly added in-scope products

[00617] 3. deletes the offer-pool link for those no longer in scope.

[00618] hi this mode, OfferCreation employs data from the Views provided in the SWH, but does not contact Product DB. [00619] Data from SWH View:

[00620] Algorithms:

[00621] 1. Cache current offers and mark each for "delete":

unMd->{ itemld -> [list of offered] }

[00622] 2. Cache unit-pool mapping:

unitld->[list of poollds]

[00623] 3. Iterate through all items retrieved for each SWH views:

IF the item already exists in the cached offers, mark offer for update and add offer to the "to update" group

ELSE mark item for insertion and add item to the "to insert" group

[00624] 4. For all items in the "to insert" group, query Rubies Operational DB to find those items "moved back in-scope". For those items, set OFFER STATUS back to 'A', and update SPEND_CAP_MET, CPD, PRMARY_CAT_ID.

[00625] 5. Update OFFER_ATTRIBUTE_DL tables for offers marked for update.

[00626] 6. Insert into OFFER, OFFER_ATTRIBUTE_DL,

OFFER_POOL_REL tables for offers in the "to insert" group, but not resurrected in step 4, all inserts of the same offer is in a transaction: [00627] OFFER table:

OFFERJD: new offerld (use nextld table)

NAMESPACEJD: copy

ASSET JTYPEJDxopy

ASSET JD:copy

ITEMJDxopy

OFFER TYPE JD: use static mapping

OFFERJSfAME: generate from 'Product Name'

IMPORT JDATE/UPDATE J) ATE: current time stamp

STATUS: default status ('A')

MANUALJBOOST: default manual boost (?)

[00628] OFFER_ATTRIBUTE_DL table:

OFFERJTEXT: see 'Generate Offer Text' section

SUPPRESS: default value (O')

SPEND_CAP_MET: copy

CPD: copy

INSERT_DATE/UPD ATEJD ATE: current time stamp

[00629] OFFERJPOOLJREL table:

OFFERJD: POOL ID:

[00630] 7. For all offers in offer cache marked for "delete":

set STATUS = T

[00631] "Update" mode: In this mode, OfferCreation checks all current "in- scope" offers for any "Offer text" updates from Production Database, and if there is any, (such as typo fix), it will then generate the Rubies offer text and updates Rubies Operational Database, in this mode, OfferCreation need not contact SWH.

[00632] Algorithms:

[00633] Cache assetlds for active offers from Rubies Operational DB [00634] Retrieve updated "Bulk html" and/or "Unit 2 text" from Product DB

(e.g., where only updated ones will be retrieved):

for unit 1: SELECT ρam.productld as assetld, av.attributeTextValue as unitText FROM ProductAttributeMap pam, AttributeValue av WHERE pam.ρroductAttributeId = 113 and pam.attributeValueId = av.attributeValueld and pam.productld in (list of cached assetlds) for unit 2 change productAttributeld to 114

[00635] Update OFFER ATTRIBUTE DL table.

[00636] Rubies Download PPD Offer Text Generation:

[00637] Rubies Unit 1 bulk_html generation: Users have a tool that automatically generates the bulkHTML code for the unit 1 promos: gdlserv/tools/ft/promo.php. Users manually enter the OID, product title, and promo text; and simply let the tool do the rest. The DL techprod team maintains this tool. For example, if 3000-2646-10268272.html is the OID, the tool can generate unit 1 promo which looks like this:

<a href="http://download.com.conV5000-2(5^(J-702^272.AftM/''><sρan class="a4"><b>Apollo Versatile Burner</bx/span></a>

[00638] Rubies Unit 1 bulkjitml generation:

[00639] To minimize changes on the users side, the same tool can beto generate

Rubies bulk_html code. To do so, users follow the same process as above, except in the place of OID, users can enter a tag (such as <?RUBICSJDLPPD_PRODUCT_URL?>) which can instruct OfferCreation to further process the tag. Using the above example, at this stage the Rubies bulkjitml will look like this:

<a hreϋ="<?RUBICS_DLPPD_PRODUCTJURL?>"xspan class="a4"xb>Apollo Versatile Burner</bx/spanx/a>

[00640] Rubies Unit 2 offer text generation:

[00641] Using current unit 2 offer as an example:

<tr>

<td width="5" align="left"ximg src="/i/b.gif width="5" heights" 1" border="0"x/td> <td width="100%"

class="a2">

<lixfont color="blue"xahre^='73000-2150_4-10277484.html?tag=related"xb>Netomat 1.0</bx/ax/fontx/td>

</tr>

[00642] OfferCreation will first generate Rubies unit 2 offer text like the following:

<tr>

<td width="5" align="left"ximg src="/i/b.gif width="5" heights" 1" border="0"x/td> <td

class="a2">

<lixfont coloi="blue"xa hre^="<?RUBICS_DLPPD_PRODUCT_URL?>"xbx? PRPDUCT_NAME?x/bx/ax/fon1x/td> </tr>

[00643] The <?RUBICS_DLPPD_PRODUCT_URL?> is again the product download link with Rubies tracking information, the <?PRODUCT_NAME?> is simply the Product Name in the product DB, or if it's overridden by "Rubies Unit 2 Text." [00644] <?RUBICS_DLPPD PRODUCT_URL?>

[00645] The <?RUBICS_DLPPD_PRODUCT_URL?> is the product download link with Rubies tracking information. On a high level, it icludes two components, $ (RUBICS-TRACK CLICK) and product download link.

[00646] ${RUBICS_TRACK_CLICK} is the tracking string for clicks generated by rubies served offers.

[00647] The product download link is the destination url part of the Rubies click tracking url, which after registering the click, gets redirected to the product download page. The definition of the product download url is:

http://$ {DOWNLOAD_HOST}/$ (FORMATED_PRODUCT_NAME}/$ {DOWNLOAD_P AGETYPE _ID}-$ {PRJMARY_CATEGORYJD}_$ {CNET_SITEJD}- $ {PRODUCTJOD} .html?$ {RUBICSJDWJTAGS}

[00648] So for example if RUBICS_TRACK_CLICK is:

http://dw.com.com/rubicsclick/c.gif?ts=$ (TJME_STAMP} &edld=$ (CNET_EDITION_ID} &onld =$ (CNET_ONTOLOGYJSrODE_ID}&sId=$ (CNET_SITE_ID} &poolld=$ (RUBICS_POOL_ID }&unitld=$ (RUBICS_UNIT_ID}&alg=$ (RUBICS_ALGORITHM_ID}&pvId=$ (CNET_PAGE VIEWJD } &off=$ {RUBICS_OFFER_ID} ,$ (RUBICS_ITEM_ID}

[00649] A RUBICS DW TAGS is:

part=rubics.$ {RUBICS__ALGORITHM_ID} &subj=$ (RUBICS_SITE_ID}&tag=$ (RUBICS_OFF ERJD} [00650] A fully generated <?RUBICS_DL_PPD_PRODUCT_URL?> looks like this:

http://dwxomxom/mbicsclick/c.gif?ts=20040625123500&edld=_&onld=_&sld==4&poolld=l&unitld= 2&alg=on&pvId=&ofi=123,l&destUrl=http://www.download.coin/Apollo-Versatile-Bumer/3000- 2646_4-10268272.html? part?=rabics.on&subj=2&tag=123

[00651] When this url is clicked, the click will be registered for pool 1, unit 2, offer 123, etc., and when the download is initiated, the download will be registered for Rubies unit 2, offer 123 with Rubies optimization algorithm on.

[00652] FIG. 14 illustrates an exemplary DW schema. FIG. 15 illustrates exemplary operational DB table relations.

[00653] The above-described devices and subsystems of the exemplary embodiments can include, for example, any suitable servers, workstations, PCs, laptop computers, PDAs, Internet appliances, handheld devices, cellular telephones, wireless devices, other devices, and the like, capable of performing the processes of the exemplary embodiments. The devices and subsystems of the exemplary embodiments can communicate with each other using any suitable protocol and can be implemented using one or more programmed computer systems or devices.

[00654] One or more interface mechanisms can be used with the exemplary embodiments, including, for example, Internet access, telecommunications in any suitable form (e.g., voice, modem, and the like), wireless communications media, and the like. For example, employed communications networks or links can include one or more wireless communications networks, cellular communications networks, G3 communications networks, Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, a combination thereof, and the like.

[00655] It is to be understood that the devices and subsystems of the exemplary embodiments are for exemplary purposes, as many variations of the specific hardware used to implement the exemplary embodiments are possible, as will be appreciated by those skilled in the relevant art(s). For example, the functionality of one or more of the devices and subsystems of the exemplary embodiments can be implemented via one or more programmed computer systems or devices. [00656] To implement such variations as well as other variations, a single computer system can be programmed to perform the special purpose functions of one or more of the devices and subsystems of the exemplary embodiments. On the other hand, two or more programmed computer systems or devices can be substituted for any one of the devices and subsystems of the exemplary embodiments. Accordingly, principles and advantages of distributed processing, such as redundancy, replication, and the like, also can be implemented, as desired, to increase the robustness and performance of the devices and subsystems of the exemplary embodiments.

[00657] The devices and subsystems of the exemplary embodiments can store information relating to various processes described herein. This information can be stored in one or more memories, such as a hard disk, optical disk, magneto-optical disk, RAM, and the like, of the devices and subsystems of the exemplary embodiments. One or more databases of the devices and subsystems of the exemplary embodiments can store the information used to implement the exemplary embodiments of the present inventions. The databases can be organized using data structures (e.g., records, tables, arrays, fields, graphs, trees, lists, and the like) included in one or more memories or storage devices listed herein. The processes described with respect to the exemplary embodiments can include appropriate data structures for storing data collected and/or generated by the processes of the devices and subsystems of the exemplary embodiments in one or more databases thereof.

[00658] All or a portion of the devices and subsystems of the exemplary embodiments can be conveniently implemented using one or more general purpose computer systems, microprocessors, digital signal processors, micro-controllers, and the like, programmed according to the teachings of the exemplary embodiments of the present inventions, as will be appreciated by those skilled in the computer and software arts. Appropriate software can be readily prepared by programmers of ordinary skill based on the teachings of the exemplary embodiments, as will be appreciated by those skilled in the software art. Further, the devices and subsystems of the exemplary embodiments can be implemented on the World Wide Web. In addition, the devices and subsystems of the exemplary embodiments can be implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be appreciated by those skilled in the electrical art(s). Thus, the exemplary embodiments are not limited to any specific combination of hardware circuitry and/or software.

[00659] Stored on any one or on a combination of computer readable media, the exemplary embodiments of the present inventions can include software for controlling the devices and subsystems of the exemplary embodiments, for driving the devices and subsystems of the exemplary embodiments, for enabling the devices and subsystems of the exemplary embodiments to interact with a human user, and the like. Such software can include, but is not limited to, device drivers, firmware, operating systems, development tools, applications software, and the like. Such computer readable media further can include the computer program product of an embodiment of the present inventions for performing all or a portion (if processing is distributed) of the processing performed in implementing the inventions. Computer code devices of the exemplary embodiments of the present inventions can include any suitable interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes and applets, complete executable programs, Common Object Request Broker Architecture (CORBA) objects, and the like. Moreover, parts of the processing of the exemplary embodiments of the present inventions can be distributed for better performance, reliability, cost, and the like.

[00660] As stated above, the devices and subsystems of the exemplary embodiments can include computer readable medium or memories for holding instructions programmed according to the teachings of the present inventions and for holding data structures, tables, records, and/or other data described herein. Computer readable medium can include any suitable medium that participates in providing instructions to a processor for execution. Such a medium can take many forms, including but not limited to, non-volatile media, volatile media, transmission media, and the like. Non- volatile media can include, for example, optical or magnetic disks, magneto-optical disks, and the like. Volatile media can include dynamic memories, and the like. Transmission media can include coaxial cables, copper wire, fiber optics, and the like. Transmission media also can take the form of acoustic, optical, electromagnetic waves, and the like, such as those generated during radio frequency (RF) communications, infrared (IR) data communications, and the like. Common forms of computer-readable media can include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other suitable magnetic medium, a CD-ROM, CDRW, DVD, any other suitable optical medium, punch cards, paper tape, optical mark sheets, any other suitable physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other suitable memory chip or cartridge, a carrier wave or any other suitable medium from which a computer can read.

[00661] While the present inventions have been described in connection with a number of exemplary embodiments, and implementations, the present inventions are not so limited, but rather cover various modifications, and equivalent arrangements, which fall within the purview of prospective claims.

Claims

WHAT IS CLAIMED IS:

1. A computer implemented method for offer selection handling, the method comprising: receiving a request for a web page, wherein the request includes an identification of content associated with the web page, the content includes one or more offers associated with respective items and to be displayed on the web page, and the offers include an advertised form of the respective items; determining candidate offers associated with the identification of the content, wherein the candidate offers include respective items associated with the candidate offers; assigning respective weights to the candidate offers, wherein the respective weights are based on at least one of past user interest performance of the items associated with the candidate offers, and revenue producing performance of the items associated with the candidate offers; selecting a predetermined number of offers from the candidate offers, wherein the selected offers are selected from the candidate offers having highest respective weights; and rendering the selected offers on the web page.

2. The method of claim 1, wherein the selecting step is based on use of a lookup table.

3. The method of claim 1, wherein the assigning step includes employing a scaling factor on the past user interest performance of the items associated with the candidate offers, and the revenue producing performance of the items associated with the candidate offers.

4. The method of claim 1, wherein the assigning step includes employing programmatic logic.

5. The method of claim 1, further comprising hardcoding the assigning step into application-specific handlers.

6. The method of claim 1, wherein the assigning step includes employing techniques to preserve runtime performance, including at least one of caching, splitting a pool of the candidate offers, and backend pre-processing.

7. The method of claim 1, wherein the rendering step further comprises: assembling final output text corresponding to the selected offers for the web page; resolving run-time variables associated with the selected offers; constructing respective sub-text for each of the selected offers; inserting the respective sub-text into a respective portion of response text corresponding to the web page; and sending the response text to the requester of the web page.

8. The method of claim 1, wherein the request further includes at least one of a location on a web site where the requested web page is located, and demographics of a user corresponding to the request.

9. The method of claim 1, wherein the method is implemented with a computer system including one or more hardware and software components.

10. The method claim 1, wherein the method is implemented via one or more computer readable instructions embedded on a computer readable medium and configured to cause one or more computer processors to perform the steps of the method.

11. A computer implemented system for offer selection handling, the system comprising: means for receiving a request for a web page, wherein the request includes an identification of content associated with the web page, the content includes one or more offers associated with respective items and to be displayed on the web page, and the offers include an advertised form of the respective items; means for determining candidate offers associated with the identification of the content, wherein the candidate offers include respective items associated with the candidate offers; means for assigning respective weights to the candidate offers, wherein the respective weights are based on at least one of past user interest performance of the items associated with the candidate offers, and revenue producing performance of the items associated with the candidate offers; means for selecting a predetermined number of offers from the candidate offers, wherein the selected offers are selected from the candidate offers having highest respective weights; and means for rendering the selected offers on the web page.

12. The system of claim 11, wherein the system is implemented with one or more hardware and software components.

13. A computer program product for offer selection handling, including one or more computer readable instructions embedded on a computer readable medium and configured to cause one or more computer processors to perform the steps of: receiving a request for a web page, wherein the request includes an identification of content associated with the web page, the content includes one or more offers associated with respective items and to be displayed on the web page, and the offers include an advertised form of the respective items; determining candidate offers associated with the identification of the content, wherein the candidate offers include respective items associated with the candidate offers; assigning respective weights to the candidate offers, wherein the respective weights are based on at least one of past user interest performance of the items associated with the candidate offers, and revenue producing performance of the items associated with the candidate offers; selecting a predetermined number of offers from the candidate offers, wherein the selected offers are selected from the candidate offers having highest respective weights; and rendering the selected offers on the web page.