Data quality is the degree to which data is fit for its intended use, measured across dimensions such as accuracy, completeness, consistency, timeliness, validity and uniqueness. Among data fundamentals, it is the property that decides whether a dataset can be trusted for decisions, reporting, automation or model training, regardless of how the data is stored or formatted.
Data quality is relative to purpose. A customer table with 5 percent missing phone numbers may be excellent for invoicing and poor for a telephone campaign. For that reason, quality is defined through explicit requirements and measurable rules, not as an absolute property of the data itself.
The dimensions of data quality
Data quality is described through dimensions, each capturing one way data can fail its purpose. Frameworks differ in naming and number, but a core set appears in nearly all of them, including the ISO 25012 data quality model and the guidance of data management bodies.
| Dimension | Question it answers | Example metric |
|---|---|---|
| Accuracy | Does the value match reality? | Share of addresses confirmed by a reference source |
| Completeness | Are required values present? | Percentage of non-null mandatory fields |
| Consistency | Do related values agree across records and systems? | Orders whose totals equal the sum of their lines |
| Timeliness | Is the data current enough when used? | Hours between event and availability |
| Validity | Does the value follow the defined format and range? | Share of dates and codes passing rules |
| Uniqueness | Is each real entity recorded once? | Duplicate rate among customer records |
Dimensions interact. A value can be valid but inaccurate, such as a correctly formatted postal code that belongs to another town. Validity is cheap to check automatically, while accuracy usually needs a trusted reference or human verification, which makes it the most expensive dimension to measure.
How data quality is measured and monitored
Data quality is measured by turning requirements into rules, running the rules on the data and tracking the results over time. The first step, data profiling, examines actual distributions, null rates, value ranges and patterns to discover what the data really looks like before rules are written.
Rules are then expressed as checks with thresholds, for example “at least 99.5 percent of orders have a valid customer reference”. Checks run inside data pipelines, on database constraints, or in scheduled monitoring jobs, and results feed scorecards and alerts.
| Check type | What it tests | Typical placement |
|---|---|---|
| Schema check | Columns, types and nullability | At ingestion |
| Rule check | Formats, ranges, allowed values | In the pipeline before loading |
| Referential check | Keys that point to existing records | After joins or loads |
| Volume and freshness check | Row counts and arrival times | Scheduled monitoring |
| Distribution check | Shifts in averages or category shares | Monitoring, often statistical |
Freshness and volume checks catch a large share of real incidents, such as a feed that silently stopped or delivered half its rows. They are simple to implement and are often the best first investment for a team starting systematic quality work.
Data quality compared with related concepts
Data quality is closely tied to other data fundamentals but answers a different question: whether the content can be trusted for a purpose.
| Concept | Focus | Relation to data quality |
|---|---|---|
| Data lineage | Where data came from and how it changed | Locates the origin of quality defects |
| Data governance | Ownership, policies and decision rights | Assigns who defines and fixes quality |
| Data integrity | Correctness preserved by constraints and processes | Protects quality during storage and transfer |
| Data validation | Checking inputs against rules | One technique for enforcing validity |
| Structured data | Data with a defined schema | Easier to measure rule by rule |
For unstructured data, such as documents or images, quality is assessed differently: by label correctness, duplicate detection, resolution or language coverage, often through sampling rather than per-record rules.
Improving data quality at the source
The most effective way to improve data quality is to prevent defects where data is created, because corrections made downstream must be repeated in every consumer and are often lost on the next load.
- Enforce constraints in entry forms and databases: required fields, formats, foreign keys and allowed values.
- Assign a data owner for each important dataset who agrees the rules and approves fixes.
- Use reference data and master data management so that codes and core entities have one authoritative version.
- Feed detected defects back to the source system rather than patching them only in the warehouse.
- Document definitions in a data dictionary, since many apparent errors are disagreements about meaning.
Downstream cleansing, such as standardizing addresses or merging duplicates, remains necessary for legacy and external data, but it should be logged and reproducible so that analysts can see what was changed and why.
Common misconceptions about data quality
Quality efforts often fail because of wrong assumptions rather than wrong tools. The following misconceptions are especially common.
- Perfect data is not the goal; the goal is quality sufficient for the use, at acceptable cost.
- A one-time cleanup does not last: without monitoring, quality decays as systems and processes change.
- More data does not compensate for poor data; in machine learning, systematic label errors bias models regardless of volume.
- Quality is not only an IT task: most defects originate in business processes that IT does not control.
Put simply
Data quality is about whether information is good enough to rely on. Think of a contact list. If numbers are missing, names are misspelled or the same person appears three times, calls fail and time is wasted.
Good data is correct, complete, up to date and recorded the same way everywhere. It does not have to be perfect. It has to be good enough for the job it is used for, and someone has to keep checking that it stays that way.
In practice
A retail chain notices that its weekly sales report disagrees with finance figures by about 2 percent. Profiling the sales data reveals three causes: duplicate transactions from a store system that resends files after network errors, returns recorded with positive amounts at some stores, and product codes missing for about 1 percent of lines.
The data team adds a uniqueness check on transaction identifiers, a validity rule that requires negative amounts for returns, and a completeness threshold that holds the load if more than 0.5 percent of codes are missing. The store system vendor fixes the resend behavior. Within two months the difference with finance falls below 0.1 percent, and the report is accepted as the single source for weekly decisions.