Hi all Ngeners
I am working on a design for a choice experiment with the following properties...
- Three alternatives (two plus one status quo (SQ))
- 4 attributes, with 3, 4, 3 and 4 levels respectively
- The SQ is defined by the same attributes but the levels are fixed - the SQ gives a fixed utility.
- The levels in the SQ are fixed so that there can be both better and worse scenarios. The SQ is defined by the second worse levels on all attributes except for the cost, which is zero.
- It is not relevant with an alternative without improvement in any attribute and a zero or positive cost.
I have some issues that I really need some advice on...
- I have tried to use the ;require command to secure that my SQ has the correct levels. The problem is that Ngene mostly hangs up and I have to restart the software. If I reduce the number of candidates quite a lot (e.g.=10) it sometimes works but it is not really stable. It does not feel okay to reduce the number of candidates that much! Any other suggestions?
- I can of course just use a constant for the SQ alternative (set the constant equal to the sum of priors and attribute levels), but is that in any way problematic? I have used the ;reject command to get rid of "dominating" alternatives but I don't know if this is a good approach.
- If I use a constant for the SQ and the Bayesian approach, should I calculate the constant utility by adding the "means"? Without the Bayesian approach it is straightforward to just "add the priors".
Please, any advice and/or suggestions are very welcome!
Below you find my syntax
Design
;alts=A*,B*,SQ
;rows=8
;alg=mfederov(candidates=100)
;eff=(mnl,d,mean)
;con
;reject:
A.clear<=1 and A.fish<=1 and A.bottom<=1,
B.clear<=1 and B.fish<=1 and B.bottom<=1,
A.clear>1 and A.fish=1 and A.bottom=1 and A.cost=0,
A.clear=1 and A.fish>1 and A.bottom=1 and A.cost=0,
A.clear=1 and A.fish=1 and A.bottom=2 and A.cost=0,
B.clear>1 and B.fish=1 and B.bottom=1 and B.cost=0,
B.clear=1 and B.fish>1 and B.bottom=1 and B.cost=0,
B.clear=1 and B.fish=1 and B.bottom=2 and B.cost=0
;require:
SQ.clear=1,
SQ.fish=1,
SQ.bottom=1,
SQ.cost=0
;model:
U(A)=b2.dummy[(u,0.2,0.4)|(u,0.1,0.3)]*clear[2,1,0]
+b3.dummy[(u,0.2,0.4)|(u,0.1,0.3)|(u,0,0.1)]*fish[3,2,1,0]
+b4.dummy[(u,0.1,0.3)|(u,0,0.1)]*bottom[2,1,0]
+b5[(n,-0.004,0.002)]*cost[0,30,50,70]
/
U(B)=b2*clear+b3*fish+b4*bottom+b5*cost
/
U(SQ)=b1[0]
+b2*clear+b3*fish+b4*bottom+b5*cost
$
Status quo w. fixed attribute levels
Moderators: Andrew Collins, Michiel Bliemer, johnr
14 posts
• Page 1 of 2 • 1, 2
Status quo w. fixed attribute levels
by laspen » Mon May 19, 2014 11:38 pm
- laspen
- Posts: 2
- Joined: Thu May 15, 2014 1:08 am
Re: Status quo w. fixed attribute levels
by johnr » Fri May 23, 2014 9:19 am
Hi
The problem you describe is due to your model not being identified. It is the same problem as described by by jmspi » Thu May 22, 2014 12:30 pm so please forgive me if I attempt to answer both posts here.
The problem is that dummy/effects codes are designed to provide estimates of effects relative to some base level (the only difference is in how you represent that base level). Both coding structures require that the levels, including the base level, vary over all alternatives. In specifying the utility functions in the fashion that you have, you not doing this. By fixing the base levels in the SQ alternative for all attributes, each attribute is acting as ASCs in the SQ utility function, and hence you have multiple ASCs for the one alternative - the base level of the codes are perfectly confounded with the SQ alternative - and hence the other effects you are trying to detect are not relative to the base level, but relative to the SQ alternative! The problem then is that an attribute is not just relative to its own base level, but to the base levels of all other alternatives as defined in the SQ alternative.
Note that if you let any one of the levels vary in the SQ alternative, then the model will work simply because the effects in the non SQ alternatives are then being compared to the SQ alternative which is varying (by the attribute which is allowed to vary), which will approximate the need that the base also varies over alternatives (this is because the base levels are perfectly confounded with the SQ level due to the fact that you fixed them that way, and hence the base utility will vary with the one attribute that is allowed to vary).
Hence, your model is acting as if it has multiple ASCs, not just b1, and hence the model is not identified. The problem and solution is mentioned in
Cooper, B., Rose, J.M. and Crase, L. (2012) Does anybody like water restrictions? Some observations in Australian urban communities, Australian Journal of Agricultural and Resource Economics, 56(1), 61-51
which I urge you to read.
Unfortunately, the issue comes down to the fact that what you are attempting to do violates the identification conditions of the model, and would do so even if you were to collect data and attempt to estimate a model this way - that is, it is not an Ngene error. In fact this is in some ways good news for Ngene – it would be worse if it did actually find a design!
John
The problem you describe is due to your model not being identified. It is the same problem as described by by jmspi » Thu May 22, 2014 12:30 pm so please forgive me if I attempt to answer both posts here.
The problem is that dummy/effects codes are designed to provide estimates of effects relative to some base level (the only difference is in how you represent that base level). Both coding structures require that the levels, including the base level, vary over all alternatives. In specifying the utility functions in the fashion that you have, you not doing this. By fixing the base levels in the SQ alternative for all attributes, each attribute is acting as ASCs in the SQ utility function, and hence you have multiple ASCs for the one alternative - the base level of the codes are perfectly confounded with the SQ alternative - and hence the other effects you are trying to detect are not relative to the base level, but relative to the SQ alternative! The problem then is that an attribute is not just relative to its own base level, but to the base levels of all other alternatives as defined in the SQ alternative.
Note that if you let any one of the levels vary in the SQ alternative, then the model will work simply because the effects in the non SQ alternatives are then being compared to the SQ alternative which is varying (by the attribute which is allowed to vary), which will approximate the need that the base also varies over alternatives (this is because the base levels are perfectly confounded with the SQ level due to the fact that you fixed them that way, and hence the base utility will vary with the one attribute that is allowed to vary).
Hence, your model is acting as if it has multiple ASCs, not just b1, and hence the model is not identified. The problem and solution is mentioned in
Cooper, B., Rose, J.M. and Crase, L. (2012) Does anybody like water restrictions? Some observations in Australian urban communities, Australian Journal of Agricultural and Resource Economics, 56(1), 61-51
which I urge you to read.
Unfortunately, the issue comes down to the fact that what you are attempting to do violates the identification conditions of the model, and would do so even if you were to collect data and attempt to estimate a model this way - that is, it is not an Ngene error. In fact this is in some ways good news for Ngene – it would be worse if it did actually find a design!
John
- johnr
- Posts: 171
- Joined: Fri Mar 13, 2009 7:15 am
Re: Status quo w. fixed attribute levels
by laspen » Fri May 23, 2014 9:01 pm
John,
many thanks for your response and the reference to the paper. The paper was very nicely written and certainly gave new insights. Still…
I understand (I hope) what you mean, but on the other hand I suspect that we are talking about slightly different issues. In our case, the status quo levels of the attributes are present in the other alternatives as well. In the paper you referred to, you state that “For the reporting attribute, the “no” level appears both in the SQ and the SP alternatives, and hence, a standard effects coding structure was applied in this case with “yes” coded 1 and “no” coded -1.”
So, the question is then if I should be able to have fixed levels in the status quo if the levels also exists in the other alternatives? If that is the case, I believe that is what I have tried without success. Or is it so that I need to introduce the "hybrid" coding structure also in my case?
My (perhaps wrong) idea is that it would be good to tell Ngene that I have status quo levels that also exist in the other alternatives, although fixed in the SQ. When I read the Ngene manual I get the impression that this is how to think about it. My intuition is that the status quo contains information besides just being a constant.
Perhaps wrong, but what I also do in the syntax is to get rid of alternatives that have all identical attribute levels as in the status quo although with a positive cost (these scenarios would be trivial). In addition, I want to get rid of alternatives with identical levels as in status quo, or better, while having zero cost (I now realize that this is perhaps not necessary).
In addition, if I am doing wrong, how come that Ngene gives me a design in some cases (e.g. if I decrease the number of candidates) but not in other. Specifically, you say that “In fact this is in some ways good news for Ngene – it would be worse if it did actually find a design!” But I do find a design when I set candidates=10.
I feel a little bit embarrassed to reveal my own stupidity with my questions, but for some reason I can’t get this straight. Any help is really appreciated.
many thanks for your response and the reference to the paper. The paper was very nicely written and certainly gave new insights. Still…
I understand (I hope) what you mean, but on the other hand I suspect that we are talking about slightly different issues. In our case, the status quo levels of the attributes are present in the other alternatives as well. In the paper you referred to, you state that “For the reporting attribute, the “no” level appears both in the SQ and the SP alternatives, and hence, a standard effects coding structure was applied in this case with “yes” coded 1 and “no” coded -1.”
So, the question is then if I should be able to have fixed levels in the status quo if the levels also exists in the other alternatives? If that is the case, I believe that is what I have tried without success. Or is it so that I need to introduce the "hybrid" coding structure also in my case?
My (perhaps wrong) idea is that it would be good to tell Ngene that I have status quo levels that also exist in the other alternatives, although fixed in the SQ. When I read the Ngene manual I get the impression that this is how to think about it. My intuition is that the status quo contains information besides just being a constant.
Perhaps wrong, but what I also do in the syntax is to get rid of alternatives that have all identical attribute levels as in the status quo although with a positive cost (these scenarios would be trivial). In addition, I want to get rid of alternatives with identical levels as in status quo, or better, while having zero cost (I now realize that this is perhaps not necessary).
In addition, if I am doing wrong, how come that Ngene gives me a design in some cases (e.g. if I decrease the number of candidates) but not in other. Specifically, you say that “In fact this is in some ways good news for Ngene – it would be worse if it did actually find a design!” But I do find a design when I set candidates=10.
I feel a little bit embarrassed to reveal my own stupidity with my questions, but for some reason I can’t get this straight. Any help is really appreciated.
- laspen
- Posts: 2
- Joined: Thu May 15, 2014 1:08 am
Re: Status quo w. fixed attribute levels
by Michiel Bliemer » Sat May 24, 2014 2:48 pm
I don't think you are asking stupid questions, status quo alternatives with dummy or effects coded variables are just very tricky. I can see your point that the reference levels appear in alternatives A and B, so there may perhaps not be a problem. Alternative SQ does not include all levels for the dummy coded variable, so there may be a potential problem. However, if you indicate that Ngene does generate a design, maybe the model is estimable.
I am just thinking out loud here, perhaps this is going nowhere, but let's try to rewrite your model. Your model is the following (for convenience I have used only the means of the Bayesian priors):
U(A) = b2.dummy[0.3|0.2]*clear[2,1,0] + b3.dummy[0.3|0.2|0.05]*fish[3,2,1,0] + b4.dummy[0.2|0.05]*bottom[2,1,0] + b5[-0.004]*cost[0,30,50,70] /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[0] + b2*clear + b3*fish + b4*bottom + b5*cost
I can rewrite the model such that the SQ alternative includes only reference levels (i.e., I am setting clear=1, fish=1, and bottom=1 as base levels, and adjusting the priors accordingly):
U(A) = b2.dummy[0.1|-0.2]*clear[2,0,1] + b3.dummy[0.25|0.15|-0.05]*fish[3,2,0,1] + b4.dummy[0.15|-0.05]*bottom[2,0,1] + b5[-0.004]*cost[0,30,50,70] /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[-0.3] + b2*clear + b3*fish + b4*bottom + b5*cost
In the multinomial logit model, it is only the differences in utility that matter, so I can subtract any numbers from all utility functions and get an identical model. Let us subtract (b2*clear[1] + b3*fish[1] + b4*bottom[1] + b5*cost[0]) from each utility function. Noting that in dummy coding the reference level has zeros attached to each of the attributes, this results in:
U(A) = b2.dummy[0.1|-0.2]*clear[2,0,1] + b3.dummy[0.25|0.15|-0.05]*fish[3,2,0,1] + b4.dummy[0.15|-0.05]*bottom[2,0,1] + b5[-0.004]*cost[0,30,50,70] /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[-0.3]
This removes the necessity to include any constraints for the SQ attribute levels. The resulting model is a regular model that seems estimable, as long as both alternatives A and B have all levels appearing for the attributes clear, fish, and bottom.
As said, I am just thinking out loud, but if I did not make any mistakes, then your model may indeed be estimable as long as your constraints on the levels in alternatives A and B are not so strict such that they permit each attribute level appearing in the design.
I am just thinking out loud here, perhaps this is going nowhere, but let's try to rewrite your model. Your model is the following (for convenience I have used only the means of the Bayesian priors):
U(A) = b2.dummy[0.3|0.2]*clear[2,1,0] + b3.dummy[0.3|0.2|0.05]*fish[3,2,1,0] + b4.dummy[0.2|0.05]*bottom[2,1,0] + b5[-0.004]*cost[0,30,50,70] /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[0] + b2*clear + b3*fish + b4*bottom + b5*cost
I can rewrite the model such that the SQ alternative includes only reference levels (i.e., I am setting clear=1, fish=1, and bottom=1 as base levels, and adjusting the priors accordingly):
U(A) = b2.dummy[0.1|-0.2]*clear[2,0,1] + b3.dummy[0.25|0.15|-0.05]*fish[3,2,0,1] + b4.dummy[0.15|-0.05]*bottom[2,0,1] + b5[-0.004]*cost[0,30,50,70] /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[-0.3] + b2*clear + b3*fish + b4*bottom + b5*cost
In the multinomial logit model, it is only the differences in utility that matter, so I can subtract any numbers from all utility functions and get an identical model. Let us subtract (b2*clear[1] + b3*fish[1] + b4*bottom[1] + b5*cost[0]) from each utility function. Noting that in dummy coding the reference level has zeros attached to each of the attributes, this results in:
U(A) = b2.dummy[0.1|-0.2]*clear[2,0,1] + b3.dummy[0.25|0.15|-0.05]*fish[3,2,0,1] + b4.dummy[0.15|-0.05]*bottom[2,0,1] + b5[-0.004]*cost[0,30,50,70] /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[-0.3]
This removes the necessity to include any constraints for the SQ attribute levels. The resulting model is a regular model that seems estimable, as long as both alternatives A and B have all levels appearing for the attributes clear, fish, and bottom.
As said, I am just thinking out loud, but if I did not make any mistakes, then your model may indeed be estimable as long as your constraints on the levels in alternatives A and B are not so strict such that they permit each attribute level appearing in the design.
- Michiel Bliemer
- Posts: 1885
- Joined: Tue Mar 31, 2009 4:13 pm
Re: Status quo w. fixed attribute levels
by Michiel Bliemer » Sat May 24, 2014 3:26 pm
If my previous rewriting of the utility functions is correct, then this syntax seems to work (I also added the requirement that the cost levels need to be attribute level balanced):
Design
;alts=A*,B*,SQ
;rows=8
;alg=mfederov(candidates=100)
;eff=(mnl,d)
;con
;reject:
A.clear<=1 and A.fish<=1 and A.bottom<=1,
B.clear<=1 and B.fish<=1 and B.bottom<=1,
A.clear>1 and A.fish=1 and A.bottom=1 and A.cost=0,
A.clear=1 and A.fish>1 and A.bottom=1 and A.cost=0,
A.clear=1 and A.fish=1 and A.bottom=2 and A.cost=0,
B.clear>1 and B.fish=1 and B.bottom=1 and B.cost=0,
B.clear=1 and B.fish>1 and B.bottom=1 and B.cost=0,
B.clear=1 and B.fish=1 and B.bottom=2 and B.cost=0
;model:
U(A) = b2.dummy[0.1|-0.2]*clear[2,0,1] + b3.dummy[0.25|0.15|-0.05]*fish[3,2,0,1] + b4.dummy[0.15|-0.05]*bottom[2,0,1] + b5[-0.004]*cost[0,30,50,70](2,2,2,2) /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[-0.3]
$
Design
;alts=A*,B*,SQ
;rows=8
;alg=mfederov(candidates=100)
;eff=(mnl,d)
;con
;reject:
A.clear<=1 and A.fish<=1 and A.bottom<=1,
B.clear<=1 and B.fish<=1 and B.bottom<=1,
A.clear>1 and A.fish=1 and A.bottom=1 and A.cost=0,
A.clear=1 and A.fish>1 and A.bottom=1 and A.cost=0,
A.clear=1 and A.fish=1 and A.bottom=2 and A.cost=0,
B.clear>1 and B.fish=1 and B.bottom=1 and B.cost=0,
B.clear=1 and B.fish>1 and B.bottom=1 and B.cost=0,
B.clear=1 and B.fish=1 and B.bottom=2 and B.cost=0
;model:
U(A) = b2.dummy[0.1|-0.2]*clear[2,0,1] + b3.dummy[0.25|0.15|-0.05]*fish[3,2,0,1] + b4.dummy[0.15|-0.05]*bottom[2,0,1] + b5[-0.004]*cost[0,30,50,70](2,2,2,2) /
U(B) = b2*clear + b3*fish + b4*bottom + b5*cost /
U(SQ)= b1[-0.3]
$
- Michiel Bliemer
- Posts: 1885
- Joined: Tue Mar 31, 2009 4:13 pm
Re: Status quo w. fixed attribute levels
by Unta » Wed Apr 17, 2019 12:33 am
Dear Ngene users,
thanks a lot for the helpful answers you have already provided in this thread.
The question I have directly relates to John's answer from May 23, 2014.
I am working on a design that is similar to the one used in Cooper, B., Rose, J.M. and Crase, L. (2012) Does anybody like water restrictions? Some observations in Australian urban communities, Australian Journal of Agricultural and Resource Economics, 56(1), 61-51:
The choice experiment has the following properties:
- There are two alternatives and one status quo (SQ)
- The alternatives have 2/4/2/3/3 attribute levels
- The SQ has for each attribute only one attribute level (1/1/1/1/1) describing the current situation.
- for two of the attributes (one of them are the costs) the attribute level of the SQ is not available for the alternatives.
The article above presents a hybrid coding approach where two base levels are created.
While I can see why this approach is also the way forward for me I am unsure about how to operationalize it in Ngene.
Any help, advice and suggestions are highly appreciated.
Many thanks and kind regards,
Christian
thanks a lot for the helpful answers you have already provided in this thread.
The question I have directly relates to John's answer from May 23, 2014.
I am working on a design that is similar to the one used in Cooper, B., Rose, J.M. and Crase, L. (2012) Does anybody like water restrictions? Some observations in Australian urban communities, Australian Journal of Agricultural and Resource Economics, 56(1), 61-51:
The choice experiment has the following properties:
- There are two alternatives and one status quo (SQ)
- The alternatives have 2/4/2/3/3 attribute levels
- The SQ has for each attribute only one attribute level (1/1/1/1/1) describing the current situation.
- for two of the attributes (one of them are the costs) the attribute level of the SQ is not available for the alternatives.
The article above presents a hybrid coding approach where two base levels are created.
While I can see why this approach is also the way forward for me I am unsure about how to operationalize it in Ngene.
Any help, advice and suggestions are highly appreciated.
Many thanks and kind regards,
Christian
- Unta
- Posts: 3
- Joined: Mon Mar 18, 2019 10:26 pm
Re: Status quo w. fixed attribute levels
by Michiel Bliemer » Wed Apr 17, 2019 9:50 am
I am not familiar with John's proposed approach, but the issue is merely that you cannot estimate a constant in the SQ alternative when you are fixing one of the dummy coded attribute levels in the SQ alternative since they will be perfectly confounded. In many cases you actually do not need the SQ constant, so simply removing the constant would also resolve the issue.
Michiel
Michiel
- Michiel Bliemer
- Posts: 1885
- Joined: Tue Mar 31, 2009 4:13 pm
Re: Status quo w. fixed attribute levels
by Unta » Wed May 08, 2019 6:11 pm
Dear Michiel,
many thanks for your prompt reply!
During the last weeks I spent more time thinking about the problem and came up with the following Ngene code, which seems to work:
;alts = alt1, alt2, SQ
;rows = 12
;alg = mfederov(candidates=100)
;eff = (mnl,d)
;con
;require:
SQ.ZONE=2,
SQ.INFRA=3,
SQ.FIN=2,
SQ.CONTRACT=0,
SQ.COST=0,
alt2.ZONE<2,
alt2.INFRA<3,
alt2.COST>0,
alt1.ZONE<2,
alt1.INFRA<3,
alt1.COST>0
;model:
U(alt1) = zone.effects[0.0|0.0] * ZONE[0,1,2] + infra * INFRA[1,2,3] + fin.effects[0.0|0.0] * FIN[0,1,2] + contract.effects[0.0] * CONTRACT[0,1] + cost * COST[0,1,2,3] /
U(alt2) = zone.effects * ZONE + infra * INFRA + fin.effects * FIN + contract.effects * CONTRACT + cost * COST /
U(SQ) = zone.effects * ZONE + infra * INFRA + fin.effects * FIN + contract.effects * CONTRACT + cost* COST $
For example, the attribute ZONE has three levels, however, only two of them should appear in the alternative (0,1) and one in the status quo (2).
The same, with different levels though, applies to the attributes COST, and INFRA.
At the moment I am working with ;require: and it seems to work- Ngene produces a design which has constant levels across the attributes in the SQ and varies the attributes in the two alternatives as specified by ;require: .
In that setting I can only include one alternative specific constant (asc) for one of the alternatives and not for the SQ.
I am not sure whether I should include the asc or not.
Again, your help and advice is highly appreciated.
Many thanks and kind regards,
Christian
many thanks for your prompt reply!
During the last weeks I spent more time thinking about the problem and came up with the following Ngene code, which seems to work:
;alts = alt1, alt2, SQ
;rows = 12
;alg = mfederov(candidates=100)
;eff = (mnl,d)
;con
;require:
SQ.ZONE=2,
SQ.INFRA=3,
SQ.FIN=2,
SQ.CONTRACT=0,
SQ.COST=0,
alt2.ZONE<2,
alt2.INFRA<3,
alt2.COST>0,
alt1.ZONE<2,
alt1.INFRA<3,
alt1.COST>0
;model:
U(alt1) = zone.effects[0.0|0.0] * ZONE[0,1,2] + infra * INFRA[1,2,3] + fin.effects[0.0|0.0] * FIN[0,1,2] + contract.effects[0.0] * CONTRACT[0,1] + cost * COST[0,1,2,3] /
U(alt2) = zone.effects * ZONE + infra * INFRA + fin.effects * FIN + contract.effects * CONTRACT + cost * COST /
U(SQ) = zone.effects * ZONE + infra * INFRA + fin.effects * FIN + contract.effects * CONTRACT + cost* COST $
For example, the attribute ZONE has three levels, however, only two of them should appear in the alternative (0,1) and one in the status quo (2).
The same, with different levels though, applies to the attributes COST, and INFRA.
At the moment I am working with ;require: and it seems to work- Ngene produces a design which has constant levels across the attributes in the SQ and varies the attributes in the two alternatives as specified by ;require: .
In that setting I can only include one alternative specific constant (asc) for one of the alternatives and not for the SQ.
I am not sure whether I should include the asc or not.
Again, your help and advice is highly appreciated.
Many thanks and kind regards,
Christian
- Unta
- Posts: 3
- Joined: Mon Mar 18, 2019 10:26 pm
Re: Status quo w. fixed attribute levels
by Michiel Bliemer » Thu May 09, 2019 10:07 am
Since you cannot add an asc to the SQ alternative and it does not make sense adding an asc to only alt1 or alt2, I think the easiest option is to not include any constants and treat all alternatives as unlabelled. If you expect that the SQ alternative will be preferred, ceteris paribus, then this may not be valid.
What you may want to do in your survey is to vary the order of alt1, alt2, and SQ, e.g. (alt1, alt2, SQ), (alt2, alt1, SQ), (SQ, alt1, alt2), and (SQ, alt2, alt1). The order of the alternative would provide you with an additional attribute with which I think you can at least correct for the left-to-right bias in model estimation.
Two more suggestions:
1. I would increase the number of candidates
2. If you know the order of the attributes, e.g. cost=1 has a lower utility than cost=3 and therefore the cost coefficient is negative, and similarly you can set the effects coded coefficients to indicate the order, then you can let Ngene automatically remove dominant alternatives by using ;alts = alt1*, alt2*, SQ*
Michiel
What you may want to do in your survey is to vary the order of alt1, alt2, and SQ, e.g. (alt1, alt2, SQ), (alt2, alt1, SQ), (SQ, alt1, alt2), and (SQ, alt2, alt1). The order of the alternative would provide you with an additional attribute with which I think you can at least correct for the left-to-right bias in model estimation.
Two more suggestions:
1. I would increase the number of candidates
2. If you know the order of the attributes, e.g. cost=1 has a lower utility than cost=3 and therefore the cost coefficient is negative, and similarly you can set the effects coded coefficients to indicate the order, then you can let Ngene automatically remove dominant alternatives by using ;alts = alt1*, alt2*, SQ*
Michiel
- Michiel Bliemer
- Posts: 1885
- Joined: Tue Mar 31, 2009 4:13 pm
Re: Status quo w. fixed attribute levels
by Unta » Mon May 13, 2019 7:28 pm
Thank you very much for your help!
I will proceed as you suggested.
Christian
I will proceed as you suggested.
Christian
- Unta
- Posts: 3
- Joined: Mon Mar 18, 2019 10:26 pm
14 posts
• Page 1 of 2 • 1, 2
Return to Choice experiments - Ngene
Who is online
Users browsing this forum: No registered users and 21 guests