combining two cost parameters.

[izakro]

Dear all,
I am designing a DCE to study households’ willingness to adopt a smart app that optimizes electric water-heater operation in winter based on daily solar radiation, with the aim of avoiding unnecessary heating on sunny days.
I have two monetary attributes:
Annual electricity cost savings from more efficient heater operation (ILS 400 / 475 / 550),
Annual operation cost charged by the service provider (ILS 45 / 90 / 135).

What ultimately matters to respondents is the net financial outcome, so in principle these could be combined into a single “net annual savings” attribute.
However, I also include a separate emissions reduction attribute (annual GHG savings), which is correlated (via restrictions in ;reject:) with electricity savings. To maintain consistency,
My concern is that collapsing the two monetary attributes into a single net savings measure would break this partial correlation, allowing unrealistic profiles (e.g., very high net savings with low emissions reductions), and losing control over the cost–emissions relationship embedded in the design.

My question is:
From an identification perspective, is it preferable to (a) keep electricity savings and subscription cost as separate attributes with restrictions, or (b) move to a single net monetary attribute and rely on respondents to process the trade-off, even at the cost of losing structural correlation with emissions?

The design is below

Code: Select all

Design 
;alts = alta*, altb*, optout*
;rows = 12
;block = 3
;eff = (mnl,d)
;alg = mfederov (candidates=500)
;reject:
alta.cost_saved = 400 and alta.emission_saved >475,
alta.cost_saved = 550 and alta.emission_saved <550,
alta.cost_saved = 475 and alta.emission_saved =600,
alta.cost_saved = 475 and alta.emission_saved =400,
altb.cost_saved = 400 and altb.emission_saved >475,
altb.cost_saved = 550 and altb.emission_saved <550,
altb.cost_saved = 475 and altb.emission_saved =600,
altb.cost_saved = 475 and altb.emission_saved =400
 
;model:
U(alta)     =       cost_saved[0.000001] *cost_saved[400,475,550]? annual
                    +emission_saved[0.000001]*emission_saved[400,475,550,600]? anual
                    +control_autonomy.dummy[0.00001]*control_autonomy[0,1]? 1=user full control 0=autonomous
                    +operation_cost[-0.00001] * operation_cost[45,90,135]/ ?annual
U(altb)  =          cost_saved *cost_saved
                    +emission_saved*emission_saved
                    +control_autonomy.dummy*control_autonomy
                    +operation_cost * operation_cost/ 

U(optout)  =       b0[0.0000]

I would greatly appreciate any advice or experience with similar designs.
Rotem

[Michiel Bliemer]

It is fine to show the cost attributes separately. This is also common in transport where for example fuelcost and tollcost are shown separately. In the model that you estimate after the data collection you can estimate separate parameters for each cost attribute, but you can also estimate a single parameter for all cost attributes if you believe that respondents simply added all costs together. You can test this statistically.

Some comments about your Ngene script:
- optout should not have an asterisk because it a different type of alternative (different label)
- the default swapping algorithm is preferably because it ensures attribute level balance. You can use conditional constraints in the swapping algorithm.

I have rewritten your script below.

Code: Select all

Design 
;alts = alta*, altb*, optout
;rows = 12
;block = 3
;eff = (mnl,d)
;cond:
if(alta.cost_saved = 400, alta.emission_saved = [400,475]),
if(alta.cost_saved = 550, alta.emission_saved = [550,600]),
if(alta.cost_saved = 475, alta.emission_saved = [475,550]),
if(altb.cost_saved = 400, altb.emission_saved = [400,475]),
if(altb.cost_saved = 550, altb.emission_saved = [550,600]),
if(altb.cost_saved = 475, altb.emission_saved = [475,550])
;model:
U(alta)   = cost_saved[0.000001]            * cost_saved[400,475,550]? annual
          + emission_saved[0.000001]        * emission_saved[400,475,550,600] ? annual
          + control_autonomy.dummy[0.00001] * control_autonomy[0,1]? 1=user full control 0=autonomous
          + operation_cost[-0.00001]        * operation_cost[45,90,135] ? annual
          /
U(altb)   = cost_saved                      * cost_saved
          + emission_saved                  * emission_saved
          + control_autonomy.dummy          * control_autonomy
          + operation_cost                  * operation_cost
          / 
U(optout) = b0[0.0000]
$

Further, when using (near) zero priors, it often happens that for numerical attributes the highest and lowest levels appear across the alternatives, and the middle level appears across the alternatives. This is optimal from an efficiency perspective, but it is often not desirable. If you look at the resulting design, you will see that this happens for the cost_saved attribute (and to a lesser extent for the operation_cost attribute). To avoid this, it is often recommended to dummy code the attribute (only during the design phase, you can use linear coding during the model estimation phase).

Michiel

[izakro]

perfectly understood! I'll also dummy code the cost atts. in the design phase
Thanks!