Efficient Design

[claudiab]

Hello,
I am designing an unlabeled CE with two product alternatives and an “opt-out” alternative. I am currently working on an efficient design, which will be used in a pilot study to generate the priors for the final Bayesian design. In the efficient design I am not going to define priors for the attributes (expect for the price attribute), since from the literature it is not clear how the levels of these attributes effect consumers’ preferences for the product in question. Below is the code I used:
design
;alts = Alt1*, Alt2*, Alt3
;rows = 12
;eff = (mnl,d)
;model:
U(Alt1) = b1.dummy[0|0]*loc[2,1,0]+b2.dummy[0|0|0]*hops[3,2,1,0]+b3.dummy[0]*org[1,0]+b4[-0.00001]*price[7.99,8.99,9.99,10.99,11.99]/
U(Alt2) = b1.dummy*loc +b2.dummy*hops +b3.dummy*org +b4*price
$

This is the first time I create an efficient design with Ngene. The Ngene manual and this forum helped me a lot, but I have a few questions:
1) As soon as I run the code, I get a warning: “One or more attributes will not have level balance with the number of rows specified: alt1.price, alt2.price”. As far as I know, attribute level balance requirement can be relaxed in the case of efficient designs. However, I was wondering whether attribute level unbalance could effect the efficiency of my priors.
2) After a few minutes, I obtain a design with a low D-error, but with an S-estimate higher than 4000000000. Is this value of the S-estimate due to the use of none or very small priors? I tried to use bigger priors and I had much better S-estimates.
3) I obtain the most “ D-efficient” design using a number of rows equal to 12, instead of 10. However, before obtaining the 12 rows design, I had this message: “A valid initial random design could not be generated after approximately 10 seconds. In this time, of the XXXXXX attempts made, there were 0 row repetitions, XXXX alternative repetitions, and XXXXXX cases of dominance. There are a number of possible causes for this, including the specification of too many constraints, not having enough attributes or attribute levels for the number of rows required, and the use of too many scenario attributes. A design may yet be found, and the search will continue for 10 minutes. Alternatively, you can stop the run and alter the syntax”.
Does this message suggest there is a problem with the 12 rows design?

I thank you in advance for you kind attention and availability.
Claudia

[Andrew Collins]

Hi Claudia

1. Yes, attribute level balance can be relaxed, and in any case, with the default swapping algorithm, Ngene will generate as close to level balance as possible. It should not make much difference with the efficiency of your design, maybe just a little, as an unbalanced attribute will not include one of the end points, and wider ranges tend to lead to more efficient designs. The difference should be quite inconsequential.

2. Yes, if you look at equation 7.9 on page 93 of the manual, you will see that as the prior approaches zero, the s-estimate approaches infinity.

3. The problem is that you have specified the design to check for dominance, alternative repetitions, etc, but have only specified signs for price. Ngene uses the signs to determine if more of an attribute (or a specific dummy coded level relative to another level) is better or worse. Without the signs, the two alternatives in a choice task will tie on the zero prior attributes, and price will always lead to dominance, unless the prices are equal (which is bad!). You will notice that the dominance XXXXX value is the large one in the error message, and the price is tied in the designs that are generated.

Do you know even the sign of the attribute levels? If so, then do specify them, just with a prior close to zero. If the sign is truly unknown, probably best to remove the *'s from ;alt. This won't then check for dominance. It may result in alternative or row repetitions, so check the generated design carefully (including for repeated rows with the order of the alternative repeated). If the best design has problems, perhaps an earlier design in the iteration history does not.

Hope this helps.
Andrew

[claudiab]

Andrew,

thank you very much for the explanation. It helps a lot!

Claudia