Many research projects begin analysis by choosing a statistical test or immediately opening statistical software. That can feel like progress, but it does not answer the more important question: does the dataset actually represent what the study intends to analyse? A model can be technically correct and still produce an unreliable conclusion when data are miscoded, duplicated, or contain impossible values.
Checking data before testing is not administrative procedure. It confirms that the unit of analysis, variables, and observation scope still match the research design that was committed to. Doing it early usually saves far more time than explaining an odd result at the end of the process.
Begin with the unit of analysis
First, identify what each row represents. It may be a respondent, transaction, company, or observation over time. Then check whether each unit appears the number of times the design expects.
For example, a customer-experience survey may be designed for one row per respondent. If the same response ID appears twice, the researcher needs to know whether it is an export duplicate or two valid survey submissions. Those situations require different treatment. A record should not be deleted simply because it looks similar.
Read the coding again rather than trusting a variable label
Short variable names in software rarely convey the full meaning of data. A variable labelled sat_3 might indicate satisfaction, or it might be a reverse-worded item. Place the coding beside the questionnaire or data dictionary and check at least five things: the valid scale range; which value represents missing data; which items require reverse coding; which groups were eligible to answer; and the unit used for the number.
A familiar error is entering 99 to mean “no response” while leaving the software to treat 99 as a valid value. The mean can then rise sharply while later statistical tests still run normally. Software cannot know that 99 is a convention; the researcher has to declare and verify it.
Investigate outliers in context
An outlier is not always an error. A company with revenue many times higher than the others may be an important observation rather than a point to remove. The right question is whether the value can occur within the logic of the phenomenon and whether there is evidence that it was recorded correctly.
Use two layers of checking. The first applies simple rules: age is not negative, a percentage does not exceed 100 when the variable is recorded as a percentage, and an end date does not precede a start date. The second examines the distribution: which values are far from the rest, which groups they appear in, and whether they coincide with signs of unusual data entry. Record the decision to retain, correct, or remove a value and the reason so that others can follow it.
Handle missing values deliberately
No single rate of missing data makes the issue safe to ignore. Examine which variables have missing values, whether they cluster in particular groups, and whether the absence may relate to the question itself. If higher-income respondents often skip an income question, simply deleting incomplete rows may make the remaining sample biased.
A short check table is enough to begin: original number of observations; missing observations for each variable; number of affected rows; and the planned treatment. In a small study, this table can sit in an appendix or analysis log. What matters is that the treatment decision is made before seeing results that favour a hypothesis.
Match a small sample back to its source
When data pass through several steps, such as online collection, file export, table merging, and recoding, randomly select a few records and match them back to the source. Ten to twenty records can uncover repeated problems such as shifted columns, lost Vietnamese diacritics, altered date formats, or incorrectly joined identifiers.
For instance, a research team may join survey data to purchase data through standardized telephone numbers. When it checks 15 cases at random, it finds that leading zeroes were removed by spreadsheet software. If the issue went unnoticed, many rows would not join and the team could wrongly conclude that those customers had no transaction.
Keep a repeatable check record
Before testing, save a short summary of the file version, checking date, observation count, rules applied, and corrections made. It does not need to be long. It makes the research repeatable, helps co-authors understand the state of the data, and prevents the researcher from relying on memory when returning weeks later.
Statistical testing is a tool for answering a research question, not a machine for repairing data. When data are checked first, the final results are easier to explain and methodological decisions rest on a clearer foundation.
