choice-metrics.com

Hello,

I’m currently faced with a problem that I have not yet been able to solve using Ngene: I have (for each respondent in a survey) a reported trip from a travel diary, with all its attributes, and the attributes of the alternative mode. For example, the respondent has reported a car trip from A to B with its attributes, and the attributes of the rail alternative have been determined by myself (or the other way around, if the reported trip was a rail trip).

Now, what I’d like to do is generate a “pivot” (not sure whether this is the correct term to use) efficient design from these data (for a mode choice experiment), without having to keep the attributes for one alternative constant. That is, I’d like to vary the attributes around the given trip and its mode alternative, without the respondent being faced with his actual reported trip as one of the shown alternatives.

Here’s a simplified example for illustration:

Reported car trip: travel time 20 minutes, cost 10 dollars.
Rail alternative determined by me: travel time 25 minutes, cost 10 dollars.

Attribute level variations to be used in the design:
- travel time -10%, +5%, +10%
- cost -10%, +5%, +10%

That is, the resulting design should contain lines such as:

car t.t. car c. rail t.t. rail c.
-10% +10% +10% -5%
+10% -10% +10% +10%
etc.

Which, for this specific respondent, would yield the following attribute combinations:

car t.t. car c. rail t.t. rail c.
18 11 27.5 9.5
22 9 27.5 11
etc.

(Respondents with different reported attributes would evidently be faced with different choices, according to the percentage changes.)

I tried implementing this using the following formulation:

U(car) = b1[-0.4] * car_tt.piv[-10%,+5%,+10%] + b2[-0.8] * car_c[-10%,+5%,+10%]
U(rail) = b1 * rail_tt[-10%,+5%,+10%] + b2 * rail_c[-10%,+5%,+10%]

However, to be able to use x.piv, Ngene logically requires x.ref to be stated somewhere, so this is obviously not the correct way to do this.

Do you have any idea on how this could be accomplished? Perhaps by multiplying the reference attributes into the parameter priors and re-formulating the attributes? That’s the best idea I’ve come up with so far, but I’m afraid I might be missing something. What I mean is something like:

U(car) = b1[-8] * car_tt_factor[0.9,1.05,1.1] + b2[-8] * car_c_factor[0.9,1.05,1.1]

(That is, b1 is now replaced by b1 times the reference value for travel time (let’s suppose 20 is the sample average here), and the percentage changes have been replaced by factors; same for cost, etc.)

This would allow me to simply multiply the reference attributes by the factors resulting from the design, thus leading to different choice situations for the various respondents. As I said though, I’m not quite sure if that’s proper methodology. I’m aware that some efficiency will be lost because of the different reported trips (i.e., the design that’s efficient for the 20 minutes reference might not be for 30 minutes), however could this be counteracted by a segregation into classes (i.e., one design for short, one for medium length, one for long trips)?

Does anyone have another idea on this might be accomplished? Any advice would be much appreciated!

Thanks a lot in advance and best regards

Claude Weis

Dear Claude,

In Ngene this reference alternative is always the status quo alternative at this stage, so it is fixed. It is an interesting idea to have varying reference attribute levels, which is something we will investigate to include.

For the moment, your best option is to (as you suggest) use segments. For example:

Code: Select all

Design
;alts(short) = car, train
;alts(long) = car, train
;rows = 9
;eff = F1(mnl, d)
;fisher(F1) = des1(short[0.4]) + des2(long[0.6])

;model(short):
U(car)   = time[-0.4] * TTCAR[10,20,30]       + cost[-0.8] * COSTCAR[5,10,15] /
U(train) = time       * TTTRAIN[20,30,40]     + cost       * COSTTRAIN[4,8,12]

;model(long):
U(car)   = time[-0.4] * TTCAR[30,40,50]       + cost[-0.8] * COSTCAR[10,15,20] /
U(train) = time       * TTTRAIN[40,60,80]     + cost       * COSTTRAIN[8,14,20]

$

With this, you generate two designs, one for short distance and one for long distance. You can create as many segments as you like.

Dear Michiel,

Given that this post was discussed several years ago, I would like to reopen it to check if there is a new way.
I need to make some attributes pivot around the respondents' answers without defining any status quo alternative. In the previous post, you mentioned that segmentation without any pivots could be the best option. However, you emphasized that there would be some possibilities in the future to add this feature to Ngene. Reading the Ngene manual and some other posts in the forum, I have not found any solution for this. I was wondering if there is a way to design pivoted attributes without having the status quo alternative?

I also have another question. Is it possible to design a set of choice experiments when there are only context variables (attributes)? Let me give an example to clarify it. We have two alternatives: accepting or rejecting an offer. The attributes are price, day of the week, time of the day. As seen, these attributes can be considered as context variable as they do not vary among alternatives. In other words, the attribute levels are the same for both alternatives (accepting and rejecting) in each choice set. Can the following utility functions be used in the design:

U(accept) = A[-0.1] * Price [2,4,6] + B.dummy [0.2] * Day [1,2] + C.dummy [0.3|-0.2] * Time [1,2,3]
U(reject) = ASC


Thanks for your support.
Peyman.

There are two ways to create individual-specific choice experiments:

1) Create a pivot design with absolute or relative pivots around reference levels
2) Create a library of designs around different reference levels.

Option 1) can be done in two different ways. [a] The first is what we describe in the Ngene manual and requires defining a separate reference alternative. [b]The second is simply generating a design with regular levels and then manually convert to absolute or relative pivots. This approach does not require defining a separate reference alternative. Option 1) has limitations because pivoting with dummy of effects coded variables is unclear and these designs require a significant amount of logic in the survey instrument to make sure that attribute levels make sense (e.g. relative pivots cannot be used with a zero reference level, absolute pivots cannot be used if values can become unexpectedly positive/negative) and easy to read (e.g. presented levels require smart rounding off).

Option 2) provides more flexibility, it can handle dummy/effects coded variables, and it does not require complicated logic or rounding off in the survey instrument. What it does require is creating different versions of the survey. In some cases, where many attributes are pivoted around reference variables, you may have to create many designs. For example, if you have travel time classes {low,medium,high}, and toll cost classes {low,medium,high}, then you need to create 9 different designs, and if you add another attribute with 3 classes you have to generate 27 designs. Survey instruments can generally handle different versions of the choice experiment (or survey) easily and while generating many different designs may be a bit of work, implementation is relatively straightforward.

In the past few years I have assisted several people in creating surveys where attribute levels are respondent specific, and I have come to the conclusion that Option 2 works best in all situations, while Option 1b works fine in case all attributes are continuous. Designs for these options can be generated with the existing version of Ngene.

Regarding your second question, context/scenario variables can be added to either the accept or the reject alternative, so the utility function that you specify is appropriate.

Michiel

Hi Michiel,

Many thanks for your response.

I would like to extend my second question. Assuming a taxi driver drops off a passenger and needs to select one of these three options: waiting at the drop-off location to receive next ride request, cruising based his experience to find a new request, and following the application recommendations. The attributes are the time of day (TD) and location (L) which are context variables. As you previously mentioned, we can add the context attributes to J-1 utility functions. The issue is that one of the alternatives also have some levels. Waiting can be divided into three levels (0,10 min, 20 min). I was wondering if I need to define a single utility function for each level (as follows) or another method is applicable?

Unique utility function for each level:

U(wait0) = td.dummy*TD[1,2] + l.dummy*L[1,2]
U(wait10) = td.dummy*TD[1,2] + l.dummy*L[1,2]
U(wait20) = td.dummy*TD[1,2] + l.dummy*L[1,2]
U(cruising) = td.dummy*TD[1,2] + l.dummy*L[1,2]
U(applicaton) = ASC

If it is right, how can I interpret the estimated parameters?

Many thanks for your massive support.
Best,
Peyman.

Perhaps you could consider something like this:

Code: Select all

design
;alts = waiting, cruising, application
;rows = all
;fact
;model:
U(waiting)     = wait * WAIT[0,10,20]           ? waiting time
               + td_wait.dummy[0] * TD[1,2]     ? time of day with alternative-specific parameter
               + loc_wait.dummy[0] * LOC[1,2]   ? location with alternative-specific parameter
               + i1 * WAIT * TD.dummy[1]        ? interaction term between wait and time of day
               + i2 * WAIT * LOC.dummy[1]       ? interaction term between wait and location
               /
U(cruising)    = cruise                         ? alternative-specific constant
               + td_cruise.dummy[0] * TD[TD]    ? time of day with alternative-specific parameter
               + loc_cruise.dummy[0] * LOC[LOC] ? location with alternative-specific parameter
               /
U(application) = app                            ? alternative-specific constant
$


Note that TD and LOC are scenario/context variables, therefore the levels for TD and LOC need to be the same across alternatives waiting and cruising, this is done via TD[TD] and LOC[LOC], see the Ngene manual on scenario variables.

In this model, all parameters are identifiable and can be interpreted meaningfully.
The constants "cruise" and "app" indicate the preferences of cruising and application relative to waiting.
Coefficient "wait" indicates how the preference for waiting varies by the amount of waiting time.
Coefficient "td_wait" indicates how the preference for waiting varies by time of day.
Coefficient "td_loc" indicates how the preference for waiting varies by location.
Coefficient "i1" essentially indicates how the sensitivity to waiting time (i.e. coefficient "wait") varies by time of day.
Etc.

You do not necessarily need interaction terms i1 * ... and i2 * ... so you could leave them out, all other components you would need.

We estimated a similar type of model in this paper:

De Bekker-Grob, Bergstra, Bliemer, Trijssenaar-Buhre, Burdorf (2015) Protective behaviour of citizens to transport accidents involving hazardous materials: a discrete choice experiment applied to populated areas nearby waterways. PLoS ONE 10(11):e0142507.

Please note that you are posting this question in a post on pivot designs, please create a new post for new questions.

Michiel

Hi Michiel,

Many thanks for your reply.

Regarding the pivot design, I was wondering if it is possible to impose any constraint when there are different segments/designs? If so, how can we define the alternatives of each segment in the syntax of con/require property?

Thanks for your attention.
Best,
Peyman.

No you cannot impose constraints when there are multiple models/segments/designs specified, this is currently not supported by our algorithms. The library of designs option works best in this case, which allows you to impose constraints on each design separately.

Michiel

May I ask you what you mean by the library of design? You mean I could design each segment separately in Ngene?
Peyman.

Yes, see my answer above where I described a library of designs (option 2).

Michiel