Survey versioning and content review management

Survey versioning is not a technical nicety - it is the only mechanism that allows changes during live fieldwork without corrupting existing response data.

How survey versioning works, why parallel content revision is poor practice, and how to structure the editing and review workflow to avoid introducing errors during fieldwork.

Ben White, 09.07.2026

What versioning is and why it matters

A survey version is a snapshot of the survey instrument at a point in time. Each time the survey is published, a new version is created. Respondents who began the survey on version 2 continue on version 2 even after version 3 is published. New respondents start on version 3. Version numbers increase monotonically and are recorded in the response data.

Without versioning, any change to the survey instrument affects all respondents - including those mid-completion. Response data collected before and after the change is mixed without any way to distinguish which version each respondent saw. This is not recoverable in analysis.

Parallel editing introduces uncontrolled errors

When multiple editors work on the same survey simultaneously, changes made by one editor may conflict with or overwrite changes made by another. The final published version reflects whoever saved last, not the intended combined result.

Content review run in parallel with editing has the same problem. If the reviewer is commenting on version 2 while the editor is building version 3, the reviewer's comments may apply to elements that have already been changed - generating confusion about whether the comment is still relevant.

TLDR Quick links

Pilot study design for a DCE

Soft launch and fieldwork monitoring

A versioning and review workflow that works

Publish at meaningful checkpoints, not continuously. A typical checkpoint schedule: version 1 for initial colleague review, version 2 with complete content for content review, version 3 as the final pre-live version for panel link testing, version 4 with test data cleared for live fieldwork, version 5+ for minor corrections during fieldwork.

Separate editing and reviewing roles. Only one person edits the live project at a time. Reviewers receive a link to the published survey (not editor access to the project) and provide feedback on the published version. The editor implements all changes in a single session and publishes the next version.

Break review into two phases. The first phase allows substantive changes - additions, deletions, reformulations. The second phase allows only verification - confirming that the first-phase changes were implemented correctly. This structure guarantees the process terminates.

Set explicit expectations about the number of review rounds before the process begins. If reviewers know they have one round of substantive changes, they use it more carefully than if they believe the process is open-ended.

Version management in a multi-site study

A multi-country health preference study involves three country teams each contributing country-specific content. Version 1 is published for each team to review independently. Version 2 incorporates all three teams' feedback. Version 3 is the final pre-live version, reviewed by the principal investigator only for verification. Version 4 clears test data and goes live.

After three days of live fieldwork, a minor wording error is identified in one country's version. Version 5 corrects it. The response data distinguishes versions 4 and 5 - respondents who saw the incorrect wording are identified and their responses are reviewed separately to confirm the error did not affect their choices.