Go to primary content
Oracle® Retail Demand Forecasting Implementation Guide
Release 16.0
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

I CPEM Calculations

Cross Promotional Effects Module (CPEM) is a data mining solution that determines promotional Cannibalization, or Halo relationships, or both between items or groups of items. The special expressions detailed in this appendix calculate cross promotional effects.

This appendix details these topics:

RdfPromoCrossEffectExpr

The promo cross effect special expression calculates the cross promotion Halo or Cannibalization effects.

RdfPromoCrossEffectExpr Syntax

The syntax for using the RdfPromoCrossEffectExpr special expression is shown in Example I-1. The input and output parameter tables (Table I-1 and Table I-2 explain the specific usage of the parameters names used in the special expression.

Example I-1 Syntax for RdfPromoCrossEffectExpr

CROSS_EFFECTS:RtnCannEff,STD_ERR:CannStdErr <-RdfPromoCrossEffectExpr(DES_SLS:LogDesnCannSls,NORM_PRICE:LogCannNorPrc,PROMO_VAR:LogCannProVar,CROSS_LIFT:LogCannLift,CROSS_MASK:CannMask,CROSS_TYPE:EffType,HIST_START:HistStrIdx,HIST_END:HistEndIdx)

Table I-1 Input Parameters for the RdfPromoCrossEffectExpr Special Expression

Parameter Name Description

DES_SLS

Aggregated deseasonalized sales at the Halo / Cannibalization level Cannibalization)

Data Type: Real

Required: Yes

Default value: 0

NORM_PRICE

Normalized regular price at the Halo / Cannibalization level

Data Type: Real

Required: Yes

Default value: 0

PROMO_VAR

Aggregated promotion variables at the Halo / Cannibalization level

Data Type: Real

Required: Yes

Default value: 0

CROSS_LIFT

Aggregated cross product sales lift at the Halo / Cannibalization level

Data Type: Real

Required: Yes

Default value: 0

CROSS_MASK

The cross promotion calculation mask to specify whether the cross effects will be calculated at Product/RHS Product/Location

Data Type: Boolean

Required: Yes

Default value: 0

CROSS_TYPE

Cross Promotion Type : 1(Cannibalization),2(Halo)

Data Type: Integer

Required: Yes

Default value: 0

HIST_START

History Start Date Index

Data Type: Integer

Required: Yes

Default value: 0

HIST_END

History End Date Index

Data Type: Integer

Required: Yes

Default value: 0

RUN_MASK

This indicator runs the SE for the given product and location.

Data Type: Boolean

Required: Yes

Default value: True


Table I-2 Output Parameters for the RdfPromoCrossEffectExpr Special Expression

Parameter Name Description

CROSS_EFFECTS

Cross effects (Halo or Cannibalization)

Data Type: Real

Required: Yes

Default value: 0

STD_ERR

Standard Error (This Parameter is useless in this release and it is reserved for future enhancement)

Data Type: Real

Required: Yes

Default value: 0


RDF Configuration Options for CPEM

CPEM gives unconstrained estimates of cross promotional elasticities, and verifies that the values are within some preset boundaries.

However, it is only at application time, in RDF, that the actual magnitude of the cross promotional lift can be calculated.

There may be several occasions when additional checks could be introduced. For instance, when an item is on promotion, it usually experiences a spike in sales. However, it may also receive Halo lift from a driver item as well. Appropriately, the cross effect should not be larger than the self lift. Preferably, the cross lift should not be larger than ten percent of the self lift.

RPAS and RDF offer the tools and hooks to implement logic preventing or alerting these types of situations.

Adjusted Forecast Example 1

An example of how the forecast can be adjusted is achieved by implementing the following pseudo code in the RPAS rules, and packaging it in the appcust.xml hook.

The stage where the rules are run can be pre-approved.

Pseudo code: 

  • if an item is on promotion

  • if halo lift > self lift * threshold then

  • halo lift = self lift * threshold

These rules prevent the halo lift from being larger than a certain percentage of the self lift for a promoted item.

Adjusted Forecast Example 2

Another example of how the forecast can be adjusted with the following pseudo code in the RPAS rules, and packaging it in the appcust.xml hook.

Pseudo code: 

  • if an item is not on promotion

  • if abs(cannibalization effect) > baseline forecast * threshold then

  • cannibalization effect = - baseline forecast * threshold

These rules prevent the cannibalization effects from dragging down the forecast too much.

Similar logic can be implemented to trigger an exception, rather than adjust the forecast, so that you can review it and determine whether or not to act.

In the pre-alert stage of the appcust.xml hook, the following logic alerts you that the cross lift is close to the self lift.

Alert logic: 

  • if an item is on promotion

  • if halo lift > self lift * threshold then

  • trigger high_halo_alert

CPEM Configuration Points

There are a few configuration points for CPEM, which define intersections at which the solution mines for Cannibalization and Halo effects, as well as supporting measures. This is handled thru labeled intersections, and the following table gives the label - level assignment for the two main ones.

Table I-3 Level - Labeled Intersection Assignment

Level Labeled Intersection

Cannibalization

#CannLvl#

Halo

#HaloLvl#


There are additional labeled intersections in CPEM, but they all depend on the two main ones.


Note:

Changing the main labeled intersections may require changing the dependent labeled intersections as well, to match the Cannibalization and Halo intersections

If the Halo level is class/region, a dependent labeled intersection may be class/region/week.

If the Halo level is changed to class/area, the dependent intersection must be changed accordingly, that is, to class/area/week.


Configuration Challenges

Finding the correct level for mining Halo and Cannibalization is not an easy task. Mining Halo is difficult because the entire merchandise space needs to be searched.

Cannibalization is difficult because the correct level is hard to determine. For instance, item is too low, but subclass may be too high.

Hierarchical Example

In the following example the item level may be too low, but Small Yogurts may be too high because of no visibility to brand or flavor.

Yogurt (Category) -> Small Yogurts (Sub Category) -> Dannon Light &rsquor;n Fit 8 oz. (Item parent) -> Dannon Light 'n Fit NF 8 oz.:Raspberry (item)

In this example, the right level may be Item parent.


Note:

The cannibalization level is recommended at the item group level. For additional information, refer to the Oracle Retail Demand Forecasting Implementation Guide.