“Other, specify” answers: reviewing and recoding them during fieldwork

What “other, specify” is for

A single-choice or multiple-choice question offers a fixed list of options. However carefully the list was piloted, some respondents will give an answer that isn't on it. An “other” option catches those answers, and a text question that follows it (the “specify” variable) records what the answer actually was. IPA's guide to specify variables describes the same pairing: the specify text is usually triggered by “other” and stored as its own variable next to the original question.

It does two jobs. It keeps the respondent's real answer instead of forcing it into the nearest option, and it tests the list: if many people give the same answer that isn't there, the list is missing something. Both jobs only pay off if someone reads the answers while fieldwork is still running, which is why “other, specify” review is one of the daily high-frequency checks, done in batches.

Why “other” answers pile up

• The list is incomplete. A pilot in one district or one season can miss crops, jobs or sources of income that are common elsewhere.
• The respondent's words differ from the option's label: a local name for a crop, a brand name for a product, a job title the list files under a broader heading. The enumerator writes the words down instead of choosing the option.
• Long lists. On a phone or tablet, typing an answer can be quicker than scrolling to the right option.
• Translation. An option label that reads well in English can be unclear in the language the interview is done in.
• Answers that aren't answers: “don't know”, “nothing”, “same as before”. These belong to a don't-know code or to the field team, not to a new category.

Read the share of “other” by enumerator as well as by question. One enumerator choosing “other” far more often than colleagues working in the same area often hasn't learned the list, which a short session with the supervisor can fix. See enumerator monitoring for reading such rates fairly.

Setting it up in the form

Give “other” the same code in every list (96 here), a code that will never be needed for a real option. Put the specify question right after the question it belongs to, ask it only when “other” is chosen, make it required, and name it so the pair is obvious:

In the choices sheet, the crops list ends with 96, labelled “Other (specify)”. The selected() form of the relevance works for multiple-choice questions too, and the constraint stops a blank or one-letter answer. XLSForm also has a shortcut, or_other, added after the list name. The XLSForm documentation notes that it only works for questions without translations or choice filters, that its label is in English and can't be changed, and recommends relevance when you need more control, as above. SurveyLoopr's “other, please specify” tip has the same pattern for ODK and KoboToolbox.

Reviewing and recoding during fieldwork

“Other” answers don't need the same-day attention a duplicate ID or a made-up interview does. Go through them every few days, in one sitting, starting in the first week, when a gap in the list is cheapest to fix. For each question:

1. Tidy the text: lower case, no extra spaces, so “Maize” and “maize ” count as one answer.
2. List each distinct answer with how many interviews gave it, most common first.
3. Decide each answer once, using the table further down, and write the decision in a mapping sheet.
4. Apply the sheet with code that starts from the raw data, so every recode is logged and can be undone.
5. Feed what you learned back to the form and the field team.

IPA's guide recommends the same shape: export the unique answers to a spreadsheet with a column for the mapping, fill it in, merge it back in code, and keep the process reproducible and rule based. Its example recodes “sky blue” to the existing “blue” and leaves “purple” as other, adding a category only if enough people wrote it. IPA's ipacheck package has commands for both halves: ipacheckspecify exports the values given for “other, specify” questions, and ipacheckspecifyrecode recodes them. Without it:

* 1. Every distinct "other" answer for the main crop, most common first
use "raw/survey.dta", clear
keep if crop_main == 96
generate text = strlower(strtrim(stritrim(crop_main_oth)))
contract text, freq(n)
gsort -n
generate new_code = .
generate note = ""
export excel using "crop_other_map.xlsx", firstrow(variables) replace

The team fills in new_code for the answers that belong to an option and leaves the rest blank. Then the sheet is applied to the raw data:

* 2. Apply the filled sheet, starting from the raw data
import excel using "crop_other_map.xlsx", firstrow clear
keep text new_code
drop if missing(new_code)
tempfile map
save `map'

use "raw/survey.dta", clear
generate text = strlower(strtrim(stritrim(crop_main_oth)))
merge m:1 text using `map', keep(master match) nogenerate
replace crop_main = new_code if crop_main == 96 & !missing(new_code)
replace crop_main_oth = "" if crop_main != 96    // the raw file keeps the text
drop text new_code
save "clean/survey_clean.dta", replace

Keep the filled sheet and add only new answers to it on later days, so a text decided once is decided the same way every time, and in every round. For a multiple-choice question the recode is two changes: take the “other” code out of the answer and add the option's code, then make sure the 0/1 column for each option agrees. Recode only when the text clearly names one option; an answer that names two, or that you have to guess at, stays as other or goes back to the field.

What to do with each kind of answer

Feeding it back to the form

When the same new answer keeps coming up across enumerators and areas, add it to the list. Give it a new code and never renumber or reuse the codes already in use, or answers collected before and after the change will mean different things. Publish the new form version, tell the enumerators what the new option covers, and recode the earlier “other” answers with that text to the new code, so the whole dataset uses one list. Note the version and the date in the codebook. For outcome questions in a study with several rounds, agree the change with the research team first, because the list also has to match the other rounds.

Read the answers for what they say about the form, too. Many answers that are local names for listed options point to labels that need the local name; many answers that don't fit the question at all point to a question that is being misunderstood, which is a training point for the next team meeting.

How DataFlow handles “other, specify” answers

DataFlow treats a text question as an “other, specify” answer when its relevance compares another question with an “other” code (96, 97, 77, -96, -77 or other), or when its name ends in _oth, _other, _os, _specify or _spec. For each one it adds a check, “Review ‘other’ answers”, that lists every answer given. Other suggested checks start switched off when they would flag more than 5% of interviews; this one always starts on, because recoding is done in one sitting whatever the number. The answers are grouped as “other” answers to recode, marked as batch work with no rush, and an open one doesn't stop an interview from counting as ready.

When DataFlow knows which question the text belongs to, the Today list splits the answers into up to three cards:

• Answers that already have an option, when the list has an option whose label starts with “Other”: those that contain exactly one option's label as a whole word, ignoring capitals and a plural “s”. One tap recodes them all: the question is set to that option (for a multiple-choice question, the “other” code is taken out and the option added), the text is cleared, and each change is a logged correction with a reason such as “Recoded ‘maize’ to Maize”.
• Answers that look like an option. An optional recode model (multilingual-e5-small, about 240 MB, downloaded only if you ask for it and run on your computer) reads the rest, in English or Bangla, and suggests an option when an answer's meaning is close enough to its label; the bar is set so that wrong suggestions are rare. The card asks you to untick any that are wrong, then recode the rest.
• Answers that are new: none matches an option. The suggestion is to keep them as written and add a category later if one keeps coming up, and one tap confirms them.

A value can also be marked as fine for the check, such as a real crop that isn't on the list: its open items close and it isn't flagged again. Every recode can be undone, and the raw submissions are never changed. In a download, the 0/1 columns of a multiple-choice question are made from the corrected answers, and the Stata do-file replays each correction from the raw data. New options go into the form on your collection platform. From the form's own skip logic, DataFlow also suggests checks for a question answered when the form says it shouldn't be asked, or a required one left blank when it should be, which covers specify text without “other” and “other” without text. Free-text answers, “other” answers among them, are read for names, phone numbers and email addresses, and a variable where at least two answers give someone away is suggested for the encrypted personal-data store. DataFlow works alongside the collection platform: it connects to SurveyLoopr, SurveyCTO, ODK Central and KoboToolbox, and reads exports from other tools.

Step by step

1. Set up the specify question. Give “other” the same code in every list, ask a required text question right after it only when “other” is chosen, and name the pair so it is obvious, such as crop_main and crop_main_oth.
2. Gather the answers every few days. Tidy the text to lower case without extra spaces, and list each distinct answer with how many interviews gave it.
3. Decide each answer once. Recode answers that name an existing option, keep genuinely new ones as other, send contradictions back to the field, and record each decision in a mapping sheet.
4. Apply the decisions from the raw data. Merge the mapping sheet into the raw data in code, so every recode is logged, repeatable and reversible, and the original text stays in the raw file.
5. Add frequent answers to the form. When the same new answer keeps coming up, add an option with a new code in a new form version, tell the enumerators, and recode the earlier answers to it.

Questions