Reviewing enriched products

After enrichment runs, each product carries signals that tell you how far it got and how complete its data is. This page covers what to look for, when to re-run enrichment, and which of your own values a run can overwrite. For the shared vocabulary, see Core concepts.

​

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.

​

Scrape warnings on a product

Enrichment reads the brand’s official site, and that step can go wrong in ways that look like success from the outside. When it does, the product carries a scrape warning — an amber banner on the enriched version of the product, explaining in plain language what happened. The same warning is recorded on the job that ran the enrichment, so you can find affected products either from the product or from the run. A warning never means the product is broken. It means one source didn’t contribute, and it tells you which one and why: In every case the run keeps everything it did gather. It continues on the lakehouse and generated content, so the product is still enriched — just without the brand site’s contribution.

​

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, properties, or other fields. Use it to prioritize which products to review or re-enrich first.

​

What “enriched” looks like

A well-enriched product has its descriptive content written, its properties 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. A run whose AI calls were refused by the provider is a specific case worth re-running: the product kept whatever the run did gather, but some content was never produced. Those products are flagged with a warning on their job, and Retry Unfinished on that job re-runs exactly them — see Provider errors. Each re-run is billable work: it counts against your plan’s enrichment allowance the same way the first run did, and a re-run that would take you over the limit is refused before anything is queued.

​

What enrichment can and can’t overwrite

​

Anything you edited by hand is kept

When you change a product property — in the app or through the product API — MerchantOps marks it as a manual edit and no automated run overwrites it again. Re-running enrichment fills the gaps around your edit; a nightly feed import reports a disagreeing row as a conflict on the import job rather than applying it. A field you deliberately cleared stays empty too — with one exception, noted on How enrichment works. That protection is per field, covers every product property, and lasts until you release it with Reset to feed. So a re-run is safe on a product you’ve corrected by hand: use it freely after a brand updates its site or new lakehouse data lands.

​

Other merchant values depend on a per-property switch

A value your feed or import supplied is protected by overwrite_merchant_input, which is off by default — so on most fields enrichment leaves it 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 a merchant-supplied value. Turn the switch off on the property if you’d rather keep the copy your feed sends. 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. See How enrichment works for the full model.