Data Quality Checks That Belong in Every Introductory Analysis

Data quality is not a single score or label. It is a set of questions about whether a dataset is complete enough, consistent enough, and clearly described enough for a specific analytical task. A table can be suitable for one question and unsuitable for another. For example, a dataset with incomplete location fields may still support a study of total record counts, but it may not support a regional comparison. The purpose of a data-quality review is therefore not to declare that a table is good or bad. It is to understand what the table can reasonably support.

Begin with completeness. Count missing values in each column and calculate their share of all records. A column with two blank cells requires a different response from a column that is blank in half of the dataset. Look at the pattern as well as the count. Are values missing mainly during one period, within one category, or after a change in the collection method? Patterns may reveal that missing information is connected to the way records were gathered.

Next, examine duplicate records. Exact duplicates are rows where every field is repeated. Partial duplicates may share an identifier, date, or reference number while differing in another field. Do not remove them immediately. Determine what a row represents and whether repeated events are expected. A participant may submit one response, while a customer may place many orders. A repeated customer identifier can therefore be valid in one table and problematic in another.

Format consistency is another important area. Dates may appear in several layouts, decimal marks may differ, and text fields may contain extra spaces. Category labels may vary in capitalization or spelling. These differences can divide one intended group into several separate groups. Build a list of unique labels for each categorical field and review unusual entries. When labels are changed, keep a mapping that records the original form and the revised form.

Numerical ranges should be checked against the meaning of each field. A percentage may be expected to fall between zero and one hundred. A rating may use a defined scale. A duration should not be negative unless negative values have a documented meaning. Values outside an expected range are not automatically wrong, but they deserve review. They may represent entry errors, unusual events, or a unit mismatch.

Cross-field logic can reveal issues that single-column checks do not find. A completion date should not occur before a starting date. A record marked “closed” may be expected to contain a closing date. A total may need to equal the sum of several component fields. Write a small set of logical rules based on the dataset description, then count how many records do not follow those rules.

Identifiers should be reviewed separately. An identifier may be expected to be unique for each row, unique for each person, or repeated across related events. Check whether the field contains blanks, unexpected lengths, or duplicate values. If several tables will be connected, examine whether the same identifier follows the same format in each table. Leading zeros, spaces, and different character lengths can prevent valid matches.

Time coverage can affect comparisons even when every row is technically correct. Check whether all periods are equally complete. A final month may contain only ten days, while earlier months contain full calendar periods. Comparing their raw totals would not describe the same amount of time. Record incomplete periods and decide whether to exclude them, adjust the comparison, or label them clearly.

Outliers also require careful treatment. An unusually high or low value can be an error, but it can also represent a real event. Review the original record, related fields, and source notes before deciding what to do. If a value is excluded, document the rule and show how many records were affected. Avoid changing data simply because it does not match the general pattern.

A change log is one of the strongest habits a new analyst can develop. For each change, record the field, original value or rule, revised value or rule, reason, and date. This creates a traceable path from the original dataset to the working version. It also makes later review much clearer.

At the end of the quality check, prepare a brief summary. State which checks were completed, how many issues were found, what changes were made, and which limitations remain. This summary should accompany the analysis rather than remain hidden in personal notes. Readers need to know whether missing records, incomplete periods, or category changes may influence the findings.

Data quality work is not about making a dataset look tidy. It is about understanding the condition of the information and the effect that condition may have on each conclusion. A structured review allows calculations to be interpreted within the right boundaries and makes the analytical process easier to explain.