Generating a design.

[Mayaba]

Dear All,
I'm new to choice experiments; my questions may sound silly. I'm doing a research in the egg industry intending to use unlabelled alternatives. I have run the syntax below for 10 hours until I had to stop the system. I got the following MNL efficiency measures are as follows;
D-error
A-0.640996
B-1.084013
S estimate 1767.389666

My questions are as follows:

- Is the syntax ok?
- Is it normal for Ngene to run for 10 hours without finding the best design?
- I had the, "no choice option," but it is not showing under the formatted scenarios.
- My study have levels which are so specific, for example the attribute, "use of cages," have yes and none levels. From the trail run I had, the levels keep changing which does not make sense, for example when the attribute level, "yes," for use of cages appears under the free - range system which does not use cages. How can I have levels fixed?
- I intend to include interactions, will this affect the efficiency of the design?
- I also intend to use blocking method to reduce the burden on respondents.
- How do I treat price as a continuous variable?


Design
;alts= Choice A, Choice B, Choice C, Choice D, Choice E, None
;rows=16
;eff=(mnl,d)
;model:
U(Choice A)=bUse of cages.dummy[-0.042]*Use of cages[1,0]+bAnimal welfare certification .dummy[0.17]*Animal welfare certification[1,0]+bAccess to outdoors[0.140]*Access to outdoors[1,0]+bPrice[-0.47]*Price[4,5,6,7,8]/

U(Choice B)=bUse of cages *Use of cages+bAnimal welfare certification *Animal welfare certification+bAccess to outdoors *Access to outdoors+bPrice*Price /

U(Choice C)=bUse of cages *Use of cages+bAnimal welfare certification *Animal welfare certification+bAccess to outdoors *Access to outdoors+bPrice*Price /

U(Choice D)=bUse of cages *Use of cages+bAnimal welfare certification *Animal welfare certification+bAccess to outdoors *Access to outdoors+bPrice*Price /


U(Choice E)=bUse of cages *Use of cages+bAnimal welfare certification *Animal welfare certification+bAccess to outdoors *Access to outdoors+bPrice*Price /
U(None)= b0(0)

$

[Michiel Bliemer]

You have made a good start. I have several comments on your syntax:
1. Avoid spaces in variable names
2. I added .dummy for boutdoors
3. You need to add an asterisk (*) behind generic alternatives in the alts command to avoid dominant alternatives
4. Since most of your choice tasks have a dominant alternative, Ngene will not be able to find a design after you check for dominance, hence you need to switch to the modified Federov algorithm
5. The modified Federov algorithm does not maintain attribute level balance. This is generally more or less automatically satisfied for categorical variables, but not for numerical variables. Therefore, I added attribute level constraints to the price attribute.
6. With 16 rows you cannot obtain attribute level balance since it is not divisible by 2 and 5 (the number of levels). I switched to 10 rows and created two blocks such that each respondent faces 10 choice tasks.
7. When using informative non-zero priors for the parameters, alternative-specific constants also need an informative prior. It CANNOT be zero because the utilities for A-E will be far below zero, making the None alternative the most preferred, which is not reasonable. Just like priors for the other parameters, you can obtain the prior for the constant by simply estimating the model using pilot study data. If you do not have pilot study data, you may want to use noninformative priors -0.00001 and 0.00001 to indicate zero priors but with a sign (so Ngene can check for dominance). In that case, you can leave the prior for the constant zero.
8. Consider if you really want to use 5 generic alternatives. This is a lot, most people use 2 or 3 generic alternatives in a choice task to make it easier for the respondent.

Code: Select all

Design
;alts = A*, B*, C*, D*, E*, None  ? you need to add an * to generic alternatives to avoid dominant alternatives
;rows = 20                       
;block = 2
;eff = (mnl,d)
;alg = mfederov                   ? since you have many alternatives, there are many dominance constraints and the default swapping algorithm cannot find a design
;model:
U(A) = bcages.dummy[-0.042]   * cages[1,0]
     + bcert.dummy[0.17]      * certification[1,0]
     + boutdoors.dummy[0.140] * outdoors[1,0]
     + bprice[-0.47]          * price[4,5,6,7,8](3-5,3-5,3-5,3-5,3-5)  ? impose some attribute level balance constraints for numerical variable
     /
U(B) = bcages * cages + bcert * certification + boutdoors * outdoors + bprice * price /
U(C) = bcages * cages + bcert * certification + boutdoors * outdoors + bprice * price /
U(D) = bcages * cages + bcert * certification + boutdoors * outdoors + bprice * price /
U(E) = bcages * cages + bcert * certification + boutdoors * outdoors + bprice * price /
U(None) = b0[-3]                  ? you need to use a reasonable prior for the constant, it cannot be 0 as it would make the None alternative the most preferred option
$

To answer your other questions:

* There exist billions of possible designs. It takes Ngene very long to evaluate all possible designs, therefore it never terminates and you simply stop Ngene when after some time it cannot find a better design. It is not possible to find the BEST design since there are just too many possibilities, but it can find a VERY GOOD design. You do not need to best, very good is good enough.

* The optout alternative is not shown since it has no attributes, but you can add it in the formatted scenarios by using the right-mouse click to manually add another column for the optout alternative.

* You have a cages attribute and an outdoors attribute. But when they are in cages, they are clearly not outdoors. You could merge these into a single attribute that has levels "cages, free-range, ...". You can also impose constraints on the design, for example ;reject: A.cages=1 and A.outdoors = 1.

* You can include interactions at the design stage, e.g. binteraction * certification.dummy[1] * price, which allows Ngene to optimise for estimating interaction effects at the design stage. If you do not include interactions during the design phase then you will usually still be able to estimate them, but at a lower efficiency.

* You are treating price as a numerical (continuous) variable in your syntax by only specifying a single coefficient, i.e. by not dummy coding. If you want more levels, you can use price[4,4.5,5,5.5,6,6.5,7,7.5,8], which can also be written as price[4:8:0.5].

Michiel

[Mayaba]

Dear Michael,

Thank you very much for a quick response. I will make some changes and run the syntax again, and report back the progress I'm making.