Market research tracking studies are a valuable source of revenue for many research agencies. However, most of the software used in market research struggles with the practicalities that face researchers and data analysts when analysing tracking data. This article looks at the problems most software has with handling tracking studies and, as importantly, looks at the importance of productivity and efficiency. Fortunately, MRDCL is one of the few products that manage trackers effectively, regardless of the data source. See why.
Tracking studies get easier and easier – right?
In theory, managing a tracking study should get easier and easier. Indeed, this is true in some ways. Staff working on a tracking study become more and more familiar with what it takes to handle it efficiently and to a client’s satisfaction. However, for data processors and data analysts, the task often gets increasingly complex. Any problems tend to compound over the life of a tracking study, and something that started as easy can become burdensome. Often, the software can be the root cause of problems associated with handling tracking studies.
The big problem: Questionnaires change
Regardless of intentions, the questionnaire used in a tracking study is likely to change at some point. This need means that the data processing software has to be able of handling these changes. What are these changes? They break down into five broad categories:
There are new questions or new rating statements
There is a need to remove some questions, permanently or temporarily
The code lists change, e.g. when there are new brands, brands merge, brands disappear
Let’s look at each of these categories in more detail.
1. Tracking studies need new questions
Clients will almost always want to add a question or two (or more) to get feedback on new issues that arise. Most data analysis software platforms can handle this scenario fairly well. The main requirement is to filter results on the periods that the question appears on the questionnaire. When there are rating statements, it is particular likely that clients will want to change the questionnaire. If there are any regular changes, this can be cumbersome to implement.
2. There is a need to remove some questions, permanently or temporarily
In essence, this is the same issue as adding new questions. There is a need to filter results on the periods that a particular question appears on the questionnaire. Again, this can become time-consuming and prone to error if there are no tools for automation. While many software products may have tools to meet this need, editing filter definitions manually for every wave is not desirable.
3. The code lists change in tracking studies
We are now approaching the things where most software products start to fall down or groan under the weight of the problem. Just as the questions may change, there may be occasions where the responses for each question need to change. In basic terms, it means that what was code 4, perhaps, needs to become code 5. This requirement often leads to one of two courses of action – physically recoding all the back data to correspond to the current questionnaire format or complex programming to merge the old code 4 with the new code 5. Effectively, this is the same solution; one physically outputs a new data file, the other does all the work behind the scenes. Nonetheless, it is prone to error and can become unmanageable where there are regular changes like this.
4. The data locations change
When questionnaires change, the field where the software platform stores each question may change. The standard response by many software suppliers is that a database stores the data for each question by variable name, so it doesn’t matter. That is probably true if the whole project is collected and analysed in one product. If the data needs to be available on a wave by wave basis in another product, this is almost certainly a problem. The majority of data collection platforms, for example, will offer no control over how your data is output as a CSV file or as ASCII format. Or, if they do, it is another awkward task, which is prone to error.
5. Variable dependencies change
If you have a tracking project of just average complexity, you may want to build variables for analysis from the original questions. These variables are likely to be in terms of codes or sequential responses. If any of the scenarios above are true, these variables may need updating as well. This task can be highly time-consuming, complex and, again, prone to error. Please take a look at my anecdote below, where we were able to reduce variable dependencies from 20 person-days per month to just a few hours per month using MRDCL – and most of that time was carrying out checking final outputs.
Exporting data for other uses
If you need to export or transfer data for other purposes – such as dashboards, multivariate statistical analysis, client databases – the problems discussed above can become real time-consuming burdens for you. That’s why there is a big difference between software that can handle tracking studies and software that handles tracking studies well.
A client was struggling with a project for several reasons. Firstly, the questionnaire changed every week. Secondly, the brands and their sub-brands changed most weeks. The pricing plans for each sub-brand changed quarterly on average. From time to time, sub-brands merged. Occasionally, brands merged. There was an average of 20 brands, consisting of almost 100 sub-brands and over 1000 price plans per year. The project was four years old when we helped our client transfer the project to MRDCL. After two months’ work extrapolating all the data, the number of days spent per month on the project reduced by over 90% from 20 days to just over one day. I doubt many software products could handle the complexity of the analysis and, certainly, not the complexity of the data itself. Further, the tables themselves were too complex for most other tabulation software products.
MRDCL and tracking studies
Finally, let’s look at why MRDCL is so good for tracking studies. Broadly, MRDCL can handle all the five problems I have cited efficiently, but there are five key points:
MRDCL allows you to build customisable templates to manage the ‘moving parts’ without using highly skilled staff.
MRDCL is a convenient way to document questionnaire changes to be more of a clerical task than a highly skilled programming task.
You never need to recode data physically. Personally, I think recoding data is one of the most dangerous operations to carry out. Automation and templates are far less risky.
MRDCL allows you to keep an audit trail of the history of a tracking study.
You can apply variable dependencies automatically so that there is no manual updating of complex variables.
MRDCL: a summary
MRDCL may not be the only tool to manage tracking studies effectively. Indeed, simple customer feedback surveys of three or four questions rarely need the power of MRDCL. However, MRDCL can deal with unexpected issues that may arise during the life of a tracking study. The project described in the anecdote grew too big and almost impossible to manage within the original platform used. Fortunately, transferring the project to MRDCL allowed the client to retain the project for several more years.
If you want to know more or discuss your tracking study, please contact me.
Meadow View House
Kent TN3 0RT