Product data enrichment for marketplaces: a practical guide

Product data enrichment adds useful, supported information to a listing that already exists. For a marketplace, the hard part is matching the information to the exact product and keeping it separate from the seller's description of the individual item.

Adding a material, model number, or capacity can help a buyer understand a listing. Adding a plausible but unverified specification creates a new problem for support.

Distinguish the product from the offer

Imagine two sellers list the same model of desk lamp. The manufacturer specifies its height, bulb fitting, and original finish options. One seller's lamp has a scratch and no original box. Those are facts about that individual offer.

Enrichment can supply the model's published bulb fitting after a reliable match. It cannot establish that a particular used lamp works, includes a bulb, or still has its original finish. Keep product facts, variant facts, and seller-specific claims in separate fields.

Match identity before fetching attributes

Start with a manufacturer identifier when one exists. Preserve its spelling and the associated brand. Google's MPN guidance explicitly warns against guessing a manufacturer part number. It is a useful discipline even if you are not submitting a Google feed.

If the identifier is missing, use several pieces of evidence: brand, model name, size, version, and photos. A name match alone is often too weak for products with annual revisions or similar variants.

When identity is unresolved, store candidate matches for review. Do not copy attributes from the first search result. See duplicate detection for the related distinction between matching a product and merging offers.

Give each field a source policy

A marketplace can allow manufacturer pages for dimensions, approved supplier sheets for pack sizes, and seller inspection records for current condition. Write down what to do when those sources disagree.

Store the source URL or document reference, retrieval time, product identifier, and the evidence supporting the field. A link to a brand homepage is not enough to explain why a specific width was proposed.

Keep missing, unknown, conflicting, and not applicable separate. An empty material field may be fixable through research. An unknown authenticity status is not a blank the agent should fill.

Validate the proposed value

Check data types, units, ranges, and vocabulary. Convert a measurement only after confirming whether it describes the product or its packaging. If you retain both a source value and normalized value, a reviewer can audit the conversion.

Use deterministic validation for simple constraints. A model's confident explanation cannot make a negative capacity valid or turn an unsupported category name into a real category ID.

For document inputs, use the supplier PDF extraction workflow. For web inputs, use manufacturer website research.

Publish enhancements without losing the original

Keep the original seller record and proposed enhancement together by a stable ID. Publish only approved fields. If a seller changes the model number, invalidate research that depended on the previous model.

Your application should consume a clear resolved representation rather than repeatedly deciding which source to trust. The database implementation depends on your stack, but the rule is the same: one approved value for each read, with provenance available to the team.

Measure enrichment by useful coverage

Do not count every populated cell as progress. Measure the share of eligible records with correct supported values, the rejection rate, review time, and the number of proposals made stale by source edits.

Goodfolk's research worker, Bea, is intended for this kind of evidence-backed completion. A pilot should start with a named category and a short list of fields. That makes it possible to judge the result before expanding to the rest of your catalog.