Algorithms

The first thing you need to do is to decide which algorithm to use. The options are:

• Random
• Shortcut
• Complete Enumeration
• Balanced Overlap
• Efficient
• Partial Profiles
• Alternative specific - Random
• Alternative specific - Fedorov

If you are puzzled, don’t worry, this is not as scary as it looks. I’ll give a short description of these algorithms and when to use them. (Spoiler alert: you will be using Complete Enumeration or Balanced Overlap in most cases).

The force is strong with this one. This should be your first choice if you are not using Partial-profile or Alternative-specific designs. This algorithm assures that the levels are balanced – within attribute and across pairs of attributes (which also leads to good D-efficiency/low D-error). It penalizes the overlap, which means that if there are the same or a higher number of levels in an attribute than there are numbers of alternatives in each task, you will never see the same two same levels in a single task. Usually this is good.

There are however cases when you actually want to show the same level of attribute across at least two of the alternatives in a single task. One example is when we assume a priori that there are some levels of an attribute (rarely attributes) that dominate an impact on a respondents choice. It means that anytime we show an alternative that has a dominating level, the respondent will automatically pick up this alternative without any further considerations. If those levels are presented only once in a task, we will not be able to get information on other attributes.

However, if we manage to show them simultaneously in 2 or more alternatives within one task, respondents will need to make a choice based on secondary attributes. This algorithm is basically a complete enumeration without penalizing the overlap, which also means that it will produce slightly worse designs in case of D-errors and balance. The other very important case when we SHOULD use this algorithm is when we plan to model interactions.

This is the most complicated algorithm provided by DisplayR. Besides the number of attributes and levels, it requires specifying priors. Its main purpose is to minimize the D-error. As we usually do not use priors for design, this one is rather not very suitable for us. Also, this algorithm leads to unbalanced designs, which is less desirable.

Our typical Partial Profile conjoint does not contain any levels. However, it is also possible to make a conjoint exercise with standard attributes with levels which will also be a partial profile (meaning that not all the attributes will be displayed). By definition, those kinds of designs perform worse in terms of D-error and overall balance of attributes. Possibly we should avoid it, however sometimes clients might want to test a large number of attributes, which might be overwhelming for the respondents. We can try to mitigate the cognitive burden of respondents with partial profiles, sacrificing some accuracy.

The alternative specific designs are very handy. They allow each of the shown alternatives to have their own set of attributes and levels. Unfortunately, it does not allow common attributes (this kind of magic is provided only by Sawtooth). It is possible to merge some attributes, however after the design is created. Particularly useful if the alternatives have only a small fracture of attributes and levels common. DisplayR provides two ways of calculating these designs: random and using Fedorov algorithm. We should always consider Fedorov’s first.

An example of attribute and levels map for Alternative Specific Design:

This algorithm randomly chooses levels, usually resulting in a highly unbalanced design. It should be avoided unless other algorithms are so slow that we cannot calculate a design within the current century. The latter (Shortcut) builds a design so that the least frequently used levels of attributes are taken for a particular task or randomly when the frequency is equal. Usually produces slightly worse designs than Complete Enumeration or Balanced Overlap, but since the algorithm is very simple, it is also fast, which might come in handy for some edge cases.