Most explanations of a codebook stop at the definition: a list of categories with codes. That's the codeframe, and we cover it in What Is a Codeframe?. This post is about the other half: the working document a coder opens every day, and what has to be in each entry for two people to code the same response the same way.
If you have ever inherited a codebook from a previous wave and found a code called "Service 2" with no definition, you already know why this matters.
The fields every code needs
A codebook entry that only has a name is a label, not an instruction. The minimum that makes a code applicable by someone who did not write it:
- Code number. A stable integer. It is what ends up in the SPSS file, so it must not be reused or renumbered between waves.
- Label. Short, in the words a client would use on a slide: "Delivery took too long", not "Logistics".
- Category (and subcategory, if you use them). The group the code rolls up to in reporting.
- Definition. One or two sentences on what belongs here.
- Examples. Three to five real verbatims, including at least one that is borderline.
- Sentiment or direction, when the study reports it.
A worked example
One entry from a codebook for the question "What could we do to improve your experience?" in a retail satisfaction study:
| Field | Value |
|---|---|
| Code | 14 |
| Category | Delivery |
| Label | Delivery was slow or late |
| Definition | The respondent complains about how long delivery took or that it missed the promised date. |
| Examples | "It said 2 days and took a week." · "Arrived after the event I bought it for." |
| Does not include | Damaged on arrival (code 16). Courier rudeness (code 21). "Shipping costs too much" (code 12). |
The last row is the one most templates leave out, and it is the one that prevents most disagreements. Two codes that sit next to each other are only separable if each says what the other one takes.
Edge-case rules: the part that grows
A codebook is not finished when you write it. Around the second week of coding, decisions get made that belong in the document: "a response that names a specific store employee goes under Customer service, not under that employee's own category." If that decision lives only in someone's head, the next coder, or the next wave, will make it differently.
Keep these as a short dated list at the bottom of the codebook, or as an instruction attached to the question. In Survey Coder Pro each question has a free-text coding guidance field that is passed to the model as instructions, which is the right place for rules like this: they are applied on every response, not just remembered.
The Other code
Every codebook needs a catch-all, and it needs a rule. Two decisions to write down explicitly: which code number it is (many teams fix a number such as 98 so it is the same across studies), and what share of responses it is allowed to hold before you treat it as a signal that the codebook is missing a category. If it is a large share, the problem is the codebook, not the respondents.
Versioning across waves
On a tracking study, the codebook is the instrument. Three rules keep it stable:
- Add, do not renumber. A new theme gets a new code number at the end of its category. The old codes keep theirs.
- Retire, do not delete. A code nobody used this wave stays in the file so the trend line has a zero rather than a hole.
- Record why. A one-line change log ("wave 9: added 31 'Subscription pricing'") is enough.
More on this failure mode in tracking studies and codebook consistency.
How this maps to a coding tool
In Survey Coder Pro the codebook is per question and can come from three places: generated from a sample of the real responses, imported from an Excel workbook you already have, or written by hand. When you import, you map your columns (Category, Label, Code, and optionally Subcategory, Definition and Examples), and the workbook can be saved at the study level and reused by every wave. A codebook can be set to strict, which blocks the model from proposing new codes during review, for the studies where the frame must not move. Codes can be reviewed by someone else through a share link: the reviewer can approve or request changes and comment on individual codes, and only the first decision on a link is recorded, so send one link per round. You can download the finished codebook as Excel, choosing which columns to include.
Frequently asked questions
What is the difference between a codebook and a data dictionary?
A data dictionary describes the variables in a dataset: names, types, value labels. A codebook for open-ended questions describes the categories used to code the text, with definitions and rules. In a delivered SPSS file the codebook shows up as value labels inside the data dictionary.
How many examples should each code have?
Three to five is enough. One should be a borderline case, because that is the response a coder will hesitate over.
Can I start from a template?
You can, but read fifty to a hundred real responses before you finalise it. A codebook written from the questionnaire alone misses the themes respondents actually raise.
Who should approve the codebook?
On agency work, usually the client or the project lead, before coding starts. It is much cheaper to change a code before it has been applied to two thousand responses.
Next steps
For the definition and the difference between a codebook and a codeframe, read What Is a Codeframe?. For the whole process the codebook plugs into, see survey coding. If you want to see a codebook generated from your own text, the free open-end coding tool takes up to 100 responses and returns the codebook as an Excel file, no account required.