Have an idea?

Visit Sawtooth Software Feedback to share your ideas on how we can improve our products.

Conditional pricing within alt-spec design

We are looking at setting up a design with a price attribute which is both conditional and alternative-specific, i.e. we have different proportional increases from current price for different sets of SKUs. When testing in SSI Web we include the interaction between SKU and each of the Price attributes, since they are conditional, and the report comes out at ill-conditioned.
As far as we can tell, this is because we are trying to estimate interactions which don't occur in the design - has anyone else encountered this? If so, is there any way around it? Or is the only option to exclude the interactions between SKU and Price and look at Main Effects only?
asked Dec 16, 2016 by Jacqui

1 Answer

0 votes
Seems to me that you can make the entire design conditional, rather than trying to do the alt-spec aspect.  The conditional pricing table allows you to specify the prices that will be customized and shown for each of the SKUs.  So, if your intention indeed is to estimate a separate price function for each SKU, then that is the route you can go (meaning, you would ask the software to include the interaction effect between SKU and the one price attribute).

However, recognize that this will lead to many parameters to estimate (a separate price function for each SKU) which may be too much for the limited data to do well.  Utility constaints can help.  

A middling position is to do what you are thinking about: create an alternative-specific design in which the proportional increases and decreases are common across multiple SKUs within the alt-specific price attribute, but in which the average price may still be different for different SKUs sharing the same alt-specific price attribute.  In that case, you would not be asking for interaction effects in the software interface (since as you have seen it results in a deficient design).  You would be estimating a common set of price weights for the SKUs you chose to group within each conditional price attribute.  This might work out well if you are using individual-level estimation (via HB), which is probably your intent.

Please note that if you proceed with the design programmed as alt-specific with the conditional pricing table, there still is the possibility open to you to manually reformat the data after data collection to test the model in which each SKU is estimated with its own unique price function.  Or, you could pull apart some SKUs for independent price function estimation and allow other SKUs to remain grouped for common price function estimation.  This data processing work involves modifying the .CHO file or the .CSV file that Lighthouse Studio can export for you.  The .CSV file is probably the easier format to modify.  If you go this route and modify the .CHO file or the .CSV file, then you need to use either the standalone CBC/HB software or the standalone Latent Class software to estimate the models.  These standalone systems act and look somewhat similar to the built-in HB and latent class facilities within Lighthouse Studio.  Your Lighthouse Studio license gives you access to these standalone software tools without any additional subscription cost.
answered Dec 16, 2016 by Bryan Orme Platinum Sawtooth Software, Inc. (174,415 points)