Data Requirements (Optimization - List Price)
- Ondřej Tesař
A List Price Optimization model needs Datamart or Data Source to run. Two sources are needed:
Transactions Datamart or Data Source
Costs Datamart or Data Source (optional)
Price Elasticity model using Multi Factor Elasticity accelerator (optional)
Transactions
Field | Required? | Comment |
|---|---|---|
Product | Yes | Typically Product ID or SKU |
Product Label | Yes | If there is no label, the same field as Product will be provided. |
Product Group | Yes | Can be any category to group the products. |
Customer Level | Yes | A category for grouping customers, such as customer segment, country… It should not be Customer IDs, which might result in performance issues; the model is not intended to be computed at the customer level. |
Quantity | Yes |
|
Revenue at List Price | Yes | List Price * Quantity. The unit List Price is then computed at a Product level. |
Discount | Yes | Correspond to discounts that apply to the list price. This discount amount is converted to a discount rate (by product and customer level) and this discount rate is used within the model to assess the impact. Extended to the quantity. May require summing up together a few fields to get this “discount”. |
Invoiced Revenue | Yes | Extended to the quantity. The difference between the Invoice Revenue and the Revenue at List Price and Discount is the “On-Invoice Adjustment”: The unit Invoice Price and the unit On-Invoice Adjustment are defined at a Product and Customer Level granularity. |
Rebates | Yes | Correspond to rebates that apply to the Invoice Revenue. This rebate amount is converted to a rebate rate (by product group and customer level) and this rebate rate is used within the model to assess the impact. Extended to the quantity. May require summing up together a few fields to get these “Rebates”. |
Net Revenue | Yes | Extended to the quantity. The difference compared to the Invoiced Revenue is the Off-Invoice Adjustment minus the Rebates: The unit Net Price and the unit Off-Invoice Adjustment rate are defined at a Product and Customer Level granularity. |
Gross Margin | Yes | Extended to the quantity. The difference compared to the Net Price is the Cost. The unit Gross Margin is defined at a Product and Customer Level granularity. The unit Costs are defined at a Product granularity. |
List Price Lower Bound | No | Unit value. If defined, then it is used in the model, otherwise just ignored. If, in some rows, the lower bound is higher than the upper bound, then none of the bounds are used for those rows. |
List Price Upper Bound | No | Unit value. If defined, then it is used in the model, otherwise just ignored. If, in some rows, the lower bound is higher than the upper bound, then none of the bounds are used for those rows. |
Costs (Optional)
Field | Required? | Comment |
|---|---|---|
Product | Yes | Typically Product ID or SKU |
Unit Cost | Yes | Unit value |
Date of cost | Yes |
|
Date of Application | No | Defines the date for which the costs are taken: latest available cost at the date of application. If no date of application is selected, then the latest future cost is used. |
Some aggregations are done during the model run. The assumption here is that the data are defined at the expected level of aggregation. If not, the average value, at the expected level of aggregation, is used.
Price Elasticity Model (Optional)
A price elasticity model computed by the Multi Factor Elasticity accelerator is optional. This adds possibility to assess the impact on the quantity of a list price change and provide a maximization of the revenue and/or profit.
Such model should be consistent with the List Price model in term of scope and time frame, as the scope of the price elasticity model should at least include the scope of the List Price model.
For further details about how a price elasticity should be set up and how it works, please refer to the documentation of the Multi Factor Elasticity accelerator