Upload your conjoint survey, map the preference column and the attribute columns, and get part-worth utilities with intervals, attribute importance against the ranges you tested, willingness-to-pay from the price slope, and a market simulation of candidate products. Ratings and choice-based conjoint both supported. Free.
Free analyses run on up to 10,000 rows. Larger files are randomly sampled to that size — sign up to analyze your full dataset.
Estimating part-worth utilities...
Sent to — Part-worth utilities with intervals, attribute importance against the tested ranges, willingness-to-pay, a market simulation, a heterogeneity check, R code, and AI insights.
Analyze another fileThe module detects which of two conjoint shapes arrived. With a 0/1 preference column and a choice-task column it fits a conditional (multinomial) logit by maximising the conditional-logit log-likelihood directly with a quasi-Newton optimiser and an analytic gradient, taking standard errors from the observed information matrix. Otherwise it fits ordinary least squares of the preference on dummy-coded attribute levels. Either way the coefficients are then re-expressed as sum-to-zero part-worths within each attribute — an exact linear transform, so the covariance matrix carries through and every level including the reference gets an interval. Attribute importance is each attribute's part-worth range as a share of the total range. Willingness-to-pay comes from the slope of the price part-worths on the numeric price levels, which is itself a linear combination of the part-worths, so the delta method uses the full covariance between a level and the slope. The market simulation sums part-worths over configurations built from the tested levels, adding logit shares only when the choice model identifies the scale. The heterogeneity check subtracts the other attributes' aggregate contributions and reads each respondent's own favourite level off what remains.
Use it on conjoint or discrete-choice survey data where respondents evaluated whole product profiles — rating them, ranking them, or choosing between them — and you need the relative weight of each attribute and the exchange rate between a feature and money.
Not for revealed-preference data such as actual transactions (use a choice or regression model on the observed prices), not for rating single features one at a time in isolation, and not when you need individual-level utilities for segmentation — that needs a hierarchical model this module does not fit.
Built for: Product managers, pricing analysts, market researchers, and UX researchers deciding what to build and what to charge
Typical data source: A conjoint or choice survey export: one row per profile a respondent rated, or one row per alternative in each choice task, with a column per product attribute
One row per profile a respondent evaluated, with a column per attribute and the stated preference. For choice-based conjoint, add a choice-task column and make the preference a 0/1 chosen flag:
Minimum 20 rows · Best with 300-8,000 rows (roughly 50 or more respondents evaluating 8 or more profiles each)
Standard-library analysis: what is each product feature worth relative to price? Map the preference column and the attribute columns from a conjoint survey — ratings/rankings of whole profiles, or choice-based conjoint with a chosen flag and a choice-task column — and get part-worth utilities for every tested level with confidence intervals, attribute importance reported against the level ranges that were actually tested, willingness-to-pay derived from the price slope when the price coefficient supports it, a market simulation over product configurations built from the tested levels, and a respondent-level check for whether the aggregate is masking opposed segments.
Every tested level at its part-worth utility with a 95% interval, re-centred to sum to zero inside each attribute.
Each attribute's part-worth range as a share of the total, printed next to the levels that were actually tested.
What each level is worth in the units of your price column — a stated-preference estimate, not a price anyone has agreed to pay.
Predicted preference for candidate product configurations built from the tested levels, with choice shares when the data identifies the scale.
How many respondents share the aggregate favourite of each attribute — the check that catches an average blending opposed groups.
The estimator, the normalisation, and exactly what the willingness-to-pay and simulation numbers can and cannot decide.
Plain-English interpretation — what the numbers mean, what's significant, and what to do next.
How much is this feature worth compared to price?
Map the preference column and every attribute column including price. You get part-worth utilities for each level, attribute importance against the ranges you tested, and a willingness-to-pay figure per level in the units of your price column — reported as the stated-preference estimate it is, with an interval that carries the uncertainty of the price slope as well as the feature.
See our FAQ for details on pricing, data privacy, and how the analysis works. Every report includes a Methodology section showing the statistical test, assumptions checked, and diagnostics run.
Run any analysis on your own data — validated R analyses, interactive reports, AI insights, and PDF export.
Try Free — No Credit CardTell us what went wrong, in your own words. We capture the page you're on automatically, so no need to describe where you are.