Fixed attribute levels for status quo

[yhashida]

I am designing a choice experiment with three alternatives: two wetland restoration alternatives and one status quo (SQ). The two restoration alternatives both improve on the SQ, in which wetland areas will decline without restoration, and all attribute levels will decline in the future. The levels that appear in the SQ are fixed and do not appear in two other alternatives.

My questions are:
1. Is it okay that attribute levels for SQ only appear in SQ and not in other alternatives?
2. If so, how can I code so that attribute levels for SQ (0 in the code below) do not appear in alt1 and alt2?
3. Any other suggestions for improvement.

Below is my attempt. Any insights will be greatly appreciated.

Design
;alts = alt1*, alt2*, sq*
;rows = 16
;block = 4
;eff = (mnl,d)
;alg = mfederov

? FISH: recreational fish harvest FISH=0 reduction, FISH=1 maintain current level, FISH=1 15% increase, FISH = 2 30% increase
? WILD: % of restored land suitable as wildlife habitat WILD=0 no additional habitat, WILD=1 25% suitable, WILD=2 50% suitable, WILD=3 75% suitable
? ACCESS: % of restored land accessible ACCESS=0 no additional access and access declines, ACCESS=1 restricted, ACCESS=2 25%, ACCESS=3 50%
? WALK :miles of boardwalk WALK=0 no additional boardwalk and miles reduced, WALK=1 restricted, WALK=2 1 mile, WALK=3 2 miles
? COST: annual tax increase $10,25,50,75,100,150,200,300

;require:
sq.FISH_sq=0,
sq.WILD_sq=0,
sq.ACCESS_sq=0,
sq.WALK_sq=0


;reject:
alt1.FISH=0 and alt1.WILD=0,
alt1.FISH=0 and alt1.ACCESS=0,
alt1.FISH=0 and alt1.WALK=0,
alt1.WILD=0 and alt1.ACCESS=0,
alt1.WILD=0 and alt1.WALK=0,
alt1.ACCESS=0 and alt1.WALK=0,
alt2.FISH=0 and alt2.WILD=0,
alt2.FISH=0 and alt2.ACCESS=0,
alt2.FISH=0 and alt2.WALK=0,
alt2.WILD=0 and alt2.ACCESS=0,
alt2.WILD=0 and alt2.WALK=0,
alt2.ACCESS=0 and alt2.WALK=0


;model:
U(alt1) = b1.dummy[0.001|0.002|0.003] * FISH[1,2,3,0]
+ b2.dummy[0.002|0.003|0.004] * WILD[1,2,3,0]
+ b3.dummy[0|0.001|0.002] * ACCESS[1,2,3,0]
+ b4.dummy[0|0.001|0.002] * WALK[1,2,3,0]
+ b5[-0.02] * COST[10,25,50,75,100,150,200,300]
/
U(alt2) = b1.dummy*FISH
+ b2.dummy*WILD
+ b3.dummy*ACCESS
+ b4.dummy*WALK
+ b5*COST
/
U(sq) = sq_asc
+ b1.dummy*FISH_sq[1,2,3,0]
+ b2.dummy*WILD_sq[1,2,3,0]
+ b3.dummy*ACCESS_sq[1,2,3,0]
+ b4.dummy*WALK_sq[1,2,3,0]
+ b5*COST_sq[0]
$

[Michiel Bliemer]

No, you cannot include dummy variables whereby one of the levels exclusively appears in the SQ alternative as this would create an unidentifiable model. All attributes with dummy level 0 will collapse into a single constant in the SQ alternative, but you can keep the cost coefficient separate. There is no possibility that SQ is dominant over alt1/alt2, or vice versa, since SQ is always cheaper while alt1/alt2 are always improvements.

Only if you allow level 0 to appear in alt1 and alt2 then you can estimate the model that you specified.

Some other comments:
1. I would use the default swapping algorithm since it maintains attribute level balance.
2. I would increase the number of rows to have more variety in the data, but it is not a must
3. I would increase the number of choice tasks you give to a respondent; only 4 choice tasks is not much
4. When using (near) zero priors, I often recommend dummy coding also the numerical attributes to get more combinations of attribute levels in your data set. You can of course still estimate the model later on with a single coefficient for cost.

Code: Select all

Design
;alts = alt1*, alt2*, sq
;rows = 24
;block = 4
;eff = (mnl,d)

? FISH: recreational fish harvest FISH=0 reduction, FISH=1 maintain current level, FISH=1 15% increase, FISH = 2 30% increase
? WILD: % of restored land suitable as wildlife habitat WILD=0 no additional habitat, WILD=1 25% suitable, WILD=2 50% suitable, WILD=3 75% suitable
? ACCESS: % of restored land accessible ACCESS=0 no additional access and access declines, ACCESS=1 restricted, ACCESS=2 25%, ACCESS=3 50%
? WALK :miles of boardwalk WALK=0 no additional boardwalk and miles reduced, WALK=1 restricted, WALK=2 1 mile, WALK=3 2 miles
? COST: annual tax increase $10,25,50,75,100,150,200,300

;model:
U(alt1) = b1.dummy[0.001|0.002] * FISH[2,3,1]
+ b2.dummy[0.001|0.002] * WILD[2,3,1]
+ b3.dummy[0.001|0.002] * ACCESS[2,3,1]
+ b4.dummy[0.001|0.002] * WALK[2,3,1]
+ b5.dummy[-0.01|-0.02|-0.03|-0.04|-0.05|-0.06|-0.07] * COST[10,25,50,75,100,150,200,300]
/
U(alt2) = b1.dummy*FISH
+ b2.dummy*WILD
+ b3.dummy*ACCESS
+ b4.dummy*WALK
+ b5.dummy*COST
/
U(sq) = sq_asc[0]
$

Michiel

[yhashida]

Thank you for the advice and additional suggestions. They are very helpful.
One clarification about your comment: What do you mean by "you can keep the cost coefficient separate"?

For this survey, I also want to differentiate two scenarios, one assuming the projects happen in survey respondents' neighborhoods, while another scenario assumes they occur somewhere far. The idea is to see if respondents value wetlands differently if they are near or far from them.
I have been planning to repeat the same choice sets for each scenario (i.e., present the same sets of choice tasks) but change the header above each scenario from "local projects" to "non-local projects." The respondents need to answer two sets of identical choice tasks but under a different context (local vs non-local).
Would this be the best approach, or would there be other ways to design the experiment more efficiently?
Any advice would be appreciated.

[Michiel Bliemer]

If you consider COST as a numerical attribute in your design (instead of dummy coding) you can use:

U(sq) = sq_asc + b5*COST_sq[0]

So all dummy code variables with a fixed level would be embedded in the constant while the cost coefficient can still be considered separately.

If you have scenarios, you will need to think about how you will include the scenario variable into your utility functions when you estimate the model. You can put it as a main effect in the status quo if you want to estimate the impact of the scenario on choosing an improvement option. But you are likely interested in understanding the impact of the scenario on the preferences towards the other attributes, in which case you need to add a lot of interactions, see for example the syntax below. If you include these interactions in the utility functions, you can optimise the design simultaneously for also estimating these estimations. But you could also consider just doing what you propose and not optimise the design with the interactions. I think both is fine.

Code: Select all

U(alt1) = b1.dummy[0.001|0.002] * FISH[2,3,1]
+ b2.dummy[0.001|0.002] * WILD[2,3,1]
+ b3.dummy[0.001|0.002] * ACCESS[2,3,1]
+ b4.dummy[0.001|0.002] * WALK[2,3,1]
+ b5.dummy[-0.01|-0.02|-0.03|-0.04|-0.05|-0.06|-0.07] * COST[10,25,50,75,100,150,200,300]
+ i1 * FISH.dummy[2] * scenario[0,1]
+ i2 * FISH.dummy[3] * scenario
+ i3 * WILD.dummy[2] * scenario
+ ...etc
/
U(alt2) = b1.dummy*FISH
+ b2.dummy*WILD
+ b3.dummy*ACCESS
+ b4.dummy*WALK
+ b5.dummy*COST
+ I1 * FISH.dummy[2] * scenario[scenario]
+ i2 * FISH.dummy[3] * scenario[scenario]
+ i3 * WILD.dummy[2] * scenario[scenario]
+ ...etc


Michiel

[yhashida]

Thank you for your help, Michiel. It is very helpful.