There are too many near-dominant choice tasks in my design

This forum is for posts covering broader stated choice experimental design issues.

Moderators: Andrew Collins, Michiel Bliemer, johnr

Post Reply
Albert Belanm
Posts: 1
Joined: Tue Apr 21, 2026 4:31 pm

There are too many near-dominant choice tasks in my design

Post by Albert Belanm »

Hello,
Thank you for providing this forum.
This is my first time conducting a choice experiment, so some of my questions may be a bit naive.
In this study, I want to explore people's preferences for a certain type of medicine. I design 5 attributes, which are:
Cost(500, 1000, 1500, 3000)
Dosing Frequency(Daily dosing, Once-monthly dosing, Once every two months, Once every six months)
Efficacy(99%, 90%)
Risk of Adverse Effects(Mild, Moderate, Severe)
Route of Way(Tablet, Injection, Implantable rod).
Among them, the injection and the implantable rod would not be paired with a daily dosing regimen, while the tablet would not be paired with a once every six months regimen.
For specific reasons, I was unable to conduct a pilot study, so I added a small prior to each level based on the previous posts in the forum. But this led to a problem. When the model's D-error converged, I reviewed the questionnaire and found some absolutely dominant scenarios. So I further added reject constraints to rule out some undesirable dominant combinations.
As a result, the absolutely dominant options disappeared, but there were still many dominant scenarios.
For example, a scenario like A: ¥3000/month, once-monthly, 90% efficacy, noticeable side effects, implantable rod vs. B: ¥500/month, daily, 99% efficacy, no side effects, tablet — in this case, one alternative is dominant in only one attribute level.
I know that Ngene deliberately designs less balanced questions to explore boundaries, but the problem is that when I carefully reviewed each scenario, I found that scenarios where one alternative is dominant in only one attribute level accounted for 16 out of 48. I wonder if this is too many.
After that, I tried increasing the priors, but the problem persisted. Below is my code:

Code: Select all

Design
;alts = prepA*, prepB*
;rows = 48
;block = 4
;eff = (mnl,d)    
?;bdraws = halton(100)  
?;rep=10
;alg = mfederov(stop = noimprov(30 mins)) 
;reject:
prepA.way = 0 and prepA.duration = 0,

prepA.way = 1 and prepA.duration = 0,

prepA.way = 2 and prepA.duration = 3,

prepB.way = 0 and prepB.duration = 0,

prepB.way = 1 and prepB.duration = 0,

prepB.way = 2 and prepB.duration = 3,

prepA.cost <= prepB.cost and 
prepA.duration >= prepB.duration and 
prepA.efficacy >= prepB.efficacy and 
prepA.risk >= prepB.risk,

prepB.cost <= prepA.cost and 
prepB.duration >= prepA.duration and 
prepB.efficacy >= prepA.efficacy and 
prepB.risk >= prepA.risk

;model:
U(prepA) = 
      b_cost[-0.01] * cost[1,2,3,6](10-14,10-14,10-14,10-14)          ? 1 unit=500       
    + b_dur.effects[0.01|0.005|0.0025] * duration[3,2,1,0]           ? 0:daily dosing; 1:once-monthly dosing; 2:once every two months; 3:once every six months     
    + b_eff[0.01] * efficacy[9,10]                                     ? 9:90% efficacy; 10:99% efficacy     
    + b_risk.effects[0.01|0.005] * risk[2,1,0]                        ? 0:severe adverse effect; 1:moderate AE; 2:mild AE
    + b_way.effects[0.01|0.005] * way[2,1,0]                          ? 0:implantable rod; 1:injection; 2:tablet 
/
U(prepB) =  b_cost * cost + b_dur.effects * duration + b_eff* efficacy 
         + b_risk.effects * risk + b_way.effects * way
$
1. I want to know whether the occurrence of this situation is acceptable, or if there is a problem with my code or the design of the attributes and levels.
2. And there is another question: If I plan to use an MXL model for the final analysis, can I just use an MNL design during the Ngene questionnaire design phase? Or, after the imbalance issue is resolved, should I still use rppanel model?
Thank you very much!
Michiel Bliemer
Posts: 2093
Joined: Tue Mar 31, 2009 4:13 pm

Re: There are too many near-dominant choice tasks in my design

Post by Michiel Bliemer »

Since you have non-zero priors that indicate the preference order of the levels of each attribute, you should not get any strictly dominant alternatives. A strictly dominant alternative is an alternative where the profile of one alternative is strictly better than the profile of the other alternative. Ngene will automatically avoid them since you put an asterisk after each alternative in the ;alts property. You should not have to impose the dominance constraints.

What can happen is weak dominance, e.g. where one alternative is much more desirable than the other, resulting in choice probabilities such as 95% versus 5%. Avoiding weak dominance is only possible with sufficiently reliable parameter priors because otherwise Ngene will not know the relative importance of each attribute. So I am assuming that you are referring to weak dominance instead of strict dominance. Since your priors are near zero, Ngene will not automatically be able to avoid weakly dominant alternatives.

If you want more control over any dominance, I recommend that you create an external candidate set. For example, you can generate a large random design (which will still obey your constraints) using for example:
;rows = 10000
;fact (and remove ;eff)

Assuming you are using Ngene for desktop/windows, you can copy this design into a spreadsheet, add a first column with values 1, and remove any rows that do not satisfy your dominance criterion. After removing the unwanted rows, you can load the candidate set back into Ngene and use:
;rows = 48
;eff = (mnl,d)
;alg = mfederov(candidates = spreadsheetname.xlsx) (or csv)

If you are using Ngene Online, you can export the design directly to a spreadsheet, remove any unwanted rows, and import back into Ngene, and use:
;alg = mfederov(candidates = spreadsheetname) (without any suffix)

To answer your second question, yes, you can estimate a (panel) MXL model, even if you optimised the design for an MNL model. It is virtually impossible to optimise the design for a panel MXL model, so I highly recommend just optimising your design for an MNL model.

Michiel
Post Reply