Editing live surveys

There are two primary considerations if edits to a live survey may be required: the effect the change will have on existing data structures, and how it will affect the survey-taking experience and data collection for respondents, for both in-progress and inactive respondents that return to the survey. It is because of these two issues that the platform now allows "Dev" and "Pub" versions of a survey to exist. Make the changes in a Dev (Development) version of the survey, and then once tested and with client approval, those changes may be published so that they can be merged into the live version of the survey.

Impact on existing data structure

The content of the programming change can impact existing data structures in many ways. If the code only introduces new questions or options, the impact is minimal. In the case of a new option for a radio (single-select) type question, the data layout does not change at all. However, adding an entirely new question will add at least one column to the data map/layout, or even multiple columns if the new question is a checkbox (multi-select).

Ultimately, adding questions or options does not affect the integrity of the data. The data stored for a given variable will remain there provided the type (e.g., radio or checkbox) or name of that variable does not change. However, the data structure (the number and order of the columns) could be shifted. The potential downside is that researchers often begin analysis during fielding, under the assumption that the data map or layout will not change. This could cause additional work for them.

Edit with care

Careless editing can have a more serious negative effect on data. For example, questions should not be renamed, and options should not be deleted outright. Renaming a variable or changing its type can disassociate the variable from the data collected for it. Deleting options will cause those codes to disappear from the data file. The best practice is to hide the question or option with a logical condition so that respondents cannot see it, rather than deleting it outright. This will allow the question or option, and its associated data, to be present in the data file, but not seen by any additional respondents.

Consider the respondents

The survey taker should be similarly considered when making programming changes. Does a change add or remove questions? If so, the page count may be altered. Respondents who started a survey before the change and finished it after the change is in place might jump forwards or backwards in a survey due to the shifted page count. The best course of action in these circumstances is to pause fielding of the survey, and to reset inactive respondents in-progress back to the first page of the survey. Alternatively, inactive respondents can be re-statused and removed from the survey, or they can be "locked out" unable to return.

Proceed with caution

If there is any uncertainty about the potential consequences a programming change might have on the data structure, the safest course is to make the changes in a Dev version of the survey and postpone publishing. Then, an export can be created to review the impact on the data set, without collateral damage, and the survey may be published afterwards.