Status quo and avoiding dominant alternatives

[JvB]

Hello,

I am conducting a DCE with each choice set containing 2 alternatives + status quo.
I have three attributes, where each attribute has three levels + status quo levels. The status quo levels are only specific to the status quo and should not be shown in the alternatives. Is there any risk of using them only for status quo but not for the alternatives? I suppose that technically in Ngene it is not a problem create status quo from fixed status quo levels, is it? Furthermore, I am also wondering if these three status quo levels can serve as reference levels for econometric analysis, specially WTP or if it causes problems using them as base/reference levels if the levels are only used for fixed status quo?

The second issue I am facing is, that I am expecting dominant alternatives as all three attributes seem to have a natural preference order (lower price is better than higher price; lower co-payments are better than higher co-payments; shorter time of co-payments is better than longer time of co-payments). I am not pretty sure how to avoid these dominant alternatives already in the design generation process? Or if this is even necessary to deal with them in the design generation process or if it is "enough" to take them into consideration in the analysis?

Appreciating your support!
Best,
J.

[Michiel Bliemer]

Hi,

A few responses:

1. "The status quo levels are only specific to the status quo and should not be shown in the alternatives". Note that a status quo alternative has (fixed) attribute levels, unlike an opt-out alternative, and these levels need to be shown to the respondent to make them clear so that respondents can compare them to the levels of the other alternatives.

2. Ngene can automatically avoid dominant alternatives if the fixed levels are specified in the utility functions using ;alts = alt1*, alt2*, statusquo*, assuming that all alternatives have the same attributes. For this to work, you need to specify the fixed levels in the status quo alternative, see point 1.

3. You could use status quo levels as reference levels I think by using differences in attribute levels. In doing that, you could possibly use different parameters for positive differences and negative differences (like in prospect theory). In most cases, researchers simply use status quo levels as regular levels.

4. "if the levels are only used for fixed status quo". If the attribute level in the status quo is quantitative/continuous then it is fine if the status quo level does not appear as a level in the other alternatives. However, if the attribute is qualitative and therefore dummy/effects coded, then you need to check for identifiability issues since a fixed dummy level that does not appear in other alternatives becomes a constant, so you will not be able to estimate a constant for the status quo alternative. Your D-error will be infinite (or very high) if your model parameters are not identifiable, so you would know pretty quickly.

If you have Ngene syntax that you would like me to check, feel free to post here on the forum.

Michiel

[JvB]

Dear Michiel,

thank you very much for your detailed answers. I really appreciate your support.
One question in order to clarify regarding status quo levels:
Do you see any problem in using two of the fixed status quo levels also for the other alternatives and one only for the fixed status quo? This seems to be necessary, as two attributes are qualitative and therefore dummy/effects coded so not using them for other alternatives will cause identifiability issues.
Furthermore, I am wondering if it is a problem that two attributes have somehow qualitative AND quantitative levels e.g. Attribute 2: status quo level: unlimited; other levels: 6 months, 12 months, 24 months; attribute 3: status quo level: unlimited; other levels: 100€, 200€, 300€)?

Thanks and best,
J.

[Michiel Bliemer]

Yes indeed it is necessary to use the levels of qualitative attributes in the statuos quo alternatives also in the other alternatives to avoid identification issues. Doing so is good and does not cause any issues.

Your second question is an interesting one. I am not sure I understand why a cost/price would be "unlimited", but my first reaction would be to dummy/effects code the cost attribute. This would however make willingness-to-pay computations more complicated. Anoither approach would be to create two attributes and create an interaction effect, something like:

U(alt) = b0 + bcosttype.dummy * COSTTYPE[1,0] + bcost * COSTTYPE * COST[100,200,300]

where COSTTYPE is dummy coded with base level 0 = unlimited and level 1 = regular. Then parameter bcost can be used to compute willingness-to-pay while bcosttype captures the preference between a regular cost and unlimited cost, if that make sense.

Michiel

[JvB]

Dear Michiel,

as I am not sure if I explained well regarding my second question, I´ll try to clarify a bit more:
I have three attributes:
A1 "price as proportion of income": status quo level -->1,5% (only used for status quo); other levels --> 2,5%; 3,5%; 4,5%
A2 "amount of co-payments in €": status quo level --> unlimited amount of co-payments (used for status quo and alternatives); other levels --> co-payments limited to 100€, co-payments limited to 200€, co-payments limited to 300€)
A3 "time period to pay co-payments": status quo level --> unlimited time period of co-payments (used for status quo and alternatives); other levels: --> time period to pay co-payments limited to 6 months, time period to pay co-payments limited to 12 months, time period to pay co-payments limited to 24 months
I could try to create two attributes per each A2 and A3 as you´ve described in your last post (unlimited and limited) and (100€; 200€; 300€). But if it is possible, I would prefer keeping the three mentioned attributes above with one qualitative level and three quantitative levels each. So can you explain what do you mean by "make willingness-to-pay computations more complicated"? Is it just getting more complicated or might it become impossible?

Thank you in advance!

[Michiel Bliemer]

The only way I can think of to use one qualitative level and three quantitative levels is using interactions as I mentioned previously, you will need to split the attribute into a qualitative part and a quantitative part since a variable can only be qualitative OR quantitative but not both. The only other alternative is to assume that all levels are qualitative and dummy code the entire variable. It is definitely possible to compute WTP with a qualitative price/cost attribute, and it is not that difficult, but most analysts prefer to have a single coefficient for the cost attribute that they use in the WTP computation. When using dummy or effects coding for a qualitative attribute, you get multiple coefficients for the cost attribute, which means that you will get multiple WTP values, namely one based on a shift from unlimited to 100, one based on a shift from 100 to 200, and one based on a shift from 200 to 300. This is because dummy/effects coding by definition allows for nonlinear effects, in contrast to the typical linear effect model when assuming quantitative variables.

Qualitative variable with nonlinear effects:
b0 + b1 * X100 + b2 * X200 + b3 * X300

Quantitative variable with linear effect:
b0 + b1 * COST

Michiel

[JvB]

Hi Michiel,

thanks again for your response.
From what you are telling some things that I´d like to make sure that I get you right, cause some poosible issues came to my mind:
- If I split attribute 2 and attribute 3 into one qualitative and one quantitative attribute each and connect them via an interaction I was wondering if it might be an issue to analyse this interaction in the end as the levels of quantitative attribute COPAYMENT will only be shown if the COPAYMENTTYPE level is regular. No level of COPAYMENT attribute will be shown when COPAYMENTTYPE level is unlimited. Furthermore, there would be a prohibiton necessary that COPAYMENTTYPE unlimited and COPAYMENTLENGHT unlimited will never be shown together as this can only be a property of status quo (in status quo bCOPAYMENT parameter would have no levels). I suppose that the minimum sample size will also be bigger if I have this interaction in my design and analysis?
- In your answer to my concerns regarding dominant alternatives you were telling "fixed levels are specified in the utility functions using ;alts = alt1*, alt2*, statusquo*, assuming that all alternatives have the same attributes. For this to work, you need to specify the fixed levels in the status quo alternatives". Did you refer only to dominance with respect to status quo or can NGENE also avoid dominance within the alternatives that occurs because all three attributes have a natural preference order? I´ve also read that some researchers are not worried about dominant alternatives in the design at all but just let the Logit model take up on this in the analysis. Could that also be a proper procedure in your point of view?
- As my alternatives are all reformoptions, I was wondering if I could also model an optout "no reform desired" instead of a status quo. I´ve seen that in literature for some research fields. Is that reliable as well (of course knowing, that I won´t have any specific status quo reference levels for analysis but could analyse WTP etc with a focus only on reform options)
Your opinion and experience is highly appreciated!
Thanks and best,
J.

[Michiel Bliemer]

First, let me say that I have never done such a splitting of an attribute into a qualitative or quantitative part, so I cannot give you defnite answers, I can only give you ideas.

- Yes quantitative values are shown to the respondent when copaymenttype is regular, and Unlimited is shown otherwise. In the data and modelling, it does not matter which level for copayment you would use when Unlimited is shown since it is multiplied by 0, so in the data you could set copayment to 0 or to 100 or to any other finite number.

- You can impose restrictions on the attribute levels such that copaymenttype and copayment length are not unlimited simultaneously

- No the minimum sample size does not increase because you will have the same number of parameters to estimate when you are dummy coding a 4-level attribute.

- I was referring to dominance across all alternatives. Ngene would check dominance between alt1 and alt2, alt1 and statusquo, and alt2 and statusquo. If you would use a constant for the status quo alternative then Ngene can only check dominance between alt1 and alt2.

- The use of status quo alternatives and opt out alternatives is debatable. An optout is required if you are interested in predicting absolute market shares, but it is not needed for computing willingness-to-pay. If the optout is not needed, I would not include it, especially if you worry that many people would choose the optout alternative as selecting this alternative does not provide much information for model estimation. Status quo alternatives are used a lot in certain applied economics fields such as environmental economics where there are typically existing policies to compare with, while in other applied economics fields they are not used much. Some choice modellers say that status quo alternatives may influence the willingness-to-pay and they suggest not including them, while others say that status quo alternatives make the choice task more familiar and therefore reduces hypothetical bias. I think that whatever decision you make, it should be fine.

Michiel

[JvB]

Dear Michiel,

thanks again for your very valuable input!
Maybe I did not get you right but regarding your input "In the data and modelling, it does not matter which level for copayment you would use when Unlimited is shown since it is multiplied by 0, so in the data you could set copayment to 0 or to 100 or to any other finite number.": If I would do it as you´ve written - setting level for copayment to any finite number when unlimited is shown for copayment type - then for computation of WTP I will not be able to use the status quo level of copayment (which would be any finite number multiplied by 0) as the lowest level of my copayment attribute in order to interpolate between this and the highest quantitative level of the attribute, or am I mixing up tings now?

Regarding dominance checking in Ngene "If you would use a constant for the status quo alternative then Ngene can only check dominance between alt1 and alt2.": I suppose that fixed levels for status quo would be defined as a constant so Ngene will not check for dominance between status quo and alt1 and alt2, but only between alt1 and alt2? Does Ngene need coefficients from pretests to check for dominance or is it “enough” to tell the software which is the natural preference order of levels per attribute? I furthermore suppose, that one should always check for dominance in the design and not only let Logit account for it in the analysis?

[Michiel Bliemer]

Let me be more precise:

U(alt) = b0 + bcosttype.dummy[x] * COSTTYPE[0,1] + bcost[y] * COSTTYPE.dummy[1] * COST[100,200,300]

COSTTYPE: 0 = unlimited, 1 = regular (base)

Then:
Contribution of "unlimited copayment" to utility is x.
Contribution of "100 copayment" to utility is 100y.
Contribution of "200 copayment" to utility is 200y.
Contribution of "300 copayment" to utility is 300y.

With these contributions to utility, you can compute the WTP by looking at the differences across levels. Note that WTP for numerical variables and categorical variations is computed and interpreted differently.

To answer your second question, while in model estimation using a fixed level is the same as setting a constant, Ngene does more than just computing a utility based on the provided utility functions. Ngene looks at which attributes and parameters appear in each utility function to detect dominance. If you replace the attribute and parameter with a constant, Ngene can no longer do this. So for dominance checks, you need to specify the full utility function, even if you set attribute levels to a fixed value as otherwise information about which attributes are generic across the alternatives is lost. You should always check for dominance in the design since the logit model is incompatible with choice tasks with dominant alternatives and it may bias your parameters if you do not correct for dominance in your scale parameter, see Bliemer et al. (2017).

Bliemer, M.C.J., J.M. Rose, and C.G. Chorus (2017) Detecting dominance in stated choice data and accounting for dominance-based scale differences in logit models. Transportation Research Part B, Vol. 102, pp. 83-104.

Michiel