Storing intermediate variables for auditability

Dynamic calculations displayed directly to respondents without being stored make auditing impossible. Store intermediate values as survey variables before displaying them.

Why storing intermediate calculated values in survey variables is essential for auditability, how to implement it, and what problems it prevents when something goes wrong during fieldwork.

Ben White, 09.07.2026

The auditing problem with on-the-fly calculations

Many surveys include dynamic calculations - attribute levels derived from the respondent's reported reference journey, price adjustments based on income, derived scores from earlier responses. These can be computed and displayed directly to the respondent without being stored anywhere in the response data.

When a respondent reports a problem - 'the prices shown were unreasonable' or 'the options didn't make sense' - diagnosing what was actually displayed requires reconstructing the calculation from the respondent's inputs. If the calculation logic has been updated since that respondent completed the survey, the reconstruction is impossible. What was shown is lost.

Stored values make problems diagnosable

If the calculated value is stored in the response data, diagnosing any problem is straightforward - the value that was displayed is in the dataset. If it was wrong, the error is visible. If it was correct, the respondent's complaint can be evaluated against the actual displayed value.

Stored intermediate values also make the analyst's job easier. Derived variables that would otherwise need to be reconstructed from inputs in the analysis script are already in the dataset, correctly computed at the time of display.

TLDR Quick links

Pivot and status quo experiment design

Soft launch and fieldwork monitoring

How to store intermediate values

For every dynamic calculation that affects what a respondent sees, create a derived value question to store the result. In SurveyEngine this is a derived value element; in other platforms it is a piped or calculated variable. The element computes the value and stores it in the response data without displaying it to the respondent.

Name the stored variable clearly and include it in the data dictionary. A variable named 'calc_travel_time_alt1_c1' is unambiguous; a variable named 'dv1' is not.

Store the inputs as well as the outputs. If the calculation depends on a reference value collected earlier in the survey, confirm that value is also stored - not just the derived result.

For pivot designs in transport SP studies, store each computed attribute level for each alternative in each choice set. This allows complete reconstruction of what was shown to each respondent, independent of any subsequent changes to the calculation logic.

Auditing a pivot design

A transport SP study uses a pivot design where attribute levels are computed from each respondent's reported journey time and cost. The computed levels are displayed in the choice tasks but initially not stored in the response data.

Midway through fieldwork, a respondent contacts the research team reporting that one of the alternatives showed a negative travel time. The calculation logic is checked and a boundary condition error is identified - respondents reporting very short journey times receive a -20% pivot level that produces a negative value.

Because the computed levels were not stored, it is impossible to determine how many respondents were affected by the error. The entire dataset is treated as potentially compromised. If the computed levels had been stored, the affected respondents could have been identified precisely and excluded, saving the remainder of the dataset.