Product catalog import: prepare reliable data before filling the store
A product spreadsheet is not yet a reliable store catalog. Variants, categories and images need to agree, and a later import must not accidentally create duplicates. Our template describes the business decisions before import. Actual file formats and available functions depend on the chosen store system.
Name the source of truth and owner
Identify the authoritative source for items, prices and availability. Different fields may have different sources; the important part is an unambiguous rule. Record who fills gaps and resolves conflicts. Our example is supplier data combined with your own selling copy: a later run should not overwrite that copy without an explicit rule.
- Data type and authoritative source.
- Owner for corrections.
- Date and scope of the starting inventory.
- Rule for conflicting values.
- Fields the import must not overwrite.
Identify products and variants clearly
Define a stable matching key. Establish whether each orderable size or version needs its own identity in the destination. A product name alone is not a reliable key in our template because editorial changes can alter it. Deliberately test known variants and products with similar names.
Prepare field mapping and transformation rules
Our matrix records source, meaning, destination, example and behaviour when empty. Review price format, currency, unit and the business meaning of availability. Do not transfer values nobody can explain. Document category and image mapping separately when those come from other sources.
- Item identifier and variant relationship.
- Name and understandable description.
- Price, currency and unit.
- Category and required attributes.
- Image file linked to the correct item.
Make errors and absent values visible
Decide which problems block a record and which become reviewable exceptions. A missing photo, unknown price and unmatched variant are different cases. We recommend an exception list with item identifier, reason and owner. Silently skipped records make it difficult to tell deliberate exclusions from missing data later.
Accept a representative trial import
Choose simple items, variants, accented characters, missing values and existing products for a small trial. Then inspect the category, product page and basket selection. Run the same sample again and compare agreed behaviour: update, preserved field or deliberately rejected record. Imported-row counts alone are not acceptance.
Hand over the ongoing maintenance process
The handover package contains mapping, identity rules, exceptions, test results and owners. Agree when data is transferred again and how changes are reviewed. Our outcome check asks whether customers find suitable products and staff can trace corrections. A larger catalog alone is not a better assortment.
Frequently asked questions
- Is a supplier file enough?
- It is a starting point. Meaning, mapping and quality need to fit your own store. Also define which of your existing content must remain.
- Should product names be the matching key?
- Not in our template. Use an agreed stable identity so editorial changes do not accidentally alter matching.
- Must everything be complete at launch?
- Define minimum information and a deliberately chosen starting selection. Missing or unchecked values should not silently appear as a valid offer.
- How do I avoid problems on the second import?
- Test a repeated run and agree update and overwrite rules first. Technical implementation depends on the store system.
Show us a small sample file and the intended destination. We can plan data rules, trial scope and the later maintenance process with you.
Discuss a product import