Conditional prices as a basis for the prices displayed in the choice sets?

Question

Hello, everyone,

I have a question regarding a CBC design where I need your experience and tips. I would like to conduct a CBC in the field of demand side management. The households have the possibility to support the energy system with different devices.

Attribute 1: Device
---------------------
Level 1: Electric car
Level 2: Heat Pump
Level 3: Dishwasher
Level 4: Washing machine

There will also be a price attribute with three levels. However, the price attribute does not represent an amount that the participants have to pay, but a compensation for their restrictions in the use of their devices.

Attribute 2: Price/Compensation
---------------------
Level 1: Low
Level 2: Mid
Level 3: High

Furthermore, the compensation is paid in three types.

Attribute 3: Type of compensation
---------------------
Level 1: Fixed compensation
Level 2: Variable compensation
Level 3: Fixed compensation + variable compensation

In the case of fixed compensation, a one-off amount is paid at the end of the year, which is independent of the number of flexibility calls. With variable compensation, no one-off amount is paid at the end of the year, but each flexibility call is compensated. The number of calls per year is estimated, but uncertain. Level three is a combination of both.

Now the price or compensation displayed depends on the attributes 1 and 2, because e.g. the electric car has a much higher electrical power than the dishwasher. If the participants decide to use the dishwasher, they will receive a much smaller amount of money. This constellation is comparable to the package size example for conditional pricing on the Sawtooth website.

Now it gets more complicated: I would also like to consider the type of compensation when displaying the alternatives in the choice sets. Example of a choice set:

Alternative 1:
---------------------
Device: Dishwasher
Type of compensation: 50€ per year fixed; 0€ per flexibility call.

Alternative 2:
---------------------
Device: Electric car
Type of compensation: 200€ per year fixed; 5€ per flexibility call, whereby we forecast 20 calls per year.

Alternative 3:
---------------------
Device: Washing machine
Type of compensation: 25€ per year fixed; 1.25€ per flexibility call, whereby we forecast 20 calls per year.

The aim is that the prices displayed are based on the conditional prices from attributes 1 and 2. For example, it is calculated that for "compensation = medium" and "device = dishwasher" the amount is 50€. However, since the type of "compensation = variable compensation", the amount of €50 is divided by the number of calls per year (e.g. 20), i.e. €2.50 per flexibility call.
But if the "type of compensation = fixed compensation + variable compensation", then the fixed amount should be 25€ (50% of the conditional price), and the remaining 25€ is divided by 20, i.e. 1.25€ per calls.

In summary, there are three overlapping factors that influence the prices displayed:
(a) Devices.
(b) Price levels.
(c) Type of compensation.

Now the questions arise to me, whether this (i) can be implemented in the software and (ii) does it make any sense at all, since I will probably not be able to separate the three effects later in the analysis?

I look forward to your opinions and tips.

Comments

This isn't really an answer, but I wonder if things are too complicated to try a traditional conjoint approach where we have generic attributes and we try to build a more general model with low/medium/high levels and such.  Maybe it would be better to just embrace the complexity and treat it like attribute 1 is device, and then attribute 2 car compensation, attribute 3 is heat pump compensation, attribute 4 is dishwasher compensation, etc.

Then the levels of "car compensation" are just the specific combinations that you would consider for car options.

The downside is that it feels a lot messier because we're not taking the typical conjoint approach and breaking things into general and combine-able attributes, but with how complex things are I don't think there's a great way to do that.   Even though it feels messier, I think it might be an easier approach in the long run to build a working choice simulator where we are less concerned about generalizing utilities for device preferences and trying to calculate attribute importances.

---

Hi, Brian,

Thank you for your answer.

If I understand you correctly, then in your example the attribute " car compensation" is the alternative-specific attribute of "device = car"? If I now set the absolute amount of compensation and the type of compensation equal, e.g. 50 euros for both the washing machine and the dishwasher, which are paid out at the end of the year. Then differences in importance can only be explained by differences in devices?

On the other hand, if I set the compensation to the same absolute amount, e.g. 50 Euro, but the type of compensation and the device are different, then I cannot specify the reason for the difference in importance, as it could be due to both?

---

Attribute importance starts to become a messy thing to work with once you break away from a simple conjoint design where all attributes are shown every time and all levels freely combine with others.  For example, say you had really high values of compensation for device 2 and really low values of compensation for device 3.  You've kind of got two issues with importance scores where you can't really say "The importance of device type is X" because the devices aren't equal on other aspects, and you can't really say "the importance of compensation is Y" because you have two separate attributes dealing with different amounts of compensation.

So, while we gain flexibility in the model when we start doing fancier things like alternative-specific designs, we tend to sacrifice some things to get there like reading a lot in to average utilities and attribute importance.  Usually if running simulations is the primary goal, it's a worthwhile trade-off.

---

Hi, Brian,

Again, a big thank you for your help.

Based on your experience, would you say that an alternative way could be two less complex, separate CBCs? One colleague argues that the respondents cannot grasp the complexity of the attributes and levels shown anyway.
He therefore proposes to show in the first CBC only the devices and levels of compensation, i.e. low/medium/high depending on the device.
The second CBC then displays the absolute amount of compensation (low/medium/high) with the type of compensation, whereby "unrealistic" combinations are also allowed. Therefore, a choice set could also look like this:

Alternative 1:
---------------------
50€ per year fixed; 0€ per flexibility call.

Alternative 2:
---------------------
400€ per year fixed; 0€ per flexibility call.

Alternative 3:
---------------------
25€ per year fixed; 1.25€ per flexibility call.

Here again, conditional pricing could be applied. However, the two attributes and levels themselves would not be displayed, only the combinations.

What do you think?

---

Potentially, there's rarely one ideal way to approach a conjoint design.  Just keep in mind that there won't really be any way to formally tie the two designs together in the software.  So I'm not sure if that's the "right" way to move forward, but I think the general principle of trying to keep things more simple is always a good one to follow.  But, at the end of the day, your design approach should follow what type of combinations you want respondents to see, while also considering what output you want and how important it is (e.g. do I just want to report attribute importances, or is it more important to me to build a simulator that let's me test specific combinations against each other).