Product Data Debt: Why Your Website Never Matches the Floor

A customer is standing in front of a sectional on the floor, asking whether it comes in the performance fabric she saw on your site. The tag on the piece says one thing. The RSA's tablet, pulled up to the same product page, says another. Nobody lied to her. Two files just disagreed, and the floor lost.

This is not a website bug. It's what happens when the site, the showroom kiosk, the POS lookup, and the marketplace feed are all fed by hand from whatever a manufacturer sent that quarter — a spreadsheet from one vendor, a PDF spec sheet from another, an unlabeled FTP dump of images from a third.

Somebody on your team already knows this. They're the one who spends a Friday afternoon retyping dimensions, renaming finishes so they read like English instead of a vendor code, and re-cropping images so nothing looks stretched. Then the next vendor refresh lands and quietly overwrites all of it.

Why doesn't fixing it on the website actually fix it?

Because the website is only one of the places that reads the same broken record. Fix a finish name or a dimension string in the site's CMS and the kiosk, the POS lookup, and the marketplace feed are all still wrong — you just fixed the one channel a customer happens to be looking at right now.

Every one of those channels pulls from a product record somewhere. Correct it at the point where a human happens to notice — usually the website, the most visible one — and the correction lives in exactly one place. The other three keep reading the old version:

• The website shows the version someone last had time to clean up.
• The kiosk on the showroom floor shows whatever synced most recently, cleanup or not.
• The POS lookup an RSA uses mid-sale often points at a different, older extract entirely.
• The marketplace feed rejects or mis-lists whatever doesn't fit its schema, silently, until someone checks.

Clean the record once, upstream of all four, and every channel downstream inherits the fix automatically. Clean it once per channel and you're doing the same afternoon of work forever, on a schedule set by however often a manufacturer decides to resend their files.

What is field-level ownership, and why does it matter more than any other catalog concept?

Field-level ownership means that for every field on every product — price, description, images, dimensions, finish name — one side owns the truth: the manufacturer or the retailer. A vendor refresh is only allowed to overwrite the fields it owns. It should never touch the ones you already edited.

Without it, catalog management is a coin flip. Sync everything on every refresh and you erase the retitled product name, the local pricing, and the curated copy your merchandising team wrote last month. Sync nothing automatically and you're back to a person retyping a spreadsheet by hand every time a vendor updates a price.

Get field-level ownership right and vendor refreshes become free maintenance — the catalog improves every time a manufacturer sends new data. Get it wrong and every refresh is a small act of vandalism against work someone already did.

Should a sofa in nine fabrics be one product or nine?

There is no single right answer — it depends on the axis and the channel. Group by the wrong axis and you either bury a customer in near-duplicate listings or hide the one option they actually wanted inside a dropdown they never open.

Fabric and finish color is usually a collapse: one product, swatch selector, nine options — a customer wants to see the sofa once, then choose the color. Configuration is often a split: a sectional with the chaise on the left and one with it on the right frequently have different dimensions and different delivery handling, and hiding that behind a color-style dropdown buries information a customer needs before they buy.

1. 01Color or fabric — usually collapse into one product with a swatch selector; the piece and its price rarely change.
2. 02Configuration (chaise left/right, sectional arrangement) — usually split into separate SKUs; dimensions and sometimes price genuinely differ.
3. 03Size — split when price and lead time move with it, collapse when they don't.
4. 04Material (leather vs. fabric on the same frame) — often a split, since cost, care instructions, and sometimes lead time diverge.

None of this is fixed forever, either. A retailer might collapse by color online but split by configuration in the kiosk, where a customer standing next to the actual floor sample needs to see the specific piece in front of them, not an abstracted product family.

What does 'good catalog data' actually mean for a furniture retailer?

Concretely: dimensions in one consistent format, finish names a customer would recognize, images that hold up when a shopper zooms in on a 4K kiosk, sets modeled as sets instead of orphaned SKUs, and pricing rules that respect MAP without a person checking every line by hand.

No two manufacturers send the same shape of file. Below is a simplified version of what actually lands in a merchandiser's inbox in one week — the same physical product, described three incompatible ways.

Every one of those inconsistencies is a small decision someone has to make correctly, every time: which unit of measurement, which finish vocabulary, whether five rows are a set or five separate products, which image is the hero. Do it once, consistently, upstream of the catalog, and the site, kiosk, and feed all inherit the same clean answer.

Why does the same bad data show up in the kiosk, search, and the salesperson's lookup?

Because every downstream system reads from the same source record. A malformed dimension string or an un-normalized finish name doesn't cost you once — it costs you everywhere that record gets used, usually right as a customer is standing there waiting.

A finish name that's really a vendor code breaks more than the product page. It breaks search, because a customer typing "weathered oak" never matches a row that says "WN-114." It breaks the kiosk, showing the same code to anyone browsing unassisted. It breaks the RSA's lookup, who now translates vendor codes out loud instead of confirming a finish both of them can see written in plain English. A dining set modeled as five disconnected rows breaks the customer's ability to buy the whole set in one add-to-cart, and breaks whoever explains at delivery why four chairs arrived separately from the table.

SKU

A single stock-keeping unit — one specific, purchasable version of a product, down to the exact finish, size, or configuration.

Variant

One option within a grouped product listing (a color, a size, a configuration) that a customer selects without leaving the page.

Set

Multiple physical pieces sold and often priced as one unit — a dining table and its chairs, a bedroom's case pieces — that should behave as one purchasable item, not scattered SKUs.

MAP

Minimum advertised price — the floor a manufacturer sets for advertised pricing, which a catalog's pricing rules need to respect automatically rather than relying on someone checking each listing.

Field-level ownership

The rule that, for each field on a product, either the manufacturer's data feed or the retailer's own edit is the source of truth — and a refresh only ever touches the fields it's assigned to own.

None of this is really a website problem, which is why redesigning the site never fixes it for long. It's a data-governance problem, solved at the layer that feeds every channel at once — the catalog itself. One Tap Commerce's catalog layer carries 250+ brand catalogs through exactly this kind of normalization, so a manufacturer's next spreadsheet updates the fields it should and leaves your merchandising work alone. If your team can already recite which vendor sends dimensions as one string and which one splits them across three columns, that instinct is the right one — it just shouldn't have to live in someone's head.