Conjoint (Choice-Based Trade-Off)

Conjoint analysis shows respondents a series of choice screens, each containing several product concepts built from a set of attributes and their levels. On every screen the respondent picks the concept they prefer, so each answer is a forced trade-off between complete offers rather than a rating of isolated attributes. Use it to measure how much each attribute level actually drives choice: pricing, packaging, plan tiers, bundles, or any offer made of composable parts.

A conjoint question has four authoring areas:

• The question card (on the canvas), holding the prompt and the Attributes editor with each attribute's levels.
• The DOE tab (Properties panel), holding Choice Screens (Number of screens, Concepts per screen), Presentation Order, Constraints, Matrix Lock, and the Design of Experiment source controls.
• The Stimulus tab (Properties panel), holding Stimulus layouts, Displayed attributes, AI stimulus generation and a live Preview.
• The Messages tab (Properties panel), holding the words the conjoint draws itself: the option set counter, the phone's Previous / Next buttons and offer counter, the phone's choose prompt, the load error message and the names screen readers announce. See Texts the conjoint draws itself.

---

Attributes and levels#

A new Conjoint question does not start empty. It is seeded with a complete demo study, the American Airlines Product Lineup: fifteen content attributes (Cabin, Seat, Seat Selection, Checked Bags, Boarding, Mileage, Snacks, Drinks, Lounge Access, Priority Bag Handling, Car Service, Check-in, Delay/Cancellation Support, First-Class Lounge Dining, Refundability), a numeric Price Level, and a calculated Price attribute conditional on Cabin. Rename or delete them as you build your own study. Every attribute and level gets fresh ids on each new question, so two questions never share them.

Attributes are what vary across concepts; levels are the values an attribute can take. Add, rename, reorder, and delete attributes and levels in the Attributes editor. Every attribute and level carries a stable internal id, so exports and DOE libraries stay consistent even if you rename things.

Each attribute (except calculated attributes, which have no authored levels) has a Bulk Edit button next to its Levels list. It opens the same paste-friendly grid used by the choice question types, scoped to that one attribute's levels, and pastes work the same way they do there: a multi-line paste into any cell fills one level per line down that column; a spreadsheet paste (tab- or CSV-delimited) spreads each row's cells across the visible columns starting at the pasted cell (for an image attribute: Text, Image URL, Tooltip); a single line without a tab, such as a sentence with commas copied from Word, pastes whole into the cell you pasted it into; on image attributes, Qualtrics-style Label|image-url lines and bare image-URL lines route the URL into the Image URL column (URL-only lines get an automatic "Level n" label), and pasted <img> tags or CSS url(...) values are cleaned to the bare URL. The footer carries the same Copy all rows / Paste clipboard into editor buttons as the choice grid for whole-table TSV round-trips with Excel or Sheets. The columns shown follow the attribute's subtype: Text (and an optional Tooltip) for every subtype, plus Image URL for image attributes or Value for numeric and price attributes. Levels you keep retain their stable id, tooltip, and display logic; only rows you remove are deleted.

Attribute types#

Attribute subtypes#

Attributes and levels can also carry display logic (the standard condition builder). Alongside the regular operands (prior answers, variables, survey metadata including Survey Language), conjoint display logic can reference other conjoint attributes and levels (earlier attributes only, since forward and circular references are prevented) and layout membership when more than the default layout exists, and each attribute or level offers a one-click Hide Always. An attribute hidden by display logic stays in the DOE and in the response data. It just isn't rendered for that respondent.

Currency override rules on Price attributes use the same condition builder but may reference only main-survey context (for example Survey Language), never conjoint attribute values. Overrides run top to bottom and the first matching rule sets the display currency; otherwise the base currency is used.

Constraints#

Constraints are an input to the design, so they live on the DOE tab rather than with the attributes. The Constraints card shows a one-line summary of what you have already authored, counted as prohibited pairs and forced dependencies, and a Manage constraints button that opens the full editor in a wide dialog also titled Manage constraints. Until you have added at least one attribute the button is disabled and the summary reads Add attributes on the Build tab first.; with nothing authored yet it reads No constraints set yet.

The dialog has two areas.

Prohibition Matrix stops two levels appearing together on the same concept. Press Add prohibition to get a card, pick a first and a second attribute in the two pickers (Attribute 1... and Attribute 2...), and the card draws a grid of that pair's levels. Click a cell to prohibit that combination and click it again to allow it. The level pair you mark is never shown in the same concept. A pair with many levels scrolls sideways inside the card. The second picker never offers the attribute chosen in the first, and changing either picker clears the cells marked for the old pair; if you change the first picker to the attribute the second one holds, the second picker empties and the grid goes away until you pick a new second attribute. The trash icon on a card removes that whole pair.

Forced Dependency pushes a value instead of forbidding one. Press Add forced dependency, set the Condition: by clicking its pill (it opens the standard condition builder), then choose the target attribute under Forced Level: and click one or more of its levels. When the condition matches a partly built concept, the target attribute is set to one of the levels you allowed, and if you allowed several, one is chosen at random. Forced dependencies take precedence over normal randomization. When the target is a combinatorial attribute you get an Item count Min and Max pair instead, which forces how many items that concept carries.

A concept that violates a prohibition is rebuilt until it fits, so a heavily constrained design takes longer to generate and can drift on balance.

Constraint conditions reference conjoint attributes only (the DOE cannot evaluate respondent-time sources). Authoring validation rejects incomplete constraints and directly contradictory ones, for example two forced dependencies that set incompatible levels for the same attribute under the same condition.

---

The DOE workflow#

The Design of Experiment decides which levels appear together on which concepts. Unlike MaxDiff, no design generation happens during a respondent session. Designs are pre-generated, validated, and activated up front, and each respondent is assigned one pre-built design (by least fill) at session start. The assignment is pinned for the whole session.

The workflow is: Lock → Generate or Upload → Validate → Activate.

1. Lock the matrix. Once the attribute/level matrix is final, open the Matrix Lock card on the DOE tab and press Lock matrix. Locking freezes the structural identifiers the DOE and the stimulus code depend on, and the card then shows the date and time it was locked. Until you do, both the generate and the upload buttons stay disabled and the card tells you The matrix must be locked before a fixed DOE can be uploaded or the question shown to respondents. The lock state is shown on the question card and in the Flow tab.
2. Generate or upload. Choose Platform-generated or Uploaded fixed DOE in the Design of Experiment card.
   • Platform-generated. Set Number of designs (500 by default, 1000 at most), optionally a Seed (optional) value (leave it on Random, or press the dice button to fill one in) so a run can be reproduced, and a Minimal-overlap mode of Full, Partial or None. Then press Generate DOE library. The library is built in the background with progress reporting, honoring structure applicability, constraints, overlap mode, combinatorial bounds, and conditional attributes. Until the matrix is locked the button is disabled and the card says Lock the matrix above before generating a DOE. It is built from the matrix as it is in the builder right now, including a teammate's unsaved live edits — never from an older saved version. If your own latest changes have not reached the server yet (for example your connection dropped), Generate does not start and tells you to check your connection and try again.
   • Uploaded fixed DOE. Use Download template for a CSV pre-filled with dummy rows and the stable attribute/level ids (a separate Column legend download sits next to it), fill in your own fixed design, then press Upload fixed DOE (CSV) and pick the file. A file downloaded with a library's Export CSV uploads again exactly as it is, with no mapping step: its attribute columns are matched by name and its level codes turned back into levels, so you can download a design, edit it (or keep it as a backup) and upload it again.
3. Validate. Generated and uploaded libraries are checked the same way: blocking errors (unknown ids, structure violations, malformed rows) must be fixed; warnings (for example balance drift beyond the threshold) are surfaced but don't block. A rejected upload lists every error with its row and the attribute it is about. An upload that passes shows its summary straight away, under the upload message: how many times each level is shown, overall and per attribute. Every library in the DOE Libraries card has a Summary button that opens its level counts, overlap and balance quality (press Hide summary to close it again), plus Export CSV, Export meta and Export summary download links. When several people edit the survey at once, a library a teammate generates or uploads appears in your DOE Libraries card as soon as you open the DOE tab, and within 15 seconds while you have it open; that reload happens quietly, and the refresh button beside DOE Libraries reloads the list at once.
4. Activate. A new library becomes the active one by itself: as soon as it is generated or uploaded it is badged in use and the message under the button says vN is now the active design, and the library that was active before is switched off. This holds on a live survey too: a respondent already in the survey keeps the design they were given when they started, and everyone who starts afterwards is assigned from the new library. To go back to an earlier library, press Activate on it in the DOE Libraries card. When no library is active, the card says so in a highlighted note (No design is active, so respondents skip this conjoint), the newest library's Activate button is outlined, and the question card's DOE line reads no active library: activate one on the DOE tab. A new library that has warnings is activated too, and the message names them (It has N warnings: see its summary.) so you can review them; activating an older library that has warnings still asks you to acknowledge them first. A library that carries warnings can only be activated with explicit acknowledgement: a dialog titled Activate with N warnings? lists them, and you have to press Acknowledge and activate rather than Keep inactive. The acknowledgement is then shown on the library as Warnings acknowledged with its timestamp and recorded in the question's version history. The active library id is shown on the question card and in the Flow tab.

Structural changes invalidate the DOE. Editing the locked matrix in a way that changes its structure (adding/removing attributes or levels, changing kinds or bounds) flips the active library to invalidated. You'll be warned first, and you must re-lock and generate or upload again before respondents see the question.

Publishing before the conjoint is ready#

You do not have to finish a conjoint before you publish the survey. A conjoint is incomplete while its matrix is unlocked, its matrix has changed since it was locked, or it has no active DOE library for the current matrix. An incomplete conjoint does not stop the survey from publishing: the survey goes live, and respondents skip the conjoint and carry on with the rest of the survey.

While a conjoint's matrix is unlocked or it has no active DOE library, its question card and its item in the Flow tab show Incomplete — not displayed in published survey. (A matrix that changed since it was locked is flagged on the Matrix Lock card instead.) When you publish, the publish dialog names each incomplete conjoint and what shows it (for example Activate a design on its DOE tab to show it., or Lock its matrix and activate a design on its DOE tab to show it.), with a Go to question button. Once the conjoint is complete (matrix locked, a library generated or uploaded and activated), the note goes away; publish again and respondents see it.

Display logic on a conjoint works as on any other question, so you can also hide a complete conjoint on purpose.

Shelf Choice and Online Choice have no matrix lock or DOE library, so they are never incomplete in this sense.

Unlocking the matrix#

While the matrix is locked the Matrix Lock card offers Unlock instead of Lock matrix. Pressing it asks you to confirm in a dialog titled Unlock the conjoint matrix?, with Keep locked and Unlock matrix.

Take the warning at face value. The lock is what every design you have generated or uploaded was built against, and what the stimulus code addresses attributes by. Unlocking allows structural changes: adding or deleting attributes, changing types or subtypes, reordering levels, or editing combinatorial bounds and constraints. Any structural change invalidates active DOE libraries, and a new library must be generated or uploaded and activated before respondents see the question again. In practice that means you lose the design you already validated, along with the time a large generation run took, and the question is skipped in the published survey until you have rebuilt one.

So unlock only when you genuinely intend to change the matrix. Renaming an attribute or rewording a level is not a structural change and does not need an unlock.

If the matrix does drift while locked, the card says so itself: a warning appears reading The attribute matrix changed structurally since it was locked. and explaining that existing DOE libraries are stale, with a Re-lock with current structure button. Use that button once the new structure is the one you want, then generate or upload again.

---

Design Assignment#

Design Assignment decides which design a respondent is given:

Balanced (least-fill) is what a question does when nothing has been chosen, so existing questions keep the behaviour they already had. Choosing By Global Variable adds a fallback, Balanced fallback, used when the Version is missing or does not match any design.

Split across the flow#

Split across the flow (pause / resume) fields one pinned design as separate windows with other questions in between, rather than as one uninterrupted block. Screens before pause sets how many screens a respondent sees before the question hands control back to the flow. The windows share a single design, so the respondent resumes the same study rather than starting a new one.

All parts share the same attributes, levels, images, tooltips and stimulus. Edit them on any part and the change shows on every part straight away. Each part keeps its own number of screens and its own display logic.

---

Map uploaded columns#

Fixed designs do not always come out of this product. When the CSV you pick for Upload fixed DOE (CSV) looks like a Sawtooth export rather than a file built from the downloaded template, a dialog called Map uploaded columns opens before anything is uploaded, so you can say what each column is. Files that already use this product's own column ids, and files downloaded with a library's Export CSV, skip the dialog and upload straight away.

At the top the dialog names the three position columns it recognised and which axis each one feeds (design, set, concept). If any trailing rows have no numeric Version, for example the free-text notes at the bottom of a Sawtooth export, it tells you how many rows were dropped.

Under Columns every other column in the file gets a row, showing the column name on the left and a Maps to picker on the right. Choose the attribute the column holds, or choose Ignore column. Columns it could match are pre-filled for you; blank and duplicate column names default to Ignore column because they have no usable name. Anything still unset is highlighted, listed under Map or ignore every column to continue:, and counted in the footer, and Confirm & upload stays disabled until every column is either mapped or ignored.

Under Level indices each mapped attribute gets its own small table: the numeric index found in the file on the left, the level it will become on the right. Index 0 is treated as NA (not shown). The proposed mapping assumes the file numbers levels from 1 in the order your levels are listed, so check any attribute whose levels you have reordered since the design was built.

Preview shows the first few rows exactly as they will be read, with the level names rather than the raw numbers, so a mis-set index shows up before you upload. Cancel throws the whole mapping away and uploads nothing; Confirm & upload sends the file with your mapping, and the usual validation errors and warnings appear on the DOE tab underneath.

Repeated cells#

If several rows in the file share the same Version, Task and Concept, the dialog adds a Repeated cells detected block, because duplicates are never accepted silently. Pick one of three answers:

If you choose Use a partition column and pick nothing, the dialog says Choose the partition column to continue. and the upload stays blocked.

---

Stimulus layouts and AI generation#

A stimulus layout controls how a concept is rendered on screen. There is no drag-and-drop layout editor. Layout code is AI-generated JavaScript, produced from your attribute list and an optional mockup image, then run in a locked-down sandbox.

• Stimulus layouts: add, duplicate, rename, and delete layouts, with the radio button marking the default. Each layout renders the concept's displayed attributes and shows its own Display rules underneath it, with an Edit button that opens the standard rule modal; saving writes the rule back to that layout. The default layout's Display rules simply read default. It is the fallback and has no editable rule. In the modal the first query option is Attribute, pre-pointed at the Theme attribute, so the usual mapping (Theme attribute is <level>) is one click away. Layouts are evaluated in the order they are listed and the first match wins. A layout can't be deleted while a rule references it. If you delete an attribute level that a layout's rule uses, the rule is kept and shows Missing option in amber in place of the level, with a note to edit it. Until you do, a rule "is <deleted level>" matches no card, so those cards use the default layout.

• What a Display rule applies to: this depends on what the rule asks about. A rule on the Theme attribute is evaluated per concept card: every card on a screen carries its own Theme level, so each card is drawn with the layout mapped to its level, and a level you never mapped falls back to the default layout. A rule on anything outside the design (survey language, a variable, an earlier answer) is evaluated once per respondent and so switches the layout for that respondent's whole survey. The usual setup is one layout per Theme level; per-respondent rules are the rarer case.

• Stimulus Canvas: Aspect ratio (width : height) sets the shape every concept card is drawn in. It applies to the canvas, not to one layout, so all layouts share it.

• Adding a layout: + Add layout creates one. The radio button beside a layout marks it as the default.

• AI stimulus generation: describe the layout (and optionally attach a mockup image with Attach mockup image); the generator knows your attributes, their stable ids and their kinds (a fixed attribute is the same on every card; a combinatorial one shows between its minimum and maximum number of items, possibly none) and follows layout and accessibility guidance. It also knows how the conjoint screen around the card works (cards side by side, chosen with a click on the whole card; on a phone, one card at a time and then a grid where a tapped card is enlarged with Choose this one; tooltips shown by the screen), and the width and height of each level image, so it shapes an image's space to the image. It sizes the card's blocks relative to the card so everything fits, never crops an image (a "full width" image keeps its whole picture), and shows fixed text such as a section heading or a "no items" line only when your description quotes it, under the condition you give. Every generation creates a new code version with author, timestamp, and the prompt used, and you can view, compare, and restore versions.

• Refining an existing layout: once a theme has generated code, a box appears under the generator, prompting Ask for a change (Refine) or ask a question (Ask), e.g. "make the price bold and larger", with two buttons:

  • Refine makes the change. The result is a new code version like any other, so it can be compared and reverted.
  • Ask only answers a question about the card ("is anything cut off on mobile?"). The card is never changed and no version is saved.

  Both work as one conversation for as long as the Stimulus tab stays open on that layout: each message goes with your earlier messages and the AI's replies, and with two pictures of the card exactly as the Preview below draws it, the same sample concept at a desktop size and at a phone size, so the AI can see what it is changing. Every reply says, in plain words, what the AI changed and why (or what it could not do), and is listed under your message. The conversation is not saved: switching layouts or reloading the page starts a new one, while the versions it produced stay. Refine is for cosmetic and layout changes rather than for adding or removing attributes.

• Choosing the model: Administrators and Support Administrators see a model dropdown above the Refine box, the same one the interface code editor (Expose JS) has. It starts on the model marked default, the same default as Expose JS (unless HM Admin sets a model for conjoint stimulus, which then takes its place); picking another uses it for the next Generate, Refine or Ask. Nobody else sees the dropdown.

• Preview: the preview draws sample concepts client-side (respecting structure, conditions, formulas, and combinatorial bounds, including a minimum of 0, so some sample cards show none of that attribute) and renders them through the same sandbox used at runtime. References to missing attributes are reported by name and stable id.

• Sandbox: layout code runs in an isolated sandbox with no network access and no access to survey data beyond the documented concept/attribute interface, with an execution timeout. Runtime errors are loud for authors in preview and generic for respondents, and a broken layout never silently renders blank values.

---

Respondent experience#

Each respondent sees Number of screens choice screens with Concepts per screen concepts each (set and concept order can be preserved or randomized). The main question text under the cards is the question text on the card on desktop (labelled Desktop main question while you edit it). Under Main Question Text at the top of the Build tab, the Mobile editor sets shorter wording for phones (while empty it shows the grey hint "Optional: shorter wording for phones", which is never saved); left blank, a phone asks "Which of these do you prefer?" while the respondent chooses. The Mobile wording and the follow-up wording take piped text (for example an earlier answer) the same way the question text does. (A survey that saved a separate Desktop text before keeps it, shown there with Use the question text instead to clear it.) At render time the widget picks the stimulus layout for each concept card by evaluating the layouts' Display rules in the order they are listed (first match wins, default layout as fallback): a rule on the Theme attribute is re-evaluated for every card, so one screen can show a different layout per concept, while a rule on the survey language, a variable, or an earlier answer resolves once and holds for the whole survey. It then applies conditional display (hidden attributes and levels stay in the data but are omitted from the stimulus), and resolves the display currency from the ordered override rules. Picking a concept can trigger an optional follow-up question about the chosen concept (separate desktop and mobile phrasing, two or three options, default "Definitely / Probably / Not Likely"). With the follow-up enabled, a screen counts as answered only once its follow-up is answered, and the question maps to the sequential analysis variant instead of the classic one.

Texts the conjoint draws itself#

Beneath the cards, the question line starts with the option set counter, Option Set 1 (of 8):. On a phone the respondent first pages through the offers one at a time with Previous and Next under a counter such as Option Set 1 (of 8): Offer 2 of 3; after the last offer all the offers are shown together under Which of these do you prefer?, and tapping one enlarges it, with an X to go back. If the follow-up is on but both follow-up texts are blank, the follow-up line reads Tell us more about your choice. If the choice screens cannot be built, the respondent sees We couldn't load this question right now. Please continue with the survey. Screen readers also announce a name for the row of cards (Choose one option), each card (Option and the card's id), the X on an enlarged card and a level with a tooltip (More information).

You can reword each of these on the question's Messages tab, in the survey's base language. In the counters, keep the words setNumber, setTotal, offerNumber and offerTotal (and optionId in the card name) exactly as they are, in whatever order your sentence needs: the conjoint replaces them with the numbers. In a multi-language survey every one of these texts, and the desktop and mobile main question text and follow-up text, is translated on the Translations tab like the rest of the question. The follow-up's answer options are not translated there, because the option a respondent picks is saved as its wording.

---

Data and exports#

Responses export as CSV, one row per concept shown (not per screen), so every alternative the respondent saw, chosen or not, is a row:

A conjoint split across the flow (Part 1 of 2, Part 2 of 2, …) is one conjoint in the response downloads (Export Data in any format, and Export All): it has one column, headed by its first part, holding the screens of every part in the order they were shown, numbered on from one part to the next (Part 2's screens follow Part 1's), and in an Excel download one conjoint sheet with every part's rows, its attributes listed once on the Key sheet. Each conjoint question still has its own sheet (two separate conjoints give two sheets); only the parts of one split conjoint share theirs. The later parts have no column or sheet of their own. The same holds for one respondent's Export Response workbook: one sheet per conjoint, a split conjoint's parts together on its sheet. A respondent who stopped after Part 1 has Part 1's screens only. (A CSV download is one flat file, so it has no conjoint sheets; use an Excel download for them.)

Because Presentation Order randomizes both the set order and the concept order per respondent, the generated and displayed numbers differ: set 1 of the design may have been shown on screen 7, and its second concept in position 3. Attribute level codes are 1-based too: the first level of an attribute exports as 1, the second as 2, and so on. (Levels are still stored 0-based internally, only the exported file is shifted.)

The full DOE library itself (every design, set, and concept) downloads with Export CSV from the DOE Libraries card on the DOE tab, for analysis or audit. The library CSV uses the same convention: designId plus 1-based designIndex, screenIndex and positionIndex, then one level-code column per attribute, and those codes are 1-based as well (first level = 1).

screenIndex / positionIndex mean different things in the two files, so pull the right one. In the DOE library they are the planned order: a design's sets are laid out in screen order and each set's concepts in position order, which is exactly the order respondents see when Presentation Order is set to Preserve DOE order. In the response export the same two columns record what a particular respondent actually saw, after per-respondent randomization. With randomization on, the two files will not agree, and that is the point of the response columns. For "which screen did this person really see this set on?", use the response export.

Reading level codes from a file exported before this change. Nothing inside either CSV records which numbering produced it, and neither export ships a legend mapping a code back to a level name. Files exported before the 1-based change number the first level of each attribute as 0; files exported after it number it 1. If you are re-running an analysis script against an older export, shift it by one, or simply re-export.

---

Related guides#

• Question Types: overview of all question types and when to use each
• MaxDiff (Best–Worst Scaling): the other trade-off question type
• Shelf Choice: a store-shelf question built on Conjoint; its design is built for each respondent, with no lock or DOE library
• Online Choice: an online-store product list built on Conjoint; like Shelf Choice, its design is built for each respondent, with no lock or DOE library
• Display Logic: the condition builder used by attribute, level, and layout rules
• Analytics & Responses: how responses are displayed and exported