Conjoint

Fit a discrete-choice model from survey responses, rank what drives decisions, and convert results into dollar willingness-to-pay by feature and segment. This example has been tested and validated with Claude.

When to use this

You need a defensible dollar figure attached to a specific feature (not just a popularity ranking) or you’re pricing a product with several moving parts. Conjoint analysis shows what people actually trade off when choosing between whole configurations, which a preference survey can’t.

This guide covers choice-based conjoint (CBC), the variant most survey platforms default to. Two other flavors exist — adaptive conjoint and menu-based conjoint — but are not covered here.

For the full walkthrough, including a side-by-side comparison of plain vs. engineered attempts, the exact bugs that replicated across two independent runs, and worked WTP numbers by segment, see the full conjoint analysis guide.

Prompt

Replace the bracketed placeholders with your own attribute names, filename, and threshold. Every column name must match your file’s literal header row, not a spreadsheet column letter.

I have a choice-based conjoint (CBC) dataset. I want to fit a
discrete-choice model, rank what drives decisions, calculate dollar
willingness-to-pay by feature, and break results out by segment.

What this prompt does:
- Fits a proper conditional/multinomial logit model on your choice
  tasks
- Converts utility differences into dollar willingness-to-pay for
  each attribute level, with uncertainty on every figure
- Checks whether segment differences are real or within the noise
  the sample size allows

What it returns:
- A ranked importance table (each attribute's utility range as a
  share of total range)
- A willingness-to-pay table with confidence intervals, per attribute
  and per segment
- Any segment flagged as too small to model separately
- A bar chart of dollar WTP by attribute and segment
- A 2-3 sentence summary distinguishing confirmed findings from
  directional ones

Please:
1. Load the data defensively. Do not treat "None," "NA," "N/A," or
   "NULL" as missing values — these are valid category labels. Verify
   that every task has exactly one chosen alternative (or none_chosen
   = 1), never both or neither. Report the row count before and after
   loading.
2. Fit a conditional or multinomial logit model. Dummy-code every
   attribute against explicit reference levels — state what each
   reference level is before estimating — rather than relying on
   alphabetical defaults. Model each task's concepts (plus any
   "none of these" option) against each other as a choice set, not
   as independent yes/no rows.
3. Calculate relative importance as each attribute's utility range
   divided by the sum of all ranges, in code at full precision.
   Do not rank attributes by raw coefficient size.
4. Before splitting by segment, check whether each segment has enough
   respondents. Flag any segment below [N, e.g., 84] respondents as
   too small to model separately; keep those respondents in the
   pooled model only.
5. Confirm each price coefficient is negative and non-zero before
   converting anything to willingness-to-pay. If a price coefficient
   is positive or zero, stop and report it rather than proceeding.
   Convert utility differences to dollars only for models that pass
   this check, and attach standard errors to every figure.
6. Compare model-implied WTP to any stated-preference benchmark
   using a formal significance test (gap ÷ combined standard error
   ≥ 1.96). Report gaps that don't clear that bar as directional,
   not confirmed findings.
7. Recompute every number independently through a second, genuinely
   different implementation before reporting anything final. Flag any
   mismatch rather than silently correcting it.
8. Present an importance table and a WTP table with uncertainty on
   every figure and any under-sized segment flagged explicitly.
9. Build a grouped bar chart of dollar WTP by attribute and segment.
10. Summarize in 2-3 sentences, explicit about which segment
    differences the sample size and standard errors actually support.

Setup

Code execution must be enabled for step 4’s verification to run. It’s on by default for Team and Enterprise accounts. Free, Pro, and Max users: enable it under Settings > Capabilities.

If your survey data lives in Sprig, skip the export, the Sprig MCP connects live surveys and responses directly into Claude so the analysis runs on current data.

How it works

1. Defensive data loading

   Checks that “None,” “NA,” and similar strings aren’t silently read as missing values, a default CSV behavior that dropped a third of a 600-respondent dataset in plain-prompt testing. Reports row count before and after to surface any loss.

2. Proper discrete-choice model

   Fits a conditional/multinomial logit model with explicit, stated reference levels rather than alphabetical defaults. Models each choice task’s options against each other as a set ( not as independent yes/no rows) and includes any “none of these” option.

3. Scaled importance ranking

   Calculates each attribute’s importance as its utility range ÷ total range, in code at full precision. Raw coefficient size is never used for ranking. In plain-prompt testing, skipping this step ranked price (the biggest real driver of choice) dead last.

4. Segment size check

   Calculates the minimum respondent floor for your design before running any segment model. Segments below the floor are flagged, excluded from their own estimate, and kept only in the pooled model.

5. Price coefficient check

   Confirms the price coefficient is negative and non-zero before converting anything to dollars. A positive price coefficient means the model is misspecified; the prompt stops and reports it rather than continuing.

6. Significance test on stated-preference gap

   If your survey includes a stated-preference calibration question, the prompt compares model-implied WTP to what respondents said they’d pay and tests whether the gap is real. Results that don’t clear the bar (gap ÷ combined SE ≥ 1.96) are reported as directional.

7. Independent verification

   Every number is recomputed through a genuinely different implementation before it’s reported. Any mismatch is flagged rather than silently corrected.

8. Output

   A verified importance table, a WTP table with confidence intervals, a grouped bar chart by attribute and segment, and a 2–3 sentence summary that separates confirmed findings from directional ones.

9. Output (Continued)

   A verified importance table, a WTP table with confidence intervals, a grouped bar chart by attribute and segment, and a 2–3 sentence summary that separates confirmed findings from directional ones.

10. Output (Continued)

    A verified importance table, a WTP table with confidence intervals, a grouped bar chart by attribute and segment, and a 2–3 sentence summary that separates confirmed findings from directional ones.

Things to check before trusting any conjoint output

• Assume alphabetical reference levels until proven otherwise. Both pandas.get_dummies and statsmodels’ formula interface default to alphabetical order with no warning. The same backwards reference levels appeared in two independently-written plain-prompt attempts.
• Verify your row count after loading. If it’s lower than expected, a valid category label was probably read as missing. Check what the default CSV reader did with “None” or “NA” in your columns.
• A negative price coefficient is a prerequisite, not an assumption. If price came out positive or near zero, the model isn’t usable for WTP conversion, the prompt requires this check before proceeding.
• Check segment n before splitting. More segments on a fixed sample means smaller cells and wider intervals. Flag and exclude any segment below your design floor rather than reporting a noisy estimate as a finding.