Data quality in practice
A buyer filters your shop for stainless steel and sees 212 fittings. You stock
400. The other 188 carry V4A instead of v4a, because two people built the
option list a year apart. Nobody typed anything wrong by their own lights, and
every one of those products is 100% complete. The catalog is still wrong.
Completeness catches missing data. This page is about the other half: data that is there and wrong.
The checks that find the most
Placeholder values. Search your text attributes for tbd, xxx, -,
n/a, siehe Datenblatt, folgt. These pass completeness and fail buyers.
Untranslated fields. Filter for products where the English description is identical to the German one. Either it was copied to satisfy completeness, or a translation step was skipped.
Outliers in numbers. Sort by weight, length and price ascending and descending. A 4,000 kg fitting or a 0 mm thread is a decimal-point or unit error and will show up instantly at the extremes.
Options that should not exist. Look at the option list of your key select
attributes. If material has both v4a and V4A, or an option used by exactly
one product, somebody worked around the model instead of using it.
Orphans. Products in no category never appear in navigation. Products with no image render as a grey box. Both are worth a saved filter.
Broken references. Products pointing at a reference record that was renamed or removed.
Duplicate SKUs across sources. Especially after a migration or a new supplier feed.
Make the checks cheap
Each of these is a filter. Save them and run them on a schedule rather than inventing them each time:
- Below 100% completeness for the primary channel
- No image
- No category
- Not enabled but complete (finished work nobody published)
- Enabled but below 100% (published work that is not finished)
That last pair is the most useful thing on this page. The two lists together show you exactly where the catalog and reality have drifted apart.
Some of these checks are already built into PIM › Products:
| Check | Where | What fixes it |
|---|---|---|
| Products with no family, so nothing to measure them against | The Without a family queue | Select them, Assign family. Completeness is measured in the same step. |
| Completeness never calculated | The Never measured queue | Select them, Recompute completeness |
| Switched-off products | The Disabled queue, or Status in the rail | Read the list. Everything in it should be off on purpose. |
| One family at a time | The Family filter | Group the work by family; missing data clusters there |
| Anything you check every week | Save the view | Open it on Monday instead of rebuilding the filter |
Prevent rather than detect
Most quality problems are modelling problems wearing a different hat:
- Free-text fields that should be select attributes. See Attributes.
- Missing validation. A regex on a part-number field, a min/max on a pressure rating, rejects bad data at entry instead of surfacing it in a report months later.
- No system of record. If two systems both write the description, they will disagree. Settle which system owns which field.
Who owns this
Data quality decays without an owner. In practice it works when one person owns the model and the weekly check, and the people who know the products own the content. It stops working when it is nobody's job and everybody's complaint.