Good product data isn't simply complete. It needs to be correct, consistent, current, structurally valid, and fit for the destination channel. A product can be 100% complete and still carry wrong dimensions, contradictory prices, or a category that doesn't fit.
PIMSuite checks catalog data for more than completeness - it looks for concrete structural and technical errors too.
Six dimensions of data quality
Completeness - are the required values present at all? Missing title, missing EAN, missing image, an empty technical attribute.
Validity - is the value structurally correct? An invalid GTIN checksum, a malformed date, a select option that no longer exists in the schema, a negative price.
Consistency - do related values contradict each other? A variant has a different material than its parent product, the selling price sits below a defined minimum margin, category and product family don't line up.
Correctness - is the information actually true? This is the hardest dimension, because software can't always determine it automatically. A perfectly formatted EAN can still belong to the wrong product.
Timeliness - is the value still current? A stale supplier cost, a discontinued product still marked active, a translation based on an outdated source version.
Channel readiness - does the record satisfy the specific destination's requirements? A marketplace requires different mandatory fields than a B2B feed.
Not every dimension is equally easy to check. The first two - completeness and validity - are largely automatable. Consistency and channel readiness need contextual rules. Correctness and timeliness can only be partially detected automatically and remain, to some degree, dependent on human review.
Completeness is not the same as quality
A record like
Title: Product 123
Description: Good product
Material: Other
can satisfy every required field and score 100% complete - and still be commercially useless. A completeness score tells you whether data exists, not whether it's any good. PIMSuite calculates every product's completeness score from its required fields, per language, and updates it immediately on every edit. Filter your entire catalog by completeness range - show everything below 80% in German, for example - and work through the list systematically.
Quality checks
PIMSuite runs a set of predefined quality checks across your catalog:
- Missing EAN - products without a GTIN/EAN/barcode that will fail marketplace submission
- Invalid EAN - barcodes that don't pass the checksum algorithm
- Missing required fields - attributes marked as required that have no value
- Missing prices - products without a selling price that can't be published
- Orphaned attribute options - select/multiselect values that reference options that no longer exist in the schema
Each check surfaces a filtered list of affected products so you can act on them directly.
Why a valid EAN isn't automatically the right EAN
A GTIN/EAN is more than 13 digits - it contains a check digit, which catches many transcription errors. If an entered EAN fails the checksum, the system knows for certain: the code is wrong. If it passes, the system only knows: the code is structurally plausible - not that it actually belongs to this product. A passing checksum is a necessary condition for correctness, not a sufficient one.
Why orphaned options happen
Old option:
color = "navy"
Schema changed:
"navy" removed / replaced by "dark_blue"
Existing products:
still reference "navy"
Orphaned attribute options almost always come from schema changes, not bad input: a select value gets renamed or removed, and products still pointing at the old value suddenly reference something that no longer exists. PIMSuite finds these cases automatically instead of letting them surface as a failed export.
Rules beyond single-field checks
The checks above are essentially presence and structure checks on individual fields. A more comprehensive data-quality setup would also cover value ranges and relationships between fields - for example:
weight > 0
width > 0
selling_price >= minimum_price
end_date >= start_date
and contextual rules:
if product_family = food
→ ingredients required
if battery_included = yes
→ battery_type required
as well as cross-field checks like: net weight shouldn't exceed gross weight, or a "sale" price above the regular price is probably an error rather than a promotion. Configurable, cross-field rules like these aren't a distinct feature beyond the five checks above today - for catalogs with specific business rules, that's a natural next step, often as custom development.
Data quality is channel-dependent
Internal PIM:
✓ title
✓ SKU
✓ price
Marketplace:
✗ GTIN missing
✗ main image insufficient
✗ required marketplace attribute missing
B2B feed:
✓ ready
A product can be internally complete and valid and still not be ready for a specific channel, because that channel has additional requirements. PIMSuite's quality checks currently run catalog-wide rather than as a separate, per-channel configurable requirement profile - if you regularly hit channel-specific submission errors, a dedicated channel-readiness check is a sensible next step.
A PIM doesn't automatically fix bad source data
If a supplier delivers inconsistent units, malformed values, wrong descriptions, or duplicate products, a PIM can detect and normalize many of those problems - but it can't guess every correct value out of thin air. That justifies a sensible division of labor: deterministic cleanup for structural problems, business rules for known relationships, AI-assisted enrichment for inferable values, and human review for anything software can't safely decide on its own.
AI and data quality belong together - carefully
AI can help detect or fill quality gaps, but AI-generated values carry their own quality risk. A pattern that works: AI proposes a value (a taxonomy category, say), the typed schema enforces that only a valid value can be saved, and a person confirms where needed. That's the same principle as on the AI features page: AI handles the ambiguity, rules enforce correctness.
Quality workflow before publication
Import
↓
Normalize
↓
Validate
↓
Score completeness
↓
Review exceptions
↓
Approve
↓
Publish / export
Data quality should happen before channel export, not after a marketplace has already rejected a product. Every PIMSuite check described above surfaces a filtered list of affected products - the practical effect is that problems get worked through systematically before they turn into a failed export or a return.
Where did this value come from?
When multiple sources supply different values for the same field - ERP, supplier feed, manual edit, AI enrichment - the question is which source wins. For prices, PIMSuite answers that explicitly through configurable cost-source strategies (preferred supplier, lowest, highest, or average cost). For fields generally: every change is recorded in the audit log with user, source, and timestamp, so you can trace after the fact which value was set by whom or what, and when. A generic, configurable precedence rule across all field types ("on conflict, source X wins") beyond that isn't a distinct feature.
Audit log: not data quality itself, but necessary for it
Data-quality checks answer: what's wrong? The audit log answers a different question: how did it become wrong?
Every change to every product is recorded: which field changed, what the old value was, what the new value is, who made the change, and when. The audit log is searchable and filterable. "Who changed the price on this product last Tuesday?" is a question you can answer in seconds.
Product version history
The version history gives you a timeline view of a product's changes. See each edit event as a snapshot - what it looked like before, what changed, who touched it. Nothing is permanently lost unless explicitly force-deleted.
Media quality is part of product-data quality
Duplicate or near-identical images don't just clutter the media library - they distort how complete and trustworthy a catalog looks. PIMSuite detects duplicate images across your entire media library using SHA-256 hashing plus perceptual hashing - details on that, including the limits of automated similarity detection, are on the Media & DAM page.
For product records themselves - as distinct from images - duplicate detection (matching on identical GTIN, supplier SKU, or unusually similar titles) isn't a distinct feature today.
How PIMSuite implements this
PIMSuite continuously checks your catalog for missing and invalid EANs, missing required fields, missing prices, and orphaned attribute options, with a filtered product list per check. Completeness scoring runs per language and updates immediately. Every change is recorded in the audit log and version history, with user, timestamp, and old and new values - so you can find and fix data problems systematically before they reach your channels.