Preference Analysis (HB)

1. What Is HB Estimation?

Hierarchical Bayes (HB) estimation discovers each individual respondent’s preferences from their choice data. Unlike aggregate models that estimate one set of preferences for everyone, HB produces a unique preference profile for every respondent in your study.

The key trick is called “borrowing strength.” HB uses information from all respondents to improve the estimates for each respondent. A respondent who answered only 10 choice tasks gets better estimates because HB knows what the overall population looks like. Respondents with noisy or sparse data are “pulled” toward the population average (a phenomenon called shrinkage), while respondents with clear, consistent choice patterns retain their individual signal.

Key Output

• Individual-level part-worth utilities: preference weights for every attribute level, for every respondent. These are the foundation for market simulation, WTP analysis, and segmentation.
• Population-level parameters: the mean vector and covariance matrix of the multivariate normal distribution of preferences across respondents.
• Model fit diagnostics: R-hat, ESS, RLH, hit rates, and other convergence and prediction quality metrics.

Why HB Is the Industry Standard

HB has been the dominant estimation method for conjoint analysis since the early 2000s. It is used by commercial conjoint software, Choicery, and throughout academic research (Rossi, Allenby, & McCulloch, 2005). Its popularity stems from three advantages:

1. Individual-level estimates enable respondent-level simulation, WTP, and clustering.
2. Borrowing strength produces stable estimates even with modest sample sizes or task counts.
3. Flexible heterogeneity: the multivariate normal population distribution captures correlations between preferences (e.g., people who prefer a high oven temperature also tend to care more about the accessories).

2. Prerequisites

3. Running HB in Choicery

3.1 The Estimation Form

Each HB estimation is stored as a named run. You can keep up to 10 saved runs per conjoint task with different settings and compare them; only one estimation per user runs or waits in the queue at a time. Figure 1 shows the form of the Pizza oven CBC (cbc_pizza_oven, 690 respondents).

No.	Control	What it does
1	Tasks badge	How many choice tasks enter estimation after the Choice Tasks filter and a random holdout task (here 10 / 10). Fixed tasks are kept out for holdout validation.
2	In-App	Runs the estimation on the Choicery server (default). Results appear in Results by themselves.
3	Create Package	Builds a Julia package you run on your own computer and import afterwards (section 3.3). Pro and Enterprise plans; on Free the pill opens the upgrade dialog.
4	Run Name	Up to 50 characters, required. The suggestion depends on the task type: CBC_Run_1, SCBC_Run_1 (CBC Shop), DRCBC_Run_1, BWCBC_Run_1, MD_Run_1 (MaxDiff), AMD_Run_1 (Anchored MaxDiff).
5	Burn-in	Iterations discarded at the start, while the sampler settles (default 10,000, steps of 100).
6	Draws/Chain	Iterations kept after burn-in (default 10,000). Draws divided by Thinning must leave at least 100 stored draws per chain, so with the default Thinning of 5 the minimum is 500.
7	Run	Starts the estimation. In Create Package mode it reads Generate Package.
8	Variable Coding	Categorical or Linear per attribute (section 3.5).
9	Add covariates	Adds respondent characteristics as a second model layer (section 3.4).
10	Advanced MCMC Settings	Opens the sampler, validation and reproducibility settings (section 3.7).

In-app runs have a budget of 100,000 iterations per chain for Burn-in plus Draws together. A larger total is refused when you click Run ("Burn-in plus draws per chain must not exceed 100,000 for an in-app run.").

3.2 Runs: Select, Compare, Delete

As soon as a task has a run, a run bar appears at the top of the Estimation step:

• Run: dropdown with every saved run, its status and the number of respondents ("· 690 resp"). Choosing a run shows its settings and results; a finished run's form is locked ("Viewing a completed run. Select New Run to change estimation settings.").
• New Run opens an empty, editable form for the next run.
• Delete this run and Delete all runs remove runs after a confirmation. The sidebar link Delete All Project Analysis Runs removes the runs of every task in the project.
• Badges warn when a run no longer matches the current state: Config changed, Filter changed or Config + filter changed (variable coding or participant filter edited since the run). Treat them as a prompt to re-estimate before reporting. Offline runs carry External Package or Imported Package.
• A failed run shows "Run failed." with a Duplicate as New Run button that copies its settings into a new form.

3.3 In-App vs Create Package

Both modes use the same statistical model and produce the same result files. The difference is where the sampler runs, how large the job may be, and how results come back into Choicery.

Switching the pill changes the field limits at once: Chains above 2 only stay while Create Package is selected. Burn-in and Draws are not changed silently; an in-app run that exceeds the budget is refused when you click Run.

What the package contains

With Create Package, Generate Package downloads <Project>_Julia_HB_Package_<Run>.zip and shows "Replication package generated. This run is waiting for external result import." The ZIP holds:

Running it and importing the results

3.4 Covariates

Covariates are respondent characteristics from your survey, such as age or an attitude scale. With Add covariates the population mean of the part-worths is regressed on the selected variables: the model then estimates how, for example, older respondents differ from younger ones. The individual utilities stay; the covariates add a second layer that describes who prefers what.

• Tick Add covariates, then open the picker (Select covariates...) and tick variables; Filter variables... searches the list. Each variable shows its type (Nominal, Ordinal, Metric).
• The line "3 / 30 variables · 3 / 10 encoded columns" counts what you picked. A metric variable needs one column; a nominal variable needs one column per category minus one.
• Choose variables you have a reason to expect an effect from. In the Pizza study these are food_involvement_z and lay_rationalism_z (z-standardized scale scores of the two Likert grids) and age: food involvement should raise the value of a hot oven and the recipe book, lay rationalism the weight of price, and age the preference between dial and touch screen.
• Prefer scale scores over single grid items, and avoid variables that measure the same thing twice (income and education, for example); they share the effect and make each one harder to read.

Covariates are available for CBC, CBC Shop, DR-CBC, BW-CBC, MaxDiff and Anchored MaxDiff. In-app covariates are switched on by the platform administrator; when they are off, the panel says "Covariate estimation is currently available in Create Package mode only", when they are on it reads "In-app runs allow up to N encoded covariate columns". The results are explained in sections 4.6 and 4.7.

Curved effects (Spline-HB-L)

By default a numeric covariate acts along a straight line: each additional year of age shifts a part-worth by the same amount. That misses effects that reverse direction, such as a level that the youngest and the oldest respondents both like and the middle age groups do not. The switch Spline-HB-L: Curved effects for numeric covariates lets each numeric covariate follow a curve instead. It sits in the Covariates panel, below the covariate picker.

• Columns. A numeric covariate uses 4 encoded columns instead of 1: 1 for the straight line and 3 for the curve. Variables with very few distinct values can use fewer. The line above the chips shows the count, so check it against the column cap. Nominal variables keep their columns and stay categories.
• Shrinkage. Each covariate's effect is shrunk toward zero when the data do not support it. Turning the switch on does not force a bend: without support the curve stays close to a straight or flat line. With few respondents a real bend can also come out flatter than it is.
• Availability. The switch exists for in-app runs of CBC, CBC Shop, DR-CBC, BW-CBC, MaxDiff and Anchored MaxDiff. It is hidden under Create Package, and packages estimate straight-line effects.
• Switched off, the run is the ordinary straight-line covariate model.

The example in section 4.7 uses three covariates chosen in advance for three expected patterns: age for a U-shaped effect on the controls, lay_rationalism_z for a nearly straight effect on price, and last_order_amount, the amount of the respondent's last pizza order, as a variable with no expected link to the controls of an oven. Both runs used 30,000 + 30,000 iterations and 2 chains and took about 7 to 8 minutes each.

3.5 Variable Coding

For CBC, CBC Shop, DR-CBC and BW-CBC you choose the coding of each attribute in Variable Coding. The form starts with the type set in the variable configuration of the project, otherwise Categorical.

Sign Constraints (Linear attributes only)

As soon as one attribute uses Linear coding, a Sign Constraints block appears with one dropdown per linear attribute ("Forces coefficient signs for linear attributes. Leave blank to let the data decide. Example: price is usually negative (<= 0)."):

• No sign constraint (pre-selected): the coefficient may be positive or negative.
• Positive (>= 0): for attributes where more should always be better, such as warranty length.
• Negative (<= 0): for price-like attributes where more should always be worse.

3.6 Task-Type Specific Options

Include None Option (DR-CBC and BW-CBC)

DR-CBC always shows Include None Option; BW-CBC shows it when the design fields a None. The follow-up question ("would you buy it?") then enters estimation as a no-choice option with its own constant ASC_none: if a respondent picks a product but answers "No", the task counts as None. A negative ASC_none means respondents generally prefer buying one of the products; a positive one means they often decline. Switch it off to estimate only among the shown products. Traditional CBC and CBC Shop follow the fielded design without a switch.

Choice Contributions (BW-CBC only)

Best + Worst (recommended) uses both answers of each task. Best only and Worst only use one stage, for diagnostic comparisons.

Estimate Display Position Effects (CBC Shop only)

Shop tasks show products in a rendered order, which can influence choice by itself. This checkbox adds control terms for the display positions, so that position effects are separated from the product utilities.

3.7 Advanced MCMC Settings

Click Advanced MCMC Settings at the bottom of the form to open three groups of settings:

3.8 Running the Estimation

Click Run. A full-screen panel Analysis Running shows the run name, the percentage, the current step ("Running MCMC estimation...") and the iteration of the current chain. Burn-in and draws are counted together, so with 30,000 + 30,000 the counter runs to 60,000 per chain.

• Cancel Analysis stops the run; partial results are discarded.
• At most 3 analyses run at the same time platform-wide. If the server is busy, the dialog "Server Busy" says "The server is currently running X out of Y analyses." and offers Join Queue. The Waiting in Queue card then shows your position and an estimated wait (about 10 minutes per analysis ahead of you), checks every 3 seconds and has a Leave Queue button.
• When the run finishes, "Preference Analysis completed!" appears and the page switches to Results.

4. Interpreting Results

Step 2 of the strip, Results, shows the selected run from top to bottom: the summary bar, attribute importance, average utilities, holdout validation, model diagnostics and, with covariates, the covariate effects and covariate curves. The header has a Download PDF button for the page (the PDF leaves out the covariate curves); most sections have their own PNG button.

4.1 Summary Bar

• N =: respondents in the run. With a respondent holdout it reads train / total, and a note "Respondent holdout is active." appears below.
• Tasks: choice tasks used; Tasks Used: used / total when tasks were excluded.
• Active Run: the run shown.
• R-hat (max) and ESS (min): the headline convergence figures (section 4.5). Check them first.
• Fitted RLH (Posterior Draw Average): average root likelihood of the respondents' own choices (section 12.5). Respondent-Holdout RLH (Posterior-Predictive) is added when the validation split was used.
• Acceptance Rate: share of accepted proposals across all iterations, in percent.

Above the bar, the collapsible Estimation details list the observation counts, the run time and, for linear attributes, how the values were centred and scaled.

4.2 Attribute Importance

A horizontal bar chart shows each attribute’s relative importance, sorted with the most important attribute at the top. All bars use the same muted teal; the ranking carries the information. A link leads to Survey Analysis for more importance charts and tables.

4.3 Average Utilities

One card per attribute shows the average utility of each level. All cards share one bar scale, so bar lengths can be compared across attributes. A switch in the section header changes the display:

• Zero-centered (default): the levels of each attribute sum to zero. Green bars are above the attribute average, red bars below.
• Diff from worst: the worst level is set to zero and the others show the gain over it ("switching from 350 °C to 450 °C adds X points").
• Linear attributes carry a linear badge and show the slope ("per unit increase", or "across the design range" in Diff from worst) with a footer listing the raw coefficient, the design range and the span.
• None option (any run with a None, e.g. DR-CBC): a separate card None Option marked "outside option" with the row No Purchase; it stays zero-centered in both modes ("A single constant has no worst level to count from.").

4.4 Holdout Validation

This section appears when the run has tasks that were not used for estimation (the fixed tasks of the design and a random holdout task) or a respondent validation split. One card per task shows:

• Hit rate: share of that task's choices the model predicted correctly (the alternative with the highest predicted utility matches the actual choice).
• Ratio: hit rate divided by chance. The pizza oven tasks show four ovens plus None, so chance is 20%: 67.8% correct gives 3.39x.
• The line "x/y correct · N options · Chance: z%" and a Details CSV button with the per-respondent predictions.
• With a validation split, a Validation Split (Report) card with a Details button appears, and the task cards move under Holdout Task Breakdown. BW-CBC runs get three cards per task: Best, Worst and the exact best-worst pair.

4.5 Model Diagnostics & Fit Metrics

Below Holdout Validation sits the collapsible section Model Diagnostics & Fit Metrics, with CSV and PNG buttons. Click the header to open it. It appears when the run produced at least one of these metrics:

With a single chain no R-hat can be computed; the R-hat entries are then left out.

4.6 Covariate Effects

When the run has covariates, the section Covariate Effects appears. At the top, "What do these numbers mean?" explains the figures. Choose a covariate in the Covariate dropdown; the chart shows how one standard deviation more of that covariate (+1 SD) shifts the utility of each level, with 90% credible intervals. The table Effects on Utilities lists the same effects (APA style) with CSV and DOCX buttons; the section's PNG button exports the chart.

In the Pizza run, one standard deviation more food involvement raises the utility of 450 °C by 27.9 points and lowers 350 °C by 20.2 points (*** = at least 99.9% of the posterior draws have the same sign). Rows without a star are drawn grey: there the data give no clear direction.

Below follow Effect on Attribute Importances (how a covariate changes the importance of each attribute, computed in ZC-diff space) and Share Explained by Covariates, each with their own CSV and DOCX buttons.

The table Share Explained by Covariates shows how much of the differences between respondents the covariates account for. The first row, All covariates, gives this share per attribute; each row below belongs to one covariate and shows its part, sorted by the mean across attributes. The eight largest are visible; Show all N covariates opens the rest. A small share does not make the covariates useless: most differences between respondents come from their own choices, and the covariates mainly describe who prefers what. Covariates that overlap share the part they explain, so a single one can show a very small or slightly negative share while All covariates stays exact; values below 0.05% show as 0.0%.

The table evaluates the shares at the posterior means. The Cov Explained sheet of the Excel export and Covariate_Explained_Share_Summary.csv add a draw-based value averaged over up to 4,000 posterior draws with a 95% interval (NDraws gives the count). It is usually higher, because the uncertainty of the covariate coefficients counts as spread there. The measure is the Bayesian R-squared of Gelman, Goodrich, Gabry and Vehtari (2019), applied to the covariate layer. For attributes with a sign constraint, marked †, the share refers to the log scale used in estimation.

More charts and tables in Survey Analysis

The HB page shows the averages and the covariate model. For the distribution across respondents and for group comparisons, follow the links under Attribute Importance and Average Utilities ("More charts, tables and analyses ... in Survey Analysis"), or open Analysis → Survey Analysis and choose Importances or Part-Worth Utilities under Preference Utilities (HB) in the sidebar.

• Preference Analysis Run picks the run, Group by (optional) a survey variable for segment comparisons (e.g. gender or diet); Load draws the view.
• Distribution shows one ridge per attribute: a wide ridge, like price here, means the attribute dominates for some respondents and barely matters for others. Bars shows the means (per group), Table the numbers, Covariates the relation to the covariates. Every view has PNG and CSV buttons.
• Part-Worth Utilities offers the same for the level utilities. The other Survey Analysis pages (Compare Groups, Crosstabs, Correlations, Regressions) work with the respondent characteristics directly.

The HB page shows the effects of the covariates you estimated. To look at the respondent characteristics themselves, or to compare utilities and importances between groups (for example age groups or high vs low food involvement) with charts, crosstabs and tests, open Analysis → Survey Analysis. It reads the individual utilities and importances of your HB runs, so you can use them like any other survey variable. The links under Attribute Importance and Average Utilities lead there directly.

MaxDiff runs show covariate effects with a Percentage points / Utility scale switch and a button "Show N effects with evidence below 95%".

4.7 Covariate Curves

Runs with numeric covariates also show the section Covariate Curves, directly below Covariate Effects. Each panel follows one numeric covariate across the range observed in the sample. The lines show how the part-worths of the selected attribute change when only this covariate changes, compared with a respondent at the covariate's average (dashed line). All other covariates stay at their reference value.

The controls of the section

• Attribute picks the attribute, the None option, or Attribute importance. There each line is one attribute's importance, in percentage points. Importance is a share of all attributes, so these lines can bend even with straight-line effects.
• Scale offers raw utilities, zero-centered diffs (as in the Covariate Effects table) and percent of the attribute's average part-worth range. The percent scale is available for categorical attributes.
• Same y-axis for all panels makes the panels comparable. Without it each panel has its own axis, and a tiny effect can look large. The figures in this section use it.
• A click on a name in the legend hides or shows its line. The PNG button exports the section, and the Cov Curves sheet of the Excel export holds the numbers.

How to read a panel

• Line: the posterior mean change. Above zero means a higher part-worth than a respondent at the average, below zero a lower one.
• Band: the pointwise 90% credible interval of that change. Where the band does not contain zero, the data give a clear difference from the average respondent at that value.
• Grey bars: how many respondents have that value. Few respondents mean a wide band, so read the ends of a curve with care.

Three patterns in the Pizza run

U shape. In Figure 14, the manual dial is worth about 42 points more at age 18 and about 43 points more at age 78 than at the average age of 45. The LED touch screen mirrors this as an inverted U, about 32 points lower at age 18 and 28 points lower at age 78. Young and old respondents thus differ from the middle age groups in the same direction.

No effect. In the left panel of Figure 14, the bands of all three controls contain zero along the entire range of last_order_amount. The lines fan out at the right end, where few respondents spent that much, and the band widens with them. In the table Share Explained by Covariates, this covariate accounts for 0.2% of the differences in the controls. No effect on one attribute says nothing about the others: the same covariate does shift the utility of the None option.

Nearly straight. In the right panel of Figure 15, the higher the lay rationalism, the more the low prices gain and the high prices lose. From the lowest to the highest value, $69 moves from about −38 to +31 points and $279 from about +45 to −32 points. The lines flatten a little at the ends, but a straight line would describe them well. Spline-HB-L leaves such an effect close to a straight line.

Straight line versus curve

The straight-line run in Figure 16 reports a steady rise of the manual dial with age, from about −11 points at age 18 to about +14 points at age 78. For the older half that points in the right direction but is far too small; for the younger half it points in the wrong direction. The covariates' share of the differences in the controls shows the same gap: age accounts for 31.8% with curves and 5.2% with straight lines.

The prediction of the choices themselves changed little in this example: Fitted RLH 0.633 with curves and 0.629 without, hit rate on the fixed tasks 58.8% and 58.5%. The curves mainly improve the description of who prefers what.

What to keep in mind

• The Covariate Effects table shows the straight part only. In a run with Spline-HB-L, the "+1 SD" columns and the chart in section 4.6 hold the linear coefficient, not the curve. Here the table gives age only +4.65 on the manual dial, while the curve reaches about +38 points at age 63. For a curved effect, read the curves; a small "+1 SD" effect does not mean there is no effect. Share Explained by Covariates counts the straight part and the curve together.
• Check convergence first. The curve parameters are part of R-hat and ESS. This run reached R-hat (max) 1.07 but only ESS (min) 35, below the guideline of 400, so it serves as an illustration; for a final report run more iterations.
• Choose covariates with a reason. A curve found by trying many covariates can be chance. A curve describes a relation in your sample, not a cause.
• Runs without the switch show this section as well, with straight lines. Sign-constrained linear attributes are estimated on a log scale, so their lines can bend even then.

MaxDiff and Anchored MaxDiff show one panel per covariate for the selected Item, in Relative Preference percentage points or on the utility scale. The anchor threshold of Anchored MaxDiff has its own entry, on the utility scale only.

5. Exporting Results

Step 3 of the strip, Export, opens Export Data once a run has results. It groups the files into three cards:

The Excel workbook contains, in this order: Summary, Settings & Diagnostics (design, HB settings actually used, RLH statistics with chance RLH, flagged respondents, holdout figures, Bulk and Tail ESS), Individual_ZC_Diffs, Individual_Raw, Individual_Importances, with linear attributes Linear_Coefficients_Raw and Linear_Coefficients_ZC, Flagged_Respondents, with covariates Cov Effects (Raw), Cov Effects (ZC), Cov Importances and Cov Explained, with a validation split Validation Split (Report), and finally Parameter_Diagnostics and Estimation Audit.

6. What to Do After HB

HB estimation is the starting point. The individual utilities feed these analyses:

• Market Simulation: header menu Analysis → Market Simulation (MaxDiff Simulation for MaxDiff tasks). Simulates shares of preference, price curves and competitive scenarios from a run with results.
• Willingness to pay: in the Market Simulation, converts utility differences into money. It works with linear and categorical price coding.
• Survey Analysis: header menu Analysis → Survey Analysis. Compares utilities and importances between respondent groups with charts, crosstabs and tests.
• AI-Driven Profile Analysis (second tab): TasteNet-MNL, for preference weights that change with respondent characteristics, not only shift with them.
• Latent Class (third tab): discovers segments with distinct preference profiles.
• Interaction Effects (fourth tab): tests which attribute interactions matter.

7. Best Practices & Common Pitfalls

Do

• Check R-hat (max) < 1.1 and ESS (min) > 400 before trusting results. Raise the iterations when they are out of range, especially with covariates.
• Use 2 chains, so that R-hat can be computed.
• Keep the fixed holdout tasks of the design and look at their hit rates.
• Report Fitted RLH together with the chance RLH.
• Choose covariates with a reason, prefer scale scores, and avoid overlapping variables.
• Switch on Spline-HB-L when a numeric covariate may not act along a straight line, and read those effects in the Covariate Curves, not in the "+1 SD" table.
• Compare several runs with different settings to check that the results are robust.

Don’t

• Don’t report a run with R-hat > 1.1.
• Don’t compare raw utility magnitudes across respondents. Use importances or ZC-Diffs; utility scales differ between respondents.
• Don’t use HB utilities as segments. HB assumes one continuous population distribution; use Latent Class for discrete segments.
• Don’t expect interaction terms: HB estimates main effects. Use Interaction Effects to test whether interactions matter.
• Don’t run HB with fewer than 30 respondents.

8. Key Definitions

9. The Two-Level Hierarchical Model

9.1 Level 1: Individual Choice Model (MNL)

At the individual level, each respondent i is modeled by a Multinomial Logit (MNL) model with their own preference vector β_i:

Here X_j is the design vector describing alternative j (coded attribute levels), and β_i is respondent i’s vector of part-worth utilities. The probability of choosing alternative j increases with its utility relative to all other alternatives in the choice set.

9.2 Level 2: Population Distribution

The second level specifies how individual preference vectors are distributed across the population:

• μ (mu) = the population mean preference vector. This represents the “average respondent.”
• Σ (Sigma) = the population covariance matrix. This captures both (a) how much individual preferences vary around the mean and (b) the correlations between preferences for different attributes.

The multivariate normal assumption is powerful because it captures preference correlations. For example, if respondents who prefer Brand A also tend to be less price-sensitive, this correlation appears as an off-diagonal element in Σ.

Covariates and Spline-HB-L

With covariates, the population mean depends on the respondent. Each respondent has a row vector z_i of encoded covariate columns with a leading 1, and the coefficient matrix A has one row per column:

With Spline-HB-L each numeric covariate contributes two parts to z_i. The linear column is the standardized covariate; category dummies are standardized in the same way. The curve block is built from a cubic B-spline with three knots at the minimum, median and maximum of the training respondents. Its columns are residualized against the intercept and all linear columns, rotated onto their remaining directions (at most 3 columns) and scaled to unit variance. The block therefore carries only the part of the effect beyond the straight lines.

The intercept keeps its fixed prior. Every linear column is its own group g, and every curve block forms one group. Each group has its own adaptive scale τ_g, drawn in the Gibbs sampler after Σ:

Reports convert the draws exactly, without changing any prediction: linear rows per unit of the usual covariate coding (per SD for numeric covariates, versus the reference for categories), curve columns shifted to zero at the reference profile. Covariate Curves evaluate each draw along the observed range and take the difference from the reference draw by draw.

9.3 Prior Distributions

Being Bayesian, the model requires prior distributions on the population parameters:

This is the prior for CBC, CBC Shop and BW-CBC. DR-CBC uses μ ~ N(0, 100 · I), not scaled by Σ. MaxDiff and Anchored MaxDiff use μ ~ N(0, Prior σ² · I) with the MaxDiff field Prior σ² (default 1.0), and their Inverse-Wishart scale comes from the field Variance Adj.

Choicery uses diffuse (weakly informative) priors by default, centered at zero. The two variances are separate: the prior on the population mean uses a fixed, very diffuse σ²_mean = 100.0 that is not exposed in the UI, while the Inverse-Wishart scale on Σ defaults to σ²_prior = 4.0 and is editable in Advanced MCMC Settings as Prior σ². These priors have minimal influence on the posterior when you have a reasonable amount of data (> 50 respondents). The Inverse-Wishart prior on Σ ensures positive-definiteness of the estimated covariance matrix.

The Inverse-Wishart degrees of freedom are fixed at df_prior = K + 5, where K is the number of estimated parameters. This is the external benchmark default and the industry convention. The "+5" offset (referred to internally as df_offset) is not exposed in the UI because: (a) at typical sample sizes (n > 200) it has negligible impact on the posterior (the likelihood dominates), and (b) departing from K+5 only makes sense for very specific academic replications. If you need a non-default value (e.g. K+2 for a paper using a more diffuse Σ-prior), edit the offline HB package's hb_analysis.jl directly and re-upload via the import path.

9.4 Shrinkage: The Key Insight

The most important property of HB estimation is shrinkage: individual estimates are pulled toward the population mean. The degree of shrinkage depends on the relative informativeness of the individual’s data vs. the population distribution.

• If respondent i has many tasks and clear patterns → high w_i → estimate stays close to their individual data.
• If respondent i has few tasks or noisy choices → low w_i → estimate is pulled toward the population mean.

This is optimal in a mean-squared-error sense (the James-Stein phenomenon). Even when individual estimates are slightly biased toward the mean, the overall accuracy across all respondents is higher than individual-level MLE (Allenby, Arora, & Ginter, 1995).

10. The MCMC Sampling Algorithm

The posterior distribution of the HB model is analytically intractable: there is no closed-form solution. Instead, Choicery uses MCMC to draw samples from the posterior, and these samples are used to estimate posterior means, standard deviations, and other quantities of interest.

10.1 Gibbs Sampling with Metropolis-Hastings Steps

Choicery’s HB implementation uses a Gibbs sampler that cycles through three steps in each iteration:

With upper-level covariates, step 2 draws the full coefficient matrix (intercept row = population mean, one row per encoded covariate column) from its matrix-normal conditional instead of μ alone. These three steps are repeated for n_burn + n_draws total iterations. The first n_burn iterations are discarded (burn-in), and the remaining n_draws iterations provide the posterior samples.

10.2 Adaptive Proposal Scaling

The Metropolis-Hastings step requires a proposal distribution. Choicery uses a multivariate normal proposal centered at the current β_i, with a scale parameter that controls the “step size.”

Each respondent has an own proposal scale, starting at 0.1. During burn-in it is adaptively tuned every 100 iterations: if the acceptance rate is more than 0.05 above the target (default 0.30) the scale grows by 10%, if it is more than 0.05 below it shrinks by 10%, always between 0.001 and 2.0. After burn-in, the scale is fixed. You steer this only through Target Accept; the scale itself is not a setting.

10.3 Multiple Chains

Choicery runs independent chains with different random seeds: 1 or 2 for in-app runs (2 is the default and the in-app maximum), up to 20 in a Create Package run. Every chain starts from the same neutral point (small random betas, μ = 0, Σ = prior) and then follows its own random path. Multiple chains serve two purposes:

1. Convergence assessment: if chains with different random paths settle on the same distribution, this is strong evidence of convergence (R-hat diagnostic).
2. More posterior samples: draws from all chains are pooled for final estimates, increasing ESS.

In Create Package runs with Parallel switched on, chains run simultaneously on separate CPU cores, with near-linear speedup. In-app runs compute the chains one after the other.

11. Convergence Diagnostics

MCMC convergence is the single most important quality check for HB results. A non-converged chain produces meaningless results. Choicery reports R-hat (max), ESS (min) and the overall acceptance rate in the summary bar, R-hat (mean) and ESS (min) again in Model Diagnostics & Fit Metrics, and the acceptance of each chain in the run progress.

11.1 R-hat (Gelman-Rubin Diagnostic)

R-hat compares the variance between chains (B) with the variance within each chain (W). If chains have converged to the same distribution, these should be similar.

Choicery implements the modern rank-normalized split R-hat of Vehtari, Gelman, Simpson, Carpenter and Bürkner (2021): each chain is split in half, draws are rank-normalized, and the larger of the bulk and the folded (scale) statistic is reported. It is computed on the stored upper-level draws, that is the population mean (or the covariate coefficient rows) and the elements of the covariance matrix.

Choicery reports the maximum R-hat across these population-level parameters as R-hat (max) in the summary strip (per-respondent convergence is only checked when Individual R-hat is switched on). Even if most parameters have excellent R-hat, a single parameter with R-hat > 1.1 means the model has not fully converged.

11.2 Effective Sample Size (ESS)

MCMC draws are autocorrelated: consecutive draws tend to be similar. ESS tells you how many independent samples your chain is equivalent to:

This is the simplified textbook form. Choicery computes the rank-normalized split bulk ESS with Geyer's initial-sequence method, plus a tail ESS (Vehtari et al., 2021); the workbook reports Bulk ESS (min), Bulk ESS (mean) and Tail ESS (min). A chain of 10,000 draws with high autocorrelation might have ESS of only 500. Thinning (keeping every kth draw) reduces stored samples but does not improve ESS per wall-clock time. It mainly saves memory.

Target: ESS > 400 for reliable posterior mean estimates. For posterior quantiles (e.g., 95% credible intervals), ESS > 1,000 is preferred.

11.3 Acceptance Rate

The acceptance rate is the percentage of Metropolis-Hastings proposals that are accepted. It is a proxy for how well the proposal distribution matches the posterior.

12. Post-Processing: From MCMC Draws to Utilities

After MCMC sampling completes, the raw draws must be post-processed into usable utility estimates. Choicery performs these steps automatically:

12.1 Posterior Mean

For each respondent i, the final utility estimate is the average (posterior mean) of all post-burn-in draws:

12.2 Reference Level Recovery (Effects Coding)

Effects coding estimates L−1 coefficients for an attribute with L levels. The reference level’s utility is recovered as:

12.3 Zero-Centered Diffs (ZC-Diffs)

To enable cross-attribute comparison, utilities are rescaled so that the average attribute range equals 100:

1. Recover the reference level (12.2), so the levels of each categorical attribute already sum to zero.
2. For each attribute, compute the range: max(utility) − min(utility).
3. Compute the average range across all attributes.
4. Multiply all utilities, including ASC_none, by 100 / average_range.

This is done per respondent, so every respondent's utilities are on the same scale.

12.4 Attribute Importance

Importances are computed at the individual level first, then averaged. This individual-level averaging is more appropriate than computing importances from averaged utilities (Orme, 2020).

12.5 Root Likelihood (RLH)

Choicery evaluates this quantity for every 10th post-burn-in draw of β_i and averages the results, rather than plugging in the posterior mean. This posterior-draw average is the value shown as Fitted RLH.

RLH is the geometric mean of the predicted probability of each respondent’s chosen alternative. It ranges from 1/J (chance level, where J = number of alternatives) to 1.0 (perfect prediction). A “good” RLH depends on the number of alternatives:

13. Design Matrix and Coding

The design matrix X encodes the attribute levels of each alternative in a format suitable for estimation. Choicery supports three coding schemes:

13.1 Effects Coding (Categorical Attributes)

For an attribute with L levels, effects coding creates L−1 columns. The reference level (last level) is coded as −1 on all columns:

13.2 Linear Coding (Numeric Attributes)

A single column contains the centered and rescaled attribute values: Choicery subtracts the mean of the levels and divides by half their range. For evenly spaced levels the sampler then works on values between −1 and +1 (here −1, −0.33, +0.33, +1). Results are converted back, so the reported coefficient is per raw unit and each level’s utility is β times (price minus mean):

13.3 None Option (ASC Column)

When the task has a None option (DR-CBC, BW-CBC, and CBC or CBC Shop with a fielded None), a separate binary column is added:

14. HB vs. Other Estimation Methods

HB is one of several estimation methods for conjoint data. The table below summarizes when to use each approach:

Why Choicery Does Not Offer Aggregate MNL

Aggregate MNL estimates a single set of utilities for the entire sample and ignores preference heterogeneity. When preferences vary across respondents (which they almost always do), the aggregate coefficients are biased and standard errors are understated. Crucially, aggregate MNL cannot produce the individual-level utilities that every downstream Choicery module (Market Simulator, WTP, Price Elasticity, Reservation Price, Hit-Rate, Sensitivity) depends on.

Because HB uses the same multinomial-logit likelihood and degenerates to the aggregate solution in the limit of zero heterogeneity, it strictly dominates aggregate MNL: you get the aggregate picture plus the individual posterior, with no realistic scenario in which aggregate MNL would give a better answer. Offering it as a separate option would invite the biased-estimate trap without adding capability, so Choicery provides HB (and, for discrete segments, Latent Class) as the only supported estimators. For the rare cases where aggregate utilities are genuinely needed (for example as a textbook baseline), two indirect routes exist: the Main Effects (Aggregate MNL) sheet of the Interaction Effects Excel export, and the 1-class baseline solution that every Latent Class run estimates alongside the multi-class models.

Why Not Cluster HB Utilities Instead of Running LC?

You can cluster HB utilities using k-means or hierarchical clustering, but this is suboptimal. LC simultaneously estimates segment membership and segment-specific preferences, which produces more coherent segments than a two-step approach. However, clustering HB utilities can be useful as a quick exploratory tool or when you need more flexibility in the clustering algorithm.