Using the right software for market research tracking studies

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
• The data locations change
• Variable dependencies change (I’ll explain fully below)

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.