How to Clean Product Data: A Practical Guide

Gartner's research puts the average cost of poor data quality at $12.9 million per year across the organizations it surveys — a figure that's held steady since Gartner first published it in 2020. Ecommerce catalogs don't usually see that cost as a single line item; it shows up as lost conversions on incomplete pages, returns from inaccurate descriptions, and marketplace disapprovals from failed validation, spread across thousands of small failures that are individually invisible and collectively enormous.

This guide covers the data-quality dimensions worth measuring, the defects that show up most often in real ecommerce catalogs, a step-by-step cleaning process, and — because a clean catalog left unmonitored degrades again within months — how to keep it that way.

The data-quality dimensions framework

IBM's widely-adopted framework (building on data-quality dimensions research going back to Wang and Strong's 1996 paper) identifies six core dimensions. Applied to product data specifically:

Framework adapted from IBM, "What Are Data Quality Dimensions?" (ibm.com, 2026), building on Wang & Strong, "Beyond Accuracy: What Data Quality Means to Data Consumers" (1996).

Most catalog teams instinctively focus on accuracy and completeness because they're the most visible on a single product page. Uniqueness and consistency are the dimensions that quietly cause the most damage at scale, because a duplicate or inconsistent record doesn't just affect one page — it multiplies the same error across every channel and every report that touches it.

Why catalogs get dirty in the first place

Cleaning is easier and more durable when you understand the mechanism that created the mess, not just the symptom. Four patterns account for most catalog degradation:

• Multiple import sources without reconciliation. A catalog built from a legacy platform migration, a supplier feed, and manual additions over several years accumulates three different conventions for the same kind of data, none of them wrong in isolation, all of them inconsistent together.
• No validation at the point of entry. If nothing stops a malformed price or a missing required attribute from being saved, the defect enters the system silently and only surfaces later — often as a channel rejection or a customer complaint, both more expensive than catching it at entry.
• Manual edits made directly in a channel, not the source of truth. A quick fix typed directly into Amazon Seller Central to resolve an urgent issue is a completely reasonable emergency response — and a guaranteed source of drift if the source-of-truth record is never updated to match.
• Taxonomy or attribute schema changes without back-filling existing data. Adding a new required attribute going forward, without a project to populate it for existing SKUs, leaves a permanent, growing gap between old and new inventory.

Addressing the mechanism, not just today's defect list, is what keeps a cleaning project from becoming an annual ritual. A catalog that gets re-cleaned every year without ever fixing why it got dirty is treating a process problem as a data problem.

The defects that show up most often

Across catalog audits, the same six patterns account for the overwhelming majority of defects found:

• Duplicate SKUs from multiple import sources. The same product enters the catalog twice — once from a direct supplier feed, once from a bulk spreadsheet import months later — under two different internal IDs, splitting reviews, sales history, and search ranking between two listings. This is often invisible until someone notices the same product appearing twice in search results, by which point months of accumulated sales and review data are split unrecoverably.
• Inconsistent attribute values. "Red," "RED," and "Crimson" all describing the same colour, none of them matching a controlled vocabulary, making filtering and reporting unreliable. A customer filtering by "Red" on a category page silently misses every product tagged "RED" or "Crimson," which looks like a merchandising failure but is actually a data consistency failure.
• Orphaned or stale price/availability. A price change made in the storefront that never propagated to the marketplace feed, or an out-of-stock item still showing as purchasable. This is the defect type most likely to trigger an actual account-level penalty, since marketplaces treat price and availability mismatches as a trust violation rather than a cosmetic issue.
• Missing or placeholder imagery. Generic manufacturer stock photos, broken image links, or images entirely absent for long-tail SKUs that never got full onboarding treatment. Long-tail products are disproportionately affected because they rarely get the same manual attention as bestsellers during initial catalog setup.
• Malformed identifiers. GTINs with incorrect check digits, or identifiers copy-pasted with extra whitespace or formatting artifacts that make them fail validation silently. A GTIN that looks correct to a human eye can still fail a check-digit validation, and the failure often isn't surfaced until a channel disapproval weeks later.
• Taxonomy misassignment. Products placed in categories that don't match their actual attributes, usually from automated categorization applied to incomplete source data. This compounds every other defect on the list, since attribute governance and validation rules are often category-specific — a miscategorized product inherits the wrong validation rules along with the wrong category.

The cleaning process, step by step

1. Audit before touching anything. Pull a representative sample (or, for smaller catalogs, the full set) and score it against the six dimensions above. This tells you which defect types are actually prevalent in your specific catalog — don't assume; different catalogs skew toward different failure types depending on how they were built. A catalog assembled mostly through manual entry tends to skew toward inconsistency; one built from bulk supplier imports tends to skew toward incompleteness and validity failures.
2. Deduplicate first, standardize second. Cleaning attribute values on a record that turns out to be a duplicate is wasted work — resolve uniqueness issues before investing in accuracy and consistency fixes on the same records. This ordering also matters for a subtler reason: which of two duplicate records is more complete or more accurate often determines which one should survive the merge, so you need that comparison before you've already "fixed" one of them in isolation.
3. Standardize against a controlled vocabulary. Map every attribute value to one canonical form. This is the step most commonly skipped under time pressure, and the one most likely to silently re-break within a year if skipped. Build the vocabulary once, store it centrally, and make it the only accepted input for that attribute going forward — not just a one-time cleanup pass with no lasting enforcement.
4. Validate against format rules. Run every identifier, price, and required field through automated validation (correct GTIN check digits, price is numeric, required fields are non-null) before considering a record "clean." Format validation is the cheapest of all these steps to automate and the easiest to skip, which is exactly why malformed identifiers are one of the most persistent defect types found in real audits.
5. Reconcile across systems. Compare the same product's data across your source of truth, storefront, and channel feeds; any mismatch found here is a consistency defect that needs a decision about which system is authoritative. This step is where the case for a governed source of truth (rather than editing each channel independently) becomes concrete rather than theoretical — every mismatch found is a preview of a future customer-facing error if left unresolved.
6. Re-score and document what's still broken. Not everything gets fixed in one pass — score the catalog again, and explicitly document remaining known issues rather than letting them disappear from view. A documented, prioritized backlog of remaining defects is a legitimate outcome of a cleaning project; a false sense that everything is now perfect is not.

Deduplication and normalization: which approach fits which problem

Most real catalogs need a combination, applied in the order of the table: exact matching first (cheap, unambiguous), rules-based normalization for known attribute variants, then fuzzy or AI-assisted matching for the harder cases that remain — never starting with the most sophisticated tool on a problem the simplest one would have solved faster.

Don't let it rot again: monitoring after the cleanup

A one-time cleaning project without ongoing monitoring is a temporary fix for a structural problem. The same forces that created the original mess — multiple import sources, manual edits, unvalidated entry points — are still active after the cleanup finishes, which means degradation resumes immediately unless something structural changes. Three things belong in an ongoing monitoring cadence:

• New-SKU validation at the point of entry. Every new product should pass the same validation rules used in the cleanup before it's allowed into the live catalog — catching a defect at entry is far cheaper than catching it after it's synced to three channels. This single change does more to prevent re-accumulation than any amount of periodic re-cleaning.
• A recurring completeness/consistency score. Re-run the same scoring used in the initial audit on a schedule (weekly or monthly, depending on catalog velocity) so drift is visible as a trend, not a surprise. A score that's flat or improving means the entry-point controls are working; a score that's declining means something upstream changed and needs investigation before the backlog grows again.
• Supplier-level quality tracking. If defects cluster around specific suppliers or import sources — they usually do — track quality by source, not just by catalog-wide average, so the actual root cause gets addressed rather than perpetually re-cleaning the same supplier's output. A supplier responsible for a disproportionate share of defects is a conversation to have directly with that supplier, not just an ongoing cleanup cost to absorb quietly.

Frequently asked questions

What are the main dimensions of product data quality?

The core dimensions, adapted from IBM's widely-used data quality framework, are accuracy (does the value match reality), completeness (is nothing missing), consistency (does the same fact match across systems), timeliness (is it current), validity (does it conform to the expected format), and uniqueness (no duplicate records).

How do you find duplicate SKUs in a large catalog?

Exact-match deduplication (identical SKU IDs or identifiers) catches the obvious cases; fuzzy matching (comparing titles, attributes, and images for high similarity even with different formatting) catches near-duplicates that exact matching misses, such as the same product listed twice with slightly different titles.

How much does bad data actually cost a business?

Gartner's widely-cited research estimates poor data quality costs organizations an average of $12.9 million per year, a figure Gartner itself has published and maintained since 2020. For ecommerce specifically, the cost shows up as lost conversions, higher returns, and marketplace disapprovals rather than one single line item.

Should I clean product data manually or with automated tools?

Automated tools handle exact-match deduplication, format validation, and rules-based standardization well at scale. Fuzzy matching and attribute standardization benefit from AI assistance but need human review for ambiguous cases. Manual review should be reserved for genuinely ambiguous or high-risk records, not the bulk of routine cleaning.