choice-metrics.com

Hello,
I am working on an unlabelled design and am looking for some guidance as to how to properly set our design constraints. The design has two alternatives with 6 attributes that have two levels each. Each participant will see 8 choice sets. We anticipate that one attribute will be very dominant, and thus want to ensure within each block, there is one choice set in which that attribute (stock) is unvaried (low stock for both option A and option B). I have tried to set this up by specifying attribute level count constraints to be non attribute level balanced. However, when I run the design, some blocks will have multiple sets with this 'locked' attribute, while other blocks do not have any. Is there any way to set a constraint so that this attribute level imbalance appears exactly once per block?

Syntax:

?
Design
;alts = facilityA*, facilityB*
;rows = 48
;block = 6
;eff = (mnl,d)
;model:
U(facilityA) = b1 * distance[0,1] +
b2 * wait[0,1] +
b3 * alone[0,1] +
b4 * friendly[0,1] +
b5 * stock[0,1](27,21) +
b6 * freq[0,1] /

U(facilityB) = b1 * distance[0,1] +
b2 * wait[0,1] +
b3 * alone[0,1] +
b4 * friendly[0,1] +
b5 * stock[0,1](27,21) +
b6 * freq[0,1]


;formatAttributes:
facilitya.alone(0=in a group, 1=alone) /
facilitya.distance(0=far, 1=near) /
facilitya.wait(0=wait, 1=no wait) /
facilitya.stock(0=low stock, 1=high stock) /
facilitya.friendly(0=unfriendly, 1=friendly) /
facilitya.freq(0=frequent visits, 1=infrequent visits) /
facilityb.alone(0=in a group, 1=alone) /
facilityb.distance(0=far, 1=near) /
facilityb.wait(0=wait, 1=no wait) /
facilityb.stock(0=low stock, 1=high stock) /
facilityb.friendly(0=unfriendly, 1=friendly) /
facilityb.freq(0=frequent visits, 1=infrequent visits) /
$

Thanks in advance for any help!

Normally appropriate priors would make sure that there exist a sufficient number of choice tasks with overlapping levels for 'stock' as the design would become inefficient if there is a dominant attribute and there is no overlap. However, in your case you have not provided any priors and therefore the design does not know that one of its attributes is fairly dominant.

Your solution works fine without the need to set priors, and your question relates to blocking. Note that blocking does not effect design efficiency, and blocking in efficient designs cannot be done perfectly (only in orthogonal designs). In other words, you can change the blocking manually, the blocking column in Ngene is merely a guide but feel free to change it and to allocate certain choice tasks to other blocks.

Michiel