choice-metrics.com

Dear Prof. Bliemer and Ngene Community

I want to create a choice experiment about preferences and willigness to pay for different styles of subscription models.

There are 4 different alternatives, where is last alternative is basically an opt-out pay-as-you-go alternative:
- A flatrate for unlimited units for a monthly price
- A 50% discount subscription where against a monthly fee a unit costs 0.25
- Quotas of free units (50, 100 or 200 units)
- Pay-as-you-go with a regular price of 0.5 per unit

My challenge is now to find the best set of common and alternative specific attributes to represent the different subscription models and avoid comparisons where one alternative is dominant. The first idea would be to simply model with an attribute for quota.

The utilities would look like this (I know this is not the final Ngene syntax)
U_flat = ASC_flat + beta_pmonth * p_flat [5, 10, 20, 30, 40]
U_50pc = ASC_50pc + beta_pmonth * p_50pc [1, 5, 10, 15, 20] + beta_punit * 0.25
U_quota = ASC_quota + beta_pmonth * p_quota [5, 10, 15, 20, 25, 30] + beta_quota * quota [50, 100, 200] + beta_punit * 0.5
U_payg = ASC_payg + beta_punit * 0.5

1) Does this design work so that Ngene will eliminate all choice situations with dominance? (A flatrate for the same or a lower price will always be better than the quota or 50% discount model)
2) Would it be better to have the quotas as dummy variables?
U_quota = ASC_quota + beta_pmonth * p_quota [5, 10, 15, 20, 25, 30] + beta_50units * dummy_50units + beta_100units * dummy_100units + beta_200units * dummy_200units + beta_punit * 0.5
3) I would like to have one common parameter for monthly price in the final model. Can I still use different levels in the design?

The next step after testing the MNL model would be to specify a MMNL model. This is because I would not assume independence of irrelevant alternatives. Respondents might have a tendency to decide whether or not to subscribe for a monthly fee and then decide which model is most attractive.

4) If I make the ASC and attributes random, do I need an additional constant for the subscription models flat, 50pc and quota?

1) This looks like a labelled experiment and for labelled alternatives there does not exist a general rule to avoid dominant alternatives because it is unclear which alternative would be dominant for all respondents as some people may prefer flat fees and some may prefer quotas. So the answer is No, Ngene would not eliminate any choice tasks because there is no clearly defined dominance. Ngene only removes choice tasks in unlabelled experiments where dominance is clearly defined.

2) Using quotas as a categorical variable may be good as the effect may not be linear, so dummy coding may not be a bad idea. Of course you could also estimate a logarithmic effect later on using quotas as a numerical variable.

3) Yes, so your specified utilities are fine.

4) I assume that you are referring to the model estimation phase (I would not recommend optimising the design for the MMNL model as it is computationally very challenging). You can simply make the existing parameters, including the constants, random. There is no need to add other constants (it would not be possible to estimate such additional constants as this would make the model unidentifiable).

In your choice experiment in the survey instrument, you would want to randomise the order in which each labelled alternative appears (across respondents, not within a respondent) as otherwise you would not be able to disentangle the ASCs from ordering effects.

Michiel

Dear Michiel

Thank you for taking the time for the detailed response.
In my case, there is a clear dominance for a flatrate that has a lower price, because the quotas will only be valid that month and the flatrate is basically an unlimited quota. Therefore, I have used conditions.

May I ask if you could have a quick look at my Ngene script? (The priors are just placeholder for the moment)
The unit price does not play a role in the utility functions (for Ngene), as it is not a variable attribute, correct?

Code: Select all

Design
;alts = flat, 50pc, quota, payg
;rows = 12
;block = 3
;eff = (mnl,d)
;cond:
if(flat.A = 10, 50pc.B < 10),
if(flat.A = 10, quota.C <10),
if(flat.A = 20, 50pc.B < 20),
if(flat.A = 20, quota.C <20),
if(flat.A = 25, 50pc.B < 25),
if(flat.A = 25, quota.C < 25)
;model:
U(flat) = b1[0.1] + b2[-0.01] * A[10,20,25,30,40]     /
U(50pc) = b3[0.05] + b2      * B[1,5,10,15,20]        /
U(quota) = b4[0] + b2 * C[5,10,15,20,25] + b5.dummy[0.001|0.002] * D[50,100,200]
$

The D-Error ist about 0.15

I think that the script looks fine.

Regarding price, is the same always the same and never varies? Could it be a scenario variable where, assuming price X, you have different options. But with price Y people may have different behaviour? E.g. differences between low and high price? If so, you could consider price as a scenario variable by adding it to all alternatives except your status quo alternative as in the script below. This means that the price is the same for all alternatives, but varies across choice tasks. You can use an alternative-specific coefficient for price to indicate differences in behaviour for each alternative.

Code: Select all

Design
;alts = flat, 50pc, quota, payg
;rows = 24
;block = 6
;eff = (mnl,d)
;cond:
if(flat.A = 10, 50pc.B < 10),
if(flat.A = 10, quota.C <10),
if(flat.A = 20, 50pc.B < 20),
if(flat.A = 20, quota.C <20),
if(flat.A = 25, 50pc.B < 25),
if(flat.A = 25, quota.C < 25)
;model:
U(flat) = b1[0.1] + b2[-0.01] * A[10,20,25,30,40] + b3_flat * price[1,2,3]    /
U(50pc) = b3[0.05] + b2      * B[1,5,10,15,20] + b3_50pc * price[price]        /
U(quota) = b4[0] + b2 * C[5,10,15,20,25] + b5.dummy[0.001|0.002] * D[50,100,200] + b3_quota * price[price]
$

Michiel

Thank you!
With price I mean the unit price which people pay for any units above the included quota (or the flatrate) as specified in the utility functions of my first post. The monthly price for the alternatives are already captured with b2 and A, B, C. To reduce complexity of the choice tasks I decided to keep this base price constant and only look at WTP for the subscriptions, given the fixed unit price.

When I add the parameter b6 for unit price and the constant values, I get Error: An attribute was specified with no levels, and was not previously defined.
So I assume this is not relevant for the design?

Design
;alts = flat, 50pc, quota, payg
;rows = 12
;block = 3
;eff = (mnl,d)
;cond:
if(flat.A = 10, 50pc.B < 10),
if(flat.A = 10, quota.C <10),
if(flat.A = 20, 50pc.B < 20),
if(flat.A = 20, quota.C <20),
if(flat.A = 25, 50pc.B < 25),
if(flat.A = 25, quota.C < 25)
;model:
U(flat) = b1[0.1] + b2[-0.01] * A[10,20,25,30,40] /
U(50pc) = b3[0.05] + b2 * B[1,5,10,15,20] + b6[-0.001] * 0.25 /
U(quota) = b4[0] + b2 * C[5,10,15,20,25] + b5.dummy[0.001|0.002] * D[50,100,200] + b6 * 0.5
U(payg) = b6 * 0.5
$

The error is because you did not define the attribute, so it would be something like the following where price only has a single level:

U(payg) = b6 * price[0.5]

But note that attributes with a single level are constants, and you cannot add constants in all 4 attributes as this would overspecify the model (remember that only differences in utility matter, so you can always normalise one of the constants to 0).

So you should either remove the payg alternative such that its utility is normalised to zero, or you should remove one of the constants (b1, b3, or b4) from the other utility functions.

Michiel