choice-metrics.com

There are two things to consider here.

First, you have specified a mixed logit model (random parameters), not a multinomial logit model with Bayesian priors. The syntax for a random parameter is for example:

b8.dummy[(u,0.007499,0.207217)]

whereas a random parameter is

b8.dummy[u,0.007499,0 ...

Correct, changing the number of levels for a numerical attribute does not change the number of parameters and would not impact the design size. Using 12 rows would be sufficient, but I would probably increase the number of rows to get more variation in the data and trade-offs presented to respondents.

It is fine to show the cost attributes separately. This is also common in transport where for example fuelcost and tollcost are shown separately. In the model that you estimate after the data collection you can estimate separate parameters for each cost attribute, but you can also estimate a single ...

Blocks are not needed. Selecting 8 choice tasks randomly from the 48 rows is also fine, or even cycling through the design by giving the first 8 to respondent 1, the next 8 to respondent 2, etc, and then starting again at the beginning of the design. I believe that SurveyEngine by default cycles ...

No that is not what you want/expect in a D-efficient experimental design. But it is easy to fix.

There are two potential causes:
1. You mis-specified your priors, as you have set several priors to identical values, indicating that they have the same preference and therefore there are much fewer ...

There is no way say what a good value for the D-error is. For one study, a D-error of 0.1 is very good, while for another study a D-error of 0.1 can be bad.

This means that you should not really pay much attention to the value of the D-error. A D-efficient design is a design with a relatively low ...

First of all, it does not matter which coding scheme you select for generating an efficient design. Yes, the D-error changes, but D-errors are not comparable across models. So for different utility functions, different priors, different coding schemes, the D-errors are not comparable. So you should ...

Yes this is possible. There are two options.

(1) Include the type of bread as a dummy coded attribute in the utility functions of BreadA and BreadB. Instead of BreadA and BreadB, you can show the type of bread as the label on top. The coefficients of the dummy coded attribute replace the ...

1. Yes you can use zero priors, that is always a safe option. The further away your priors are from the true parameters, the more efficiency you lose. Note that parameter estimates are often not significant in a pilot study because of the small sample size, and the estimate is still the best guess ...

I see. In your previous screenshot Charger1 and Charger2 are swapped around. So Pref=1 means that the option in the second row is chosen. In that case it may be correct as long as Stata understands that the first charging option (Charger2) is actually the second listed option.