Why product data decides how the store performs
A customer in a shop can pick an item up. Online, the data is the product. Filters work only if attributes are filled in consistently. Search finds only the words that are there. A delivery price is right only if the weight is. The most carefully designed store, loaded with thin and inconsistent data, feels broken.
Product data is also the part of a store project that is most often late. The build proceeds with sample products, and the real catalogue arrives in the final weeks as a spreadsheet exported from the ERP, with internal abbreviations for names and no images. Starting the data work at the beginning of the project, in parallel with design, avoids the most common cause of a delayed launch.
Decide the structure first
- 01
What is a product, and what is a variant?
What it affectsA shirt in five sizes and three colours can be one product with fifteen variants, or three products with five each. The choice shapes listing pages, search results and addresses.
- 02
Which options define a variant?
What it affectsSize, colour, pack size, voltage. Each combination needs its own code, price and stock.
- 03
How are products grouped?
What it affectsCategories form the navigation. Keep them few and based on how customers shop, not on your internal departments.
- 04
What are bundles and kits?
What it affectsProducts sold together need a rule for price and for how stock of the components is reduced.
- 05
Which products relate to each other?
What it affectsAccessories, spare parts, alternatives and items that are bought together.
- 06
Are there several brands, ranges or collections?
What it affectsThese are usually attributes or separate groupings, not categories.
Structure is hard to change after launch, because addresses, filters and integrations depend on it. Test your proposed structure with twenty varied products before committing the whole catalogue to it.
Identifiers and attributes
Every sellable item needs one stable code, usually called a SKU, that is the same in the store, the ERP and the warehouse. It should never be reused or changed, and should not carry meaning that might alter, such as a price band. Where products carry manufacturer barcodes, record those too. Marketplaces and shopping feeds commonly ask for them.
Attributes are the facts customers choose by: material, dimensions, capacity, compatibility, colour. Three rules make them usable.
- Define each attribute once. A name, a unit and the kind of value: a number, a choice from a list or free text. Use lists wherever possible.
- Control the values. Navy, navy blue and dark blue are three filter options unless you decide they are one. Keep a list of allowed values per attribute.
- Separate number from unit. Store 250 and millilitres, not 250ml in one cell, so that products can be sorted and compared.
- Decide which attributes apply to which categories. A filter for screen size belongs on televisions and nowhere else.
- Fill them in completely. A product missing an attribute disappears when a customer uses that filter.
Names, descriptions and images
| Element | Standard to set | Common fault |
|---|---|---|
| Product name | A fixed pattern, such as brand, product, key feature, size | ERP abbreviations and codes shown to customers |
| Short description | One or two sentences on what it is and who it suits | The name repeated |
| Full description | Benefits, use, what is included, care, in your own words | Manufacturer text copied unchanged, identical on many sites |
| Specifications | Held as attributes and shown as a table | Buried in a paragraph where filters cannot use them |
| Images | Minimum size, background, angles, order and file naming by product code | Mixed sizes and backgrounds, files named by camera number |
| Image descriptions | A short text alternative for each image | Missing, which harms accessibility and image search |
| Search fields | A page title and description per product, from a pattern where volume is large | Left empty, or the same on every product |
Write the standards on one page with good and bad examples, and give it to everyone who creates products. If you sell in several languages, decide now who translates names, descriptions and attribute values, and where translations are stored.
Prices, tax, shipping data and stock
- 01
Prices
Standard price, any compare-at price, and prices per currency or customer group if used. State whether prices include tax.
- 02
Tax class
Each product assigned to the right tax treatment for each market, confirmed with your accountant.
- 03
Weight and dimensions
Packed weight and size for every item. Carrier rates and delivery options are calculated from them, and wrong values cost money on every order.
- 04
Shipping restrictions
Items that are oversized, fragile, hazardous or cannot be sent to certain places.
- 05
Stock
Quantity per location, whether an item may be sold when out of stock, and lead time.
- 06
Status and dates
Active, draft or discontinued, with launch dates for new lines.
A worked example
A lighting retailer prepares its catalogue
This example is invented to show the scale of the work and where it hides. A lighting retailer is moving 3,800 items to a new store.
- StructureA test with twenty products settles that finish and size are variants, while a pendant and a wall light of the same design are separate products linked as a collection. The count becomes 1,450 products with 3,800 variants.
- AttributesTwenty-two attributes are defined. The ERP export contains 31 spellings for 9 finishes and bulb fittings written five ways. Lists of allowed values are agreed and the data corrected.
- NamesERP names such as PEND 3LT BRS 40 become a pattern: collection, type, number of lights, finish, size. A formula generates most of them.
- ImagesA quarter of items have no usable image. A photography day is booked for own-brand lines, and suppliers are asked for the rest, with a naming rule based on the product code.
- ShippingPacked weights are missing for 900 items. The warehouse weighs them over two weeks. Fourteen oversized items are flagged for a special delivery service.
The data took ten weeks, longer than the store's design and build. Because it began in the first week of the project, it finished in time, and the filters worked on launch day.
A product sheet you can copy
Use one row per variant, with the product-level columns repeated or held on a second sheet. Adjust the attribute columns to your catalogue.
Product data sheet: columns
TemplateIdentity
Product code of the parent product
Variant code (SKU), unique and permanent
Manufacturer barcode, where one exists
Brand
Structure
Category
Option 1 name and value (for example Colour: Navy)
Option 2 name and value (for example Size: Large)
Related products and collection
Content
Product name, following the naming pattern
Short description
Full description
Page title and page description for search
Attributes
One column per attribute, values from the allowed list
Numbers and units in separate columns
Images
Image file names in display order
Text alternative for each image
Commercial
Price, and compare-at price if used
Tax class
Packed weight, length, width and height
Shipping restrictions
Stock location and quantity
Status: active, draft or discontinued
Decide where the data lives and who keeps it right
Data that stays good
- Each kind of data has one home system
- Codes, prices and stock come from the ERP automatically
- Descriptions and images are managed in the store or a product information tool
- A named person approves new products against the standards
- New products cannot go live with required fields empty
Data that decays
- The same field edited in two systems
- Products created in the store before they exist in the ERP
- No one responsible for descriptions and images
- Standards known only to the person who wrote them
- Corrections made in a spreadsheet that is imported again later
Where the catalogue is large or sold through several channels, a product information tool that sits between the ERP and the store is worth considering. For most smaller catalogues, clear ownership and the store's own tools are enough. Our guide on connecting ecommerce to ERP and inventory covers how the systems divide the work.
Product data checklist
Product data preparation checklist
0 of 11 checkedWhat to do next
Export your product list today and count three things: items without an image, items without a packed weight, and the number of different spellings of your most common attribute. Those counts tell you how long the data work will take.
Our e-commerce platform development page explains how we plan catalogue work alongside the build. Send us a sample of your product export and we will tell you what we would fix first.
Common questions
How long does it take to prepare product data?
It depends on the number of items and the state of what you have. A small, tidy catalogue may be ready quickly. A large one exported from an ERP, with missing images and inconsistent attributes, can take longer than building the store. Count the gaps early, assign the work to named people and start at the beginning of the project.
Can we use the manufacturer's descriptions?
You can, where your supply agreement allows, and they are better than nothing. The same text will appear on every other retailer's site, which gives search engines and customers no reason to prefer yours. Rewrite descriptions for your best-selling and highest-margin products first, in your own voice, and work down the list over time.
Should product data live in the ERP or the store?
Split it by kind. Codes, costs, prices, tax, weights and stock belong in the ERP, where operations and finance work. Names for customers, descriptions, images and search text belong in the store or a product information tool, where marketing works. The integration creates the product from ERP data and leaves the presentation fields alone.
What is a SKU, and why does it matter?
A stock keeping unit is the code for one specific sellable item, such as a particular size and colour. It ties together the store, the ERP, the warehouse and any marketplace. If codes differ between systems, change over time or are reused, orders go to the wrong item and stock figures stop agreeing. One permanent code per item prevents that.
Do we need a product information management tool?
Not usually for a single store with a modest catalogue. It becomes useful when thousands of products, several languages or several sales channels make the store's own tools and spreadsheets unmanageable, or when many people enrich product data. Start with clear standards and ownership. A tool cannot substitute for either.
