Key points
- Product data quality sets the ceiling for every workflow. No prompt adds an attribute the catalog does not hold, and an error in the source gets repeated by the automation across every channel at once.
- Before your first rollout, check six areas: required fields, identifiers, variant consistency, units and formats, duplicates, and categories and attributes. On a real export, not in the store admin.
- Data written for humans is not the same as machine-readable data. Any parameter meant for a filter, a feed or an answer has to live in its own field, with a predictable name and a value from a controlled list.
- Clean in order: required fields and identifiers first, then consistency, enrichment last. Enriching a messy catalog means paying twice for the same work.
From the audit in the previous chapter you have a queue: you know which tasks come back every week and which ones eat the most hours. Before you launch the first of them, take one step sideways and look at what the automation will actually be working on. Almost every use of AI in a store reads the same catalog: descriptions, translations, attribute mapping, feeds, even the answers a customer gets about a product spec. The premise of this chapter is uncomfortable but it saves weeks: AI will not fix a messy catalog, it will multiply the mess. The goal is not a perfect catalog, because there is no such thing. The goal is a catalog that is orderly enough in the fields your first workflow will touch.
Garbage in, garbage out, only faster
When a person writes descriptions, the data quietly corrects itself along the way. An editor looks at the photo, sees "black" in the color column while the product is graphite, and fixes it. An automation will not. It executes exactly what you gave it, across all three hundred items, just as patiently and just as wrongly. That is the real difference in the nature of the error: manual work produces single, random mistakes, while automation produces systematic ones. A systematic error has one advantage, since a single rule change fixes it, and one serious drawback, since until it is fixed it touches the entire assortment at once.
The second thing that is easy to miss: data quality sets a ceiling on workflow quality that no tool will break through. If the catalog holds no capacity, no material and no dimensions, a description generated from it will be flowery and empty, because there is nothing specific to build from. The worse version is when the model fills the gap with a plausible-sounding value and you end up with a spec nobody verified, published in a channel that is accountable for it. The cost of that error does not stop at a fix in the file, it shows up in returns, complaints and disapproved listings.
Six things to check before the first rollout
You run this review once, on an export from the real source, and treat it as an entry condition for the rollout. It does not have to cover the whole catalog: a sample of a few dozen items plus deliberately hard cases (products with variants, bundles, items with several units of measure) is enough. You are answering one question: are the errors isolated or systematic.
| Area | Control question | Sign that you have a problem |
|---|---|---|
| Required fields | Does every product have the full set of fields your channels require, not just your store? | The list of gaps at publishing never ends, and each channel demands a different set |
| Identifiers | Are SKUs and GTINs unique, valid and attached to the right variant? | The same SKU in two rows, or a parent GTIN copied onto every variant |
| Variant consistency | Does every variant carry the same set of attributes and a correct link to its parent? | Variants crammed into one cell, size written as "M" in one row and "38" in another |
| Units and formats | Are units, dimensions, dates and prices written in a single format? | "42 cm", "42cm" and "0.42 m" living in the same column |
| Duplicates | Does the same product appear in the catalog exactly once? | Two records for one product with different descriptions, prices and stock |
| Categories and attributes | Does each internal category map unambiguously onto the channel taxonomy? | The "Other" node is one of the largest categories in the tree |
Run the review on the export, not in the store admin. The admin shows data the way a human wants to see it, while a workflow reads the file.
You do not have to do this check by hand, because it is repetitive work in its own right: finding duplicates, recomputing code check digits and catching inconsistent units are good tasks for a tool. The technical side of such a review, along with the rules about working on a copy and reviewing the diff, we covered step by step in the piece on cleaning a catalog CSV. This chapter is about the layer above it: what has to be true about your data before running an automation makes sense at all.
Written for humans is not the same as readable by machines
This distinction accounts for half of the failed rollouts. The sentence "water resistant, it will survive a shower just fine" is clear to a customer and useless to a system. A sales channel expects an attribute with a fixed name and a value from a closed list, a store filter needs a number, and a model answering a question about a spec needs a field where that value simply sits. The rule is simple: if a parameter is meant for a filter, a feed, a comparison engine or an answer, it has to live in its own field, with a predictable name and a value from a controlled list, not only inside a sentence in the description.
A model can extract parameters from prose, and sometimes that is a sensible shortcut, but it is worth naming what it is. Extraction from text is high-accuracy guessing, which makes it suitable for rescuing legacy data rather than for being the source of truth. Two simple tests tell you which side your catalog is on. First: can the data be sorted and filtered without reading any descriptions. Second: would two different people filling that field enter exactly the same value. If the answer to either is no, the field is text rather than data, and every workflow built on it will break in places you did not anticipate.
One source of truth, even when there are several systems
In practice almost nobody runs a single system. Prices and stock live in the ERP, descriptions and images in the store or a PIM, the marketplace keeps its own attributes and categories, and somewhere alongside there is a spreadsheet where marketing maintains campaign copy. One source of truth does not mean migrating all of that into one tool, because such a migration is often more expensive than the problem it solves. It means something cheaper and doable straight away: for each field you name one system that owns it, and the others read that field instead of overwriting it. Conflicts are settled by the field owner, not by whichever write happened last.
Without that decision a workflow can run correctly and still be useless. The automation improves descriptions in the store, the nightly ERP sync overwrites them with the old version, and you discover it two weeks later when nobody remembers the cause. Naming field owners is an afternoon of work: take the list of fields your first workflow will touch and write down the source system and the direction of flow for each. You leave the rest of the catalog alone at this stage.
Before you launch a workflow, answer one question: where does the output land? An automation that writes its results outside the source of truth (straight into a sales channel, say, or into a separate spreadsheet) does not tidy your data, it creates another version of it. Three months later you have four versions of the same product description and nobody knows which one is current. Output goes back to the system that owns the field, and spreads from there into the channels.
The cleaning order: required, consistent, only then richer
The order has a financial consequence, because any pass done at the wrong stage has to be repeated. Run the three passes below in sequence and check a sample after each one, rather than firing everything at once.
Pass one: required fields and identifiers
You start with what a product cannot exist in a channel without, and with the keys that connect your systems. Gaps in required fields block publishing, and an invalid or duplicated identifier derails everything downstream that tries to join data from two sources. One boundary matters here: missing identifiers are not generated. A valid GTIN comes from GS1 or the manufacturer and has to be filled from a real source, while the tool should flag it reliably rather than invent it.
Pass two: consistency
Only now do you unify variants, units, colors, naming and categories, and resolve duplicates. The output of this pass is not just a cleaner file but a set of dictionaries: the list of allowed colors, the unit format, the mapping of internal categories onto the channel taxonomy. Those dictionaries are the input for everything you launch in the next chapter, so it pays to write them down in one place rather than keep them in the head of whoever happens to run the catalog.
Pass three: enrichment
Filling missing attributes, writing descriptions, translating and adding data for search all come last, on a catalog that is already in order. Reversing this order is the most common and most expensive mistake, because you enrich records that turn out to be duplicates, or generate copy for variants that will have to be split differently. You end up paying twice for the same work, and the second time is usually the pricier one.
The exit criterion for this chapter is practical rather than perfect: you can point to a sample of a few dozen random products with no gaps in channel-required fields, unique identifiers, consistent variants and units written in a single format. On top of that, you have written down which system owns which fields. That is enough to launch your first workflow, and that is what the next chapter covers.
Questions
Do you need a PIM to start with AI in ecommerce?
No. The entry condition is deciding which system owns which fields and which way the data flows, and that fits on a single page. A PIM solves a problem of scale: many channels, many languages and many people editing the same catalog. If you run one market and one channel, rolling out a PIM before your first workflow usually delays the result instead of accelerating it.
Will AI not clean the catalog for me?
Largely yes, and it is worth using: finding duplicates, recomputing code check digits, normalizing units and colors, and flagging gaps are repetitive work a tool does faster and more patiently than a person. There is one boundary: values that are not in the source (a GTIN, a technical spec, a material) should be flagged by the tool, not filled with a plausible-sounding guess.
How large a sample is enough to judge product data quality?
A few dozen random records plus a handful of deliberately hard cases: products with many variants, bundles, items with unusual units, and recently added products. You are not after statistical significance, only the answer to whether the errors are isolated or repeat along one pattern. A systematic error is visible in a dozen or so records.
