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 three authoring areas:

• The question card (on the canvas) — the prompt and the Attributes editor with each attribute's levels.
• The Settings tab (Properties panel) — screens and concepts per screen, follow-up question, aspect ratio, currency, presentation order, and the Design of Experiment (DOE) controls.
• The Stimulus layouts panel — how a concept is rendered, using AI-generated layout code.

---

Attributes and levels#

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); 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 — 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.

DOE constraints#

Below the Attributes editor, the DOE Constraints section authors the generation constraints:

• Force constraint — when its condition matches a partially built concept, the target attribute is set to one of the permitted levels (one is chosen at random when several are allowed), or a combinatorial attribute's item count is forced. Force constraints take precedence over normal randomization.
• Regular constraint — a prohibition: when the left side is true, the right side must not also be true. Violating candidates are rebuilt (up to 5 retries, then targeted bucket refills and up to 50 more).

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 Force constraints 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, lock it from the Settings tab. Locking snapshots the matrix (as a hash) so a DOE can be built against it. The lock state is shown on the question card and in the Flow tab.
2. Generate or upload.
   • Generated — the server builds a library of designs (500 by default) as a background job with progress reporting, honoring structure applicability, constraints, overlap mode, combinatorial bounds, and conditional attributes, from a stored random seed so results are reproducible.
   • Uploaded — download the CSV template (pre-filled with dummy rows and the stable attribute/level ids), fill in your own fixed design, and upload it.
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. Every library has a viewable and exportable distribution summary — level counts, overlap, and balance quality.
4. Activate. Activating a validated library version makes it the one respondents are assigned from. A library that carries warnings can only be activated with explicit acknowledgement — the warnings are shown in a confirmation dialog, and the acknowledgement (with timestamp) is 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 fielding.

---

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.

• Layouts — add, copy, rename, and delete layouts. 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.
• 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.
• AI generation — describe the layout (and optionally attach a mockup image); the generator knows your attributes and their stable ids and follows layout and accessibility guidance. Every generation creates a new code version with author, timestamp, and the prompt used — you can view, compare, and restore versions.
• Preview — the preview draws sample concepts client-side (respecting structure, conditions, formulas, and combinatorial bounds) 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 iframe with no network 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 — 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 above the screens supports separate desktop and mobile content (Settings tab), falling back to the question text from the Build tab. 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.

---

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:

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) and its distribution summary can also be exported as 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 — 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 — 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
• Display Logic — the condition builder used by attribute, level, and layout rules
• Analytics & Responses — how responses are displayed and exported