Session 7 was about the Experimentation approach in MKTR. Some big picture insights:
- Experiments are a very powerful confirmatory tool that can be applied in a variety of business situations.
- Experiments are gaining widespread acceptability in business as the cost of conducting them drops and the benefits derived pile up (i.e., their ROI keeps rising)
- The colloquial usage of the term 'experiment' often confuses people. In MKTR, and in the Research in general, 'true' experiments test treatment against an equivalent control group to cancel out extraneous effects.
- Experiments rely on logical hypotheses and measurable outcomes.
- While web-based and services firms were the first to leverage this powerful tool, product based firms are finally getting into the act - testing innovations big and small is now commonplace in even FMCG and engineering goods firms.
- Many firms go with pseudo- or quasi- experiments when the exacting conditions required for a true experiment may not be justified under the cost/benefit calculations.
Admittedly this year, in general, am quite happy with my own time-management in class - most classes have had a fair amount in-class Q&A time and have tended to end on time. However, Session 7 was quite a bit rushed towards the second half and I felt the conjoint portion for once could certainly have doen with more time.
To make up, here's a lengthy, colloquial blog-post on how you may want to use metric conjoint analysis for your project, for example.
Suppose your project R.O. says:
R.O.- Find customers' atribute preferences for Breakfast Noodles
Since you're asked to find attribute preference (or attribute importance) in a bundle of attributes, this is a clear cut case for conjoint analysis application.
You determine through qualitative study that Breakfast noodles product has five key attributes along which people tend to evaluate it: (i)Price, (ii)PackSize, (iii)Brand, (iv)Whether there are special flavors or not and (v) whether it is 'vitamin fortified' or not. You can make the attributes and attribute levels table in Excelf or MEXL analysis thus:
Notice that while the attributes are clear cut, the use of "High", "medium/low" in the attribute levels is imprecise. Who knows how different respondents may view or understand it? Hence, if your product development and competition benchmarking is fairly advanced, then you should ideally put in hard numbers there as far as possible. For instance, see below:
Clearly, there are two vertically differentiated bundles {assuming people will generally tend to prefer a well-known international brand (Nestle) over a well-known Indian one ('Parle') over an unknown local one 'Desi'}
Now prepare a set of product bundles for respondents to evaluate. They shouldn't include the vertically differentiated bundles as far as possible, in order to better force trade-offs in the purchase decision. Say you choose 8 bundles to show:
The hard 'design' part is over, its time to program the Qs you have into a websurvey. The bundle rating questions may look like this in qualtrics:
Ensure the bundles are presented to respondents in randomized order to avoid (or rather, to average out) any order effects.
Like I mentioned in class, metric conjoint is practically obselete now. Firms have moved on to choice based conjoint (or, CBC) in which you would present a bouquet of bundle options in each 'choice task' (e.g. like the one below) and the respondent makes a binary choice - picks one bundle as most preferred in the bouquet. See below for how a CBC choice task might look like when programmed into a web survey:
In the above figure, I couldn't figure out how to get Qualtrics to have both the image and the multiple choice question together in one question, so I did them as separate questions and grouped them together.
Chalo, I hope that helps clarify the conjoint part of what is going on. Metric conjoint interpretation is fairly straightforward and MEXL help is quite good, I hear. Should you require specific assistance in interpreting conjoint results for your projects etc, pls let me know and we can go over it individually.
Sudhir
No comments:
Post a Comment
Constructive feedback appreciated. Please try to be civil, as far as feasible. Thanks.