# More details on coding and estimating continuous price via piecewise?

Hi, are there any more details for this?  I have a CBC project where summed pricing is appropriate and I'd like to estimate it via piecewise, but after research I am still not 100% sure of the steps to take for estimation.  Some questions for me still remain such as:

(1) This seems to describe what you do with the break points, but what about the end points?  Are they ignored in the code?  Suppose in the above prices were shown anywhere between (and including) \$500 and \$1,000, with your \$650 and \$800 as breakpoints.  How would \$500 be coded then?  \$600, \$650, \$700, \$800, \$900, \$1,000 to complete the example?

(2) Following the above, if n is the number of price levels you want, will you have n+1 parameters?

(3) Are the parameters interpreted similarly as if price was part-worth with n discrete levels?

I hope my questions above make sense, and thank you in advance for your consideration!

-Wes

The end points are accounted for by the coding of the first and last terms in your piecewise parameters.  For example, imagine you have a continuous function to model prices from 0 to infinity (but likely no larger than \$900).  Imagine you plan for cut-points at \$500, \$600, and \$700.  The betas involve estimating slope within these intervals:

B1 , <\$500
B2 , >=\$500 to < \$600
B3 , >=\$600 to \$700
B4 , >=\$700

So, you've got a continuous function that handles any price.   If price is below \$500, then the B1 slope is the only thing we need to compute the utility at that price point.  If the price is above \$700, then we need to use B1 * 500 + B2 * 100 + B3 * 100 + B4 (price - 700).  So, you can see that estimating the utility for a price higher than \$700 involves all four terms in the model.

The piecewise function gives you a continuous function for computing the utility of price at any value along the supported continuum.  However, if you want to discretize the utilities for specific price points (as if you had used dummy-coding), then you may indeed compute the utility associated with (for example) \$400, \$500, \$600, \$700, \$800.  Respondents will have seen potentially 100s or 1000s of unique price values, but your analysis will just summarize the utility at discrete points (\$400, \$500, \$600, \$700, \$800).
answered Jun 30, 2014 by Platinum (153,080 points)
Thanks for your response Bryan.  This clears up some confusion, but I have a couple other questions to follow up on this.

Your utility calculations now make sense to me.  But I wonder how, if reporting aggregate utilities, you'd interpret these price attributes.  Please let me know if I'm misunderstanding this, but, based on your example above, you essentially have 4 price attributes, 1 representing prices under \$500, another representing prices \$500-\$600, etc.  So, can we think of the aggregate utility for \$500-\$600 as the utility for an additional \$100 in cost, or must we always think of it relative to the base <\$500 utility?  And I see how the utility can be calculated and used in a manually programmed Excel simulator, but is it possible to use the SMRT simulator here?

Your last paragraph really tied this all together for me because I guess I was always imagining continuous piecewise as simply making a discrete or part-worth attribute from a continuous one, when that's not really the case.  But it sounds like this is possible, to take a continuous price variable in a conjoint study, and turn it into a discrete attribute with X number of levels, almost as if we just had a price attribute with X levels to begin with.  Is this correct, and if so, how would this be done/coded to analyze via CBC/HB?  And maybe more importantly, should this be done, is this approach appropriate, or is the above method of continuous piecewise from your original response the better option?