Enrichment status
Every product tracks an enrichment status that tells you where it is in the process — for example, whether it’s still queued, in progress, finished, or ran into a problem. Use it to spot products that haven’t been enriched yet or need attention.Completeness score
Alongside the status, each product carries a completeness score — a single number that reflects how much of the product’s data is filled in. A higher score means a more complete record; a low score points to a product still missing descriptions, attributes, or other fields. Use it to prioritize which products to review or re-enrich first.The score reflects completeness, not correctness. A high score means the fields
are populated — always spot-check the values themselves.
What “enriched” looks like
A well-enriched product has its descriptive content written, its attributes standardized to your catalog’s values, and brand data filled in from the sources enrichment consulted. Because enrichment adds a new version rather than overwriting, the enriched result sits alongside the version you started with — the latest or production-labeled version usually holds the richest data. See Versioning for which version to read.Identifiers are only filled in if you’ve declared them
Enrichment can copy an identifier it found on a matched lakehouse product back onto your product — a UPC, a vendor style ID, and so on — but this is opt-in and driven entirely by your own dictionary. It happens only for a property definition your organization has explicitly flagged as an identifier and given an identifier type. An organization that has flagged none gets no identifier fill at all, and nothing about the run says so — the fields simply stay empty. Two further limits apply even to flagged properties: only product-level properties are filled this way (variant-level identifiers are never back-filled), and only where your product’s value is empty. An identifier you already hold is never replaced.Re-running enrichment
You can run enrichment again on a product — for example after the brand updates its site, or after new data lands in the lakehouse. Each run adds another version with the freshest merged result, so re-running is safe and never destroys earlier versions.What enrichment can and can’t overwrite
Values you entered are protected by a per-property switch,overwrite_merchant_input, which is off by default — so on most fields
enrichment fills gaps around your data and leaves your data alone.
Three built-in fields ship with the switch on, because MerchantOps is
expected to author them: description, features, and meta title. On
those three, a run can replace text you typed. Turn the switch off on the
property if you’d rather keep your own copy.
The guard is evaluated against the field’s currently tracked source, so it
protects a value only while that value is still attributed to your input — a
field enrichment filled because you left it blank isn’t covered. Both the guard
and the source order can be overridden per product type.
A change you make by hand is additionally recorded as a manual edit. Feed
imports honor that absolutely: an imported row never overwrites a hand-edited
field, and disagreeing rows are reported as conflicts on the import job. See
Manual edits for what the mark does and doesn’t
protect against.
Because enrichment adds a new version rather than editing in place, the version
you started with — including the values you entered — always remains available.
See Versioning.
How enrichment works
The steps enrichment runs and how it decides which source wins a field.
Versioning
Why enrichment adds versions and which one holds the richest data.
Quality review
Advisory checks that flag duplicate, contradictory, or unsupported copy.
Manual edits
How your own edits are marked, protected, and released.