Case Study

Complex Product Line

By 1990 the Product Lines of both Coke and Pepsi were wide and complex. The variety of Products included:

  • Bottles and Cans
  • Regular and Diet
  • Cherry and Vanilla Flavors
  • Large and Small Containers
  • Multi-Pack Bundles

This Market Simulation generates part-worth Customer Distributions for all of these Feature Variations, then combines them into Products. The Market Simulation then calculates a “Quantity Error” as the difference between the Predicted Quantity and the Actual Quantity from the Market. This “Quantity Error” is used by later Market Simulation workflows to tune each of the Features.

See also: Wikipedia – Comparison of Cola Products

This Case Study provides a high-level overview of the workflow without detailed explanation. It assumes you are already somewhat familiar with KNIME and Market Simulation. If not, start by reviewing the Building Blocks and Community Nodes.

Differentiation Pattern

This Case Study again uses a very common Differentiation Workflow Pattern to build a set of part-worth Customer Distributions for each Feature. Click here for a detailed review of the Differentiation Workflow Pattern.

#1 Brand

Brand Differentiation

This Market Simulation has not yet been tuned, so the Differentiating Parameters of all of the Features have been set up with an¬†initial “best guess”.

For the Brand Feature, Pepsi has been initialized with a Brand that has less Vertical Differentiation (Quality = -1.0) than Coke but has more Strange Differentiation (Niche = +2.0). This is to reflect Pepsi’s history of niche marketing campaigns and support of progressive causes. For example, Pepsi was the first Cola Product to specifically target African Americans in the 1940s.

The Horizontal Differentiation between the Coke and Pepsi Brands has been initialized with a Correlation = 0.75.

#2 Flavor

Flavor Differentiation

Three main Flavors have been defined:

  • Diet
  • Regular
  • Flavored

Appropriate Variations for the available Products have also been defined, including “Cherry.Coke”, “Vanilla.Coke”, “Coke.Zero”, and “Pepsi.Max”.

The ‘Differentiation Vertical’ node ranks the main Flavors, assigning the most value to ‘Diet’ and the least value to ‘Flavored’.

The ‘Differentiation Horizontal’ node is set to treat the main Flavors as “Quite Subjective”. This reflects the fact that the value Customers place upon ‘Diet’ is largely uncorrelated with the value they place upon ‘Flavored’.

#3 Can vs Bottle

Container Differentiation

A part-worth Customer Distribution for ‘Can’ and a part-worth Customer Distribution for ‘Bottle’ is created to model the different types of available beverage containers. There are no Feature Variations so the second (optional) input port is left empty.

#4 Bundles

Different Bundles

A part-worth Customer Distributions have also been set up for ‘Single’ Containers and ‘Multiple’ Container Bundles.

#5 Beverage Volume

Volume Value

A more complex workflow branch has been set up to calculate the average value Customers would place on each sized container. The model reduces the incremental value as total volume increases.

The Horizontal Differentiation has also been set up with ‘Features are Ranked’ and ‘Highly Objective’. This means that Customers will view two adjacent container sizes (say 350 ml and 450 ml) as being highly similar, while two distant container sizes (say 350 ml and 2000 ml) will be viewed by Customers as uncorrelated.

#6 Simulate Market

Product Generator

Finally all of the individual Features are aggregated into Products. At the same time, other details from the real-world market are integrated into the model, including [Price], [Cost] and [Quantity].

Note how the Products and the set of associated Features are first listed in a horizontal table and then converted into a vertical list. For more information on how this is done, see the Feature Table to List node.

The ‘Simulate Market’ node at the end of the workflow predicts the Quantity sold of each Product given the model’s Willingness To Pay (WTP) Matrix.

In addition, the ‘Simulate Market’ node calculates a ‘Quantity Error’ field. This is the difference between the Predicted Quantity sold and the Actual Quantity sold gathered from real-world research. This ‘Quantity Error’ field is used by later workflows to tune each of the Features in the Market.