Why MRDCL is efficient at producing analysis from tracking studies

There are many market research tabulation or crosstab software packages available, but few handle tables from tracking studies as well as MRDCL. Tracking studies often provide valuable revenue for market research agencies and most parts of the research process usually become easier to manage throughout the tracker’s existence, however, the data processing, tabulations and reporting of tracking studies often present problems.

Questionnaires often change during the life of tracking studies

Tracking studies often start life with the intention of the questionnaire rarely or never changing – or, at least, only having minor changes from time to time. The reality is that over the course of a tracking study, the questionnaire will often change, sometimes quite significantly. The questionnaire changes can make reporting data from different questionnaire versions difficult in many software analysis systems. This article will explore the problems encountered handling the data processing of tracking studies and the problems that many software products have. After this, a review of MRDCL’s solution to each problem will follow.

Problem 1 – Questions are added or removed

It is quite common for there to be a need to add or remove questions in a tracking study. This may be because there are new topical questions to ask or that refining the questionnaire can provide more valuable feedback. Also, researchers may need to add or remove certain statements to reflect changing or, perhaps, seasonal needs.

Problem 1 – how most software handles (not MRDCL)

Most software will allow filters to be placed on questions so that respondents who answered the question will appear in any analysis. Some may do this automatically; others will need a filter to be specified. An alternative solution used by some software is for questions to be held in a database so that the software stores entries by question name. This approach can solve the problem but become confusing as it is desirable to name questions logically – e.g. q1, q2, q3, q4 etc. at the outset. Later, the names may become q1, q99, q4, q3 if there is a need to remove a question or re-order the questions.

Problem 2 – Responses to questions (such as brand lists) change

Over and above, the adding or removal of questions, there is often a need to change the responses to questions. This change might be due to new brands being available or a need to change the questionnaire to collect more detailed data or forming precodes due to a high number of other answers.

Many software systems struggle when confronted with this problem. Most software packages work on the principle of each response having a code assigned. Where there is a need to add a new code, this may mean pushing the codes to the next code from the point where the extra code appears. It might also add to complications where the researcher wishes to randomise codes or show the codes in forward and reverse order.

Problem 2 – how most software handles (not MRDCL)

Most software packages deal with this tracking scenario by recoding the data, so that code 5, for example, at one wave of data is recoded as code 6 at the next wave. This solution can be time-consuming to implement as well as being prone to error.

Problem 3 – Data layouts change

Combined with the first two problems, the layout of the data may change. By this, I mean the physical location it appears in the data. This solution may mean that the data needs to be recoded to a ‘master’ format so that it is compatible with all waves of the survey.

Problem 3 – how most software handles (not MRDCL)

Software products that store data on question name basis tend to handle this quite well, but others will not. Most software products will need to recode the source data or perform a function that matches the data to one master format. This operation is likely to be time-consuming and prone to error. Our QPSMR software handles this problem by having a data handover facility which automatically recodes backdata to the latest format.

Problem 4 – Categorisation and variable building may be datapoint dependent

There is often a need to build variables from data that you will need to update during the existence of a tracking study. Let’s take an example. Let’s say that you start with 20 brands that you want in a variable of three categories indicating whether each brand is expensive, averagely priced or cheap. As brands change, you are likely to need to change the variable indicating whether each brand is expensive etc.

Problem 4 – how most software handles (not MRDCL)

Most software will require the user to update the variable definitions with each cut of data. This problem is likely to be time-consuming and prone to error. A master coding sheet is the preferred solution when using MRDCL.

Problem 5 – Period analysis (or rolling periods)

It is quite common to analyse data from tracking studies by periods. These may be months, quarters, years, rolling periods or some other timescale analysis. This task may take time to prepare each time that you require data reports or there may be some difficulties where one of the above four problems are apparent.

Problem 5 – how most software handles (not MRDCL)

Many software packages are not geared up for this type of analysis. While it may be possible to set up period analyses, this may need manual implementation each time reports are required.

Problem 6 – Different software may be used to collect data

This problem is, to be honest, a variation of Problem 3 except that it can be more problematic. If there is a need to change software for data collection, the data map will likely be different from the one from the previously used product. This issue necessitates the same solutions as cited in Problem 3. However, the problem is often greater as different products will tend to store data in completely different ways making data recoding labour-intensive. For example, multiple response questions are stored in different ways by market research programs. Recoding that data may be quite difficult to implement.

Problem 6 – how most software handles (not MRDCL)

The solutions here are the same for Problem 3 in most cases. The scale of the problem, though, is likely to be a greater one.

Problem 7 – Filters change

This problem is a less common problem, but there are occasions when the respondents that route to specific questions can change throughout a tracking study.

Problem 7 – how most software handles (not MRDCL)

The logic required for filter definitions can become quite complex when there are differences during a tracker’s history. Some software may struggle to allow such complex filter definitions.

Why MRDCL is different – The Overall Problem

The heart of the problem for most software packages when it comes to processing tracking studies is that changes to the questionnaire and the data cause one or more of the following problems:

• It may not be possible to handle
• It requires recoding
• It is time-consuming to implement
• It is prone to error

The solutions usually revolve around writing a complex script or multiple recode specifications. These specifications tend to be poorly documented, embedded in the code of the project and not passed on coherently as new staff work on the project. This issue is a very real problem that is often under-estimated.

Why MRDCL is different – What’s different?

In a nutshell, MRDCL has tools that let you use templates that make all your work visible, easy to share or pass on to colleagues and easy to manage with most things being fully automated. To counter the four problems caused by most other software:

• It will be possible to handle
• It will not require recoding
• It will not be time-consuming
• It will be far less prone to error

Why MRDCL is different – How MRDCL handles tracking studies

So, what are these templates that make handling tracking studies so efficient and adaptable? The answer is that you have two options. You can either design your custom templates that handle whatever complications your tracking survey presents or you can use a template that already has every eventuality built in. We call the ready-made template the OnTraq template. It is supplied by MRDC Software for a one-off fee, which is to cover the cost of training and initial support. The OnTraq template has so many features that training and support for the first project or two are generally recommended, although we do offer a pay-as-you-go deal with the template supplied free of charge.

Why MRDCL is different – Do I need the OnTraq template?

Your next question is likely to be whether you need the OnTraq template or whether you should design templates yourselves. If you have a large number of trackers or trackers that are complex, I would advise on using the OnTraq template as it comes with a whole set of tools to assist you. If you have a small number of trackers or they are simple, you might prefer to design your own templates.

Why MRDCL is different – What does an MRDCL template look like?

Users build most templates in Excel (we will be adding Google Sheets as an option in 2020). Below is a very simple example. It shows Brands A, B, C and D being codes 1, 2, 3 and 4 at Wave 1 of a project. At Wave 2, we add Brand XX in the middle, and the codes move accordingly. At Wave 3, we add Brand E and remove Brand B. You can see that managing this template is more of a clerical task. The way MRDCL works is that a once-written generic script will read the worksheet and read the different coding systems at Waves 1 to 3 without a line of MRDCL code changing. In other words, you only script once, after that it is automatic.

This example is just one example of a simple template. The other problems that I mentioned can be handled using similar techniques.

Why MRDCL is different – automating templates

For more skilled users, it is possible to automate the updating of these worksheets. For example, where you have data maps output from a data collection software, it is possible to automate the output of these into your MRDCL custom template or the OnTraq template.

Talk to us

If you want to improve the efficiency of processing your tracking studies, talk to us, so that we can explain more fully how we can optimise your processing by understanding your needs more fully. You can contact me at phil.hearn@mrdcsoftware.com for more help.