Covariates and "left right effect" in WTP space

[cybey]

Hello, everyone,

I have two questions for you experts.

(1) Covariates in WTP space

I have formulated a MIXL model in WTP space (Bayesian estimation) and would like to incorporate some covariates. I have specified the parameters as follows...

Code: Select all

wtp_Attribute1Level2_value = wtp_Attribute1Level2 +
      
      ## Sociodemographics
      wtp_Gender_Attribute1Level2 * COV_Gender +
      wtp_Age_Attribute1Level2 * COV_Age +
      wtp_Education_Attribute1Level2 * COV_Education +
      wtp_Residence_Attribute1Level2 * COV_Residence +

... while wtp_Attribute1Level2 is normally distributed and the covariates are fixed parameters in apollo_HB.

The utility function looks like this:

Code: Select all

V[['alt1']] = b_Price_value * ( wtp_Attribute1Level2_value * Attribute1Level2 + ...

Now I ask myself how I can/must consider covariates, which affect the overall willingness to pay, in model specification? I am thinking of covariates such as income, which is usually said to have an influence on the price parameter.

Code: Select all

b_Preis_value = b_Preis +

      ## Sociodemographics
      b_Income_Preis * COV_IncomePerCapita

Do I do it like the non-price parameters (see above) or do I have to let the income affect all attributes and levels? In the latter case, I would then see if the influence is significant on average and not for a specific attribute and level?


(2) "left right effect" in WTP space

In the manual on page 68, alternative-specific constants are included in the MIXL to account for "left-right effects". Is it possible/sensible to integrate the alternative-specific constants into WTP space? So...

Code: Select all

V[['alt1']] = b_Price_value * ( wtp_asc_1_value + wtp_Attribute1Level2_value * Attribute1Level2 + ...)

... instead of ...

Code: Select all

V[['alt1']] = wtp_asc_1_value + b_Price_value * ( wtp_Attribute1Level2_value * Attribute1Level2 + ...)

The former would make it possible to determine willingness to pay for left-right effects? On the other hand, I then have the lognormal distribution of the price coefficient "in play".

Best wishes
Nico

[stephanehess]

Hi Nico

on point 1, for income, I would not use a linear specification like this, and would rather use something like in example 3. You can put the income elasticity on the cost attribute, and then the inverse relationship will apply to the wtp measures.

on point 2, I would keep the left-right constants outside the wtp part.

Btw, on your socio-demographic shifts, be careful what this means for your conditionals, which I guess is what you're using in terms of outputs. Fine if the shifts are all fixed terms, but not if they're random, as the conditional for a combination of parameters is not necessarily the combination of individual conditionals.

Stephane

[cybey]

Hi Stephane,

Thanks for your quick response. I have two questions about it:

(1) My code now looks as follows:

Code: Select all

b_Price_value = ( b_Price + b_TariffSwitched_Price * COV_TariffSwitched ) *
      ( COV_Income / COV_Income_Mean ) ^ elast_Price_Income *
      ( COV_PriceMonthly / COV_PriceMonthly_Mean ) ^ elast_Price_PriceMonthly

b_Price is negative lognormally distributed, the other parameters are fixed. The problem I have with income is that it is only ordinally scaled, but I treat it as a continous variable. As many survey participants don't want to give information about their income, I asked them to rank their income relative to the average income while giving the information what the average income is. So my data about income is scaled like this:

1: Far below average
2: Below average
3: Average
4: Above average
5: Far above average

Relative specifications of income make no more sense now. But how can I combine an income elasticity and this scaling?

(2) Why would you keep the ASCs outside the wtp part?

I look forward to you answer.

Best wished
Nico

[stephanehess]

Nico

here's an example of how I've done this in a recent study:

b_fee = fee * ( income_miss * mult_no_income_fee + ( 1 - income_miss ) * ( income_hh / mean_income ) ^ lambda_income_fee )

so you have a separate multiplier for those with missing income.

re asc and wtp, for me, ASCs capture a range of different things, and expressing them in money terms often doesn't make a lot of sense, but it could be different in your case of course

Stephane

[cybey]

Okay, thanks. Actually, I do not have a problem with missing values.

A small example:

In your survey, a respondent has an income of 2000 euros per month and the average income is 3000 euros. So it can be said that this participant's income is two thirds of the median income. It is possible to interpret the fraction.

In my case, a respondent's income is "below average" (=2) and the average income is 3, so the fraction is 2/3. But I can't really interpret this fraction as I only know that the respondents's income is below average, but not by how much. In this respect I can only interpret the elasticity in terms of its sign, but not in terms of its relative or absolute height. Is that correct? If so: is there perhaps an elegant solution to this problem?

Nico

[stephanehess]

Personally, if you just have these five categories, I would just estimate five cost coefficients, one for each group.

[cybey]

Good idea! The only problem with my data is that I have two sets of data (N = 941 and N = 58). With the second dataset, I have too few observations, especially in some income classes, to estimate five parameters for price.
In total, I have three variables whose influence on the price coefficient I would like to check:

(i) Net household income
An ordinal scaled variable with five levels:
1: Far below average
2: Below average
3: Average
4: Above average
5: Far above average
This could also be used to calculate net household income per capita by dividing the net household income by the number of persons living in the household.

(ii) Tariff switched
Is a dummy variable and indicates wheter a respondent has switched his/her supplier during the last years.

(iii) Price monthly
Is a numerical variable for the monthly price paid by a survey participant.

Now I am looking for a specification to take all three variables into account and without increasing the number of parameters to be estimated too much. As you told me not to use an additive specification for the price coefficient, I thought of the following:

Code: Select all

b_Price_value = b_Price *
      ( 1 + (b_TariffSwitched_Price*COV_TariffSwitched) ) *
      ( 1 + (b_Income_Price*COV_Income_centered) ) *
      ( COV_PriceMonthly / COV_PriceMonthly_Mean ) ^ elast_Price_PriceMonthly

Does this specification make sense?

• b_TariffSwitched_Price should express the percentage points b_Price_value increases if COV_TariffSwitched takes the value 1.
• The aim of b_Income_Price is to express by how much percent the price coefficient increases (decreases) if the income category increases (decreases). So, let a household’s income be one level below the average (COV_Income_centered = -1), and assume b_Income_Price = -0.10, then b_Price_value increases by a factor of ( 1 + (-0.10 * (-1)) ) = 1.1.
  Non-linearities are not taken into account in this formulation. Otherwise I end up with elasticity again.
• The elasticity formulation of PriceMonthly comes from Apollo example 3.

[stephanehess]

Hi Nico

with N=58, I would really strongly suggest sticking to an MNL model. I would worry much more about whether it's reasonable to estimate random heterogeneity on such a small sample (whether with HB or not) than whether the sample is big enough for deterministic heterogeneity

Stephane

[cybey]

Hi Stephane,

thank you very much for the tip. I will take this into account. However, just out of curiosity: Does my specification for the price attribute work, or have I missed something, e.g. wrong interpretation of the coefficients?

Best wishes
Nico

[stephanehess]

Nico

sorry for the slow reply. I think I would worry about this specification just in terms of how you go from the ordinal variable to a continuous one, i.e. far below=-2 and below=-1. It assumes linearity that might not be right. Plus, different people could interpret the categories differently. To me, separate parameters would still be the safest thing to test first and then learn about the shape of the functionality form.

Stephane