When an online shop doesn't sell as well as hoped, attention usually turns first to the design, then to traffic, and finally to price. Far less often does it fall where the cause actually lies in many cases: on the product data. It's unspectacular, maintaining it is tedious, and it never appears as a success story in any marketing presentation. Nevertheless, it determines whether an item is found, understood, and bought. dhbdhj
Product data is more than text and images
In the shop, a product consists of several data layers that serve different purposes.
The identifying data – item number, EAN, manufacturer number – ensure that an item can be uniquely referenced. They are a prerequisite for price comparisons, marketplace connections, and clean inventory management.
The descriptive data – name, short and long descriptions, images, videos – do the selling work. They replace what touching the product and consultation do in brick-and-mortar retail.
The structuring data – categories, properties, variants, filter values – determine whether an item can be found in navigation, search, and filters. They are the most frequently neglected layer and, at the same time, the one with the greatest leverage.
The commercial data – prices, tiered prices, tax rates, delivery times, shipping methods – control the shopping cart and checkout.
An item can have an excellent description and still remain invisible because it lacks filter properties. Conversely, the best filter structure is useless if the description reads like a data sheet.
The most common mistake: adopting manufacturer texts unchecked
Many shops adopt texts and attributes directly from their suppliers' data feeds. That is efficient and, as a first step, entirely legitimate. It becomes problematic when this import marks the end of the processing.
Manufacturer texts are written for the manufacturer, not for your shop. They are aimed at a professional audience, use internal terminology, and describe features without explaining the benefit. On top of that: when twenty retailers use the same text, identical content appears in twenty places on the web. For search engines that is not a disqualifier, but there is also no reason to favor your page in particular.
The pragmatic middle path is: import manufacturer data as raw material, then manually refine the highest-revenue items. A range analysis usually shows that twenty percent of items account for eighty percent of revenue. Those twenty percent deserve real editorial work; the rest gets by with clean basic data for now.
Modeling properties correctly
Modeling properties is a decision with a long half-life. Those who get it right early save themselves costly migrations later.
A practical rule of thumb: anything someone might filter by is a property. Anything that only serves as information is an attribute or part of the description. The color of an item is a property. The label "Made in Germany" can be one if origin is a purchasing criterion – otherwise it belongs in the running text.
Three rules have proven effective:
1. Normalize values. "Red", "red", "Red metallic" and "RAL 3020" are four filter values for one color. Establish a binding vocabulary and maintain synonyms in a mapping table.
2. Separate units. Store "1.5" and "l" separately, not "1.5 liters" as text. Only this way can range filters and sorting be implemented.
3. Not every property needs to be filterable. A filter with forty values, each occurring once, helps no one. Filters need discriminatory power.
Images are data
Images are rarely regarded as a data quality topic, but they behave exactly like one. Inconsistent cutouts, changing aspect ratios, and different crops make a category page look restless, even if each individual image is fine on its own.
Therefore define a binding image standard: aspect ratio, minimum resolution, background, position of the object in the image, number of views per item, and a naming convention that includes item number and image position. Add alternative texts – not only for accessibility, but also because they serve as descriptions in image search.
Defining responsibilities
Data quality rarely fails because of the tool and almost always because of unclear responsibilities. Therefore clarify in writing who maintains which fields and who approves them.
In many teams a simple division has proven effective: purchasing is responsible for identifying and commercial data, editorial for the descriptive data, and the e-commerce team for the structuring data. One person has the final approval and checks a short checklist before going live. This checklist may well seem trivial – it's precisely the trivial mistakes that are the expensive ones.
## Making quality measurable
Data quality can be captured in metrics surprisingly well. Useful ones include, among others:
- Completeness rate per mandatory field across the entire range
- Share of items without an image or with fewer than the minimum number of images
- Share of items without filter properties in their main category
- Search queries with no results – often a direct indication of missing synonyms
- Return rate per item – conspicuous outliers often point to misleading descriptions or incorrect measurements
A simple dashboard with these five values is more effective than an extensive quality manual that no one reads. What matters is that the figures are reviewed regularly and assigned to individual people.
## Maintenance as an ongoing process
Product data is never finished. Ranges change, suppliers adjust feeds, seasonal items come and go. A fixed rhythm rather than occasional big campaigns therefore makes sense: a weekly look at new items, a monthly report on completeness, and an annual review of the category structure.
Those who establish this rhythm notice a double effect after just a few months. Search delivers better results because it works with better data. And support receives fewer inquiries because the answers are already on the product page.
## Tools come last
The question of the right PIM system is usually asked too early. A dedicated system pays off as soon as multiple channels are served, several people maintain data simultaneously, or translations come into play. As long as a single shop is at the center and two people maintain the data, keeping the data in the shop system itself suffices, supplemented by documented import templates and a versioned mapping table. Anyone who introduces a PIM without first clarifying structure and responsibilities gets the same problems in a more expensive interface.
## Conclusion
Product data maintenance is not a project with a beginning and an end, but an operational discipline. It doesn't produce spectacular before-and-after images, but it simultaneously improves findability, conversion, and return rate. For an online shop there are few investments that work on so many levels at once – and hardly any that is so reliably underestimated.
Comments
No comments yet.
Write a comment