specification of a model with few payment vehicles

[Anat Tchetchik]

Dear Ngene users,

I'm not sure how much this question relates to this forum as it has more experimental design relevance, however I could use some advice or direction.
We are trying to elicit preferences towards different types or E-Waste recycling programs.
The design is labelled with the 3 alternatives being: 1)"home pick up" (2)curbside"- drop off containers placed along the street(3) drop off centers
There are (at least) 2 payment vehicles considered:
(1) at the point of purchase the Electronic device- as a % of the device cost. Obviously the range of percents levels will be lowest for the "drop off centers" (e.g. (0.5%, 1%, 1.5%)) and highest for the "home pick up" (e.g. (2%,2,5%,3%)
(2) Annual fees for the service (again- fees levels range will be lowest for "drop off centers" (e.g. $ 10, $ 20, $ 30) and highest for "home pick up" e.g. ($ 50, $ 75, $ 100)

Does it make sense to include two different payment methods, with price levels that are actually not comparable- since in the payment option 1 (% of the device cost) - the respondent have no way to estimate how much it will cost him eventually as most people can't evaluate how much money they expand on electricity over a year.
So I'm afraid we might be "counting apples with oranges"
Any comment will be greatly appreciated,
Best
Anat

[Michiel Bliemer]

You can create scenarios in Ngene, see Section 8.5 of the manual. In this, you can keep the levels across alternatives the same, so you are comparing oranges with oranges and have different pay methods.
We applied something similar in a study in which we had also three alternatives (train, car, car), in which the last two alternatives were only different in the payment method, not in the toll level or travel time.
Just be careful in case of unlabelled alternatives, as you will need at least one alternative to be labelled (e.g., status quo or none), or you will need interactions in case the same levels appear in all alternatives.

Michiel

[Anat Tchetchik]

Dear Michiel,
Thank you very much for you reply!
Yet- I am not sure that I understand- we need to create two different scenarios-one for each payment method (and then let the scenario characteristics treated as covariate atts.) however the levels of the price attributes in the two methods are intrinsically different- in one methods they are provided as a percent of the e-device purchased whereas in the other - as fixed annual payment in $ to be paid no matter how much e-device you buy... isn't this a (huge) problem for the later analysis?
Finally- does the paper you have referred to is: "Pay-as-You-Drive Strategies: Case Study of Safety and Accessibility Effects"

Thanks,
Anat

[Anat Tchetchik]

Hi again,
Following my last post (replying Michiel's answer to my question) I have tried what the manual section 8.5 suggests and received the following error:
Error: An attribute that mimics another attribute's levels (i.e. scenarios) was specified and is not compatible with orthogonal designs.
What options do I have? as I want to have priors for the next stage design...
this is the syntax:
Design
;alts = home, curb, center, opt-out
;rows = 72
;orth = sim
;block=9
;eff=(mnl,d)
;model:
U(home) = b1+ b2*freq[0,1,2] + b4 *payment[0,1]+ b5 * priceA[6,7,8]+b6*burden[0,1]/
U(curb) = c1+ b2*freq + b4 *payment[payment]+ b5 * priceB[3,4,5]+ b6*burden[0,1] + b7*distanceA[0,1,2] /
U(center)= d1+ b2*freq +b4 *payment[payment]+ b5 *priceC[0,1,2]+ b6*burden[0,1]+ b7*distanceB[3,4,5] + b8*centertype[0,1]$
Best,
Anat

[Michiel Bliemer]

I think I understand what you mean now.
We have had similar problems when trying to design surveys for pay-as-you-drive, where we compared an annual fee with a per-kilometer fee. The problem is, that a survey is a very simple choice, whereas in practice the choice is much more complicated. In our case (and perhaps in yours), the payment method choice influences the number of kilometres driven as well. I believe we designed an experiment in which they not only had to choose the payment method, but also choose how many kilometres they would drive. This is a discrete-continuous choice, which has to be estimated with a discrete-continuous model (see the work of Bhat). It is therefore difficult to present choices that actually represent a whole time period (like a month or year). There is no easy solution I think.

The work i was referring to was for a project done by a colleague, I am not sure whether it is in a paper.

Your final question is easy to answer, and the Ngene error gave you essentially the answer: orthogonal designs cannot work with constraints (such as scenarios), they are very rigid and have no flexibility. You will have to remove ;orth = sim from your syntax. Ngene will assume all betas have zero priors if you do not specify them, which is the same assumption as orthogonal designs make, so there is no problem removing ;orth = sim.

[Anat Tchetchik]

Hi Michiel,
You have raised an important issue that I wasn't thinking about- that the payment method may influence the amount of electronic devices one buys over a period.
(I was only bothered with how to extract WTP having to different payment methods..) Since this is an M.Sc. thesis that I'm advising and we are really interesting in eliciting the trade-offs between the "money" and "effort" that embedded in the three labelled recycling alternatives- I think it is better to remain with the annual fee option and drop the other payment method which requires from the respondent more cognitive effort ..
What do you think?
Anat

[Michiel Bliemer]

I guess it depends on the questions you would like to answer with your experiment.
Perhaps you could phrase the questions in a different way, for example:
A - You pay a fixed $X per year
B - You pay an amount of Y devices per year, which amounts to $X per year given your current driving behaviour
where you have asked earlier about the number of km they drive each year.

Each experiment is different, so it is difficult for me to comment on every individual experiment, but I hope my comments were a bit helpful.

Good luck,
Michiel

[Anat Tchetchik]

Thanks much, it is instructive and helpful!
Anat