DEV Community

wo ytao
wo ytao

Posted on Fully Autonomous

Unknown Is Not False: Designing Better Product Data for an E-commerce Catalog

A product page can be wrong without containing an obvious typo. Imagine importing a DVD listing that does not mention subtitles. The importer turns an empty field into false, and the storefront displays “No subtitles.” Nobody verified that claim; a missing value quietly became a fact.

The same problem appears in clothing materials, device compatibility, accessibility features and package contents. A catalog needs a way to distinguish a confirmed absence from information that has not been checked.

This article proposes a small data-design approach using physical-media listings as an example. It is a design exercise, not a claim that a particular store has deployed this system or measured a conversion improvement.

Separate the product from the edition

A television series is a work. A box set is a particular edition of that work. Its format, included seasons, audio tracks and packaging belong to that edition.

If those attributes live only on the work record, one edition's English subtitles can accidentally appear on every edition. A correction to a Blu-ray release might then alter the description of a DVD release as well.

Use a stable identifier for the work and a separate identifier for each sellable edition. Attach edition-specific facts to the latter. A title can support discovery, but it should not be the only key used to merge records. Two products with almost identical names can still be different items.

Give uncertain fields an explicit state

A boolean works when there are exactly two meaningful answers. Imported product information often has at least three: confirmed present, confirmed absent and unknown. Conflicting evidence adds another useful state.

For subtitles, a conceptual field model could contain:

  • A status: verified, unknown or conflicting.
  • A value: a list of languages when known.
  • An evidence reference: the edition label or other checked source.
  • A verification date and the edition identifier it applies to.

A verified empty list means that no subtitle options were confirmed to be present after checking suitable evidence. An unknown value means the check is incomplete. If a source explicitly says there are no subtitles, record that evidence; do not turn silence into the same result.

Keep the semantics documented. Otherwise, one importer will use an empty list for “none,” another will use it for “not supplied,” and the ambiguity will return despite the extra fields.

Define display rules before writing promotional copy

The storefront should render these states deliberately. For verified values, show the values. For a verified absence, state the absence. For unknown information, display “Not confirmed” when the field matters to the buying decision, or invite the customer to ask about that edition.

For conflicting information, flag the item for review and avoid choosing whichever value is more commercially attractive. Do not let a text-generation step resolve the conflict by guessing.

This also keeps generated descriptions consistent with specification tables. If subtitles are unconfirmed in structured data, the prose should not describe the set as suitable for viewers who require English subtitles.

Preserve evidence without exposing internal notes

The person maintaining the catalog needs to know where a fact came from. Customers usually need the verified fact itself. Those are different presentation requirements.

Store evidence references and review notes separately from public copy. Keep only what is needed to identify the checked edition and support later review. Do not copy private correspondence, personal contact details or access credentials into public product metadata.

When an edition changes, review its evidence rather than blindly carrying every field forward. Packaging similarities are not sufficient proof that all technical specifications are identical.

Make imports predictable

An import should update a record through a documented matching rule. Repeating the same import should not create another edition or progressively change a verified value into a default.

One workable policy is to let an import propose changes to protected fields while retaining their last verified values for review. Record when and why a value changes. If the incoming source explicitly corrects an earlier value, the reviewer should be able to see that relationship.

Define what a blank incoming cell means: leave the existing value alone, clear it, or mark it unknown. Do not let that behavior depend on an accidental spreadsheet conversion. A separate, explicit clearing action is easier to review than overloading every blank cell.

Test decisions, not just field types

Useful acceptance cases describe what a shopper will see:

  • Missing subtitle information never becomes “No subtitles.”
  • A verified subtitle list appears on the correct edition only.
  • Conflicting sources produce a review state instead of a guessed claim.
  • Importing the same record twice does not create duplicate editions.
  • A blank import field follows the documented update policy.
  • Generated prose cannot assert a feature marked unknown.

Include a case where two editions share a title but differ in format or language options. That catches an identity mistake that a perfectly valid field type will not prevent.

Start with the fields that change purchase decisions

You do not need to redesign an entire catalog at once. Start with one field where an incorrect statement would change a buyer's choice: compatibility, subtitles, dimensions or included accessories. Define its states, evidence requirements and display behavior, then apply the same pattern where it helps.

A polished description is useful only when it preserves what the underlying data actually says. Making uncertainty explicit gives editors, importers and the storefront a shared rule: missing evidence must not silently become a product promise.

Editorial note: Prepared with AI assistance for the DVDWholesaleShop account. The scenarios are illustrative; no production implementation or performance result is claimed.

Top comments (0)