Context - include as interaction effect?

[MartDelft]

Hi all,

I am new to choice experiments and Ngene. I am using it for my thesis at the university. I had a introductory course into choice experiments in which Ngene was used. What I want to do is estimate the willingness to use night trains for travel within Europe. I got 3 alternatives: night train, take plane early in the morning and take a plane the evening before. The attributes I take into account are travel time, travel cost, comfort (only for night train) and interaction between travel time and comfort. Comfort itself will be measured in a separate (kind of) HII experiment. The plane the day before will be a 'base' alternative (utility = 0) and not be varied. Respondents will first be asked to make a choice between night train or taking a plane in the early morning, followed by a question stating 'this choice or the base alternative'. However, I also want to change the context because I think the willingness to take the night train varies with the wanted arrival time. So I have 3 different context settings in my mind: arriving at 08:00, 10:00 and 12:00. This is where my confusion starts.

The lecture slides I have state that context is included in the utility function by using interaction, and that the context is usually effects coded. However, I have a context attribute with 3 levels. Ngene returns that a combination of interaction with a effects coded attribute is not supported. I also noted that this approach is different then the Ngene manual proposes (the design within a design section). So I would like to ask the more experienced people for advice. The Ngene code I have now is as follows (note that I do not have any information about the priors, so assumed 0):

Code: Select all

? Design for main choice experiment
design
;alts = train, plane, planeref
;rows = 12
;eff = (mnl,d)
;model:
U(train) = ASC_train + Btt_train * TT_train[11.67,12.92,14.17] +  Btc_train * TC_train[40,80,120,160]
+ Bcom * Com[1,3,5] + Bctt * TT_train * Com /
U(plane) = ASC_plane + Btt_plane * TT_plane[4.5,4.75] + Btc_plane * TC_plane[60,110,160]
 + Btime*Time[Time]
$


Explanation: ASC is the constant for the alternatives, TT is travel time (in hours), TC is travel costs, Com is the comfort attribute and then in the train utility is a interaction between travel time and comfort.
Regarding including the context: if I need to include the context as interaction, I expect the arrival time influences the base preference for the night train, so the ASC. I tried something like this, which obviously doesn't work, Btime[0|0].effects * Time[0,1,2] * ASC_train. My lecture slides unfortunately do not give a Ngene example for this section.

Some questions:
a) The other approach mentioned by the manual does seem to work. So including a Btime_train[0|0].effects * Time[0,1,2] attribute in both utility functions (for plane Btime_plane), and no interaction. However, how do I interpret it? Lets say when estimating the returned values for Btime are 0.5 (for 08:00, level 0) and 0.75 (for 10:00, level 1). Assume ASC is 1, can you 'add it up' and say the 'base preference' for the train at 08:00 is 1.5? Or is that not correct and should it be interpreted separately from the ASC?
b) When using the approach from the manual, the context changes each choice situation. So task 1: 08:00, 2: 12:00, 3: 12:00, 4: 10:00 etc. I am wondering if that is alright for respondents or just confusing and if it would be preferred to get several questions regarding 08:00, followed by 10:00 and 12:00? Can you just change the order of the tasks in the generated design?
c) A more general question: Ngene now finds a design in 12 rows, I was wondering if there is any benefit of generating a larger design with blocks?

That is it for now, maybe I get more questions in the process. Many thanks!

[Michiel Bliemer]

I think that there are a few issues that need to be resolved first, you need to think carefully about your utility functions.

1. You cannot simply set the utility of an alternative to zero, except when it represents an opt-out (no choice). In your case, the alternative represents a plane trip and therefore has attributes, namely it has a travel time and a travel cost, and perhaps you need to include other attributes (such as an additional hotel night?).

2. Isn't comfort a qualitative variable? You can interact travel time with individual dummy coded levels as I have done below. Level 1 is the base level, so you will be estimating a parameter for the interaction with level 3 and travel time, and another parameter for the interaction with level 5 and travel time.

3. Your flight time is almost fixed, it varies between 4.5 and 4.75, which is a very narrow range. This will likely mean that you cannot estimate the flight time parameter since there is not enough variation in the data. If the destination is fixed (and the flight time is fixed), then flight time ends up in the ASC and you cannot estimate it separately. Alternatively, you can include "destination" as another scenario variable. The destination determines the flight time (and train time), ,which provides more variation in your data and allows you to estimate a flight time parameter.

Code: Select all

design
;alts = train, plane, planeref
;rows = 24
;block = 2
;eff = (mnl,d)
;model:
U(train) =    ASC_train
            + Btt_train        * TT_train[11.67,12.92,14.17]
            + Btc_train        * TC_train[40,80,120,160]
            + Bcom.dummy[0|0]  * Com[3,5,1]
            + Bctt3            * TT_train * Com.dummy[3]
            + Bctt5            * TT_train * Com.dummy[5]
            + Btime.dummy[0|0] * Time[1,2,0] /

U(plane) =    ASC_plane
            + Btt_plane        * TT_plane[4.5,4.75]
            + Btc_plane        * TC_plane[60,110,160] /

U(planeref) = Btt_plane        * TT_plane[4.5,4.75]
            + Btc_plane        * TC_plane[60,110,160] 
$

a) Scenario (context) variables can be included as interactions or as a main effect (in a labelled experiment). You have a labelled experiment and therefore you can include the arrival time scenario as a main effect. If you think that it changes the preference towards train, then you can enter it directly into the train alternative as a dummy coded variable. Or you can put it in the utility functions of the plane alternatives, that is essentially the same. Utility is additive, so yes you can say that the scenario variable changes the ASC. You can also interpret it independently from the ASC and simply say that the scenario variable makes an alternative more or less attractive like any other attribute.

b) You can rearrange the order of the questions manually if you like, that is not be a problem. I can understand that you want to group the scenarios.

c) Yes there is a benefit. A larger design has more variation, which is often a good thing (especially if you are thinking of adding several more interaction effects at a later stage). I generally prefer a slightly larger design (blocked) over a small design. A paper by Sandor and Wedel on heterogeneous designs in the Journal of Marketing Research discusses the potential benefit of a larger design.

Michiel

[MartDelft]

Thanks for your comments.

1. You cannot simply set the utility of an alternative to zero, except when it represents an opt-out (no choice). In your case, the alternative represents a plane trip and therefore has attributes, namely it has a travel time and a travel cost, and perhaps you need to include other attributes (such as an additional hotel night?).

I see what you mean. And it was an approach I first took. However, when discussing this with my supervisor he correctly mentioned that the main trade-off/question I have is between night train and taking a plane early in the morning. So my intention is not to vary the 'taking the plane the day before' alternative. Therefore suggested treating it as a 'base alternative'? In that case my lecture slides indicate that the utility can be 0. And the included ASC (for both train and plane) is the 'base utility difference' compared to the plane the day before?

However, I now found the section in the manual that indeed mentions the reference alternative (page 148/149) that indeed includes a utility function for the non-varying reference alternative. So that would be a better solution? In that case the alternative code would be something like this, now including hotel costs:

Code: Select all

U(planeref) = Btt_plane        * TT_plane[4.5,4.75]
            + Btc_plane        * TC_plane[180,230,280]


2. Isn't comfort a qualitative variable? You can interact travel time with individual dummy coded levels as I have done below. Level 1 is the base level, so you will be estimating a parameter for the interaction with level 3 and travel time, and another parameter for the interaction with level 5 and travel time.

I guess you are right. I made the assumption/simplification that comfort will be linear, including a linear regression model for the HII experiment.

3. Your flight time is almost fixed, it varies between 4.5 and 4.75, which is a very narrow range. This will likely mean that you cannot estimate the flight time parameter since there is not enough variation in the data. If the destination is fixed (and the flight time is fixed), then flight time ends up in the ASC and you cannot estimate it separately. Alternatively, you can include "destination" as another scenario variable. The destination determines the flight time (and train time), which provides more variation in your data and allows you to estimate a flight time parameter.

I forgot quite an important part, the times are based on a trip of around 1100 km (comparable to Amsterdam - Vienna or Milan). The respondents will be told this. So the train times are based on a average speed, including stops, of 80/90/100 km/h. The flight times are based on looking for some flight schedules, generally it takes around 1:45 - 1:55 flying time. The last one I rounded to 2:00. Including the other parts of transferring to the city centre, waiting at the airport etc, results in 4.5 and 4.75. You would suggest making the difference larger, like 4.5 and 5.0?

Thanks for your answer on the other three questions. Very clarifying .

[Michiel Bliemer]

I am not sure what you mean with a "base alternative". There are three types of 'special' alternatives, namely (i) a no-choice alternative with a zero utility, (ii) a status quo alternative that is the same for everyone and has a utility function with fixed attribute levels, and (iii) a respondent-specific reference alternative that has fixed but respondent-specific attribute levels. I am not sure what lecture slides you are referring to, but in the case of a status quo or reference alternative I would not use a zero utility because this would mean that the disutilities of the flight time and cost of the planeref alternative are absorbed by the ASCs, which makes them more difficult to interpret. It is more appropriate to capture time and cost via attributes with parameters generic across the two plane alternatives. The appropriate way is to write out the utility functions and fix the attribute levels, for example:

U(planeref) = Btt_plane * TT_planeref[4] + Btc_plane * TC_planeref[230]

I think that without significantly varying the trip distance it it likely not realistic to vary flight times much. I am not sure whether a range from 4.5 to 5 will be large enough to be able to estimate a statistically significant parameter for flight time, but it may be if your sample size is sufficiently large. The main way to avoid the issue is to consider a trip of 1100km and a trip of, say, 600km, as a scenario variable. But I can understand that this is not what you want to do in your study so you may have to accept that the flight time parameter is difficult to estimate.

Michiel