Modeling the Price Function

With ACBC, we have taken the approach of treating the price attribute as a "summed," continuous variable. With summed price, the survey author assigns component-based (level-based) prices (and optionally, a base price for the product). When we display the total price of the product (in the Screener, Choice Tasks, and Calibration sections), we add the prices for its levels (plus any optional base price), and then we vary the price randomly by a user-specified amount of random variation (e.g. -30% to +30%). This has the benefit of displaying overall prices that are more in line with the general quality of the products (for example, it avoids showing a poor product at relatively high prices). But, the drawback is that if price is not varied randomly (and independently) enough, strong enough correlations between price and product features can result and will lead to relatively imprecise estimates of both. In general, we recommend that overall price be varied by at least -30% to +30% to reduce such multicollinearity and ensure reasonably precise estimates. More guidance related to this can be found in the white paper: "Three Ways to Treat Overall Price in Conjoint Analysis" available in our Technical Papers library at www.sawtoothsoftware.com.

Because there are myriad combinations of attribute levels that can make up a product (and each level can have assigned component prices) and prices are varied randomly within a specified range of variation, thousands of unique "displayed" prices can be found across a sample of respondents. To model the effect of price on product choice, we have chosen three effective coding methods: Linear, Log-Linear, and Piecewise.

Linear Function: The total price shown to respondents is coded as a single column in the design matrix. This assumes that the impact of price on utility is a linear effect. (However, note that when projecting respondents' utilities to choices in the simulation module, one typically exponentiates the total utility for products, so the final impact of price on choice probabilities is modestly non-linear.) The benefit of linear coding is that only one parameter is estimated, conserving degrees of freedom. But, if the actual impact of price on utility is non-linear, the linear assumption for this model is simplistic and suboptimal.

(Advanced Note: We temporarily transform whatever price range you provide to the range -1 to +1 so that HB converges quickly. Then, we re-expand the parameters back to the original scale when reporting the final utilities.)

Log-Linear Function: The total price shown to respondents is transformed by the natural log and coded as a single column in the design matrix. This assumes that the impact of price on utility is log-linear, or somewhat curved, as shown below:

As with the Linear function, only one parameter is estimated, which conserves degrees of freedom. But, if the actual impact of price on utility doesn't conform well to the smooth log-linear curve, this model is suboptimal. Because of the method we use to estimate discrete utilities for price points for communication with the SMRT market simulator, you must specify a number of interior price points in addition to the endpoints for the curved function to be reflected within market simulations.

Piecewise Function: This is a more advanced and flexible function--and the approach we recommend for most datasets. The user provides specific breakpoints, and a different slope (linear function) is estimated to characterize the relationship of price to utility between each breakpoint. For example, consider a conjoint study where the total price (after adding the price components and randomly varying the prices by, say, -30% to +30%) results in a range of prices actually shown to respondents from $725 to $5,250. The user supplies "breakpoints" to use in developing the piecewise price function. Let's assume the user hypothesizes that the price function has elbows at $1,500 and $3,000, but is linear between adjacent breakpoints and end points. In other words, the user might hypothesize a relationship between price and utility as is depicted in the chart below:

Rather than estimate a single slope (parameter) that characterizes a smooth relationship from $725 to $5,250, we are in this case fitting three slopes (ß1, ß2 and ß3). The particular function above suggests that this respondent (remember that these betas are computed at the individual level) reacts more strongly to price changes between $725 and $1,500, and then less strongly to prices between $1,500 and $3,000. Then, the reaction is stronger again for prices higher than $3,000.

One could specify as many breakpoints as desired along the price continuum, but each additional breakpoint leads to another parameter to be estimated, and overfitting (including reversals) will eventually result. A key decision is where to place the breakpoints. It would be a mistake to place breakpoints such that very few products seen by respondents actually fell within a range bounded by two breakpoints. In the example above, if very few products were evaluated that fell in the range $750 to $1,500, the model would have very little information by which to obtain a stable estimate of ß1. We recommend you export the BYO data (using Analysis + ACBC Counts Report) and view the distribution of prices for chosen products to help determine appropriate breakpoints. Or, to get a more complete picture of the prices for products included in the design, we've created a free program (Get_ACBC_Prices.EXE) that you can download that will report a frequency distribution of all prices included in the near-neighbor designs across respondents.

The benefit of piecewise functions is that they will provide much better fit to the data than a linear function if the price function is truly non-linear. The drawbacks are that they lead to more parameters to estimate, and importantly that the analyst must determine the appropriate number and position of the breakpoints. We also restrict you from estimating interaction terms involving piecewise Price, as such designs are often deficient. Why is this so? Consider an interaction between brand and price, where some brands never occur in the high tier range. We'll be attempting to estimate betas for interaction effects where there is no information in the design matrix.

If the piecewise function is used, we simply carry the utility forward to the market simulator just for the prices corresponding to the end points and breakpoints for each respondent. When simulating prices between adjacent breakpoints, the market simulator applies linear interpolation. Thus, using the piecewise model results in utilities associated with discrete price levels (determined by the analysis) for use in the market simulator--the same process as is used in Sawtooth Software's ACA, CBC, and CVA systems. However, the choice of specific price levels is done post hoc rather than prior to fielding the study.

(Advanced Note: We temporarily transform whatever price range you provide to the range -x to +x, where x is the number of price parameters to estimate in the model so that HB converges more quickly. Then, we re-expand the parameters back to the original scale when reporting the final utilities.)

---

Recommendations:

When using piecewise functions for summed price, it may take significantly longer for HB to converge. You may wish to significantly increase the number of initial iterations (prior to assuming convergence).

In general, we recommend the piecewise function, using between 1 to 3 breakpoints.

One can constrain each of the betas in the piecewise function to be negative, if constrained estimation is desired.

Even though we restrict you from estimating interactions involving piecewise price, note that the very nature of creating a piecewise coding should inherently capture some interaction effects with price. For example, if premium brands are associated with a relatively large level-based price, then the beta associated with the upper price range will to a great deal be estimated specific to the occurrence of premium brands.