Huge D-error when incl. att that mimics another att's level

[izakro]

Hi all,
I have created two alternatives labeled design aimed at eliciting the preferences of academics for conferences (in particular, "regular' conferences vs. hub format). I want to have an attribute that mimics another attribute's levels (the attribute duration in the code below). However, this increases the D-error to a scale of hundreds.
Is there any way to avoid this large D-error and still have this feature in the design?
Thanks
R.

Code: Select all

Design
;alts = reg_conf, hub
;rows = 40
;block = 8
;eff = (mnl,d)
;cond:
if(reg_conf.flight_time = [4,8], reg_conf.total_cost =[1500,2000, 2500]) ,
if(reg_conf.flight_time = [12,16,18], reg_conf.total_cost =[3000, 3500]) ,
if(hub.flight_timeh  = [2], hub.total_costh  = [1000,1500]),
if(hub.flight_timeh  = [4], hub.total_costh  = [2000,2500]),
if(reg_conf.total_cost = [2000,2500], hub.total_costh  = [1000,1500])
;model:

U(reg_conf)  =    b [n, 1.008,0.214]
                   + flight_time[n,-0.022, 0.016]* flight_time[4,8,12,16,18](7-9, 7-9, 7-9, 7-9, 7-9 )     
                   + total_cost[n, -0.0006, 0.0004]*total_cost[1500, 2000, 2500, 3000, 3500](7-9,7-9, 7-9, 7-9, 7-9)     
                   + covid.dummy[n,-1,0.04]* covid[0,1]
                   + duration[1]*duration_days[2,4]
                   + particiapnts[n,0.017, 0.0078]*particiapnts[300,600, 900,1200](9-11,9-11, 9-11, 9-11)     
                   + attractiveness[n,0.131, 0.042]*attractiveness[1,2,3,4,5]/

U(hub)   =          flight_time*flight_timeh[2,4] (19-21,19-21)           
                   + total_cost*total_costh[1000,1500, 2000, 2500] (9-11,9-11, 9-11, 9-11)     
                   + covid* covid
                   + duration*[duration_days]
                   + particiapnts*particiapntsh[150,200,250,300](9-11,9-11, 9-11, 9-11)         
                   + attractiveness* attractiveness
$


[Michiel Bliemer]

The issue is that the model that you have specified is not identifiable, caused by the perfectly correlated duration attributes in both alternatives and hence the coefficient "duration" cannot be estimated. This results in a very large D-error.

Duration seems to be a scenario variable that is constant across alternatives. The correct syntax would have been duration * duration_days[duration_days], but this does not resolve the issue.

There are only two ways to include scenario variables:
(i) as a main effect in either "reg_conf" or "hub", but not both. The interpretation would be relative to the other alternative.
(ii) as an interaction effect with another attribute. The interpretation would be that it affects the sensitivity to another attribute.

For example, the script below would work.

Code: Select all

Design
;alts = reg_conf, hub
;rows = 40
;block = 8
;eff = (mnl,d)
;cond:
if(reg_conf.flight_time = [4,8], reg_conf.total_cost =[1500,2000, 2500]) ,
if(reg_conf.flight_time = [12,16,18], reg_conf.total_cost =[3000, 3500]) ,
if(hub.flight_timeh  = [2], hub.total_costh  = [1000,1500]),
if(hub.flight_timeh  = [4], hub.total_costh  = [2000,2500]),
if(reg_conf.total_cost = [2000,2500], hub.total_costh  = [1000,1500])
;model:

U(reg_conf)  =    b [n, 1.008,0.214]
                   + flight_time[n,-0.022, 0.016]* flight_time[4,8,12,16,18](7-9, 7-9, 7-9, 7-9, 7-9 )     
                   + total_cost[n, -0.0006, 0.0004]*total_cost[1500, 2000, 2500, 3000, 3500](7-9,7-9, 7-9, 7-9, 7-9)     
                   + covid.dummy[n,-1,0.04]* covid[0,1]
                   + duration[1]*duration_days[2,4]
                   + particiapnts[n,0.017, 0.0078]*particiapnts[300,600, 900,1200](9-11,9-11, 9-11, 9-11)     
                   + attractiveness[n,0.131, 0.042]*attractiveness[1,2,3,4,5]
                   + attr_dur[0] * attractiveness * duration_days
/

U(hub)   =          flight_time*flight_timeh[2,4] (19-21,19-21)           
                   + total_cost*total_costh[1000,1500, 2000, 2500] (9-11,9-11, 9-11, 9-11)     
                   + covid* covid
                   + particiapnts*particiapntsh[150,200,250,300](9-11,9-11, 9-11, 9-11)         
                   + attractiveness* attractiveness
                   + attr_dur[0] * attractiveness * duration_days[duration_days]
$

Michiel

[izakro]

Thank you so much, Michiel,
Would these two options to resolve the problem hold for generic design as well?

I prefer the first option (incl. duration as a main effect in one alternative "reg_conf").
My question is whether, in the menus presented to respondents, I should manually add the level for this att. for the Hub alternative (equalizing to the level determined by the design)?
Thanks!
R.

[Michiel Bliemer]

The first option, adding a scenario as main effect, is not appropriate/meaningful for unlabelled alternatives, only for labelled alternatives. For unlabelled alternatives, you always need to include scenario variables in an interaction with an attribute.

Note that both options have different behavioural interpretations; as a main effect, it affects the preference towards a labelled alternative, and as an interaction effect, it affects the sensitivity towards the attribute that it is interacted with.

In choice tasks presented to respondents, you usually put the scenario at the top of the choice task. A scenario variable is NOT a characteristic of an attribute, it is a description of the choice context.

Michiel

[izakro]

Thanks a million! Just one last clarification, if respondents receive 3 menus, and in each menu the scenario variable (conference duration) potentially receives a different level (1,2,3 day) will it be possible to estimate the preference for this att. via the MNL (given that is some variation within respondents)?

[Michiel Bliemer]

Scenarios may vary from choice task to choice task within a respondent, and the only way to estimate the model is via the interactions that I explained (or as main effect in a labelled experiment). Even if the scenario varies across choice tasks, its value remains THE SAME ACROSS ALL ALTERNATIVES (even if it varies across choice tasks for the same respondent) and therefore it can only be included in these specific ways in the utility function.

Michiel

[izakro]

Thanks a lot!