This document relates generally to computer-implemented price analysis systems and more particularly to computer-implemented promotion price analysis systems.
Retailers face a difficult task when attempting to establish promotion prices for the products and/or services that they offer. The task involves balancing a seemingly set of opposing factors, such as trying to attain a profitable and rational mix of prices that will generate revenue and profit while temporarily reducing items prices during a promotion. The task is made even more difficult if the retailers are confronted with many products that have to be priced.
In accordance with the teachings provided herein, systems and methods for operation upon data processing devices are provided for determining promotion prices for a plurality of items. As an example, a system and method can be configured to receive electronic data about items for a promotion event and to receive electronic data about vehicles for a promotion event. An optimizer, which is implemented on a data processor, includes or has access to an optimization formulation for determining optimal promotion prices for the items and for determining assignments of the vehicles to the items for promoting the items during the promotion event. The determined optimal promotional prices and the determined assignments of vehicles to promote the items are provided as output to a user or to another computer program.
As another example, a system and method can be configured to receive electronic data about items for a promotion event and to receive electronic data about vehicles for a promotion event. An optimizer, which is implemented on a data processor, includes or has access to an optimization formulation for determining optimal promotion prices for the items and for determining assignments of the vehicles to the items for promoting the items during the promotion event. The determining of the optimal promotion prices through the optimizer is based upon the effect on an item's own demand and upon cross effects on demands of other items. The optimization formulation includes demand models that relate prices and support vehicle assignments of the items to demands. One or more of the demand models are nonlinear demand models. The optimizer includes local searching instructions and branching scheme instructions. The local searching instructions are configured to determine combinatorial possibilities in arriving at the optimal promotional prices and assignments of the vehicles to the items. The branching scheme instructions are configured to compute incremental changes in performance indexes associated with the assignments of the vehicles to the items. The determined optimal promotional prices and the determined assignments of vehicles to promote the items are provided as output to a user or to another computer program.
A price promotion optimization system 110 works to establish optimal or new optimal temporary reductions in prices 120 for the selected items and also can determine which vehicles 130 should be used to help promote such items. A price promotion optimization system 110 can be involved in many different contexts, such as in dealing with small-sized price promotion optimization problems as well as with complex price promotion situations involving determinations of tens of thousands of prices at thousands of locations or stores for a retailer with a nation-wide presence. As an example, a price promotion optimization system 110 can recommend items to be promoted on different vehicles and their prices by taking into account one or more of the following features in performing its price promotion optimization operations:
Users 140 can interact with the system 110 through a number of ways, such as over one or more networks 150. Server(s) 160 accessible through the network(s) 150 can host the system 110. One or more data stores 170 can store the data to be analyzed by the system 110 as well as any intermediate or final data generated by the system 110.
The system 110 can be an integrated web-based reporting and analysis tool that provides users flexibility and functionality for performing price promotion optimization. It should be understood that a system 110 could also be provided on a stand-alone computer for access by a user.
The promotion price optimization system 110 includes an optimizer 310 with an optimization formulation 312 that captures the objective 314 and constraints 316 of the business problem. The constraints 316 can be expressed as linear equalities or inequalities. A variety of constraints 316 can guide the results 308 of the system, such as promotion pricing and assignments of items to promotion vehicles:
The demand models, relating the prices and support vehicle assignments of items to demands, are nonlinear as indicated at 320. Because of this, arriving at optimal or near-optimal solutions for this problem presents mathematical difficulties given its nonlinear integer nature 320 and the problem-size defined by the number of items and locations involved in a typical promotion planning problem. Moreover, the selection of a price from a price grid and the assignment of an item to a support vehicle lead to a discrete or integer optimization formulation as shown at 322. This results in an optimization formulation 312 that is a nonlinear mixed-integer optimization formulation.
As shown in
The local search algorithm 400 can account for non-linear effects introduced due to interactions among support vehicles. For example, assigning an item to both vehicles A and B can lead to demand increase higher than the sum of increases by assigning to A or B individually. In such a case, if item 1 is currently assigned to both vehicles A and B, then replacing item 1 by item 2 on only one vehicle can lead to inferior solutions due to the fact that in the revised solution, items 1 and 2 are assigned to one vehicle each. However, replacing item 1 by item 2 on both vehicles may lead to a better solution than the current solution because this solution has item 2 receiving a non-linear demand increase.
A branching scheme 402 is combined with the local search algorithm 400 to ensure that the local search does not get trapped in inferior solutions. In the branching scheme 402, evaluating the quality of a solution requires estimation of demand, revenue, and margin values for the current prices and assignments. Since a very large number of solutions are evaluated in order to arrive at a local-optimal solution, it is useful to be able to evaluate a solution quickly. The algorithm can compute the incremental changes in demand, revenue, and margin over the previous solution.
The optimization formulation 312 of a price promotion optimization system 110 can be mathematically specified in different ways, such as an approach having the mathematical formulation described below that captures the demands of items as a function of price settings and assignments of items to support vehicles. The mathematical formulation described below captures the objective and constraints of a promotion optimization problem. Most of the constraints are expressed as linear equalities or inequalities. The integer optimization is used because the prices of promoted items come from a grid of price points and the assignments of items to support vehicles have to be binary variables. The demand models, relating the prices and promotion supports of items to demands, are nonlinear resulting in a nonlinear mixed-integer optimization formulation.
For the optimization formulation 312, the following notation is used to outline the mathematical formulation and the solution approach:
Additional notations are used herein when needed in the demand model and the optimization formulation 312.
With reference to this notation and to
M
iljb
=e
α
×X
jb+(1−Xjb) (2)
In this model, the demand of item i at location l, represented by dil, is modeled as the base forecast multiplied by the lift multipliers resulting from price discounts and support vehicle assignments.
In the log-linear form of a direct model, only the price multiplier, Milj], of the log-linear differs from the log-log form:
In the optimization formulation 312, the driver variable is the price variable and Xib, the variables indicating assignments of items to branches of support vehicles. In the optimization formulation 312, the price discounts 512 are as follows:
Item i can be assigned to at most one point in the grid of promotion prices.
The recommended price of an item is captured as the sum of two terms. The first term represents the promoted price if item is assigned to one of grid points. The second term represents the regular price when all Yig variables for this i are set to zero.
In the optimization formulation 312, support vehicle assignments 514 are as follows:
The number of items assigned to a vehicle should not exceed the capacity of vehicle. If an item is assigned to a branch containing vehicle v, then it implies that the item is assigned to vehicle v. Hence, assigning an item to a branch results in assigning an item to all vehicles in the branch.
An item could be assigned to at most one branch of support vehicles.
This ensures that an item assigned to vehicle v is also discounted using price promotion. It should be included for all i, v pairs where vehicle v requires price promotion also.
In the optimization formulation 312, the revenue target 516 is as follows:
rev+rSlack≧revTarget (11)
Revenue should exceed the revenue target. Any shortfall in reaching the revenue target is captured by variable rSlack.
In the optimization formulation 312, the margin target 518 is as follows:
marg+mSlack≧margTarget (13)
Margin should exceed the margin target. Any shortfall in reaching the margin target is captured by variable mSlack.
In the optimization formulation 312, the percent margin target 520 is as follows:
margPct+mtSlack≧margPctTarget (15)
Percent margin should exceed the percent margin target. Any shortfall in reaching the percent margin target is captured by variable mtSlack.
In the optimization formulation 312, the demand target 520 is as follows:
dem+dSlack≧demTarget (17)
Demand should exceed the demand target. Any shortfall in reaching the demand target is captured by variable dSlack.
The objective 522 is then specified in terms of its components. Putting the components together leads to the overall objective, with the maximization terms as follows:
wdemObj×dem+wrevObj×rev+wmargObj×marg+wmargPctObj×margPct
The optimization formulation 312 can also include target penalties as follows:
wrSlack*rSlack+wmSlack*mSlack+wmtSlack*mtSlack+wdSlack*dSlack
The weighted sum of slacks in achieving targets is to be minimized. Only one of the four weights is set to a non-zero value. The KPI used for setting the target should be different from the KPI that is used as the objective. Weights are set to be zero for KPIs not used as targets.
The operational scenario generates a locally optimum solution of the original problem. It can generate a solution that can not be improved upon by making price changes or by performing item swaps on support vehicles. Due to the incremental evaluation of a solution from the previous solution, a large number of solutions can be evaluated in a short time to allow optimization of large-scale problems involving thousands of items and locations.
With respect to the operational scenario at step 600 in
At step 602 key performance indexes (KPIs) (e.g., revenue, margin, percent margin, and demand) and target shortfalls are calculated for the starting solution. The best solution is initialized as the starting solution. The count of “improving moves” is initialized to zero.
At step 604 the current item is initialized as the first item.
At steps 606 and 608, if the price grid has a deeper discount than the current price, then the deeper discount closest to the current price is selected.
At steps 610 and 612, if the current item is required to have the same price promotion as a set of other items, then the current prices of the other items is set the same as this price.
At steps 614 and 616, the KPIs (e.g., revenue, margin, percent margin, and demand) and target shortfalls are calculated for the current solution using the demand model described above. Calculation of new KPIs is performed by computing incremental changes from the previous solution. For example, if the price of item is changing from 25% to 33% discount, then it loses the lift received from 25% discount and gains the lift from 33% discount. The cross effect of this price change shows in the demands of other related items as well which shift from the effect of 25% discount to the effect of 33% discount. The other KPIs such as revenue and margin are correspondingly changed. KPIs of items not related by cross effect remain unchanged. Shortfalls from targets are updated using the incremental changes in the KPIs.
At steps 618 and 620, if the current solution is better than the best solution, then the best solution is updated as the current solution. Solutions are compared first on satisfaction of target. If the KPI target is not reached, then the solution that is closer to target is considered better. If the target is reached, then the solution with the higher value of KPI that is selected as the objective is considered better. If the best solution is updated, then the count of improving moves is incremented by 1 and processing proceeds to step 628; otherwise, processing continues to step 622.
At step 622, if step 614 evaluated a deeper discount than current price, then processing proceeds to step 626; otherwise it proceeds to step 628.
At steps 624 and 626, if the price grid has a lesser discount than the current price, then the lesser discount closest to the current price is selected and processing returns to step 614; otherwise, processing proceeds to step 628.
By step 628, either changing price of current item to an adjacent discount has updated the best solution or both increasing and reducing the discount has not succeeded in improving the best solution. The next item is selected and process returns to step 608. If no item remains, then processing proceeds to step 632.
By step 632, a move to adjacent prices has been tried on all items and improving moves have resulted in updating the best solution. The first item is selected at 632 as the current item and processing proceeds to step 634.
At step 634 the first branch of support vehicles is selected as the current branch.
At steps 636 and 638, if an item is currently assigned to any branch other than the selected branch, then it is removed from these branches. If the current solution is such that the item is already assigned to all vehicles in the branch, then processing continues to step 652; otherwise, processing proceeds to step 642.
At step 642, among the vehicles in the branch that do not have a current item assigned yet, a set A is created as the vehicles that have reached the capacity (i.e., limit on assignments), and B is set as the vehicles that have room to accommodate one or more items.
At step 644, an item is assigned to all vehicles in set B.
At step 646, an assigned item is swapped with the current item for vehicles in set A. An item to remove from the vehicle is selected as the item that gives the least contribution to the KPIs among the currently assigned items.
At step 648, KPIs (e.g., revenue, margin, percent margin, and demand) and target shortfalls are calculated for the current solution obtained by assignments and removals in steps 644 and 646. The demand model described above is used for calculating lifts. Calculation of new KPIs is performed by computing incremental changes from the previous solution. For example, if item 1 is removed from a vehicle and item 2 is assigned in its place, then the demand for item 1 is adjusted to remove the lift from assignment and the demand for item 2 is adjusted up to account for the lift from assignment. Cross effects of removing item 2 and assigning item 1 are also considered. Other KPIs such as revenue and margin are correspondingly changed. KPIs of items not related by cross effect remain unchanged. Shortfalls from targets are updated using the incremental changes in the KPIs.
At step 650, if the current solution is better than the best solution, then the best solution is updated as the current solution. Solutions are compared first on satisfaction of target. If a KPI target is not reached, then the solution that is closer to target is considered better. If a target is reached, then the solution with the higher value of KPI that is selected as the objective is considered better. If the best solution is updated, then the count of improving moves is incremented by 1.
At step 652, the next branch is selected as the candidate for assignment. If all branches have been searched, then processing proceeds to step 654; otherwise processing returns to step 636.
At step 654, the next item is selected as the candidate for assignment. If all items have been searched, then processing proceeds to step 658; otherwise, processing returns to step 634.
At step 658 if the count of improvements is zero, then a local optimum has been reached since no changes to adjacent prices or assignment swaps on support vehicles can improve the solution. If a local optimum is not reached, then the counter of improvements is reset to zero and processing returns to step 604; otherwise, processing stops.
It should be understood that, similar to the other processing flows described herein, the steps and the order of the steps in the processing flow of
While examples have been used to disclose the invention, including the best mode, and also to enable any person skilled in the art to make and use the invention, the patentable scope of the invention is defined by claims, and may include other examples that occur to those skilled in the art. Accordingly the examples disclosed herein are to be considered non-limiting. As an illustration,
A price promotion optimization system streamlines the promotional planning process, i.e. between marketing and merchandising and can evaluate impact of promotional decisions on revenue and margin. Through the promotion plans and a price promotion optimization system, a user can handle many different types of promotion decision problems, such as:
The following provides an example of different operations and user interfaces of a promotion price optimization system that can be used within the workflow of
In the workflow of
When a user works with an event, the user typically creates event vehicles that advertise an event. The user also creates and works with event plans that define how to implement an event. Event vehicles and event plans automatically act within the scope of the event that contains them. Specific product assignments for an event vehicle or for an event plan are executed at all locations within the scope of an event.
To create an event, from any view of an open calendar, the user selects New Event from the Menu drop-down list that is located in the top-right corner of the calendar window. An example of a New Event dialog box appears at 1600 in
To open an event, a user can open an existing event from any view of a calendar. When the user opens an event, the event window opens. The user can see the following information in the event window:
To open the event window from any view of an open calendar, a user completes the following steps:
To modify event details, a user clicks the Event details link in an event window to open the Event Details dialog box, such as the one shown in 1700 in
To view of modify the event scope, a user accesses the Scope Definition dialog box to modify the scope of an event. The scope of an event is the set of products and locations that are available to that event. The default scope of an event is the same as the scope for the calendar that contains the event. However, the user can refine the scope of an event to be a subset of the calendar scope. Event plans that the user creates contain the same scope as the associated event. Note: The user cannot modify the scope of an event if that event contains an active plan.
The user accesses the Scope Definition dialog box from the Scope link in the event window. Alternatively, the user accesses this dialog box from the Scope link in the Event Details dialog box.
After the user closes the Scope Definition dialog box, the number of products and locations that are included in the event scope is reflected in the Scope section of the event window.
The user can review the performance of an event on the Event Performance tab of an event window. This tab displays two tables that summarize the performance of the products and locations that are included in an event. The third table lists all products that are promoted in an event.
At the top of the Event Performance tab, there is a message area. The user is notified in this area when key performance indexes or indicators (KPIs) are out-of-date or when there are calculation errors. This area also displays the date and time when data was last updated. The user can update KPIs for an event by clicking Update KPIs. This button is dimmed if KPIs are up-to-date. Note: If there are errors during KPI calculation, a message appears in the Message tab for an event.
The Event Scope Performance table displays the KPIs for all products and locations that are included in the scope of an event. The Promoted Items Performance table displays KPIs for all products that are included in one or more event vehicles or that have promotional pricing (or both). The values that are displayed in these two tables are the same when the scope of an event is the same as the set of promoted products and locations. Any negative values are displayed in parentheses.
The columns that appear in the Event Scope Performance table and the Promoted Items Performance table are described in the following table:
The Promoted Products table lists the set of products that are included in an event vehicle or that have promotional pricing (or both). The user can control the columns that appear in this table. The user selects the columns that the user wants to see in the Promoted Products table from the Show drop-down list. These are the default column sets:
The user can modify the columns that appear for each column set by selecting that set from the Show drop-down list and selecting Customize Columns from the Menu dropdown list that is located in the top-right corner of the current window. Note: Any negative values are displayed in parentheses.
When the user publishes an event, that event becomes visible to all users whose scope overlaps with the event in at least one product and location. The user can make modifications to the scope of an event after it has been published, although the user cannot change the start or end dates for an event after it has been published.
To publish an event from the event window, the user completes the following steps:
To publish an event from the list of events for a calendar, the user completes the following steps:
The user can delete an event to remove it from a calendar. This removes the event and all associated event vehicles and event plans for that event. To delete an event from the event window, complete the following steps:
To delete an event from any view of a calendar window, the user completes the following steps:
With respect to event vehicles, an event vehicle is a tool, such as a radio commercial or a newspaper insert, that supports a promotional event. The following provides information about the tasks that the user can perform with vehicles in the event window.
The user clicks the Event Vehicles label in the event window to view the list of existing event vehicles. From the Event Vehicles section, the user can perform the following tasks:
To create an event vehicle, a user completes the following steps to add a vehicle to the list of event vehicles in the event window:
To view an event vehicle's details, a user accesses the Vehicle Details dialog box to view or modify details for an event vehicle. In this dialog box, the user can make changes to the following settings for a vehicle:
A user completes the following steps to view or modify details about a vehicle that appears in the Event Vehicles list of the event window:
To delete an event vehicle, the user can delete any vehicle in the event vehicle list of the event window. To do this, the user completes the following steps:
With respect to event plans, a user accesses an event plan to work with individual products. For each plan, the user can perform the following tasks:
The user clicks the Event Plans label in the event window to view the list of existing event plans. From the Event Plans section, the user can perform the following tasks:
To create an event plan, a user completes the following steps to create an event plan:
To modify an event plan, the user can modify an event plan in the event plan window. To do this, the user opens an event plan window by selecting the name of the plan from the Event Plans list in an event window. Then the user selects Open Plan from the Menu drop-down list that is located in the top-right corner of the event window. The event plan window opens with the name of the event plan as the title of the window and displays details about the event plan. An example of this interface window is shown at 1900 and
The user accesses the Plan Details dialog box to modify the details for an event plan, such as the dialog box 2000 depicted in
When the user opens an event plan or a temporary price change (TPC), the user sees a message that tells the user that regular prices are being retrieved. No changes can be made to an event plan or a TPC until all regular prices have been loaded.
To modify the goals and constraints for an event plan, in the optimization/evaluation section of the event plan window, the user can see information about the event plan status and optimization and pricing constraints. This information includes the following:
To set optimization goals and price constraints for an event plan, the user completes the following steps:
To select the products that are assigned to a plan, the Product assignments list displays the products that are assigned to an event plan or an event vehicle. Each row in the Product assignments list represents either a single product or a group of products from the product hierarchy. The user can control the columns that appear in the Product assignments list. The user selects the columns that the user wants to see in the Product assignments list from the Show drop-down list. These are the default column sets:
The user can modify the columns that appear for each column set by selecting that set from the Show drop-down list and selecting Customize Columns from the Menu dropdown list that is located in the top-right corner of the current window.
If there are products that are in the scope of an event and that are included in an overlapping TPC, those products appear in the event list automatically. All rows for those products are dimmed in the Product assignments list and promotional pricing is limited if there are already approved price changes.
Similarly, products for overlapping calendar vehicles appear in the Calendar Vehicle Assignments list. The products and the name of the calendar vehicle are displayed in this list. This is list is read-only, and it is shown for the user's reference. The user opens the appropriate calendar vehicle window to make changes to the list of products that are assigned to a calendar vehicle.
To modify the entries in the product assignments list for a manual plan, the user adds products or product groups to the Product assignments list so that the user can work with them. In this list, the user indicates promotional prices for products, and the user assigns products to event vehicles.
For an optimized plan, all products that are in the event scope are eligible for promotional pricing and for inclusion in event vehicles. The optimization process selects products from the event scope for promotional pricing and vehicle assignment. The selected products are added to the Product assignments list automatically. However, if there are products that the user wants to designate for promotional pricing or for inclusion in an event vehicle, then the user can add them to the Product assignments list. Similarly, if there are products that the user wants to exclude from promotional pricing or from inclusion in an event vehicle, then the user can add those products to the Product assignments list. After the user adds them to the list, the user indicates whether to include or to exclude them from optimization results, such as through the dialog box 2100 depicted in
To remove products from the Product assignments list, the user highlights those products and click the interface item. In the confirmation dialog box, the user clicks OK to complete the deletion request. The user clicks Cancel to cancel the request.
To enable calculation of optimal promotional prices for the products in an event plan, the user needs to optimize that event plan. During optimization, the system selects a subset of products and locations from the event scope and calculates all allowable pricing combinations to determine the solutions that meet the plan target value. From this set of solutions, the one that maximizes the event plan goal is used to set promotional prices. During optimization, these actions occur:
Note: Before the user optimizes an event plan, all regular prices and supply costs are loaded. In the event plan window, the user verifies that the status bar (in the lower right of the Revenue Optimization window) does not indicate “Getting regular prices.”
To optimize an event plan from the event plan window, the user completes the following steps:
To optimize an event plan from the event window, the user completes the following steps:
Optimization might take some time, depending on the number of products and locations that are included in the plan. When optimization is complete, promotional prices appear in the Promotion Amount column of the Product assignments list. In addition, any event vehicle assignments are indicated with a green check in the column for that vehicle. Because optimization might take some time, the user can continue working in another view or the user can close the application. Optimization continues in the background. Note: Each row in the Product assignments table is treated independently during optimization. This is true even if a product on one row is a subproduct of another row.
To assign products to an event vehicle manually, the user can use the Product assignments list to control product assignments to event vehicles. Each event vehicle has a check box column in the Product assignments list. The user can look at this column to see which products have been assigned to or excluded from the associated event vehicle.
If the user optimizes a plan, assigning a product to an event vehicle forces all optimized solutions to include the product in that event vehicle. Similarly, excluding a product forces all optimized solutions to exclude the product from that event vehicle.
To assign a product to an event vehicle, the user completes the following steps:
To exclude one or more products from an event vehicle, the user completes the following steps:
To enter changes in price or cost manually and evaluate an event plan, a user accesses the Product assignments list to enter prices when those prices apply across price zones. If the user is setting prices that vary across price zones, then the user accesses the Set Price By Price Zone dialog box. Note: If the user optimizes an event plan, then the user can force a product to always have promotional pricing by selecting the check box in the Promotion Amount column of the Product assignments list. The user does not have to enter a price in the Promotion Amount cell. The user can designate the type of promotional price in the Promotion Type column.
To enter promotional prices manually in the Product assignments list, the user completes the following steps:
To enter changes in cost in the Product assignments list, the user completes the following steps:
To evaluate the effects of cost or price changes, after the user enters changes to promotional prices (or to costs), the user evaluates the effect of these changes for an event plan. To evaluate an event plan, the user selects Evaluate from the Menu drop-down list that is located in the top-right corner of the event plan window.
To set prices by zone and evaluate an event plan, a user accesses the Set Price By Price Zone dialog box to set prices if the user selected the Price by zone option during plan creation. If the user enabled this setting, then the Allow promoted price to vary by Prize Zones setting has a check mark beside it in the Optimization/Evaluation section.
To enter promotional prices manually across price zones, the user completes the following steps:
To evaluate the effects of price changes, after the user enters price changes using the Set Price By Price Zone dialog box, the user then evaluates the effect of those price changes. To evaluate an event plan, the user selects Evaluate from the Menu drop-down list that is located in the top-right corner of the event plan window.
To review optimization or evaluation messages after optimization or evaluation is complete, the user looks in the Optimization/Evaluation section to review any messages that pertain to those calculations. In this section, the user sees the status of the optimization or evaluation, as well as any warnings or errors.
The user sees a warning message in this section after optimization or evaluation is complete if there are plan goals or targets that are not met. The user also sees a warning message in this area when the KPIs for a plan are out-of-date. This can occur after data has been updated or after a change has been made to an overlapping calendar vehicle or TPC.
If any errors occurred, the Messages tab comes into view automatically in the event plan window. All error messages are listed on this tab.
To Review the Performance of an Event Plan, after optimization or evaluation is complete, the user can review the expected performance of an event plan on the Plan Performance tab of the event plan window. The section at the top contains the Plan Performance table. If necessary, the user clicks the Plan Performance label to view this table. The contents of the Plan Performance table are described in the following table.
Note: Any negative values are displayed in parentheses.
If the user is satisfied with the results of an event plan, the user can publish the event that contains the plan.
To change the status of an event vehicle after product assignment to event vehicles is complete, the user approves the assignments by changing the status of the vehicle.
Note: The user can change the status of an event vehicle when the key performance indexes (KPIs) for an event are up-to-date.
To change the status of an event vehicle, the user completes the following steps:
To change the status of a price promotion to implement an event plan, after promotional prices have been assigned to products in the Product assignments list, the user approves the price promotion so that those prices can be implemented. When the user approves a price promotion, the user selects the current event plan to become the only active plan. As a result, any overlapping event plans become inactive. The only action that the user can perform with an inactive plan is to delete it from the event window.
The user can have more than one active plan for an event. This is often the case when the user compares the effectiveness of one plan with others. However, price changes cannot be implemented until a price promotion has been approved and the remaining plans have become inactive. Note: When a plan becomes inactive, it cannot become active again. The user needs to unapprove a price promotion, and then create new alternative event plans if the user wants to perform more comparisons between event plans.
To change the status of a price promotion, the user completes the following steps:
The user can copy an event plan for an event. This saves time when the user wants to create a new event plan that is similar to an existing event plan. An example of a copy event plan dialog box is shown at 2300 in
To copy an event plan from the event plan window, complete the following steps:
To delete a plan from the list of event plans in an event window, the user completes the following steps:
To delete a plan from the event plan window, the user completes the following steps:
Regarding vehicles, a vehicle is a tool, such as a radio commercial or newspaper insert, that is used to create awareness of promotions. A vehicle can stand alone (a calendar vehicle), or it can be associated with an event (an event vehicle). Typically, calendar vehicles are planned well in advance, often up to a year ahead. Event vehicles are planned as the user plans a promotional event.
Vehicles have a scope-a defined set of products and locations-associated with them. During system installation and configuration, the solution administrator implements the definitions for the vehicle types that are specific to the user's organization.
The user can perform the following tasks with vehicles:
The user can view the list of calendar vehicles for a calendar in the Vehicle List view of a calendar. The user can access the Vehicle List for a calendar by opening a calendar and selecting Vehicle List from the View drop-down list.
The columns that appear in this list are explained in the following table:
Regarding the calendar vehicle window, the user can control the details of a calendar vehicle from the calendar vehicle window. An example of a calendar vehicle window is shown at 2400 in
The Calendar details section displays the start and end dates, the status, and the name of the calendar that contains the calendar vehicle.
The Scope section displays a count of the total number of products and the total number of locations that are available to the calendar vehicle. The Scope label is a link to the Scope Definition dialog box.
The Product assignments section displays the products that are assigned to a calendar vehicle. Each row in this section represents either a single product or a group of products from the product hierarchy. The user controls the products that are assigned to a calendar vehicle in the Product assignments section.
Regarding the Event Vehicle List, the user can view the list of support vehicles for an event in an event window. The user can access an event window by opening an event from the calendar chart view or from the Event List view.
The columns that appear in the event vehicle list are explained in the following table:
Regarding vehicle categories and category attributes, the system can support a number of vehicle categories. These categories represent the various vehicles that might be used to support promotional events or to promote a set of products. The default vehicle categories that are available in the system are listed here:
The vehicle category descriptions that are discussed here are based on the default categories that come with a promotion optimization system. Some details, such as the specific attributes for each category and even the list of vehicle categories, might vary depending on the configuration for the user's organization.
Each vehicle category has attributes that are specific to that category. The values that the user enters for these attributes, such as vehicle size or placement, are mapped to a level of support. For example, a half-page newspaper vehicle might map to a medium support level, and a full-page newspaper vehicle might map to a high support level. The information about the vehicle category and its support level is used to track the sales impact for similar vehicles. This information is then used to predict more accurately the expected retail impact of new vehicles.
The values that the user can enter for category-specific attributes are generally specific to the user's organization.
Regarding BOGO vehicles, a user uses a BOGO (Buy One, Get One) vehicle to give a promotional price on a product when the customer purchases one or more of the same product. For example, a grocer might allow a customer to buy one can of soup and receive a second can of the same soup at half price.
In addition, when defining a BOGO vehicle, the user can specify that the customer must purchase more than one of an item in order to receive a promotional price for an additional item. For example, a clothing retailer might advertise a special where the customer receives a free shirt with the purchase of two shirts in the same line.
BOGO vehicles have these specific attributes:
Regarding a coupon vehicle, a coupon vehicle is an advertisement that has an accompanying coupon. Customers receive a promotional price when they provide their coupon during a purchase.
A coupon vehicle has these specific attributes:
Regarding a discount vehicle, a user uses a discount vehicle to apply a discount to the current price of all products that are assigned to it. If a product is already designated as part of a price reduction, then the price for that product is further discounted by the amount that is indicated in the discount vehicle. That is, any other discount is applied to a product first and then discounted by the percentage in the discount vehicle.
Discount vehicles have one specific attribute: the size of the discount percentage. All products that are assigned to a discount vehicle receive the same percentage discount from the current price.
Regarding an X for Price vehicle, an X for Price vehicle is similar to a BOGO vehicle because customers receive discounts when they purchase more than one unit of a product. With an X for Price vehicle, customers receive a promotional price when they purchase a specific quantity of an item. For example, as part of a promotion, the user might offer a price of $9.00 for two items that normally cost $5.00 individually. There are no default attributes that are associated with an X for Price vehicle.
A calendar vehicle is a stand-alone vehicle that is planned well in advance of execution. Calendar vehicles are not associated with an event. An event vehicle is created to support a promotional event. The purpose of calendar vehicles and event vehicles is to increase demand for the products that they feature.
To create a new vehicle, a user completes the following steps:
To open a vehicle, a user completes the following steps to open a calendar vehicle:
For an event vehicle, there is no vehicle window to open. To access details about an event vehicle, the user accesses the Vehicle Details dialog box.
The user can modify the following details about a calendar vehicle or an event vehicle in the Vehicle Details dialog box:
The user opens the Vehicle Details dialog box for a calendar vehicle by clicking the Vehicle details link in an open calendar vehicle window. Alternatively, the user can select Calendar Vehicle Details from the Menu drop-down list that is located in the top-right corner of the calendar vehicle window.
The user opens the Vehicle Details dialog box for an event vehicle from an open event window by completing the following steps:
To use the vehicle details dialog box, the user can modify the details of a vehicle by using the Vehicle Details dialog box, such as the dialog box depicted at 2600 in
To modify the product assignments for a vehicle, when the user creates a vehicle, the user defines the scope of that vehicle. This is the list of products and locations that are available to a vehicle. Before a vehicle can be implemented, the user assigns specific products to that vehicle. The products that the user assigns are selected from the vehicle's scope. The number of products or product categories that the user assigns to a vehicle cannot exceed the number of spots that are designated for a vehicle. This value does not apply to all vehicle types. For example, BOGO and coupon vehicles do not have a limit on the number of spots that can be assigned to them.
To Assign Products to a Calendar Vehicle, for a calendar vehicle, the user sets product assignments in the Product assignments section of the calendar vehicle window. Each row in this section represents either a single product or product category from the product hierarchy. Calendar vehicles automatically apply to all locations of the products that are assigned to them. To modify the product assignments for a calendar vehicle, the user completes the following steps:
For an event vehicle, the user controls product assignments in the Product assignments section of an event plan window. The user creates an event vehicle before products can be assigned to it from an event plan. There are several ways that products can be assigned to an event vehicle:
To modify the product assignments for an event vehicle, the user completes the following steps:
The user accesses the Assign Products dialog box to add products or product categories to the Product assignments section of a calendar vehicle or an event plan window. The user can access the Assign Products dialog box by clicking the interface item in the Product assignments section. An example of such a dialog box shown at 2700 in
The status of an event vehicle appears in the Event Plans list of an event window. The user scrolls over to the column that displays the name of a vehicle to see the status of that vehicle. The status of a vehicle is updated nightly. Note: Only event vehicles have a status that is associated with them. An event vehicle can have the following status values:
The user can change the status of an event vehicle from the Product assignments section of an event plan window. The user completes the following steps to change the status of an event vehicle:
The user can delete a calendar vehicle from the calendar vehicle window or from a calendar window. To delete a calendar vehicle from the calendar vehicle window, the user completes the following steps:
To delete a calendar vehicle from the Chart view or the Vehicle List view of a calendar, the user completes the following steps:
The user can delete an event vehicle from the event window by completing the following steps:
As additional example of the wide scope of the systems and methods disclosed herein, it is further noted that the systems and methods may be implemented on various types of computer architectures, such as for example on a single general purpose computer or workstation (as shown at 2800 on
It is further noted that the systems and methods may include data signals conveyed via networks (e.g., local area network, wide area network, interne, combinations thereof, etc.), fiber optic medium, carrier waves, wireless networks, etc. for communication with one or more data processing devices. The data signals can carry any or all of the data disclosed herein that is provided to or from a device.
Additionally, the methods and systems described herein may be implemented on many different types of processing devices by program code comprising program instructions that are executable by the device processing subsystem. The software program instructions may include source code, object code, machine code, or any other stored data that is operable to cause a processing system to perform methods described herein. Other implementations may also be used, however, such as firmware or even appropriately designed hardware configured to carry out the methods and systems described herein.
The systems' and methods' data (e.g., associations, mappings, etc.) may be stored and implemented in one or more different types of computer-implemented ways, such as different types of storage devices and programming constructs (e.g., data stores, RAM, ROM, Flash memory, flat files, databases, programming data structures, programming variables, IF-THEN (or similar type) statement constructs, etc.). It is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.
The systems and methods may be provided on many different types of computer-readable media including computer storage mechanisms (e.g., CD-ROM, diskette, RAM, flash memory, computer's hard drive, etc.) that contain instructions (e.g., software) for use in execution by a processor to perform the methods' operations and implement the systems described herein.
The computer components, software modules, functions, data stores and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code. The software components and/or functionality may be located on a single computer or distributed across multiple computers depending upon the situation at hand.
It should be understood that as used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise. Finally, as used in the description herein and throughout the claims that follow, the meanings of “and” and “or” include both the conjunctive and disjunctive and may be used interchangeably unless the context expressly dictates otherwise; the phrase “exclusive or” may be used to indicate situation where only the disjunctive meaning may apply.
This application claims priority to and the benefit of U.S. Application Ser. No. 60/923,454 (entitled “Computer-Implemented Promotion Optimization Methods and Systems” and filed on Apr. 13, 2007), of which the entire disclosure (including any and all figures) is incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
5195172 | Elad et al. | Mar 1993 | A |
5319781 | Syswerda | Jun 1994 | A |
5627973 | Armstrong et al. | May 1997 | A |
5652842 | Siegrist, Jr. et al. | Jul 1997 | A |
5712989 | Johnson et al. | Jan 1998 | A |
5767854 | Anwar | Jun 1998 | A |
5799286 | Morgan et al. | Aug 1998 | A |
5867494 | Krishnaswamy et al. | Feb 1999 | A |
5926820 | Agrawal et al. | Jul 1999 | A |
5946662 | Ettl et al. | Aug 1999 | A |
5953707 | Huang et al. | Sep 1999 | A |
5963910 | Ulwick | Oct 1999 | A |
5999908 | Abelow | Dec 1999 | A |
6009407 | Garg | Dec 1999 | A |
6014640 | Bent | Jan 2000 | A |
6023684 | Pearson | Feb 2000 | A |
6029139 | Cunningham et al. | Feb 2000 | A |
6041267 | Dangat et al. | Mar 2000 | A |
6076071 | Freeny, Jr. | Jun 2000 | A |
6078892 | Anderson et al. | Jun 2000 | A |
6115691 | Ulwick | Sep 2000 | A |
6151582 | Huang et al. | Nov 2000 | A |
6175876 | Branson et al. | Jan 2001 | B1 |
6182060 | Hedgcock et al. | Jan 2001 | B1 |
6226623 | Schein et al. | May 2001 | B1 |
6236977 | Verba et al. | May 2001 | B1 |
6237138 | Hameluck et al. | May 2001 | B1 |
6249768 | Tulskie et al. | Jun 2001 | B1 |
6263315 | Talluri | Jul 2001 | B1 |
6275812 | Haq et al. | Aug 2001 | B1 |
6286005 | Cannon | Sep 2001 | B1 |
6321133 | Smirnov et al. | Nov 2001 | B1 |
6321206 | Honarvar | Nov 2001 | B1 |
6397224 | Zubeldia et al. | May 2002 | B1 |
6456999 | Netz | Sep 2002 | B1 |
6470344 | Kothuri et al. | Oct 2002 | B1 |
6484179 | Roccaforte | Nov 2002 | B1 |
6502077 | Speicher | Dec 2002 | B1 |
6526526 | Dong et al. | Feb 2003 | B1 |
6546135 | Lin et al. | Apr 2003 | B1 |
6553352 | Delurgio et al. | Apr 2003 | B2 |
6560501 | Walser et al. | May 2003 | B1 |
6581068 | Bensoussan et al. | Jun 2003 | B1 |
6584447 | Fox et al. | Jun 2003 | B1 |
6611829 | Tate et al. | Aug 2003 | B1 |
6640215 | Galperin et al. | Oct 2003 | B1 |
6643659 | MacIssac et al. | Nov 2003 | B1 |
6728724 | Megiddo et al. | Apr 2004 | B1 |
6735570 | Lacy et al. | May 2004 | B1 |
6750864 | Anwar | Jun 2004 | B1 |
6898603 | Petculescu et al. | May 2005 | B1 |
6901406 | Nabe et al. | May 2005 | B2 |
6907382 | Urokohara | Jun 2005 | B2 |
6970830 | Samra et al. | Nov 2005 | B1 |
7039594 | Gersting | May 2006 | B1 |
7062447 | Valentine et al. | Jun 2006 | B1 |
7068267 | Meanor et al. | Jun 2006 | B2 |
7085734 | Grant et al. | Aug 2006 | B2 |
7089266 | Stolte et al. | Aug 2006 | B2 |
7092896 | Delurgio et al. | Aug 2006 | B2 |
7092918 | Delurgio et al. | Aug 2006 | B1 |
7092929 | Dvorak et al. | Aug 2006 | B1 |
7130811 | Delurgio et al. | Oct 2006 | B1 |
7133876 | Roussopoulos et al. | Nov 2006 | B2 |
7133882 | Pringle et al. | Nov 2006 | B1 |
7171376 | Ramakrishnan | Jan 2007 | B2 |
7236949 | Natan et al. | Jun 2007 | B2 |
7240019 | Delurgio et al. | Jul 2007 | B2 |
7249031 | Close et al. | Jul 2007 | B2 |
7251615 | Woo | Jul 2007 | B2 |
7302400 | Greenstein | Nov 2007 | B2 |
7302410 | Venkatraman et al. | Nov 2007 | B1 |
7310646 | Rangadass et al. | Dec 2007 | B2 |
7346538 | Reardon | Mar 2008 | B2 |
7370366 | Lacan et al. | May 2008 | B2 |
7379890 | Myr et al. | May 2008 | B2 |
7395255 | Li | Jul 2008 | B2 |
7440903 | Riley et al. | Oct 2008 | B2 |
7505482 | Adamczyk et al. | Mar 2009 | B2 |
7519908 | Quang et al. | Apr 2009 | B2 |
7536361 | Alberti et al. | May 2009 | B2 |
7617119 | Neal et al. | Nov 2009 | B1 |
7689456 | Schroeder et al. | Mar 2010 | B2 |
7752067 | Fotteler et al. | Jul 2010 | B2 |
7756945 | Andreessen et al. | Jul 2010 | B1 |
7798399 | Veit | Sep 2010 | B2 |
7877286 | Neal et al. | Jan 2011 | B1 |
7895067 | Ramakrishnan | Feb 2011 | B2 |
20020013757 | Bykowsky et al. | Jan 2002 | A1 |
20020046096 | Srinivasan et al. | Apr 2002 | A1 |
20020072953 | Michlowitz et al. | Jun 2002 | A1 |
20020099678 | Albright et al. | Jul 2002 | A1 |
20020107723 | Benjamin et al. | Aug 2002 | A1 |
20020116237 | Cohen et al. | Aug 2002 | A1 |
20020123930 | Boyd et al. | Sep 2002 | A1 |
20020169654 | Santos et al. | Nov 2002 | A1 |
20020169655 | Beyer et al. | Nov 2002 | A1 |
20020178049 | Bye | Nov 2002 | A1 |
20030023598 | Janakiraman et al. | Jan 2003 | A1 |
20030028437 | Grant et al. | Feb 2003 | A1 |
20030050845 | Hoffman et al. | Mar 2003 | A1 |
20030078830 | Wagner et al. | Apr 2003 | A1 |
20030083924 | Lee et al. | May 2003 | A1 |
20030083925 | Weaver et al. | May 2003 | A1 |
20030088458 | Afeyan et al. | May 2003 | A1 |
20030097292 | Chen et al. | May 2003 | A1 |
20030110072 | Delurgio et al. | Jun 2003 | A1 |
20030110080 | Tsutani et al. | Jun 2003 | A1 |
20030120584 | Zarefoss et al. | Jun 2003 | A1 |
20030126010 | Barns-Slavin | Jul 2003 | A1 |
20030126136 | Omoigui | Jul 2003 | A1 |
20030167098 | Walser et al. | Sep 2003 | A1 |
20030172145 | Nguyen | Sep 2003 | A1 |
20030208402 | Bibelnieks et al. | Nov 2003 | A1 |
20030208420 | Kansal | Nov 2003 | A1 |
20030220830 | Myr | Nov 2003 | A1 |
20030229502 | Woo | Dec 2003 | A1 |
20030236721 | Plumer et al. | Dec 2003 | A1 |
20040093296 | Phelan et al. | May 2004 | A1 |
20040103051 | Reed et al. | May 2004 | A1 |
20040111388 | Boiscuvier et al. | Jun 2004 | A1 |
20040111698 | Soong et al. | Jun 2004 | A1 |
20040199781 | Erickson et al. | Oct 2004 | A1 |
20050033761 | Guttman et al. | Feb 2005 | A1 |
20050066277 | Leah et al. | Mar 2005 | A1 |
20050096963 | Myr et al. | May 2005 | A1 |
20050197896 | Viet et al. | Sep 2005 | A1 |
20050198121 | Daniels et al. | Sep 2005 | A1 |
20050256726 | Benson et al. | Nov 2005 | A1 |
20050256753 | Veit et al. | Nov 2005 | A1 |
20050262108 | Gupta | Nov 2005 | A1 |
20050267901 | Irlen | Dec 2005 | A1 |
20050289000 | Chiang et al. | Dec 2005 | A1 |
20060047608 | Davis et al. | Mar 2006 | A1 |
20060069598 | Schweitzer et al. | Mar 2006 | A1 |
20060074728 | Schweitzer et al. | Apr 2006 | A1 |
20060143030 | Wertheimer | Jun 2006 | A1 |
20060248010 | Krishnamoorthy et al. | Nov 2006 | A1 |
20070055482 | Goodermote et al. | Mar 2007 | A1 |
20070100981 | Adamczyk et al. | May 2007 | A1 |
20070174119 | Ramsey et al. | Jul 2007 | A1 |
20070223462 | Hite et al. | Sep 2007 | A1 |
20070288296 | Lewis | Dec 2007 | A1 |
20080077459 | Desai et al. | Mar 2008 | A1 |
20080140581 | Mayer | Jun 2008 | A1 |
20080140688 | Clayton et al. | Jun 2008 | A1 |
20080208678 | Walser et al. | Aug 2008 | A1 |
20080208719 | Sharma et al. | Aug 2008 | A1 |
20090271241 | Pratt | Oct 2009 | A1 |
Number | Date | Country |
---|---|---|
1413955 | Apr 2004 | EP |
WO 0111522 | Feb 2001 | WO |
2007002841 | Jan 2007 | WO |
Number | Date | Country | |
---|---|---|---|
60923454 | Apr 2007 | US |