Building a Product Information Source of Truth Before You Automate
Most ecommerce problems that look like technical failures are really information problems. A product title differs between the storefront and the marketplace listing, a weight is recorded in pounds in one place and kilograms in another, and a discontinued variant still appears in a feed. Before you automate anything that moves product data, it helps to decide where the authoritative version of each fact lives. This article walks through a practical way to organize product information so that the rest of your operation can rely on it, and it closes with questions to ask any vendor or internal team before you commit.
Separate the record from the presentation
A useful distinction is between the product record and the places where that record is displayed. The record is the internal set of facts about an item: its identifier, dimensions, materials, cost, supplier, origin, and status. The presentation is what a shopper or a channel sees: the headline, the bullet points, the image order, and the marketing copy. When these two are blended together, every edit to a headline risks altering a fact, and every channel that needs a slightly different wording tends to fork its own copy of the item.
Keeping the record separate lets you change presentation freely while holding facts steady. A marketplace may require a shorter title, a wholesale feed may need a different category code, and your own storefront may want longer descriptive text. All of these can be generated from the same underlying record, which is far easier to audit than three hand-edited copies that have quietly drifted apart over a year.
Decide the owner of each field
Every field in the record should have a named owner, meaning the person or function responsible for its accuracy. Dimensions and weights often belong to whoever handles inbound inventory or packaging. Cost and supplier details usually belong to purchasing. Descriptive copy may belong to a content lead, and compliance-related details such as material declarations may belong to whoever answers customer questions about them. Writing this down in a simple table, with one row per field and one owner per row, prevents the common situation where everyone assumes someone else is checking a number.
Ownership also clarifies what happens when two sources disagree. If the supplier sheet says a bottle holds 500 milliliters and the packaging label says 473, the field owner decides which value is authoritative and records the reason. Without an owner, the disagreement simply gets resolved differently each time it appears.
Standardize naming, units, and identifiers
Consistency matters more than any particular convention. Choose one unit system and state it explicitly in the record. Choose one date format. Decide whether colors are stored as a controlled list or as free text, because free text produces entries like 'navy', 'Navy Blue', and 'dark blue' that cannot be filtered reliably. Attribute hierarchies, such as a parent product with child variants for size and color, should follow the same logic across the whole catalog so that a new item can be added by copying a pattern rather than inventing one.
Identifiers deserve particular care. Each variant should have a unique internal identifier that never changes, even if the display name is revised. External codes, such as barcodes, should be stored in their own field and verified at entry. Reusing an identifier after a product is discontinued is a common source of errors in order history and inventory counts.
A checklist for organizing product information
Before connecting product data to any system, work through these items. First, confirm that every active product has exactly one record and that duplicates have been merged or retired. Second, check that each required field is populated, and note which fields are optional for particular channels. Third, verify that units, date formats, and controlled vocabularies are applied the same way across all rows. Fourth, confirm that every field has a named owner and a last-reviewed date. Fifth, spot-check a sample of records against physical items or original supplier documents, since a clean spreadsheet can still contain wrong numbers.
Sixth, document how discontinued and changed products are handled, including how identifiers are retired and how historical records are kept for reference. Seventh, decide how presentation copy will be generated or stored, and make sure edits to presentation do not silently change facts in the record.
Questions to ask before you automate
Whatever tool, service, or internal process you are evaluating, ask how it reads product data and where it stores its own copy. Ask whether changes made in the record propagate automatically, on a schedule, or only when someone triggers them, and what happens to a channel listing if a required field is missing. Ask how conflicts are flagged, who sees the flag, and how a correction is applied. Ask what the process does with discontinued items and how it avoids publishing stale information.
You should also ask what is and is not included in the setup you are considering. Confirm in writing which channels, data fields, and update behaviors are covered, rather than assuming them. The goal is not to find a perfect system but to understand exactly what your product information will do once it leaves your hands, so that when something goes wrong you know where to look and who to ask.