Pivot design on the fly (heterogeneous) and effects coding

[xdupom]

Dear NGENE community,

Thanks a lot for your hard work in making the NGENE manual so clear, it helped me a lot understanding things! This is the first time I am making a choice experiment design and I would be really glad if I could get your feedback on a few points for my quite complex design.

I will survey companies that use harmful chemicals in their electronic products and investigate their willingness to switch towards safer chemicals in their products. Companies will have their own status quo (SQ) based on the description of the product they sell the most.
Therefore, I need a heterogeneous pivot design since I have different SQs for different companies (and the design will be generated on the fly). I have 3 alternatives including the SQ, and 4 attributes:
- Health and environmental properties (Hep): qualitative attribute with 5 levels=[0,1,2,3,4];
- Label (Lbl): qualitative attribute with 2 levels=[0,1];
- European regulations (Reg): qualitative attribute with 2 levels =[0,1]);
- Product price (Pri): quantitative price attribute with 4 levels =[-5%, 0%, 5%, 10%].

What follows is the preliminary piece of code that is common to all codes presented after.

Code: Select all

Design
;alts(SQ1) = altA*, altB*, SQuo*
;alts(SQ2) = altA*, altB*, SQuo*
;alts(SQ3) = altA*, altB*, SQuo*
;rows = 8
;eff = fish(mnl, d)
;fisher(Fish) = design1(SQ1[0.33]) + design2(SQ2[0.33]) + design3(SQ3[0.34])
;alg = mfederov(candidates=5000000)

I had in mind the following constrained models specification that does not work because of the incompatibility between the pivot design and the effects coding:

Code: Select all

;reject:
altA.Hep = 4 and altA.Lbl<> 0,
altA.Reg = 0 and altA.Hep > 1,
altB.Hep = 4 and altB.Lbl<> 0,
altB.Reg = 0 and altB.Hep > 1

;model(SQ1):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep.ref[4]             + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[1]    + b4[0]*Pri.ref[4000]/
U(altA) =         b1                 *Hep.piv[-4,-3,-2,-1,0] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep.piv[-4,-3,-2,-1,0] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]                     

;model(SQ2):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep.ref[1]          + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[4000]/
U(altA) =         b1                 *Hep.piv[-1,0,1,2,3] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep.piv[-1,0,1,2,3] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]                  

;model(SQ3):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep.ref[0]         + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[4000]/
U(altA) =         b1                 *Hep.piv[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep.piv[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]  
$

Therefore I got rid of the effects coding (although not ideal in my setting) and wrote the following working code (by pivoting differently my attribute levels depending on the SQ): is it conceptually correct?

Code: Select all

;reject:
altA.Hep = 4 and altA.Lbl<> 0,
altA.Reg = 0 and altA.Hep > 1,
altB.Hep = 4 and altB.Lbl<> 0,
altB.Reg = 0 and altB.Hep > 1

;model(SQ1):
U(SQuo) = b0[0] + b1[0]*Hep.ref[4]             + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[1]    + b4[0]*Pri.ref[4000]/
U(altA) =         b1   *Hep.piv[-4,-3,-2,-1,0] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1   *Hep.piv[-4,-3,-2,-1,0] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]                     

;model(SQ2):
U(SQuo) = b0[0] + b1[0]*Hep.ref[1]          + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]   + b4[0]*Pri.ref[4000]/
U(altA) =         b1   *Hep.piv[-1,0,1,2,3] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1   *Hep.piv[-1,0,1,2,3] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1] + b4   *Pri.piv[-5%,0%,5%,10%]                  

;model(SQ3):
U(SQuo) = b0[0] + b1[0]*Hep.ref[0]         + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]   + b4[0]*Pri.ref[4000]/
U(altA) =         b1   *Hep.piv[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1   *Hep.piv[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1] + b4   *Pri.piv[-5%,0%,5%,10%]     
$

Finally, I have re-used one of your tricks (cf http://choice-metrics.com/forum/viewtopic.php?f=4&t=377) to actually keep my effects coding on the "Hep" variable (which would be the ideal design) and it works. But I would be glad if you could have a look and tell me whether there is a magic somewhere that actually corrupts my thinking ? I.e that I perform a heterogeneous pivot design with effect coding on the variable Hep (by 'triangularly' rejecting the undesirable model specific cases) ?

Code: Select all

;reject:
altA.Hep = 4 and altA.Lbl<> 0,
altA.Reg = 0 and altA.Hep > 1,
altB.Hep = 4 and altB.Lbl<> 0,
altB.Reg = 0 and altB.Hep > 1,
SQuo.Hep <> 4 and SQuo.Reg = 1,
SQuo.Hep <> 1 and SQuo.Reg = 0 and SQuo.Pri = 4000,
SQuo.Hep <> 0 and SQuo.Reg = 0 and SQuo.Pri = 4001

;model(SQ1):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[1]    + b4[0]*Pri.ref[4000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]                     

;model(SQ2):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[4000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]                  

;model(SQ3):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[4001]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]  
$

Note the last price (in the SQ3 model) that is set to 4001 so as to be able to discriminate the reference alternatives in SQ2 and SQ3 and reject undesirable cases.

I am very grateful for your feedback, my pilot starts on Monday, which is always a little bit stressful .
Best regards,

Marion

[Michiel Bliemer]

If it works and you are happy with the design then it is fine, it is difficult for me to understand someone else's experiments.

But from looking at your syntax, I understand the following:

Hep: The reference level is either 0, 1, and 4, but for altA and altB all levels appear so this is actually not a pivoted attribute.
Lbl: The reference level is always 0 and all levels appear for altA and altB so this is a regular attribute.
Reg: The reference level is either 0 or 1, and all levels appear for altA and altB so this is not a pivoted attribute.
Pri: This seems an actual pivoted attribute depending on the value that is input for Price from the respondent.

You could consider using this part of the syntax (note that you should not use more than 10,000 candidates, otherwise it is far too slow):

Code: Select all

Design
;alts = altA*, altB*, SQ*
;rows = 8
;eff = (mnl,d)
;alg = mfederov

;reject:
altA.Hep = 4 and altA.Lbl<> 0,
altA.Reg = 0 and altA.Hep > 1,
altB.Hep = 4 and altB.Lbl<> 0,
altB.Reg = 0 and altB.Hep > 1

And then perhaps separately generate these designs:

Design 1: Hep=4, Reg = 1

Code: Select all

;require:
SQ.Hep = 4

;model:
U(SQ)   = b0 
        + b1.effects[0|0|0|0] * Hep[0,1,2,3,4]        
        + b2                  * Lbl_SQ[0] 
        + b3                  * Reg_SQ[1]  
        + b4                  * Pri.ref[4000] 
        /
U(altA) = b1                  * Hep 
        + b2                  * Lbl[0,1]
        + b3                  * Reg[0,1]
        + b4                  * Pri.piv[-5%,0%,5%,10%](2,2,2,2)
        /
U(altB) = b1                  * Hep 
        + b2                  * Lbl 
        + b3                  * Reg
        + b4                  * Pri.piv[-5%,0%,5%,10%](2,2,2,2)                     
$

Design 2: Hep = 1, Reg = 0

Code: Select all

;require:
SQ.Hep = 1

;model:
U(SQ)   = b0 
        + b1.effects[0|0|0|0] * Hep[0,1,2,3,4]        
        + b2                  * Lbl_SQ[0] 
        + b3                  * Reg_SQ[0]  
        + b4                  * Pri.ref[4000] 
        /
U(altA) = b1                  * Hep 
        + b2                  * Lbl[0,1]
        + b3                  * Reg[0,1]
        + b4                  * Pri.piv[-5%,0%,5%,10%](2,2,2,2)
        /
U(altB) = b1                  * Hep 
        + b2                  * Lbl 
        + b3                  * Reg
        + b4                  * Pri.piv[-5%,0%,5%,10%](2,2,2,2)                     
$

Design 3: Hep=0, Reg=0

Code: Select all

;require:
SQ.Hep = 0

;model:
U(SQ)   = b0 
        + b1.effects[0|0|0|0] * Hep[0,1,2,3,4]        
        + b2                  * Lbl_SQ[0] 
        + b3                  * Reg_SQ[0]  
        + b4                  * Pri.ref[4000] 
        /
U(altA) = b1                  * Hep 
        + b2                  * Lbl[0,1]
        + b3                  * Reg[0,1]
        + b4                  * Pri.piv[-5%,0%,5%,10%](2,2,2,2)
        /
U(altB) = b1                  * Hep 
        + b2                  * Lbl 
        + b3                  * Reg
        + b4                  * Pri.piv[-5%,0%,5%,10%](2,2,2,2)                     
$

You could further create additional designs by varying reference levels for Price. Unlike the Fisher command, the designs do not get optimised simultaneously, but the approach above provides more flexibility, allows constraints, and is easier to understand.

Michiel

[xdupom]

Many thanks for your quick reply !

1- You understood perfectly what I am trying to do indeed. That is true that Hep, Lbl and Reg are not actually pivoted. But is it ok to "pivot" differently the reference alternative to get Alternatives A and B? So that indeed, in the end, the levels of attributes Hep, Lbl and Reg are the same for each status quo.

2- Regarding the variation of the price in the reference alternative: I might increase the number of status quos and therefore the number of models indeed. But actually, in my design, there is an infinity of status quos because of the price attribute that widely varies across firms (between 500sek and 20000sek). Indeed, the considered product could be a phone or a washing machine depending on what the company sells. Since there are too many proces to represent in the design. Currently, I fixed the price to 4000sek in my status quos SQ1, SQ2, SQ3 for the design. Do you think I should consider for example one high price and one low price in order to capture more variation in the status quo (which will happen for sure)? This means I would end up with 3 more status quos in the design i.e. SQ1, SQ2, SQ3 with the same low price (e.g. 4000sek) and SQ4, SQ5, SQ6 with the same high price (e.g. 12000sek)? I can even go for 9 different status quos to represent even better the possibilities. Then is 9 SQs still feasible or it starts to be too much?

3- I am not sure I understand your suggestion to generate separate designs for my SQs. If I do that, I will end up with different choice sets for the (currently) three segments, right? But I want my respondents to be faced with the same choice sets whatever their status quo, hence my choice of a heterogeneous design (with pivot on the price attribute). Did I miss something in your suggestion?

4- Note: since I am working with companies, I will have a relatively little number of individuals in my sample (approximately 80 I think). So I can't really either block my design or consider different segments unfortunately. Would you consider the choice situations of my design (4 attributes) complex? I have considered 8 choices to present to companies but I do not know if it is already too much for such a design or not.

Many thanks again for your precious help.

Best,

Marion

[Michiel Bliemer]

1. Yes that is OK, it just a more complicated way of doing this I guess.

2. Currently the design is optimised for price levels around 4000, so if the respondent puts in a reference level of 500 and 20000 then the design may not be very efficient. Therefore, it may be wise to optimise around different fixed reference points. I refer also to the work of Rose, Bliemer, Coillins and Hensher on pivot designs around reference levels.

3. I did not understand that you wanted to have exactly the same questions, there is generally no need to use the same design, the respondents also have different reference levels so they will face different questions anyway. But if you insist on using exactly the same design then you can do as you propose I guess. Note that 8 rows will not be enough in that case, I would go at least double that as otherwise there is very little variation in your design. In that case, you may need to block the design.

4. You can always block your design, blocking may actually make your design more efficient. Only having 8 choice tasks may not provide much amount of information, a slightly larger design is often found to be more efficient (see the work of Sandor and Wedel on heterogeneous designs). I do not think that your choice design is very complex, I think that 8 is not too much.

Michiel

[xdupom]

Thank you very much for your clarifications.

1- Do you agree that it is not possible to generate a heterogeneous design on the fly if I am not sure about the exact number of status quos my respondents may have? Here is my reasoning. My respondents will select the price of their current product (i.e. among a list of prices [500 sek, 1000sek, 2000sek, 3000sek,..., 20000sek]) and this selected price will be inputed in the reference alternative. Because the number of prices and therefore status quos is too large, I can only create an NGENE design based on a subset of status quos. Therefore, since the status quos used to generate the design are not exhaustive, I cannot generate a heterogeneous design because (if I understood well) the alternatives A and B 'depend' on the status quo i.e. a respondent with SQ1 will not face the same alternatives as a respondent with SQ2. On the contrary with a homogeneous design, whatever the status quo of the respondents, the alternatives they face will be the same. Therefore, given my design (in which I do not know in advance which prices will be selected by companies), I can only generate a homogeneous design. Am I correct?

Below is my new code considering 9 SQs that span 3 different prices:

Code: Select all

Design
;alts(SQ1) = altA*, altB*, SQuo
;alts(SQ2) = altA*, altB*, SQuo
;alts(SQ3) = altA*, altB*, SQuo
;alts(SQ4) = altA*, altB*, SQuo
;alts(SQ5) = altA*, altB*, SQuo
;alts(SQ6) = altA*, altB*, SQuo
;alts(SQ7) = altA*, altB*, SQuo
;alts(SQ8) = altA*, altB*, SQuo
;alts(SQ9) = altA*, altB*, SQuo
;rows = 24
;block=3
;eff = fish(mnl, d)
;fisher(Fish) = design(SQ1[0.11], SQ2[0.11], SQ3[0.11], SQ4[0.11], SQ5[0.11], SQ6[0.11], SQ7[0.11], SQ8[0.11], SQ9[0.12])

;alg = mfederov(candidates=50000)
;reject:
altA.Hep = 4 and altA.Lbl<> 0,
altA.Reg = 0 and altA.Hep > 1,
altB.Hep = 4 and altB.Lbl<> 0,
altB.Reg = 0 and altB.Hep > 1,
SQuo.Hep <> 4 and SQuo.Reg = 1 and SQuo.Pri = 1000,
SQuo.Hep <> 1 and SQuo.Reg = 0 and SQuo.Pri = 1000,
SQuo.Hep <> 0 and SQuo.Reg = 0 and SQuo.Pri = 1001,
SQuo.Hep <> 4 and SQuo.Reg = 1 and SQuo.Pri = 5000,
SQuo.Hep <> 1 and SQuo.Reg = 0 and SQuo.Pri = 5000,
SQuo.Hep <> 0 and SQuo.Reg = 0 and SQuo.Pri = 5001,
SQuo.Hep <> 4 and SQuo.Reg = 1 and SQuo.Pri = 10000,
SQuo.Hep <> 1 and SQuo.Reg = 0 and SQuo.Pri = 10000,
SQuo.Hep <> 0 and SQuo.Reg = 0 and SQuo.Pri = 10001

;model(SQ1):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[1]    + b4[0]*Pri.ref[1000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]                     

;model(SQ2):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[1000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]                  

;model(SQ3):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[1001]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%] 

;model(SQ4):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[1]    + b4[0]*Pri.ref[5000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]                    

;model(SQ5):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[5000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]                 

;model(SQ6):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[5001]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%] 

;model(SQ7):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[1]    + b4[0]*Pri.ref[10000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,-1] + b4   *Pri.piv[-5%,0%,5%,10%]                    

;model(SQ8):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[10000]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]                 

;model(SQ9):
U(SQuo) = b0[0] + b1.effects[0|0|0|0]*Hep[0,1,2,3,4] + b2[0]*Lbl.ref[0]   + b3[0]*Reg.ref[0]    + b4[0]*Pri.ref[10001]/
U(altA) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]/
U(altB) =         b1                 *Hep[0,1,2,3,4] + b2   *Lbl.piv[0,1] + b3   *Reg.piv[0,1]  + b4   *Pri.piv[-5%,0%,5%,10%]               
$

Questions:
2- It seems I cannot specify the number of occurance of each of the levels for the Hep attribute due to the constraints I have. Without this specification, the design is generated. I still get this: "Warning: One or more attributes will not have level balance with the number of rows specified: squo.hep, alta.hep, altb.hep, squo.hep, alta.hep, altb.hep, squo.hep, alta.hep, altb.hep, squo.hep, alta.hep, altb.hep, squo.hep, alta.hep, altb.hep, squo.hep, alta.hep, altb.hep. Note: Defaulting to assigning blocks with the 'minsum' method." Can I ignore the error? I do not manage to get rid of the warning.

3- Does blocking the design diminish my statistical power? With two blocks, I will have approximately 30-40 companies per block. With 3 blocks, I will have approximately 20-25 companies per block. Does it sound ok for an econometric analysis?

4- I would like to test for rationality/consistency of the respondents. Therefore, I thought about adding a choice set where one alternative is clearly dominant. Should I add a 9th choice set for each respondent (not included in the measurement of efficiency)?

Thank you very much again! I hope I was clear.

Best,

Marion

[Michiel Bliemer]

1. I am not sure what you mean with "a heterogeneous design on the fly". A homogeneous design means that you use a single experimental design and a heterogeneous design means that you have multiple experimental designs given to different respondents. With a pivot design, a homogeneous design still means that the survey is respondent-specific due to differences in reference levels. Heterogeneous designs can be created by making a library of designs a-priori for different classes of respondents (e.g. low price, high price, etc) and then you can still pivot around their actual reference levels. Instead of pivoting, I generally just create a large number of designs, one for each segment of respondents (e.g. low price, Hep = 4, Reg = 1). The advantage of this approach is that I optimise for all respondent types and I can control all the levels shown to respondents. In a pivot design where levels are computed on the fly, you have make sure that you use appropriate rouding. If someone states a price of 5230 and you take -10% you may get quite "ugly" non-rounded values, so you need to make sure that you round these values in the survey instrument. A heterogeneous design also exists when you use blocking, because a respondent faces only one specific block in the design while another respondent faces another block. If your main aim is to compare respondents across different segments, then using a homogeneous design is a good idea because then at least you use the same design across all respondents. But if your objective is to obtain choice preferences across a population, then using a heterogeneous design will likely be a better choice, e.g. creating a library of designs. It also depends what is easier to implement in the survey instrument. A pivot design may require programming more logic, while a library of designs requires creating multiple versions.

2. You can ignore this warning, the modified Federov cannot keep attribute level balance and therefore always generates this warning. The only attribute where I would impose attribute level constraints is Price. See the syntax in my previous post where I imposed constraints to ensure that Price would be attribute level balanced.

3. Yes that is OK, you do not do your analysis per block, you pool all data from all blocks and do your analyses over all blocks combined, therefore you do not lose statistical power.

4. Yes you can do this. When you add such a choice task with a dominant alternative, it is indeed good to make it the last question.

Michiel

[xdupom]

Waouh, this makes everything clear in my mind, thanks so much for your time. Then I will decide between a heterogeneous pivot design and separating e.g. 30 different designs that span all possible prices (which would indeed be more accurate).

If I decide to generate separately a large number of designs as you suggest, can I keep only 8 rows for each design? Or is it still better to increase the number of rows and block? E.g. consider 16 rows (2 blocks) or 24 rows (3 blocks)?

That will be my last question. I am very grateful, I wish you a very nice weekend,

Best,

Marion

[Michiel Bliemer]

If you create a library of designs, you can keep the 8 rows because across the designs you will have plenty of variation.

Enjoy your weekend and good luck with the pilot on Monday!

Michiel

[xdupom]

Perfect! I'll do that then! All your advice was great and super clear! Very very valuable. Many thanks Michiel, I really mean it.

[xdupom]

Dear Michiel,

I have now run the pilot and I realize that 8 choices (+ the rationality test at the end) is too much: it seems to discourage the companies to answer. Therefore I am thinking of presenting them with only 4 choice sets (+ rationality test at the end). I have a few doubts regarding how to do that though.
As you suggested, I generated a library of designs according to the status quos. There are 24 possible status quos in total (resulting from different combinations of attribute levels), meaning I have 24 individually optimized designs.

1 - For each of these 24 status quos, can I generate a design with 4 rows only (instead of 8) ensuring that each price level appears once (instead of twice before)? Ngene does generate such a design although efficiency is lower (divided by 2.5 approximately). Are 4 rows enough in terms of variation of attribute levels? Or is it a too big sacrifice in terms of efficiency?

2- An alternative would be to generate 8 rows and block the design into two parts. That would be my preferred option but my concern is that very few (or only one) respondents might end up in some status quos, resulting in e.g. only one of the blocks being showed to these few respondents. Is that a big problem?
Indeed, I work with companies so I might get only 80 or 100 respondents maximum. However, they vary a lot in terms of status quos (price of their product especially) and it is not possible to know the distribution of companies in advance, hence the 24 possible status quos in my design to make sure I cover every company type.

3- I have 4 price levels in total. If I sacrifice balance in the price attribute (ensured in 1- and 2-), then I can increase efficiency by increasing the number of rows to e.g. 5 instead of 4. But can I sacrifice that balance?

Which of 1), 2) or 3) would you suggest in my situation? Or maybe you have some other idea I have not thought about? Or maybe it is just not feasible to reduce my design to 4 choice sets, i.e. 8 is the strict minimum given my constraints?
It is a complex trade-off I am facing here (design efficiency vs number of completed surveys) :)

Again, many thanks for your valuable help.

Best,

Marion