A Practical Guide To Conjoint Analysis

1. 1Confirm the two preconditions before computing anything: you must know the full set of competitors a buyer actually considers in the category, and every one of those competitors' choice-relevant features must appear as levels in your experimental design. If a competitor has a feature you never tested, you cannot score it and the forecast is invalid.
2. 2Define the competitive set explicitly, including your own product as one member. In the passage example the set is four cars: the Saturn plus three rivals (Toyota, Volkswagen, Kia). The denominator of the model sums across all n products in this set including product i.
3. 3Score each product's total utility by summing its part-worth utilities from the conjoint output table, one level per attribute (brand, price, horsepower, upholstery, sunroof). Do this for your product and each competitor identically.
4. 4Apply the multinomial logit: exponentiate each product's utility, then divide the exponential of product i by the sum of exponentials across all n products in the set. The result is the predicted share of choices for product i.
5. 5Read the output as a share of the specified competitive set, not the whole market — it is share-of-choice among the profiles you defined. Change the set or a competitor's feature and the share moves.
6. 6To answer application 2 (impact of a new entrant), add the new profile to the set, recompute all exponentials, and observe how the shares of existing products redistribute.
7. 7Keep utility scaling straight: within each attribute the part-worths sum to zero, so negative numbers mean below-average preference, not negative value. Use the raw signed utilities in the summation.

Predict share for a Saturn profiled as $23,000; 220 HP; cloth interior; no sunroof. Its summed utility is 2.10 - 0.13 - 2.24 - 1.60 - 0.68 = -2.55. The competitive set adds a $27,000 Toyota/250HP/cloth/no sunroof, a $29,000 Volkswagen/280HP/leather/no sunroof, and a $23,000 Kia/220HP/cloth/no sunroof, each scored the same summation way. You then feed the four utilities into the multinomial logit, dividing exp(-2.55) by the sum of exp() across all four products. The result is a 2.5% predicted market share for the Saturn within that specified set. Any vehicle describable by the design against any set of design-describable competitors is forecast the same way.

• If a competitor in the real choice set has a feature not represented in your design, then stop — you cannot compute its utility and the share forecast is unusable until the design is fixed.
• If you change the membership of the competitive set or any competitor's profile, then recompute every product's share, because logit shares are relative to the whole set and are not additive across sets.
• If a summed utility is negative, then treat it as valid input to the model — negative reflects below-average within-attribute preference, not disqualification.
• If the sum of the absolute t-values for an attribute's highest- and lowest-preference levels is greater than three, then that attribute is contributing to the choice process and belongs in the forecast; if not, respondents ignored it.
• If you intend to forecast beyond the tested levels (e.g., more horsepower than any profile in the design), then do not — you have no basis to value it, so ensure the design spans the full realistic range up front.

• Omitting a real competitor from the set. The tell: your predicted shares sum to 100% but the number feels inflated because a strong rival was left out of the denominator.
• Reading the number as absolute market share rather than share within the defined competitive set. The tell: you quote '2.5% of the market' when it is 2.5% of choices among four specified profiles.
• Including a competitor feature that was never a level in the design. The tell: you can't fill in a part-worth for one attribute of a rival and quietly zero it out, distorting that product's utility.
• Misreading negative part-worths as products to exclude. The tell: someone drops the Saturn's -2.24 term or flips its sign, changing the utility from -2.55 and inflating the share.
• Forecasting outside the tested attribute range. The tell: the profile you want to evaluate has a level (like horsepower above the maximum tested) that has no corresponding utility, so you invent one.

• ▸Product i (your offering) — full profile, one level per attribute
• ▸Competitor list — every product a buyer actually considers, each fully profiled
• ▸Design coverage check — confirm every listed profile's features exist as tested levels (yes/no)
• ▸Utility summation per product — add the part-worth of each attribute level to get total U
• ▸Exponentiated utility per product — compute exp(U) for i and all competitors
• ▸Denominator — sum of exp(U) across all n products including product i
• ▸Predicted share of product i — exp(U_i) divided by the denominator, as a percent
• ▸Set-definition note — record exact competitive set so the share is interpreted relative to it
• ▸Scenario variant — new/changed profile to add, then recompute all shares

1. 1For each attribute, find the highest and lowest part-worth utility across its levels. Because utilities are scaled to sum to zero within an attribute, the range for a two-level attribute equals 2 times the absolute value of one level (e.g., Sunroof = 2 x 0.68 = 1.36).
2. 2Compute the within-attribute utility range: subtract the lowest-utility level from the highest-utility level for that attribute.
3. 3Sum the ranges across all attributes in the design (including the one you are evaluating) to get the denominator.
4. 4Divide the target attribute's range by the summed ranges. The result lies between 0 and 1 and reads as the percent decision weight for that attribute.
5. 5Repeat for every attribute and confirm the importances sum to 100%, giving you a ranked map of what drives choice.
6. 6Before trusting the numbers, check that each attribute is significant: sum the absolute t-values of its highest- and lowest-preference levels; treat the attribute as meaningful if that sum exceeds three.
7. 7Document the tested level ranges alongside every importance figure, because importance is defined by the design's span, not an absolute property of the attribute.

Take Horsepower in the car study. Its within-attribute utility range divided by the sum of all attributes' ranges yields 25% of the overall decision weight. Running the same calculation across the design gives Price about 27%, Upholstery about 23%, Brand about 15%, and Sunroof about 10% — the five values summing to 100%. You can see why Upholstery outranks Sunroof directly: the leather-versus-cloth utility gap is 2 x 1.60 = 3.20, more than double the sunroof gap of 2 x 0.68 = 1.36. The larger the utility swing an attribute produces, the more it drives choice. Note that these percentages are anchored to the tested ranges — Price spanned $23K–$29K here, and widening it would inflate Price's importance.

• If an attribute's utility range is larger than another's, then it carries more decision weight — regardless of how many levels each has.
• If you widen the distance between an attribute's most extreme tested levels, then expect its computed importance to rise, so hold ranges fixed when comparing across studies.
• If the sum of absolute t-values for an attribute's highest- and lowest-preference levels is at most three, then treat the attribute as not significant in the choice process.
• If an attribute turns out insignificant, then it probably should never have been in the design, because respondents are ignoring it when they choose.
• If you are comparing importance across attributes, then always report the tested level ranges alongside each percentage so readers can judge the design's influence.

• Reading a low t-value on a mid-preference level (e.g., Saturn at 0.87) as the attribute being unimportant — the tell is that the level sits in the middle of its attribute; test the extreme levels' combined t-values instead.
• Treating attribute importance as an intrinsic property rather than a design artifact — the tell is claiming Price 'is' 27% important without stating the $23K–$29K range that produced it.
• Comparing importances across studies with different tested ranges — the tell is one study showing Price far higher simply because it spanned $21K–$31K instead of $23K–$29K.
• Interpreting negative part-worths as 'negative utility' when computing ranges — the tell is mishandling the zero-sum scaling; a negative number only means below-average preference within that attribute.
• Forgetting to include the attribute in question in the denominator sum — the tell is importances that don't total 100% across all attributes.

• ▸Attribute name: label the feature being weighted.
• ▸Highest-utility level + value: record the top part-worth within this attribute.
• ▸Lowest-utility level + value: record the bottom part-worth within this attribute.
• ▸Utility range: subtract lowest from highest (for 2-level attributes = 2 x |one level|).
• ▸Tested level span: note the actual min–max tested (e.g., $23K–$29K) that defines this range.
• ▸Sum of all attribute ranges: add every attribute's range, including this one.
• ▸Importance %: range divided by sum of ranges, expressed as a percentage.
• ▸Significance check: sum of absolute t-values of the extreme levels; flag if not > 3.
• ▸Total row: confirm all importance percentages sum to 100%.

1. 1List every attribute management can actually manipulate in the product (brand, price, horsepower, interior, sunroof), then write down all levels for each before touching software — commercial packages require this as input.
2. 2Replace vague levels with concrete, quantified ones: swap 'really roomy' for a specific measurement, since tangibility of levels directly raises validity.
3. 3For each quantitative attribute (price, horsepower), set the level spacing tight enough that interpolation between consecutive levels stays credible — wide gaps (e.g. only $25,000 and $27,000) leave the value of an intermediate point like $24,000 or $25,300 poorly estimated.
4. 4Set the range of each quantitative attribute to span the full realistic span management would ever consider as a design alternative — including a ceiling above the highest level you'd actually ship, so trade-off analysis isn't blocked at the boundary.
5. 5For market-share use, enumerate the competitive products a consumer actually considers in the category and include every one of their important features as attribute levels, so you can compute utility for rivals, not just your own product.
6. 6Count total attribute levels and budget data collection accordingly: more levels demand more data to hold output accuracy constant.
7. 7After estimation, verify each attribute earned its place — check that the summed absolute t-values of its highest- and lowest-preference levels exceed three; if not, the attribute was wrongly included.

The car design tests horsepower with a maximum level of 280, and a current profile is a 280-hp, leather-interior vehicle. When you try to ask how much extra horsepower would compensate for switching leather to cloth, you hit a wall: because 280 is the top level tested, there's no data on how consumers value anything above it, so the trade-off can't be computed. The sunroof trade-off works fine by contrast — adding a sunroof lets you raise price from $23,000 to about $25,300 at consumer indifference, found by reducing price utility 2.10 by 1.36 to 0.74 and interpolating linearly between the $25,000 and $27,000 levels. The difference is entirely a design-quality issue: price and sunroof were bracketed so their relevant range fell inside tested levels, while horsepower's ceiling coincided with the profile under study. Had the design placed the maximum horsepower level above any car management would ship, the leather-to-cloth trade-off would have been recoverable too.

• If a level means different things to different respondents (e.g. 'really roomy'), then rewrite it as a concrete, quantified level before fielding.
• If you intend to use output for trade-off analysis, then set each attribute's tested range to span the full span of realistic alternatives, with headroom above the highest value you'd actually build.
• If two consecutive quantitative levels are far apart, then narrow the spacing — the wider the gap, the worse your estimate of any value between them.
• If the summed absolute t-values of an attribute's most- and least-preferred levels is under three, then drop that attribute — respondents aren't using its information.
• If you need market-share forecasts, then only proceed once every relevant competitor's important features are represented as levels in the design.

• Setting a quantitative attribute's maximum at the exact value of the product under study — the tell is a trade-off question that returns 'impossible to determine,' as with the 280-hp ceiling.
• Using vague levels like 'really roomy' — the tell is respondents interpreting the same level differently and unstable, low-validity utilities.
• Spacing quantitative levels too widely — the tell is that interpolated values (a $24,000 estimate between $23,000 and $25,000) feel unreliable.
• Reading a low t-value on a mid-preference level (Saturn at 0.87) as 'attribute not significant' — the tell is judging significance level-by-level instead of summing the extreme levels' absolute t-values against three.
• Omitting a rival's key feature from the design, then attempting market-share forecasting — the tell is you cannot compute the competitor's utility for the logit model.

• ▸Attribute name — one row per manipulable product feature.
• ▸Levels list — write out every level to be tested for this attribute.
• ▸Concreteness check — mark whether each level is quantified/unambiguous or vague; rewrite vague ones.
• ▸Level count — total levels here; sum across rows to size data needs.
• ▸Quantitative spacing — for numeric attributes, list gap between consecutive levels and flag oversized gaps.
• ▸Range span — record min and max tested; confirm max exceeds any realistic ship value for trade-off use.
• ▸Competitor coverage — for market-share studies, list each rival product and confirm its key features appear as levels.
• ▸Significance plan — note which two extreme levels you'll sum absolute t-values on (threshold = 3).

1. 1Choose the response format before selecting software: either ratings (respondents score each profile on a numerical scale) or choice (respondents pick one car from a competing set). The exact data collected is dictated by the conjoint type you use.
2. 2Feed your finished experimental design — every attribute and every level written down explicitly — into the off-the-shelf software as required input; the software generates the hypothetical product profiles from that design.
3. 3Deploy via personal computer or a Web-based version of the software to guide respondents through an interactive survey, presenting profiles built directly from your design.
4. 4Repeatedly present respondents with profiles (each car described by horsepower, color, price, transmission, etc.) so the software can infer attribute values from the series of ratings or choices rather than from isolated attribute questions.
5. 5Let the software estimate attribute-level utilities (part-worths) from the pooled participant ratings/choices for aggregate-level analysis, or estimate separate utilities per segment/individual if segmentation is the goal — the data collection procedure stays identical either way.
6. 6Confirm every attribute level shown to respondents is tangible and concrete (e.g., '280 horsepower', '$23,000') rather than vague ('really roomy'), because collected responses to ambiguous levels invalidate the inferred utilities.
7. 7Consult Orme's 'Which Conjoint Method Should I Use?' and the Sawtooth Software technical papers (http://www.sawtoothsoftware.com/techpap.shtml) to resolve practical implementation questions the note doesn't cover.

For the sports car study, you decide asking a consumer directly how much more a 240-horsepower car is worth than a 220-horsepower one yields a dollar value that won't reflect real marketplace choices. Instead you load an experimental design of car attributes and levels into off-the-shelf conjoint software. The software generates hypothetical car profiles combining brand, horsepower, interior, sunroof, and price, then guides each respondent through a PC or Web survey asking them to rate each car on a numerical scale or choose one from a competing set. By collecting these repeated ratings/choices, the software infers the value of each attribute. The output is estimated part-worths such as Toyota 0.75, leather 1.18, no sunroof -0.68, price level 2.10, which sum to a total car utility of 4.95. Swapping brand to Volkswagen (0.65) drops total utility to 4.85 — exactly the 0.10 brand difference, showing how collected choices translate into interpretable trade-offs.

• If a quantitative attribute like price or horsepower matters, then space consecutive tested levels closely — collecting data on far-apart levels makes interpolating an untested value (e.g., $24,000) unreliable.
• If you plan to interpret utilities, then use ratings-based collection when you need scaled scores and choice-based collection when you want to mimic marketplace selection — the collected data type must match your intended conjoint method.
• If an attribute has more levels, then plan to collect more data to hold output accuracy constant.
• If you want segment- or individual-level utilities rather than aggregate, then keep the same data collection and basic output interpretation — only the estimation math changes.
• If an attribute is qualitative like brand, then never set up collection expecting to interpolate between levels — interpolation is only valid for quantitative attributes.

• Using vague attribute levels ('really roomy') in the profiles — tell: respondents interpret the same profile differently and utilities come out unstable or nonsensical.
• Asking about each attribute in isolation instead of collecting ratings/choices over full multi-attribute profiles — tell: dollar values respondents give don't predict real choices.
• Setting quantitative levels too far apart — tell: you can't credibly estimate consumer evaluation of an in-between value like $24,000.
• Including an attribute respondents ignore — tell: even at the level of highest vs lowest preference the summed absolute t-values stay at or below three, meaning it shouldn't have been in the design.
• Misreading a mid-preference level's low t-value (e.g., Saturn at 0.87) as insignificance — tell: you drop an attribute because a middle level scaled near zero, ignoring that scaling forces moderate levels toward zero t-values.

• ▸Response format: ratings scale or choice among competing set — pick one and note why
• ▸Delivery platform: PC-based or Web-based software — record the tool used
• ▸Attribute list: write down every attribute to be tested (e.g., brand, horsepower, interior, sunroof, price)
• ▸Levels per attribute: list each level explicitly; flag any vague wording to replace
• ▸Quantitative level spacing: note gap between consecutive numeric levels and any interpolation needs
• ▸Sample/data volume plan: estimate responses needed given total number of levels
• ▸Analysis grain: aggregate, segment, or individual-level utilities
• ▸Profile presentation count: number of profiles each respondent rates or chooses among
• ▸Reference check: implementation questions to resolve via Orme / Sawtooth technical papers

1. 1State the inference goal: you are not asking consumers to price a feature directly (they can't accurately), so structure the study to recover attribute-level values from choices/ratings among full profiles.
2. 2List every attribute and its levels in writing before collecting data — commercial software requires this as input. For the car example that means brand, horsepower, interior, sunroof, price, each with defined levels.
3. 3Write levels that are tangible and quantifiable; replace vague levels like 'really roomy' with concrete, measurable ones so all respondents interpret them identically.
4. 4Space quantitative levels (price, horsepower) so consecutive levels are close enough that interpolation to untested values (e.g., $24,000) stays accurate, but keep total level count in check because more levels demand more data for the same accuracy.
5. 5Let the software generate hypothetical product profiles from your design and collect repeated ratings or choices among competing profiles via PC or Web survey.
6. 6Read the output as part-worth utilities scaled to sum to zero within each attribute; interpret a negative part-worth as 'less preferred than a positive-utility level,' not as literally negative value.
7. 7Confirm each attribute actually drives choice by summing the absolute t-values of its highest- and lowest-preference levels; if that sum exceeds three the attribute is significant.
8. 8Use the recovered part-worths operationally: sum levels to get a product's total utility, and compare utility differences to quantify trade-offs and willingness-to-pay.

Take a Toyota with 280 hp, leather interior, no sunroof, at $23,000: its utility is 0.75 + 1.18 + 1.60 - 0.68 + 2.10 = 4.95. Adding a sunroof raises the sunroof part-worth from -0.68 to +0.68, giving 0.75 + 1.18 + 1.60 + 0.68 + 2.10 = 6.31, a gain of 1.36 utility units. Consumers would be equally happy if you offset that gain by reducing price utility by 1.36, i.e., from 2.10 down to 0.74. Because -1.56 < 0.74 < 1.15 in Table 2, the equivalent price sits between $25,000 and $27,000, and assuming a linear price–utility relationship in that range you interpolate to the exact figure. This is the preference inferred from choices, not a number the consumer stated. Note the same logic quantifies the Toyota-vs-Volkswagen brand value: 0.75 - 0.65 = 0.10 utility, the only difference between two otherwise identical cars.

• If a level means different things to different respondents (e.g., 'really roomy'), then rewrite it as a tangible, quantified level before fielding.
• If the attribute is quantitative (price, horsepower), then you may interpolate between tested levels to value untested points; if it is qualitative (brand), then interpolation is nonsensical — never do it.
• If a mid-preference level like Saturn shows a low t-value near zero, then don't judge the attribute by that level; instead sum the absolute t-values of the most- and least-preferred levels and check whether it exceeds three.
• If an attribute turns out not significant in choice, then it probably should not have been in the design because respondents ignore its information.
• If you want willingness-to-pay for a feature, then convert the feature's utility change into equivalent price utility and map that back to a dollar range via the price part-worths.

• Asking consumers directly how much a feature is worth (e.g., 240 vs 220 hp) — the tell is a stated dollar figure that doesn't match how they actually choose in a marketplace setting.
• Reading a negative part-worth as 'negative value' rather than 'less preferred within the attribute' — tell: someone concludes a level hurts the product when it's just below the zero-sum midpoint.
• Judging attribute significance from a single mid-range level's low t-value — tell: dismissing a real driver like Brand because Saturn's t was 0.87.
• Spacing quantitative levels too far apart — tell: you can't credibly value an in-between price like $24,000 because interpolation over a wide gap is inaccurate.
• Loading in too many levels without enough data — tell: noisy, low-accuracy utility estimates despite a reasonable design.
• Interpolating across qualitative levels like brand — tell: someone computes a 'value between Toyota and Volkswagen,' which is meaningless.

• ▸Attribute name: write one product feature to be tested.
• ▸Levels (list): enter each specific realization; mark whether quantitative or qualitative.
• ▸Tangibility check: rewrite any vague level into a concrete/measurable one.
• ▸Level spacing (quantitative only): note gap between consecutive levels and whether in-between interpolation is needed.
• ▸Part-worth utilities: record each level's estimated utility (should sum to zero within the attribute).
• ▸Significance check: enter |t| of highest- and lowest-preference levels; flag attribute significant if sum > 3.
• ▸Total product utility: sum chosen levels' part-worths for the profile under study.
• ▸Trade-off / WTP calc: enter utility change from a feature swap and the price part-worths to interpolate the equivalent dollar value.

1. 1Lay out your table of part-worths by attribute, with each level's estimated utility. Confirm the utilities within each attribute sum to (or near) zero — this is the scaling convention that governs all interpretation.
2. 2Read a negative utility as 'less preferred than average within this attribute,' not as literal negative value. A level at 0 is neither high nor low; it sits mid-preference within its attribute.
3. 3To score any product profile, sum the part-worths of its selected levels across all attributes. That total utility is directly comparable to any other profile you build from the same design.
4. 4To compute trade-offs, isolate the utility change from one attribute (e.g., adding a sunroof = +2×0.68 = +1.36) and find the offsetting change in another attribute (e.g., how far price utility can drop) that returns total utility to its original value.
5. 5For attribute importance, take (highest utility − lowest utility) within each attribute, then divide that range by the sum of all attribute ranges. Result is between 0 and 1 — the percent decision weight.
6. 6For market share, verify the two conditions (you know the competitive set; each competitor's features are in the design), compute each product's total utility, then apply the multinomial logit: exp(U_i) / Σ exp(U_j).
7. 7Judge statistical significance by summing the absolute t-values of the highest and lowest levels within an attribute; treat the attribute as significant if that sum exceeds 3. Ignore mid-preference levels' low t-values.

For the profile Saturn / $23,000 / 220 HP / cloth interior / no sunroof, the part-worths sum to 2.10 − 0.13 − 2.24 − 1.60 − 0.68 = −2.55 total utility. Contrast trade-off logic on a Toyota / 280 HP / leather / no sunroof / $23,000, whose utility is 0.75 + 1.18 + 1.60 − 0.68 + 2.10 = 4.95. Adding a sunroof raises it to 6.31, a gain of 1.36. To hold the consumer indifferent, price utility can fall by 1.36, from 2.10 to 0.74. Because −1.56 < 0.74 < 1.15 in the price table, the tolerable price sits between $25,000 and $27,000; linear interpolation pins the exact figure. This shows how the same set of estimated part-worths drives profile scoring, trade-off pricing, and (via logit) the Saturn's forecast 2.5% share.

• If a level's utility is near zero and its t-value is low, then don't declare it insignificant — the scaling forces mid-preference levels toward zero; test the attribute using the sum of |t| for its extreme levels instead.
• If the summed absolute t-values of an attribute's highest and lowest levels exceed 3, then treat that attribute as significant in the choice process.
• If an attribute turns out non-significant, then it likely shouldn't have been in the design — respondents aren't using its information.
• If you widen the distance between an attribute's most extreme levels, then its computed importance will almost certainly rise — so importance is design-dependent, not absolute.
• If you want market share forecasts, then confirm every relevant competitor and its features are encoded in the experimental design before applying the logit model.

• Reading a negative part-worth as 'this level has no value.' The tell: someone recommends dropping a feature because its utility is negative, ignoring that scaling forces some levels below zero.
• Applying the standard single-t-value significance test to conjoint levels. The tell: an analyst flags 'Saturn' (t = 0.87) as insignificant when it's simply mid-preference within Brand.
• Reporting attribute importances as fixed traits of the product. The tell: importances quoted without reference to the level ranges chosen in the design.
• Building a market share forecast while omitting a real competitor or its features from the design. The tell: shares that don't reconcile with observed market behavior because the competitive set was incomplete.
• Interpolating price trade-offs outside the tested range or without checking which utility interval the target falls in. The tell: a 'willingness-to-pay' figure that lands beyond the price levels actually in the table.

• ▸Attribute name — list one row per attribute in the design.
• ▸Level utilities — record each level's estimated part-worth; verify the row sums to ~0.
• ▸Level range — enter (highest utility − lowest utility) for the attribute.
• ▸Attribute importance — divide this attribute's range by the sum of all ranges; express as %.
• ▸Extreme-level t-values — note |t| for the highest and lowest level; flag attribute significant if sum > 3.
• ▸Profile total utility — sum selected level part-worths across all attributes for the product being scored.
• ▸Trade-off target — state the utility gain from the added/changed feature to be offset.
• ▸Offsetting level — identify the attribute level (with interpolation range) that returns total utility to baseline.
• ▸Competitive set utilities — list each competitor's total utility for logit share = exp(U_i)/Σexp(U_j).

1. 1Start from the estimated part-worth utilities table; confirm the levels are scaled to sum to zero within each attribute so you interpret differences, not absolute signs.
2. 2Compute the total utility of the baseline product by summing the part-worths of its chosen levels (e.g., brand + horsepower + interior + sunroof + price).
3. 3Change exactly one attribute (the improvement) and recompute total utility; subtract to isolate the utility gain from that single change — nothing else in the profile may move.
4. 4Convert that utility gain into the compensating attribute (usually price) by reducing the improved product's price utility by the exact amount of the gain, so overall utility returns to the baseline (indifference).
5. 5Locate the target price utility between two tested price levels, verify it falls strictly between them, then linear-interpolate within that bracket to solve for the exact dollar figure.
6. 6Report the result as the point of indifference: the price at which the average consumer is equally happy with the improved-and-more-expensive car versus the baseline.
7. 7Repeat for any attribute pair — but only if the target value stays inside the tested range; if it lands at or beyond an endpoint, stop, the estimate is not supportable.

A Toyota with 280 HP, leather interior, no sunroof, and price $23,000 has total utility 0.75 + 1.18 + 1.60 - 0.68 + 2.10 = 4.95. Adding a sunroof raises the sunroof part-worth from -0.68 to +0.68, giving 0.75 + 1.18 + 1.60 + 0.68 + 2.10 = 6.31 — a gain of 1.36. To return to indifference you must give back 1.36 of price utility, so the price utility drops from 2.10 to 2.10 - 1.36 = 0.74. Because -1.56 < 0.74 < 1.15, that utility sits between the $25,000 and $27,000 tested levels, so you linear-interpolate within that bracket. The result: with the sunroof, price can rise from $23,000 to about $25,300 and the average consumer is indifferent between the two cars. That roughly $2,300 swing shows the value of a sunroof to consumers is very substantial.

• If only one attribute changes between two profiles, then the utility difference equals the difference between just those two level part-worths — no need to re-sum everything.
• If the compensating price utility falls strictly between two tested price levels, then linear-interpolate; if it equals a level, read it directly.
• If the trade-off requires a value beyond the maximum (or minimum) tested level of an attribute — e.g., more than the 280 HP maximum tested — then you cannot estimate it; declare it out of range.
• If you are designing the study for trade-off use, then set each attribute's tested range to span the entire realistic range management might consider before collecting data.
• If the sum of absolute t-values of the highest- and lowest-preference levels within an attribute exceeds three, then treat that attribute as significant in the choice process and valid for trade-off analysis.

• Trying to value additional horsepower when the baseline already sits at the 280 HP tested maximum — the tell is the target level lands at or past the range endpoint, so no interpolation bracket exists.
• Interpreting a negative part-worth as 'negative value' rather than 'below-average preference' — the tell is treating any negative-utility level as undesirable when scaling merely centers levels at zero.
• Reading a low t-value (like Saturn's 0.87) as proof an attribute is unimportant — the tell is a mid-preference level near zero utility that mechanically produces a small t; check the extreme levels instead.
• Changing more than one attribute between profiles and attributing the whole utility difference to one feature — the tell is a utility gap that doesn't reconcile with a single level difference.
• Extrapolating price beyond the tested price levels or assuming linearity outside the observed bracket — the tell is a solved dollar figure that lies outside the two prices you interpolated between.

• ▸Baseline profile: list each attribute and its chosen level
• ▸Baseline total utility: sum all baseline part-worths
• ▸Improved attribute + new level: the one feature you change
• ▸Utility gain: improved total utility minus baseline total utility
• ▸Target price utility: baseline price utility minus the utility gain
• ▸Price bracket: the two tested price levels whose utilities straddle the target
• ▸Range check: confirm target utility lies strictly between the two level utilities (Y/N)
• ▸Interpolated indifference price: linear-interpolated dollar value within the bracket
• ▸Interpretation: dollar amount consumers will trade for the improvement at indifference