labeled design; same attribute different levels for each alt

[Anat Tchetchik]

Dear all!
I have used the below labeled design to obtain prior values for the next stage efficient design.
The attribute: Payment has different levels for each alternative and accordingly being named as: paymenta, paymentb, and paymentc (yet the coefficient is the same: b4)
I have finished collecting the data and want to run it now:
(1) can I use MML for this purpose, or a mixed logit is always preferable even for obtaining the priors..
(2) In the MML (or mixed logit) estimation how do I address the fact that the payment attribute has different levels for each alternative?

this is the design for the prior:
Design
;alts = home, curb, center, optout
;rows = 72
;orth = sim
;block=9
;eff=(mnl,d)
;model:
U(home) = b1+b2*freq(0,1,2)+ b4*paymentA(0,1,2)+b5*burden(0,1,2)/
U(curb) = c1+b2*freq(0,1,2)+ b4*paymentB(0,1,2)+ b5*burden(0,1)+b6*distanceA(0,1,2) /
U(center)= d1+b2*freq(0,1,2)+b4*paymentC(0,1,2)+b5*burden(0,1)+b6*distanceB(3,4,5)+b7*centertype(0,1)$

Any advice will be greatly appreciated,
Best regards,
Anat Tchetchik

[johnr]

Hi Anat

Typically you want to generate the design assuming the same model you are going to estimate in practice. If you intend to run a MMNL model, then you generate a design for that model. However, we have found that MNL designs tend to perform reasonably well when panel MMNL models are estimated, particularly when the number of choice tasks increase. Hence, if time is a constraint, we would generate an MNL design and simply use that.

In reference to your question about different levels for the same attribute, there is no real issue. it will depend on theory and empirical evidence. Some would argue that a $ is a $, so spending it on a toll for using a car or a fare for taking bus shouldn't matter, even though the amount of $ for both might be different. If you believe that, then you impose a generic parameter. However, people may view differently spending a $ travelling in a car is different to spending a $ on a bus. In that case, you use alternative specific parameters. This will be an empirical issue. Note however that if the levels are too different and you use generic parameters, then you may get some form of aggregation bias where the parameter will average out between the two sets of levels and not represent either attribute particularly well. Hence, I would err on the side of caution and use alternative specific parameter estimates, or at least generate a design capable of estimating them.

John

[Anat Tchetchik]

Hi John,
Thank you very much for your answer.

As for your answer to my question about different levels for the same attribute, I use a generic parameter for price believing that $ is a $,however the levels in my case are indeed too different, so I understand that having an alternative specific parameter (ASP) estimates is warranted to avoid bias.
However, I'm not sure what do you mean by 'at least generate a design capable of estimating them"
The design I was referring to (bellow) is a labelled one, already having ASPs: b1, c1 and d1.
Did you refer to these as the ASPs? or to additional creating interaction terms between each ASP and price?

e.g. in terms of my design below, is the underlined modification should be included in the design?

U(home) = b1+b2*freq(0,1,2)+ b1*b4*paymentA(0,1,2)+b5*burden(0,1,2)/

or that such interactions relevant for the estimation stage only?

Design
;alts = home, curb, center, optout
;rows = 72
;orth = sim
;block=9
;eff=(mnl,d)
;model:
U(home) = b1+b2*freq(0,1,2)+ b4*paymentA(0,1,2)+b5*burden(0,1,2)/
U(curb) = c1+b2*freq(0,1,2)+ b4*paymentB(0,1,2)+ b5*burden(0,1)+b6*distanceA(0,1,2) /
U(center)= d1+b2*freq(0,1,2)+b4*paymentC(0,1,2)+b5*burden(0,1)+b6*distanceB(3,4,5)+b7*centertype(0,1)$

Best regards.
Anat

[Michiel Bliemer]

I am trying to understand your design code, but it does not make sense to me. You have not provided any levels to the payment attributes? You just provided (0,1,2), note that in Ngene it should be [0,1,2]. But all three payments seem to have the same levels, so I do not understand it when you say they have different levels.

It is irrelevant which attribute levels you use, you can use the same b4. Different alternatives can have different attribute levels, but the same b4.

I do not understand what you mean with b1*b4. This is not an interaction term, but a multiplication of parameters. Ngene cannot handle that. Ngene can only handle interactions (multiplications) of attribute levels. And why would you want a multiplication with the constant? That does not seem to make sense.