Data quality work stalls when it is framed as cleaning. The recurring argument about a figure is almost never about the data; it is about who is allowed to define the field and who may correct it.
This guide covers the dimensions worth measuring, how to sample one field honestly, and why giving a single field an owner and a correction route proves more than a complete data dictionary.
Key takeaways
- It is ownership, not cleaning: Two teams defining a field differently is the whole problem, and tooling alone never closes it.
- Sample two hundred by hand: The error rate you find is the only honest baseline and usually surprises both teams.
- Freshness is the forgotten dimension: A field that is accurate and three weeks old is useless to a decision taken daily.
- Do one field end to end: One field with an owner and a working correction route beats a dictionary nobody is accountable for.
Look for the business signal behind the technology
The signal for data quality work is an argument that keeps recurring. Two departments quoting different totals, a report that has to be explained before it can be used, a customer record nobody will correct because they are not sure who is allowed to: these are ownership problems rather than cleaning problems.
Not all of it is worth fixing. A field that nobody uses for a decision can stay imperfect, and a programme that treats every column as equally important will spend a year producing a dictionary and change nothing.
Take one field people argue about and ask each team to define it. The two definitions written side by side are usually the whole problem, and the conversation that follows is cheaper than any tooling.
Use four lenses to understand the opportunity
Definitions
Take one field two teams define differently and write both definitions side by side. The gap between them is the data quality problem, and it is a question of authority rather than of cleaning, which is why tooling alone never closes it.
Ownership
Name the role allowed to change the definition and the role allowed to correct a value. These are different permissions and conflating them is how a definition quietly drifts whenever somebody fixes a record in a hurry.
Freshness
Decide how current the field has to be for the decision it feeds, and find out how current it actually is. Freshness is the dimension nobody measures, and it is the one that makes an accurate figure useless.
Correction
Describe how a wrong value is reported, how long a fix takes, and whether downstream copies are updated too. A correction route that stops at the first system leaves the error in every report built on the copies.
Assess the current state without buying software first
Sample two hundred records by hand and check that field against something you trust. The error rate you find is the only honest baseline, and it is almost always different from what either team expected.
Decide what useful measurement looks like
Measure the error rate for the specific field rather than a composite quality score. A single index across forty fields moves slowly, means nothing to anybody, and cannot be acted on by the person who owns any one of them.
Add freshness to the measure. A field that is accurate and three weeks old is useless for a decision taken daily, and accuracy alone will report that everything is fine.
When software is likely to help
Tooling helps once the definitions and the owners exist: validation at entry, a correction route, a check that runs against a trusted source. Those automate agreements that have already been made.
Bought before the agreements, a quality platform produces a dashboard of problems that nobody has the authority to fix. The tool is then blamed for a governance gap it was never able to close.
For the commerce context where these data decisions show up first, see E-Commerce App Development: A Practical Planning Guide.
Start with a bounded improvement
Take one field end to end: definition, owner, correction route, re-sample after a month. One field with a working route proves the approach and gives you a method, which fifty fields at the definition stage never will.
Read the opportunity from the outside in
Begin where the bad data is noticed rather than where it is stored. Which decision went wrong, who found out, and how long after? Then follow it back through the correction route, the ownership and the definition until you reach the point where the two versions diverged.
Name the smallest change that would show: one field with one owner and a published correction route. That is something you can measure in a month, and it is a better argument for the next piece of work than a data strategy document.
Risks to make visible
| Lens | Common risk | Early response |
|---|---|---|
| Definitions | Two teams define the field differently | Write both definitions side by side and settle it before any cleaning starts. |
| Ownership | Nobody may change a value | Name who owns the definition and who may correct a record, separately. |
| Freshness | Accuracy is reported without currency | State how current the field must be for its decision and measure how current it is. |
| Correction | Fixes stop at the first system | Check whether downstream copies are updated when a value is corrected. |
A 30-day validation plan: Data quality
Days 1 to 5: pick the field people argue about. Choose one field that causes disagreement between two teams and ask each of them to define it. Write both definitions down side by side. The gap between them is the data quality problem, and it is a question of authority rather than of cleaning. Ask each of them what decision they use it for, because two teams usually want different things from the same field rather than the same thing differently.
Days 6 to 15: sample it by hand. Take two hundred records and check that field manually against something you trust. The error rate you find is the only honest baseline, and it is almost always different from what either team expected. Note what kind of error dominates, because that determines whether the fix is a rule, a form, or a conversation. Record who checked and against what, since an error rate without a stated reference is an opinion with a decimal point attached.
Days 16 to 30: give it an owner and a correction route. Name the person allowed to change the definition and the person allowed to correct a value, then publish how a wrong value gets reported and how long a fix takes. Re-sample at the end of the month. One field with a working route is worth more than a dictionary nobody is accountable for. Publish the second figure even if it has not moved, as a correction route that has not yet worked is still worth more than one that was never defined.
A practical worksheet: Data quality
Data quality work stalls when it is framed as cleaning rather than as ownership. Pick one field that causes arguments and complete every row for that single field before widening the scope.
| Decision area | What to record |
|---|---|
| Definitions | What the field means, what it excludes, and which two teams currently disagree about it |
| Ownership | The named role allowed to change the definition, and the one allowed to correct a value |
| Freshness | How current it has to be for the decision it feeds, and how current it actually is |
| Correction | How a wrong value is reported, how long a fix takes, and whether downstream copies are updated too |
| Measurement | The error rate for that field, counted against a sample someone has checked by hand |
Do this for one field end to end rather than for fifty fields at the definition stage. A single field with a real owner and a working correction route is worth more than a complete data dictionary that nobody is accountable for.
Related guides
- The next practical step is described in BI Dashboard: Examples, KPIs, and Design Principles.
- Much of this depends on what is in AI Workflow Automation: Use Cases, Risks, and Roadmap.
If Data Quality: Dimensions, Examples, and an Improvement Plan leaves you needing the data joined up before anything is built on it, Discuss Your Data Product.
Ali Boran Gazel