choice-metrics.com

Hello,
I am working on a study aimed at determining residents' willingness to pay for an improvement in ecological connectivity.
In this study, I am using 6 attributes plus the payment instrument, which is the contribution. So, I am using two change alternatives and one status quo alternative, however I consider the status quo as the current measure and/or no change. In other words, the status quo is considered the reference.
The attributes are: protected areas, riparian buffer zones, wildlife crossings, type of governance, incentive (for private landowners), and contribution.
After several combinations, I propose the two syntaxes used:
Syntax 1:
Design
;alts = alt1, alt2, sq
;rows = 40
;block = 8
;eff = (mnl,d)
;alg = mfederov
;require:
alt1.cost <> alt2.cost
;reject:
alt1.ap = alt2.ap and alt1.br = alt2.br and alt1.pf = alt2.pf and alt1.gov = alt2.gov and alt1.inc = alt2.inc,
alt1.cost - alt2.cost > 100,
alt2.cost - alt1.cost > 100
;model:
U(alt1) =
b_ap.dummy[0.03|0.06|0.09] * ap[2,3,4,1]
• b_br.dummy[0.20|0.04] * br[3,2,1]
• b_pf.dummy[0.04|0.08] * pf[3,2,1]
• b_gov.dummy[0.04|0.03|0.01] * gov[3,4,2,1]
• b_inc.dummy[0.03|0.06|0.05|0.04] * inc[3,4,5,2,1]
• b_cost[-0.005] * cost[10,25,50,75,100,150,200]
/
U(alt2) =
b_ap.dummy * ap
• b_br.dummy * br
• b_pf.dummy * pf
• b_gov.dummy * gov
• b_inc.dummy * inc
• b_cost * cost
/
U(sq) =
asc_sq[-0.3]
$
Thus D-error = 0.157806
In the different probabilities, there is a status quo line where the probability is equal to 0.425…
Syntax 2: in this syntax, there is no presence of the status quo
Design
;alts = alt1, alt2, sq
;rows = 40
;block = 8
;eff = (mnl,d)
;alg = mfederov
;require:
alt1.cost <> alt2.cost
;reject:
alt1.ap = alt2.ap and alt1.br = alt2.br and alt1.pf = alt2.pf and alt1.gov = alt2.gov and alt1.inc = alt2.inc,
alt1.cost - alt2.cost > 100,
alt2.cost - alt1.cost > 100
;model:
U(alt1) =
b_ap.dummy[0.03|0.06] * ap[2,3,4]
+ b_br.dummy[0.20] * br[3,2]
+ b_pf.dummy[0.08] * pf[3,2]
+ b_gov.dummy[0.04|0.03] * gov[3,4,2]
+ b_inc.dummy[0.03|0.06|0.05] * inc[3,4,5,2]
+ b_cost[-0.005] * cost[10,25,50,75,100,150,200]
/
U(alt2) =
b_ap.dummy * ap
+ b_br.dummy * br
+ b_pf.dummy * pf
+ b_gov.dummy * gov
+ b_inc.dummy * inc
+ b_cost * cost
/
U(sq) =
asc_sq[-0.3]
$
Thus D-error = 0.089286
Regarding the probabilities, there are 5 lines for the status quo that have a probability around 0.41…
My various questions are as follows:
1. Do I need to label my alternatives?
2. Do I need to reduce the number (levels) of my payment instrument, which is the contribution?
3. Do I need to exclude my status quo from the possible choice of my policies (A/B) in order to obtain a low D-error?
4. What role do the "B estimate" and the "S estimate" play?
5. When I do not penalize my status quo, the D-error is high; is this normal?
6. Could you advise me on the approach to adopt?

Thank you in advance for your help. I would like to have a design that would allow me to conduct a pilot survey.

Franck Banalet

A status quo alternative is typically different from an opt-out alternative in that it DOES have attributes and levels. Namely, it has fixed levels of certain attributes. This can be achieved by constraints such as:
;require:
sq.ap = 1, sq.br = 1, ... etc.
;model:
U(sq) = asc_sq + b_ap.dummy * ap + b_br.dummy * br + ... etc

If the status quo levels are all equal to the base level (1), then with dummy coding these values simply become zero and you can omit them in the utility function, as you seem to have done. Your first syntax looks correct, assuming that the base level (1) of the status quo alternative can appear also in alt1 and alt2.

1. You can label them as "Current", "Option A" and "Option B" or something like that. The "Current" alternative has an ASC to account for the status quo effect.

2. No, if you consider cost as a numerical attribute and you are only estimating a single coefficient then you can have as many levels as you want. Note that with the modified Federov algorithm the design often goes to outer levels, so please check the generated design. It is usually recommended to use the default swapping algorithm unless you are unable to formulate your constraints as conditional constraints. I do not understand why you need the long reject constraint, which only rejects if five attributes have exactly the same level, which is extremely unlikely to happen. I think you can remove this constraint. And the other constraints would also work with conditional constraints. For example, you could consider:
;cond:
if (alt1.cost = [10,25], alt2.cost < 150),
if(alt1.cost = [50,75], alt2.cost < 200),
etc.

3. You should not look at the D-error when formulating your model since D-errors are not comparable across different model specifications. You should include the status quo if that is the choice experiment you want to conduct.

4. You can ignore the B estimate, which describes utility balance and is not that important. The S estimate is a sample size estimate, which explains the likely sample size you need if all respondents would face all 40 choice tasks. This assumes that your priors are correct (but since you have not conducted a pilot study, your priors are very unreliable and you should probably ignore the S estimates at this stage).

5. D-errors depend on the model you estimate, and for some models they are higher than for others. You should only worry if the D-error becomes extremely high (e.g. 9999) or Undefined. A D-error below 1 or somewhat above 1 is normal, especially when you have many dummy variables.

6. See above discussion.

Michiel

Hello Michiel,
Thank you for your availability and for the various answers you provided to my questions.

I take note of your comments.
I will do as you suggested and will get back to you if needed.

Thank you very much.

Franck

Hello,

Following my previous concerns, I would like to seek guidance on the following questions:

Referring to my initial syntax, without considering constraints: in this setup, I treat the status quo as the reference level. However, I notice that this option often appears dominant among the choice alternatives. How can I prevent the status quo (current level) from being dominant?
Taking cognitive burden into account, what is the recommended number of choice tasks that respondents can reasonably handle? My questionnaire already seems quite long.
Suppose I set rows = 48 and block = 4, which would likely result in 12 choice tasks per respondent. Would this not be too high?
To what extent is the use of constraints recommended in Ngene?

Thank you in advance for your advice and insights.

Franck

You need to specify the status quo alternative with the actual attributes and reference levels, and then tell Ngene that all alternatives are unlabelled so that Ngene can automatically avoid dominant alternatives.

Assuming that you are using Ngene version 1.X (desktop/Windows), you need:
;alts = alt1*, alt2*, sq*

Further, you need to specify the utility function as I indicated previously. Each of your levels in each alternative would be the actual level of that alternative, not the change from the status quo. For example, if level 1 refers to the status quo level of an attribute, set it to that level for the status quo. You did not specify what the cost is for the status quo alternative, perhaps it is zero? If zero, and level 1 is the status quo level for all categorical attributes, then the status quo alternative will always be dominant because it costs nothing and your priors indicate that all other levels have a positive utility. So perhaps your status quo cost is not zero or your status quo level for the other attributes is not 1.

Your script would look something like the script below, but as said, something is not right here because the status quo alternative would always be dominant with these settings.
Michiel

Hi Michiel,
Thank you very much for your insights.
I am currently using Ngene version 1.6. Also, I had previously omitted to specify the different levels of my attributes, but you correctly inferred them in your explanation.

To address your questions, here is how my status quo is defined:
• Protected areas (ap): 1 = all activities allowed (status quo, reference level)
• Riparian buffers (br): 1 = no new measures (status quo)
• Wildlife crossings (pf): 1 = no new crossings (status quo)
• Governance (gov): 1 = municipal (status quo)
• Financial and non-financial incentives (inc): 1 = no new incentives (status quo)
• Contribution (cost): 0 = no contribution (status quo)

Thus, level 1 represents the status quo for all attributes, except for cost. The other levels therefore correspond to change levels, i.e., [2, 3, 4, 5], depending on the attribute.

Thank you again for your availability and for the suggested script.

Franck

Ok yes. So alt1 and alt2 will be more costly, but will have better levels for the other attributes. That makes sense.

Make sure that you run any script using the modified Federov algorithm for quite some time. Since you have 40 rows, and the candidate set by default has 2000 rows, you would need to run the script at least for 40*2000 = 80,000 iterations.

If you observe that only the outer levels are used for cost, then consider using something like:

b_cost[-0.005] * cost[10,25,50,75,100,150,200](2-6,2-6,2-6,2-6,2-6,2-6,2-6)

The level frequency constraints 2-6 mean that each level should appear between 2 and 6 times across the 40 rows.

Michiel

Hi Michiel,

Thank you again for your insights.

1- I would like to know whether the level frequency constraint (2–6) only applies when the number of rows is greater than or equal to 40. For example, if I use 30 rows or 36, would this constraint still be appropriate, or is there a specific logic to follow? Also, I am not strictly committed to having exactly 40 rows.
2- At what point can I consider that one script is satisfactory and better than another? In other words, what criteria should I use to decide that a design can be selected and used in my pilot study?
3-Which key indicators should I rely on to make a final decision at this stage?

Thank you very much.

Franck

1. With 40 rows and 7 cost levels, with perfect attribute level balance each level would appear 40/7 = 5.7 times on average within the design. So it is probably better to use 4-8 (values around 6) rather than 2-6.

2. A script should properly specify the model as you would most likely estimate it, including using the envisaged coding scheme, constants, interaction effects, etc. Priors would preferably come from a pilot study as there is risk in setting them manually.

3. If you specify the appropriate model then Ngene determines a good efficient design. Since D-errors are not comparable across model and prior specifications, there is not much else to evaluate. The main check is to do pre-testing to make sure that all choice tasks make sense, which includes assessing the attribute levels and their range.

Michiel