How do you check KoboToolbox data quality before analysis?

Oct 12 2026 · Templates

Five checks that catch bad survey data before it reaches your report: completeness, duplicates, outliers, skip-logic and enumerator patterns.

Why run data-quality checks before you analyse KoboToolbox data?

KoboToolbox form logic reduces some errors but does not remove them. Enumerators work offline, skip questions, or re-submit after a failed upload. A figure that looks plausible in a dashboard can still come from a record that should never have entered the dataset.

Set the rules before you look at results. If you decide which records to drop while you already know which way they pull the average, you will make biased choices without noticing. The Kobo to report toolkit at /store/kobo walks through the export, check and write-up sequence in that order.

What are the five checks to run before analysis?

1. Completeness: required fields are present and non-empty, and you know how many forms came in with the minimum completed.
2. Duplicates: the same respondent or household appears twice, usually from a re-submission or a shared device.
3. Outliers: values outside the plausible range for that question, including ages, yields, plot sizes or expenditure.
4. Skip-logic violations: answers that exist where an earlier response should have made the question irrelevant.
5. Enumerator patterns: one enumerator's submissions are too uniform, too fast, or clustered at a single value.

How do you check completeness and duplicates?

Export to CSV or XLSX and work on a copy, never on the live project. Count blank required fields by question and by enumerator. A single enumerator with blanks across many forms usually points to a training or device problem rather than random missingness.

For duplicates, match on your unique respondent ID first. Where no ID exists, match on a combination of name, location and interview date, then review near-matches by hand. Automated fuzzy matching produces false positives on common names.

How do you spot outliers and skip-logic violations?

Outliers are best caught by ranges set at the design stage. If the form accepts an age of 200 or a harvest of 90 tonnes from a half-hectare plot, the check has to happen afterwards instead.

• Set hard constraints in the form where possible, so impossible values cannot be submitted at all.
• After export, filter each numeric variable against its plausible range and review every flag by hand.
• For skip-logic, cross-tabulate the gating question against the dependent one. Any cell that should be empty but is not is a violation.
• Note whether a violation came from the form logic or from manual editing after submission.

How do you catch enumerator patterns?

No single indicator proves fabrication, but a cluster of them is worth a closer look.

• Interview duration far below the median for that questionnaire.
• The same answer selected for every item in a long grid, or straight-lining on Likert scales.
• GPS points identical across interviews, or outside the assigned area.
• Submissions clustered at unusual hours.
• Unusually few corrections, notes or refusals in one enumerator's batch.

Review a sample of that enumerator's records against the paper trail or a callback. Then decide at programme level whether to re-interview, exclude, or keep the records with a written note.

What should your exclusion log contain?

1. The date the check was run and who ran it.
2. The dataset version or export date.
3. The number of records before the check.
4. The number flagged, and the rule used to flag them.
5. The number fixed and the number excluded, with the reason for each.
6. Who approved the decision.

Store the log with the dataset, not in a separate folder. /store/vault keeps the data and the log together, so the version you report from is the version you can defend.

When should you fix a record rather than exclude it?

Fix a record when the error is traceable to a single field and you have a reliable source to correct it against: a paper form, a callback, or the enumerator's own note. Exclude when the interview as a whole is in doubt, or when the missing data sits in a variable your analysis depends on.

Never impute silently. If you fill a gap, say so in the log and in the limitations section of the report.

How do these checks fit into your wider M&E workflow?

These checks sit between data collection and analysis. In a typical cycle they follow the final collection round and precede the first draft of results, so the numbers in your report and the numbers in your log agree.

Two practical links. Your indicator definitions should state the plausible range for each numeric variable, so the outlier check has something to test against; write that once at design stage and the checks become mechanical. The indicator library at /store/indicator covers this, and the evaluation plan templates at /store/evalplan show where verification steps sit in the timeline.

If you are building forms from scratch, the tools directory at /tools and the logframe template at /blog/logframe-template-google-sheets are useful companions. Members get the check templates in editable form through /membership, and if you would rather have the workflow assembled for you, see /store/finder or book a call at /book.