Why and how to create coding variables 🔗
Although all answers to all questions are saved anyway, we recommend using coding variables. There are several advantages to using coding variables:
If you are using the
*backbutton, and if a participant changes their mind about a particular answer, then when they go back and click an answer again, their answers will appear in the datafile CSV as two separate answers separated by a bar (e.g., "yes" | "no"). If you've created a coding variable for that question, however, only the final answer that the participant gave will be stored in the datafile CSV in the coding variable column. This is useful if you want to be able to quickly analyze the final answers that were chosen.
- Coding variables can save you time in multiple other ways as well. For example, if you create a variable that is coded as "1" when someone has given a particular answer of interest and a "0" when they give any other answer, you will then be able to quickly ascertain the proportion that gave this answer of interest using the datafile CSV without having to use any spreadsheet text-searching functions.
Here are some tips on creating coding variables:
We recommend naming each variable clearly and leaving as
little room for misinterpretation as possible. This may lead
to some longer variable names, but we argue that this is far
better than using unclear, indistinct, or misleading variable
- If you want to input particular variables using query string parameters, you can also define shorthand versions for these variable names elsewhere in the program. For tips on doing this, see this section .
- If scales are repeated across multiple questions, we recommend defining an answer scale at the start, so that you don't have to code each question separately.
- Please see the other subheadings in this section for examples of each type of question.
Next: How to design questions that ask participants to choose one item from a set of options