Have an idea?

Visit Sawtooth Software Feedback to share your ideas on how we can improve our products.

Merging 2 attributes for the analysis


I am analyzing profile-case MaxDiff data & have some monotonicity problems with some levels. I wanted to merge some of these items (consider 2 items chosen as the equal) so that in the analysis they will have the same preference value in the Logit and the Latent class estimation. How is this possible?

asked Jan 17 by AMYN Bronze (2,980 points)

1 Answer

+1 vote
Best answer
If I'm understanding correctly, you have a Best-Worst Case 2 (the "best-worst conjoint" or "profile" case MaxDiff).  

So, this type of MaxDiff looks like the conjoint design case, where there are different attributes (factors) such as brand, speed, and price and multiple mutually-exclusive levels within each attribute.

You are currently seeing reversals, but instead of dealing with them in the standard way where the analyst specifies that one level is to be preferred vs. another level, you are wanting to merge some items so that instead of having 2 items (levels), you want the design and analysis to consider that these separate levels were actually the same level and should get the same utility estimate.  

I'm assuming these multiple levels to be combined are levels within the same attribute.

Also, I'm assuming you are using our Lighthouse Studio software, which has MaxDiff as a component.

There are multiple ways to do this in our software, requiring some extra data processing and file manipulation.

Approach 1 is to create a copy of your current Lighthouse Studio MaxDiff project using the Save As feature.  Then, export the Design from the Design tab to a .CSV file using the Import/Export button.  Modify the design to renumber the items such that the two levels now are the same level and the other levels are consecutive integers following the recoding.  You also modify the item list in MaxDiff to remove the one item and so that the items now match the numbering in the modified .CSV design file.  Then, import the new design file using the Import/Export button.  Next, your data file no longer matches the new scheme.  So, you have to delete your respondent data file for the duplicated (copy) of the project.  And, you can bring the data over again from the original project using the "paper and pencil import" approach.  There is documentation in Lighthouse Studio software for using paper-and-pencil data collection.  It involves storing the respondent ID, MaxDiff Design version number, and responses to the best-worst questions in a .CSV file.  Then, it involves importing that .CSV file containing the respondent version# and answers using the "paper-and-pencil" option in the Data Management + Get Data tab.

Approach 2 is to use the original project with the two levels to be collapsed still represented as two levels...but to export the MaxDiff data under Data Management + Export Data to a .CHO file.  This is a dummy-coded file using the .CHO format that needs to be analyzed using the standalone Latent Class Module or the standalone CBC/HB module.  You would need to manually modify this file to delete a column from the design matrix (representing the level to be deleted) and you'd need to modify the rows corresponding to the row to be deleted to show that the level shown to respondents now is the same as the new collapsed level.

I think Option 1 is probably the easier of these two.

Both approaches require multiple steps (and I may have forgotten to list a detailed step that is required).  

So, the summary position is that it's complicated to collapse two levels in our software for utility estimation.  The shortcut approach (which is not statistically proper) is to not bother collapsing the two levels in the experimental design, but just to average the two utility levels after utility estimation.  It will approximate the more proper approaches above and would save a lot of time.
answered Jan 20 by Bryan Orme Platinum Sawtooth Software, Inc. (172,790 points)
selected Feb 7 by AMYN
Hi Bryan,

Thank you very much for your detailed reply. All your assumptions are correct and Sorry for not explaining them clearly in my question.  My first choice was to indicate (forcefully) that the levels which are not monotonic are arranged according to a certain logical arrangement, this approach worked fine for almost all the levels and is by far very acceptable. As you know in academia, professors tend to stick to the methods they are most familiar with or that have been used before and I might be forced by some reviewers to try this way of handling the monotonicity issue, thus I wanted to know how complicated it can be.
Thanks again for the final suggestion that might save a lot of time and will keep it in mind if needed.