What

is

data

quality?

What does data quality mean?

Data quality tells you whether your data is good enough for what you want to do with it. That makes it a relative measure. An address that works for an invoice can be too rough for route planning. A product description that works fine internally can be unsuitable for a web store. The concept belongs to data management, but the problem almost always starts in daily practice: at data entry, in an integration or during a migration. Improving data quality therefore means looking beyond the database, at the processes that put the data there.

What are the dimensions of data quality?

Six dimensions come back in almost every framework. The next section shows, per dimension, what it means, how to measure it and what an error looks like in practice.

How do you measure data quality?

You measure data quality by agreeing on a rule for each important field and counting how many records meet it. You don't need a separate package for that. A database query or an export to a spreadsheet already gives a first picture for most dimensions. Start small. Pick the ten or twenty fields a process really depends on, such as customer number, billing address and product code, and measure those. Record the result with a date. A one-off measurement says little; one you repeat every month shows whether things are getting better or worse.

Where does poor data quality come from?

Poor data quality usually starts in four places. The first is data entry: free text fields without validation, required fields filled with a full stop just to get past them. The second is a migration, where fields in the old and new system almost, but not quite, match. The third is an integration that translates data incorrectly, for example a country stored as text in one system and as a code in another. The fourth is time itself: contacts change jobs and addresses change. And when the same data is kept in several systems, differences appear on their own. That pattern is called a data silo.

Why do AI projects fail on data quality?

An AI model learns from the data that is there, errors included. If the same products appear under three names in your records, the model sees three products that each have a third of the sales. The resulting prediction is technically correct and practically useless. That is why data quality is the first question in any AI project, before choosing a model. Measure how complete, unique and consistent the source data is, and you know whether the project is feasible. How to build that into a project is described on the page about AI integration and implementation.

How do you improve data quality for good?

Cleaning up fixes the problem once; structural improvement stops it from coming back. That takes three things. First, an agreement per data type on which system is leading: the single source of truth. Second, an owner per domain, often called a data steward, who decides what a valid value is. Third, rules that stop errors at the source instead of fixing them afterwards. For master data such as accounts, suppliers and products, those agreements come together in master data management.

Building data quality into your software.

Most of the gain is in the software where people enter data. A dropdown instead of a free text field, a check for duplicate registration numbers when creating an account, a postcode that is formatted automatically: small changes that remove a whole category of errors. Integrations count too. An integration that rejects a record when a required field is missing, and reports it, is better than one that half accepts it. You set rules like these in the layer where you organise your data management, so the data is reliable before it reaches a business intelligence dashboard.

In short.

Data quality is the degree to which data is fit for its purpose, measured across six dimensions: completeness, accuracy, consistency, timeliness, uniqueness and validity. Poor data quality comes from data entry, migrations, integrations and ageing data. Improving it for good means one leading source per data type, an owner per domain and validation where data comes in.