The Field Data Quality Standard

The Field Data Quality Standard is an openly licensed checklist of the checks a field survey's data should pass while the team is still in the field, from duplicate IDs and interview length to back-checks, personal data and the correction log. It rests on four principles: raw data never changes, every correction is logged and reversible, checks run every day during fieldwork, and thresholds are written down before fieldwork starts. Version 1.0 is published by ARCED International under CC BY 4.0.

By Mehrab Ali, founder of DataFlow · Updated 2 November 2026

What the Standard covers

The Standard lists the checks field survey data should pass while interviews are still coming in, and the rules for correcting data without losing the original. It is written for research teams, survey firms, M&E staff and the clients who commission surveys. It has four principles and 43 numbered items in 11 categories, so you can cite an item by its number (“Standard 9.4”) in a terms of reference, a quality assurance plan or a pre-analysis plan.

Version 1.0, November 2026. Published by ARCED International under CC BY 4.0: you may copy, adapt and share it, commercially too, as long as you credit ARCED International and link to this page.

Four principles

Raw data never changes. Keep every submission exactly as it arrived from the server. Cleaning happens on a copy, so you can always go back to what the enumerator recorded.
Every correction is logged and reversible. Each change records the interview, the variable, the old and new values, who made it, when and why. Code can rebuild the clean data from the raw data and the log at any time.
Checks run every day during fieldwork. Run them on each new batch of interviews, at least once a day, while the enumerator is still near the respondent and a revisit or a call costs little.
Thresholds are written down before fieldwork. Agree each check and its limits in the quality assurance plan or the contract before the first interview. If a threshold changes, record the date, the old and new values and the reason.

How to read the checklist

Each item says what it checks, why it matters, how often to run it and, where one exists, a default threshold. The defaults come from two places: arceddataflow, the Stata workflow ARCED Foundation has checked its surveys with since 2023, and the check engine in DataFlow, which grew out of it. They are starting points for a typical interview survey. Where neither sets a number, the item says “None” or “Set per survey”, because a sensible limit depends on the questionnaire.

“Daily” means every time new data arrives, and at least once a day while interviews are being done. “Weekly” items need a few days of data before they say anything useful. Skip items that don't apply to your survey, and say so in the plan.

The checklist

1. IDs and duplicates

Item	Why it matters	How often	Default
1.1 Unique respondent ID. The same survey ID appears in more than one interview.	A household counted twice, or a mistyped ID that breaks the merge with the sample and with later rounds.	Daily	Flag every repeated ID among consented interviews (arceddataflow).
1.2 Duplicates in other identifying fields. The same phone number, or another value that should be unique, under different IDs.	One person interviewed under two IDs looks like two respondents.	Daily	Set per survey: name the fields. arceddataflow checks the ones you list, such as the phone number called.
1.3 IDs match the sample. Every interview belongs to the sample list, and every sampled unit is accounted for.	Interviews outside the sample, or sampled households quietly dropped, bias the results.	Daily	None: compare with the sample list.
1.4 Form version. Interviews filled in on an older version of the form after a newer one is in use.	Older versions may lack corrected questions or constraints, so their answers aren't comparable.	Daily	Flag interviews on an older version dated on or after the first day of the latest one (arceddataflow).
1.5 Test interviews. Submissions dated before fieldwork started.	Training and pilot interviews inflate the counts and the averages.	Daily	Leave out interviews dated before the survey's start date (arceddataflow).

2. Completeness

Item	Why it matters	How often	Default
2.1 Progress against target. Completed interviews by day, area and enumerator, against the sample target.	Shows early whether fieldwork will finish on time, and where it is falling behind.	Daily	The target from the sample design.
2.2 Required questions left blank. A question that is required and always asked has no answer.	A working form shouldn't allow it, so a blank points to a programming or export problem.	Daily	Flag every blank in a required question with no relevance condition (DataFlow).
2.3 Missing answers by enumerator. The share of blank answers to each question, for each enumerator.	An enumerator with far more blanks than the team may be skipping questions.	Daily	Flag a question that is blank in 70% or more of one enumerator's interviews (arceddataflow).

3. Interview timing

Item	Why it matters	How often	Default
3.1 Interview length. Interviews that are much shorter or longer than usual.	A very short interview may have skipped sections or not happened. A very long one may have been left open or finished later.	Daily	Under 40% of the median length (and at least 5 minutes) or over 3 times the median. Before data arrives, under 10 minutes. Consented interviews only (DataFlow).
3.2 Dates agree. Start date, end date and submission date.	Different days can mean a form reopened later or a wrong device clock. A phone that syncs late explains many gaps between the end and submission dates.	Daily	Flag when the start and end dates differ, or the end date differs from the submission date (arceddataflow).
3.3 Time of day. When interviews start, by hour, for each enumerator.	Interviews late at night, or many starting a few minutes apart, deserve a question.	Daily	None: review the pattern (arceddataflow reports it by day and by enumerator).
3.4 Time per question. Seconds spent on each question, where the platform records a text audit.	A question answered in a second or two was probably not read out.	Daily, where recorded	None: compare questions and enumerators (arceddataflow).

4. Ranges and outliers

Item	Why it matters	How often	Default
4.1 Allowed ranges. Numbers outside the limits the questionnaire allows.	Catches impossible answers and typing slips, such as an extra zero.	Daily	The form's constraints. For numbers without one, limits agreed before fieldwork; DataFlow suggests some from the first answers, switched off until someone confirms them.
4.2 Outliers. Values far from the other answers to the same question, overall or within a village or team.	Catches values that are possible but unlikely: a typo, a wrong unit, or a real case worth confirming.	Daily	More than 3 interquartile ranges beyond the quartiles, with at least 10 answers in the group (DataFlow), or more than 3 standard deviations from the mean (arceddataflow). Don't-know and refusal codes are left out first.

5. Logic and consistency

Item	Why it matters	How often	Default
5.1 Rules across questions. Answers that contradict each other, such as more children in school than people in the household.	At least one of the answers is wrong, or a question was misunderstood.	Daily	Set per survey, written as XLSForm-style conditions.
5.2 Impossible combinations. Pairs of answers that should never occur together, such as a 15-year-old with 20 years of work experience.	Often the wrong person picked from a roster, or a filter question answered wrongly.	Daily	Set per survey. A cross-tab of the two questions shows which pairs to forbid.
5.3 Roster rows. Each row of a repeat group (a household roster, a plot list) checked like a question, and the number of rows compared with the count given earlier.	A roster shorter than the reported household size can mean members were left out to shorten the interview.	Daily	The form's constraints, applied to every row.

6. Response quality

Item	Why it matters	How often	Default
6.1 Don't know and refusal share. The share of an interview's answers that are “don't know” or “refused”.	A high share can mean a tired or unwilling respondent, or an enumerator who isn't probing.	Daily	Flag interviews where more than 20% of answers are don't know or refused, once at least 5 are answered (DataFlow). Codes from the form, or -999, -998, -888, -99, -98 and -97.
6.2 “Other, specify”. The free-text answers given when “other” was chosen.	Many belong to an existing option and should be recoded. The rest show options the form is missing.	Daily list, recoded in batches	Review every one.
6.3 Enumerator comments. Notes enumerators leave in comment fields and on single questions.	Comments explain odd answers and report problems before they show up as flags.	Daily	Read every comment that says something, skipping entries such as “na” or “no” (arceddataflow).

7. Enumerator performance and signs of fabrication

Item	Why it matters	How often	Default
7.1 Productivity. Interviews per enumerator per day, and days worked.	Far more interviews a day than the rest of the team can mean rushing or invention.	Daily	None: compare with the team (arceddataflow).
7.2 Flags per enumerator. Each enumerator's flags per 100 interviews, by check.	A rate makes enumerators with different workloads comparable, and shows who needs a call or retraining.	Daily	None: compare with the team.
7.3 Response patterns. Each enumerator's share of don't know, refused, skipped, not applicable and “other” answers, their consent rate, and their average interview length.	An enumerator who differs from the team on several of these at once deserves a closer look.	Daily	None: compare with the team (arceddataflow).
7.4 Statistical signs of made-up interviews. Six signs, against the enumerators working in the same area: near-copies among their interviews; numbers that vary much less than the team's; choices nearly always the most common answer; amounts in round thousands; hardly any “don't know”; and “no” to the questions that open a section.	Someone inventing answers tends to pick typical values, avoid “don't know” and skip sections. Each sign looks for one of those habits.	Daily	Near-copy: 85% of answers the same. An enumerator is flagged when the signs together put them well outside the team, with at least 10 interviews each and 4 enumerators to compare. The interviews behind the signs join the back-check sample (DataFlow).

8. GPS location

Only where the form records a GPS point and the consent and ethics approval cover it.

Item	Why it matters	How often	Default
8.1 Point recorded. Interviews with no GPS point.	Missing points for one enumerator can mean the GPS was switched off on purpose.	Daily	Flag every interview without a point (DataFlow).
8.2 Accuracy. The accuracy the device reports for the point.	A point accurate only to a few hundred metres can't place an interview in a village.	Daily	Flag points less accurate than 50 m (DataFlow).
8.3 In the named area. Distance from the middle of the other interviews in the village or area the interview names.	An interview far from its area was done elsewhere, or labelled wrongly.	Daily	Flag interviews more than 5 km from the middle of their area's other interviews (DataFlow).
8.4 Possible travel. The speed an enumerator would need to get from their previous interview to this one.	A journey no one could make means a wrong clock, or an interview not done in person.	Daily	Flag anything over 60 km/h (DataFlow).
8.5 Same spot. Several of one enumerator's interviews recorded in the same place.	Interviews filled in at one place, such as a tea stall, instead of at each household.	Daily	Flag three or more of one enumerator's interviews within 15 m of each other (DataFlow). For listing and census work, two interviews within a few metres may be the same household twice.

9. Back-checks

Item	Why it matters	How often	Default
9.1 Sample. A random share of each enumerator's interviews, asked a short set of questions again, plus interviews flagged by other checks.	It tests the interview against the respondent: did the visit happen, and do the answers hold?	Weekly, from the first week	10% of each enumerator's interviews (DataFlow).
9.2 Who does them. A back-check team independent of the enumerators and supervisors being checked.	A supervisor back-checking their own team has a reason to find nothing.	Set before fieldwork	None.
9.3 Question types. Each back-check question typed: 1, shouldn't change between visits (roof material, household size); 2, tests the enumerator's skill; 3, may change, so compared within a tolerance.	Differences on type 1 point at the enumerator, on type 2 at training, and on type 3 at the question.	Set before fieldwork	Type 3 tolerance: 10% of the original value, for amounts of money and other decimals (DataFlow).
9.4 Agreement by enumerator. The share of type 1 answers that differ, for each enumerator.	Shows whose interviews don't hold up on a second visit.	Weekly	Flag an enumerator when 10% or more of type 1 answers differ, once at least 10 answers are compared (DataFlow).
9.5 Agreement by back-checker and question. The same rates for each back-checker and each question.	A back-checker who disagrees with everyone, or a question everyone disagrees on, is a back-check problem rather than an enumerator one.	Weekly	None.

10. Personal data

Item	Why it matters	How often	Default
10.1 Find personal fields. Names, phone numbers, addresses, ID numbers, dates of birth, GPS points, photos and the phone's own identifiers, plus sensitive topics such as health or religion.	Anyone who gets these can identify respondents.	When the form is set up, and on each new version	Look at each field's name, its question and what its answers look like (DataFlow).
10.2 Personal data in free text. Names and numbers written into comments, notes and “other” answers.	Rules about fields miss them, and they travel with every copy of the data.	Daily	Flag a free-text field once at least two of its answers seem to identify someone. One alone is often an enumerator's or official's name (DataFlow).
10.3 Kept apart and encrypted. Personal fields stored separately from the working data, encrypted, with access limited to named people.	The team can check, clean and share data without handling identities.	From the first download	Split into an encrypted container (arceddataflow uses VeraCrypt).
10.4 De-identified outputs, logged unlocks. Downloads and reports leave personal data out unless someone unlocks it, and every unlock is logged.	Every exposure of personal data becomes a recorded decision.	Every download and report	Public reports merge areas with fewer than 5 interviews (DataFlow).

11. Reporting and audit

Item	Why it matters	How often	Default
11.1 Daily flag list. One list of new flags by enumerator, each with the interview, question, value and what is needed: confirm, correct or revisit.	Flags only help if they reach the field team while a revisit is still possible.	Daily	Set a deadline to answer each flag in the contract.
11.2 Correction log. For every change: interview ID, variable, old value, new value, who, when and why. Dropped interviews are logged with a reason too.	Without a reason, nobody can check or defend a correction later.	Every correction	A correction or drop without a reason is refused (arceddataflow).
11.3 Cleaning code. Code, such as a Stata do-file or an R script, that rebuilds the clean data from the raw data and the log with no manual steps.	The client, a reviewer or a journal can reproduce the clean data.	With every delivery	None.
11.4 Tamper-evident record. A log of checks run, thresholds changed, corrections made and personal data unlocked, where any later edit shows.	Shows the history wasn't rewritten after the fact.	Continuous	Each entry carries a hash of the one before (DataFlow).
11.5 Field report. Progress, the results of each check and how flags were resolved, shared with the client.	The client sees quality without receiving the data.	Weekly	None.

Using the Standard

In a contract, attach the checklist to the terms of reference as an annex with your own thresholds filled in, and refer to items by number. The data quality clauses for a terms of reference show how. In a quality assurance plan, list the items you will run, who runs them, the thresholds and where the results go, and note the items you leave out.

When a firm collects the data for you, run the daily items yourself on its data and ask the firm for the weekly ones. See how to monitor a survey firm and how to choose a data collection firm.

Teams that already use IPA's ipacheck or follow the World Bank's DIME Wiki on high-frequency checks will recognise most categories. The Standard adds numbered items, defaults and the rules for corrections.

Where the defaults come from, and DataFlow

arceddataflow is ARCED Foundation's open-source Stata workflow. Its checks report covers duplicates, form versions, refusals, dates, outliers, missing answers, comments, time per question, time of day and productivity, and its correction sheet refuses a change that has no reason.

DataFlow, a desktop app made by ARCED International, implements the Standard. It sets up checks from the form and runs them on every sync from SurveyLoopr, SurveyCTO or ODK Central, or on CSV and Excel exports from KoboToolbox and other tools. Its duplicate and outlier checks are tested against arceddataflow: on the same reference survey, with the same settings, DataFlow flags exactly the interviews arceddataflow flags, and that comparison runs as a test with every change to DataFlow. The GPS, back-check and fabrication defaults come from DataFlow's engine. See what DataFlow checks.

Licence and citation

The Field Data Quality Standard is licensed under CC BY 4.0. Copy it into your own documents, translate it or change the thresholds; just credit it. A suggested citation:

ARCED International (2026). Field Data Quality Standard, version 1.0. https://letdataflow.com/standard. Licensed under CC BY 4.0.

Questions

What is the Field Data Quality Standard?

An openly licensed checklist of 43 data quality checks for field surveys, in 11 categories from IDs and duplicates to reporting and audit, with four principles for correcting data. Each item says what it checks, why, how often and, where arceddataflow or DataFlow sets one, a default threshold.

Can I use the Standard in my own terms of reference or QA plan?

Yes. It is licensed under CC BY 4.0, so you can copy, adapt and share it, commercially too, as long as you credit ARCED International and link to letdataflow.com/standard.

Do I need DataFlow to follow the Standard?

No. Every item can be run in Stata, R or a spreadsheet, and the defaults are written so you can code them yourself. DataFlow is one way to run them on every sync.

Where do the default thresholds come from?

From arceddataflow, ARCED Foundation's Stata workflow, and from DataFlow's check engine. They are starting points: adjust them to your questionnaire and write them down before fieldwork starts.

How often should field data quality checks run?

Every time new data arrives, and at least once a day during fieldwork, while enumerators can still revisit or call respondents. Back-check comparisons and field reports are weekly, because they need a few days of data.

Does the Standard apply to phone surveys or listing exercises?

Most items apply to any survey done by interviewers. Skip the ones that don't fit, such as GPS for a phone survey, and say so in your quality assurance plan. Item 8.5 has a separate default for listing and census work.