Product Generator

Input Ports

Input Product Features: The set of Features that define each Product (and Product Variation) in the Market. Each row corresponds to a Feature that can be found in one or more Products. Note that 'Price' is not a Feature that should be included here - 'Price' is added downstream as part of the Input Product Array to a Market Simulation node. The Input Product Features must have the following columns:

1. Product (string): List of Product Names or Product ID values. If the same Product is sold from multiple Locations then unique Product Names should be used for each combination. For example, a Product.Location format could be used for Product 'P1' sold at three locations: P1.L1, P1.L2, and P1.L3. Similarly if the same Product is sold by competing rivals, then unique Product Names should be used for each competitive Store. For example, a Store.Product format could be used for the Product 'P1' sold by three Stores: S1.P1, S2.P1, and S3.P1. Each unique Product Name found in the Input Product Features table will be added to the Output Product Array and Output WTP Matrix.
2. Feature (string): List of Features associated with the given Product. Each listed Feature should have a matching Customer Distribution of the same name in the Input Customer Distributions table. Each Customer Distribution contains the part-worth values for the Feature across all Customers. The Product Generator node will aggregate these Feature part-worth Customer Distributions together into a total Willingness To Pay (WTP) value that each Customer has for the Product. A Feature name may be a generic term that can describe many Products. For example, the "Coke" Feature and the "Pepsi" Feature could be used to describe the Brand value of a number of Products. Alternatively, a Feature may be specific to a single Product. For example, the Feature "Coke.Classic.Bottle.Shape" could be used to describe the differentiation offered by just the original Product. Finally, if the Product is a multi-pack bundle then the same Feature can be added to the Product more than once.
3. Attribute (string): (optional) Special Features can also be identified by the Attribute column. Special Features can describe either Categorical Attributes or Numerical Attributes. Categorical Attributes include: 'Description', 'Brand', 'Store', 'Location', 'Family', 'Category', 'Platform', and 'Units'. These Categorical Attributes can be specified in either the 'Attribute' column or specified in their own named column. Categorical Attributes found in either the 'Attribute' column or in their own named column are expected to also be found in the 'Input Customer Distributions' and will be aggregated. Care should be taken to avoid double-counting. Numerical Attributes include: 'Price', 'Cost', 'Volume', 'Quantity', and 'Transactions'. If the Attribute column is set to 'Price', 'Cost', or 'Volume' then the Feature column is expected to contain a double (floating point) value. If the Attribute column is set to 'Quantity' or 'Transactions' then the Feature column is expected to contain an integer value. The Attribute column can be created by an upstream 'Feature Table To List' node.
4. Price (double): (optional) The incremental Price or Price adjustment to charge the Customer when providing the Feature as part of the Product. Price can be included as a Special Feature in the 'Attribute' input column, or in its own 'Price' input column. The Product Generator node will aggregate the Price of each Feature into a total Product Price in the Output Product Array. If Price is set both here and in the Input Feature List, then this value can be used to personalize the Price for the particular Product.
5. Cost (double): (optional) The incremental Cost or Cost adjustment born by the supplier to provide the Feature to the Customer. Cost can be included as a Special Feature in the 'Attribute' input column, or in its own 'Cost' input column. The Product Generator node will aggregate the Cost of each Feature into a total Product Cost in the Output Product Array. If Cost is set both here and in the Input Feature List, then this value can be used to personalize the Cost for the particular Product. For example, if a Competitive Rival has a Cost advantage due to Economies of Scale and can produce the same Feature for $10 cheaper than other Competitors, then this value could be set to '-10.0'.
6. Volume (double): (optional) The 'Static Volume' of the Product relative to the Volume of other Products in the Market. For example, if a Product were a twin-pack then its Volume would be '2' while the Volume of the original Product would be '1' (default). Other scales could also be used, so that one Product might be 250 (ml) while another 500 (ml). But care with the scale should be taken as the Units are disregarded and the default of '1' will always be used if a Volume is missing. This 'Static Volume' field in the 'Input Product Array' is only important if an accompanying 'Dynamic Volume' field (or _VOL field) is found in the 'Input WTP Matrix'. Otherwise this field is ignored as Virtual Customers do not distinguish Products by the different Volume they require.
7. Capacity (integer): (optional) The Capacity Constraint for the Product. A Product's Capacity may be limited by manufacturing constraints or by inventory levels. If the Capacity level is provided then the Quantity sold for the Product cannot exceed the Capacity limitation. If Capacity is not provided, or Capacity is negative, then the Quantity sold for the Product is not limited.
8. Quantity (integer): (optional) A reference Quantity sold for the Product in the actual (real-world) Market. Quantity can be included as a Special Feature in the 'Attribute' input column, or in its own 'Quantity' input column. Typically only a single Quantity per Product is specified. But if multiple Quantity values are found for a Product, then the Product Generator node will aggregate all of the values together into a total Product Quantity in the Output Product Array.
9. Transactions (integer): (optional) A reference number of Transactions for each Product in the actual (real-world) Market. Transactions are only relevant if Customers purchase by Volume. That is, the 'Input WTP Matrix' must contain either a 'Volume' field or at least one '_VOL' field. Otherwise each Customer will purchase only a single Product, and the number of Transactions will equal the Quantity sold.

Input Feature List (optional): Additional information about each Feature that can be aggregated into the final Product. The Input Feature List must have the following columns:

1. Feature (string): The unique identifier for each Feature Variation. Each listed Feature should have a matching Customer Distribution of the same name in the Input Product Features table as well as in the Input Customer Distributions table. Products comprising this Feature will also aggregate additional data from the row.
2. Price (double): (optional) The incremental Price to charge the Customer when providing the Feature as part of the Product. The Product Generator node will aggregate the Price of each Feature into a total Product Price in the Output Product Array. This method of Price generation is similar to Cost-Plus-Pricing where each Product Feature provides a fixed contribution to the final Price. Note that this method of Pricing-by-Feature is not the most common way to set Price, but it can be a convenient way for the Product Generator node to generate a starting default Price for each Product. Price can later be optimized to maximize Revenue, maximize Profit, or maximize Market Share by a downstream Price Optimization node.
3. Cost (double): (optional) The Cost born by the supplier to provide the Feature to the Customer. The Product Generator node will aggregate the Cost of each Feature into a total Product Cost in the Output Product Array. Note that using each Feature Cost here is but one way of calculating the overall supply Cost of the Product to Customers. A fixed Cost and Profit Margin for each Product can be generated elsewhere. Or each Customer may have a different 'Cost to Serve' that is calculated separately.
4. Volume (double): (optional) The 'Static Volume' of the Product relative to the Volume of other Products in the Market. For example, if a Product were a twin-pack then its Volume would be '2' while the Volume of the original Product would be '1' (default). Other scales could also be used, so that one Product might be 250 (ml) while another 500 (ml). But care with the scale should be taken as the Units are disregarded and the default of '1' will always be used if a Volume is missing. This 'Static Volume' field in the 'Input Product Array' is only important if an accompanying 'Dynamic Volume' field (or _VOL field) is found in the 'Input WTP Matrix'. Otherwise this field is ignored as Virtual Customers do not distinguish Products by the different Volume they require.
5. Capacity (double): (optional) The Capacity Constraint for the Product. The Product Generator node will aggregate the Capacity of each Feature into a total Product Capacity in the Output Product Array.
6. Quantity (double): (optional) The Product Quantity sold in the real-world Market. The Product Generator node will aggregate the Quantity of each Feature into a total Product Quantity in the Output Product Array.
7. Transactions (integer): (optional) A reference number of Transactions for each Product in the actual (real-world) Market. Transactions are only relevant if Customers purchase by Volume. That is, the 'Input WTP Matrix' must contain either a 'Volume' field or at least one '_VOL' field. Otherwise each Customer will purchase only a single Product, and the number of Transactions will equal the Quantity sold.

Input Customer Distributions (double): The set part-worth values for each Feature and each Virtual Customer in the Market. Each row corresponds to a Virtual Customer and contains the Customer's part-worth value for the Feature. Each column and matching entry in the 'Input Product Features' table corresponds to the Feature's Customer Distribution. In addition, this 'Input Customer Distributions' can also contain two types of 'Dynamic Price' and two types of 'Dynamic Cost' Distributions that depend upon the Customers who Purchase the Product. These personalized 'Dynamic Prices' and 'Dynamic Costs' adjust the 'Static Price' and 'Static Cost' found in the 'Input Product Array' to calculate the Product's Margin. This 'Input WTP Matrix' may also contain 'Dynamic Volume' fields which allow Virtual Customers to Demand different levels of Quantity of each Product.

1. Feature01, Feature02, etc (double): Each of the Features listed in the 'Input Product Features' should have a corresponding column in this 'Input Customer Distributions' table. Each row represents a different Virtual Customer, and each value represents the Customer's part-worth value for each Feature.
2. Volume (double - optional): The personalized 'Dynamic Volume' of Product demanded by each Virtual Customer. For example, if the 'Input Product Array' contains a list of beverages of Volume 250ml, 330ml, 500ml, 750ml, and 1000ml then a Virtual Customer with a demanded Volume of '1000' could purchase a Quantity of either 4, 3, 2, 1, or 1 of the Products (respectively). If Customers are buying by Volume then they must purchase in whole number integers. For instance, if a Product had a Volume of 250ml but a Customer demanded 300ml then the Customer would only be able to buy 1 of that Product. Note that the excess Volume of 50ml received by the Customer is deemed to be of no value! The Price, WTP, and Consumer Surplus are all re-scaled by the relative Quantity demanded. When Customers buy in Volume then the Output Transactions field will differ from the Output Quantity field - otherwise these two values ought to be the same. Note that the 'Input Product Array' need not also contain a 'Volume' field. If the Product Volume is missing then the Product is presumed to be sold in Volumes of 1 Unit.
3. _VOL (double - optional): The per-Product 'Dynamic Volume' (VOL) demanded by each Virtual Customer. This per-Product 'VOL' value will override the general 'Volume'. For example, a Virtual Customer buying laundry detergent might generally demand a 'Volume' of 2 (Litres) but might only demand a '_VOL' of 1 (Litre) for the concentrated detergent Product. Negative values will be replaced with a Demand Volume of zero '0'. If both of the 'Dynamic Volume' values ('Volume' and '_VOL') are missing then a default of '1' will be used.
4. _PAV (double - optional): The Price Adjustment Variable (PAV) is the percentage adjustment to the Price (typically a Discount) a particular Customer would receive when they Purchase the Product. For example, if the Customer is entitled to a 10% Discount then the 'PAV' would be set to 0.90. The 'Price Adjustment Variable' column is identified by the Product's Name followed by a trailing 'PAV'. The 'PAV' designator can be upper-case or lower-case and may-or-may-not be separated by a space, underscore, or other single character. For example, 'Product_01_PAV' or 'Product 02 PAV' or 'Product03pav'.
5. _PAF (double - optional): The Price Adjustment Fixed (PAF) is the fixed adjustment to the Product's Price. For example, if Customers pay different amounts for Shipping the Product then this could be modeled using the 'PAF' column. If the WTP Matrix contains both 'PAV' and 'PAF' columns, then the Price is first multiplied by the variable 'PAV' before adding the fixed 'PAF'. The 'Price Adjustment Fixed' column is also identified by the Product's Name followed by a trailing 'PAF' in a manner similar to the 'PAV' designator.
6. _CTS (double - optional): The Cost To Serve (CTS) is the additional Cost that must be incurred when a Product is sold to a particular Customer. This is a Dynamic Cost as some Customers are cheaper to serve than others, and is only incurred if the Customer actually Purchases the Product. The 'Cost To Serve' column is identified by the Product's Name followed by a trailing 'CTS'. The 'CTS' designator can be upper-case or lower-case and may-or-may-not be separated by a space, underscore, or other single character. For example, 'Product_01_CTS' or 'Product 02 CTS' or 'Product03cts'.
7. _CTM (double - optional): The Cost To Make (CTM) depends not upon the individual Customer but upon the number of Customers who Purchase the Product. This 'Cost To Make' can be used to simulate the Law of Diminishing Returns. Starting from the first row in the column, each 'Cost To Make' row represents the incremental Cost of manufacturing each additional Product. If the Product is sold ten-times, then the total Dynamic Cost is the sum of the first 10 CTM rows. The 'Cost To Make' column is also identified by the Product's Name followed by a trailing 'CTM' in a manner similar to the 'CTS' designator.

Output Ports

Output Product Array: The Output Product Array contains all of the unique Products found in the Input Product Features table, along with calculated values in the 'Mean', 'SD', and 'Cost' columns that reflect the aggregated Customer Distributions across all Features. This Output Product Array must be supplemented with Product 'Price' data before it can be connected to a downstream Market Simulation node. The Output Product Array will contain these columns:

1. Product: The unique Product found in the Input Product Features table. A new Willingness To Pay (WTP) Customer Distribution with matching name will also be found in the 'Output WTP Matrix'.
2. Description: The description of the Product or the full name of the Product if the Product field contains an identification number.
3. Price: The starting Price to charge the Customer for the Product if setting Price by the Features included in the Product. This Product Static Price is the sum of all Feature Prices found in the Input Feature List.
4. Cost: The Cost born by the supplier to provide the Product to the Customer. This Product Static Cost is the sum of all Feature Costs found in the Input Feature List.
5. Volume: The given 'Static Volume' of the Product relative to the Volume of other Products in the Market or '1' if the Volume has not been defined in the input.
6. Units: The given Units of Measurement (UoM) associated with the Product's Volume.
7. Capacity: The Capacity Constraint for the Product. A Product's Capacity may be limited by manufacturing constraints or by inventory levels. If the Capacity level is provided then the Quantity sold for the Product cannot exceed the Capacity limitation. If Capacity is not provided, or Capacity is negative, then the Quantity sold for the Product is not limited.
8. Quantity: A reference Quantity sold for the Product in the actual (real-world) Market. If the Quantity is provided to a downstream Market Simulation node then a 'Quantity Error' can be calculated as part of a Market Tuning Loop.
9. Transactions: The simulated number of Transactions for each Product. By default, each Customer will purchase only a single Product, and the number of Transactions will equal the Quantity sold. Transactions and Quantity will only vary if Customers are purchasing by Volume. That is, the 'Input WTP Matrix' must contain either a 'Volume' field or at least one '_VOL' field so that Virtual Customers demand different Product Quantity.
10. Mean: The Mean of the WTP Customer Distribution values found in the 'Output WTP Matrix'. The relative difference of the Means between Products reflects the primary degree of Vertical Differentiation between each.
11. SD: The Standard Deviation (SD) of the WTP Customer Distribution values found in the 'Output WTP Matrix'. A Product lacking Vertical Differentiation (that is, having a low Mean) can still attract Customers if it has a relatively high SD, or if it has Horizontal Differentiation (that is, its Customer Distribution uncorrelated) relative to other Products.

Output Willingness To Pay Matrix: The Output WTP Matrix made up of the Customer Distributions for each Product in the Market. Each column name matches a Product from the Output Product Array. Each row corresponds to the Willingness To Pay (WTP) of a Virtual Customer for each Product. The Output WTP Matrix quantifies the maximum Price that each Customer would pay for each Product in the Market if no other Products were available. This WTP Matrix can be directly connected to a downstream Market Simulation node.

Popular Predecessors

• Table Creator35 %
• Customer Distributions19 %
• Column Appender15 %
• Column Appender12 %
• Feature Table To List4 %
• Demand Curve4 %
• Price Sensitivity4 %
• Joiner4 %
• Column Splitter4 %

Popular Successors

• Demand Shredder15 %
• Price War15 %
• Profit Engine8 %
• Simulate Market8 %
• Tuning Loop End8 %
• Show all 11 recommendations