How to define priors correctly

[Andrew]

Dear Ngene users,

even after reading ngene manual and some posts here I am not sure how to correctly specify prios in ngene.

For example, how to specify priors for following attributes:

1. price attribute with "20", "40", "60 $"
Assuming respondents prefer 20 to 40 and 60 $

But when it turned out (maybe in a pilot study) Level with 40 $ was chosen more often, that is people are willing to spend more for specific products.

2. location attribute with "resort_A", "resort_B", "resort_C"
Assuming respondents prefer B for sure; but there is an uncertaintity about A and C

3. side effects 1 attribute with "none", "moderate", "severe"
Assuming respondents strongly prefer to have no side effects here

4. 3. side effects 2 attribute with "none", "moderate", "severe"
Assuming respondents could live with moderate side effects; that is side effect 2 is worse than side effect 1 from previous example.

And when there is greater uncertainty about true priors how to specify random distributions for examples above?

I hope somebody may help out. I love Ngene software and I am eagerly to learn more to use it more efficiently.

Best
Andrew

[Michiel Bliemer]

Below some suggestions. Clearly, the values are use are just examples, they have to make sense in your study.

1. I think you are talking about nonlinearities in your utility function. You could use dummy or effects coding.

So for example,

U(alt) = ... b.dummy[0.1|-0.3] * price[40,60,20] + ...

This way, you make $20 the reference level, and with 3 attribute levels you need two dummy variables (the value for $20 is set to zero for dummy coding).
Then the value 0.1 for 40 means that it is preferred over $20, and the value -0.3 means that 60 is less preferred than $20.
However, you also talk about 'for specific productions'. If the product is an attribute in your utility function, you can create an interaction effect, something like b * price * product.

2. You can use Bayesian priors to include uncertainty.

U(alt) = ... + b.dummy[(u,-0.1,0.1)|0.3] * resort[1,2,3] + ...

The value 0.3 means that resort 2 (B) is preferred over resort 3 (C), and since 0.3>0.1, it is also preferred over resort 1 (A).
The Bayesian value (u,-0.1,0.1) means that resort 1 (A) is preferred in 50% of the cases over resort 3 (C), and in 50% of the cases less preferred than C.

3. Again using dummy coding:

U(alt) = ... + b.dummy[-1,-1.5] * side[1,2,0] + ...

The value -1 for moderate (1) and -1.5 for severe (2), with a reference of none (0) mean that there is a strong preference for no side effects.

Hope that helps,
Michiel

[Andrew]

Many thanks, Michiel.

Thanks for clearing this up for me on the basis of my examples.

This really helps.

[Andrew]

I think I need little help with my design regarding priors.
Assuming linearities I coded design with priors from a pilot study.
Looking at design output I noticed middle levels are overlapped in all choice situations, and not compared with any other level.
Even when I effect-code one or two attributes, e.g. b2[0,09|0,02], I encounter same problem with mid levels.
I am fine with a moderate degree of overlap, but then over all attributes.

What did I do wrong here?

Code: Select all

Design
;alts = alt1, alt2
;rows = 18
;block = 2
;eff = (mnl,d)
;model:
U(alt1) = b2[0.24]  * A[0,1,2] +
          b3[0.125] * B[0,1,2] +
          b4[0.116] * C[0,1,2] +
          b5[0.104] * D[0,1,2] +
          b6[0.094] * E[0,1,2] +
          b7[0.107] * F[0,1,2] +
          b8[-0.1]  * G[0,1,2] /
U(alt2) = b2        * A        +
          b3        * B        +
          b4        * C        +
          b5        * D        +
          b6        * E        +
          b7        * F        +
          b8        * G        $



[Michiel Bliemer]

I am not sure what you mean with overlap in the middle levels. When I run that syntax and look at the design, there is some overlap (but not much). and it is over all attributes and over all levels. There will always be some overlap in the design. Could you clarify the problem? Or perhaps post the design with the problem?

If you want to have minimum overlap, you can use an optimal orthogonal design (ood) approach, add ;orth = ood to your syntax and remove ;eff = (mnl,d). This will provide you with a design that has no overlap in any level. However, this may not be the most efficient design.

The reason why it causes usually more overlap in middle levels is that you have specified a linear relationship and the most efficient choice tasks are always such that the attributes across the two alternatives are as far apart as possible. So it will try to generate as many (0,2) and (2,0) as possible, as this provides maximum information. But since your design will by default also be attribute level balanced, there need to be ones as well in the design, so it adds some (1,1). If you would have three choice tasks, then (2,0), (0,2) and (1,1) would be more efficient than (1,0), (2,1), (0,2). So that could be an explanation. You mention that you tried to effects-code the variable, and that should likely lead to less overlap, but as you mention this is not the case?

One thing to note. It seems that you have two unlabelled alternatives, and your priors have a clear sign. You may encounter dominant alternatives, so you may wish to use ;alts = alt1*,alt2*

[Andrew]

Thanks for the fast answer again and helping me out with this.

Here the design output I got from posted design.
When I am not wrong level 1 is only compared with itself over all choice sets, and level 0 only with level 2.

Choice alt1.a alt1.b alt1.c alt1.d alt1.e alt1.f alt1.g alt2.a alt2.b alt2.c alt2.d alt2.e alt2.f alt2.g Block
1 2 0 2 1 1 1 0 0 2 0 1 1 1 2 2
2 0 2 1 2 0 2 0 2 0 1 0 2 0 2 2
3 1 2 0 2 2 0 0 1 0 2 0 0 2 2 2
4 0 1 2 1 2 2 2 2 1 0 1 0 0 0 1
5 1 0 0 0 2 2 0 1 2 2 2 0 0 2 1
6 1 2 2 1 1 2 1 1 0 0 1 1 0 1 2
7 2 2 0 0 0 0 2 0 0 2 2 2 2 0 2
8 1 1 2 2 2 0 2 1 1 0 0 0 2 0 1
9 0 1 1 0 0 1 0 2 1 1 2 2 1 2 1
10 0 0 1 1 1 0 2 2 2 1 1 1 2 0 2
11 1 1 0 0 2 2 2 1 1 2 2 0 0 0 2
12 2 0 2 0 1 1 1 0 2 0 2 1 1 1 2
13 0 1 1 1 1 0 1 2 1 1 1 1 2 1 1
14 2 0 0 2 0 1 1 0 2 2 0 2 1 1 1
15 2 1 1 2 0 2 2 0 1 1 0 2 0 0 1
16 0 0 1 2 1 1 1 2 2 1 0 1 1 1 2
17 1 2 2 0 0 0 0 1 0 0 2 2 2 2 1
18 2 2 0 1 2 1 1 0 0 2 1 0 1 1 1

Your explanation regarding specified linearity makes sense to me and that attributes have to be as far apart as possible for efficiency. But from design above I will not get any information from level 1, right?

[Michiel Bliemer]

That is correct, there is no information collected comparing 1 with 1, only between 0 and 2. But this is essentially what you asked for, as you specified a single parameter for each attribute, indicating a linear relationship. In that case, it is always optimal to only use the outer levels, 0 and 2. So if you indeed expect linear relationships, you could choose to only use levels 0 and 2. But perhaps you have a good reason for using level 1, perhaps because you would like to test for nonlinearities. In that case, you have to specify all coefficients as dummy or effects coded. Ngene will then no longer generate a design comparing 1 with 1, as this will make the coefficient for level 1 unestimable and thereby having an infinite D-error. To summarise, for attributes for which you expect a linear effect, you could use just the outer levels, but for attributes that you expect nonlinearities, add effects-coded priors. Ngene will optimise for the specific model and nonlinearities that you specify. I am just wondering, why are all levels 0, 1, and 2? This seems design coding, not actual attribute levels, or perhaps you intend to estimate all parameters with effects-coding.

[Andrew]

I think I got it, at least I understand way better now. And you are right I would definitely like to test for non-linearities as well. So I gonna use effects-coding. Reason for using 0, 1, and 2 is that all but cost attribute have attribute levels "none", "moderate", "severe". I thought its best to use 0, 1, 2 or 1, 2, 3. This way its easier to check design manually. And I will replace real level names later.