> This page is for Product.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.feedonomics.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.feedonomics.com/_mcp/server.

# Re-running enrichments

> How to use quality scores to target a second enrichment pass, what to change between runs, and how new products get enriched.

Your first run is rarely your last. Enrichments can be re-run, and the scores from a previous run tell you exactly which products are worth running again.

## Let the scores decide

The most efficient way to plan a second pass is to work from the output of the first one. Rather than re-running your whole catalog, target by score:

* **Products that fell below your threshold** — these are the ones that didn't clear your bar. They're the highest-value re-run because there's real headroom.
* **Products with a specific recurring issue** — if a batch produced the same kind of problem across a group of products, fix the cause and re-run just that group.
* **Products that scored well** — leave them alone. Re-running content you already accepted spends allotment for little gain.

> **Fix the cause first**
>
> A re-run with the same config and the same source data will produce broadly similar results. Change something before you re-run — sharpen the brand voice, tighten the config, or improve the underlying product data. Otherwise you're paying for the same answer twice.

## What to change between runs

| What the scores show                              | What to change                                                                                     |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Accuracy issues — claims the data doesn't support | Improve the [source data](/product/enrichment/what-makes-good-source-data) for those products      |
| Consistency issues — fields disagreeing           | Tighten the [config's](/product/enrichment/generation-configs) field requirements                  |
| Brand adherence issues — right facts, wrong voice | Refine your [brand voice input](/product/enrichment/brand-voice), then create a new config         |
| Good scores but the copy doesn't land             | Add specificity to [brand voice and context](/product/enrichment/inputs), then create a new config |

Not sure what the issues on your scorecard mean? See [Understanding your quality scores](/product/enrichment/scorecard).

If the copy is accurate and on-brand but generic, that's usually not a fix at all — it's a scope question. A depth enrichment, scoped to one category with context aligned to it, produces detail a coverage enrichment can't. See [Enrichment strategy](/product/enrichment/strategy).

> **Re-running isn't always the answer**
>
> If only a handful of products need small wording changes, don't spend a re-run on them — adjust them directly with a transformed data override. See [Editing enriched content](/product/enrichment/editing-content).

## Bringing in new products

As your catalog grows, new products get enriched by including them in a new batch. Most teams settle into a rhythm — a batch when a new collection lands, or a standing weekly or monthly pass over whatever's new — and reuse a config that's already proven itself on similar products.

## Mind the cost of re-running

> **How usage is counted**
>
> Usage counts every enrichment you **send** for processing — not just the results you accept. If you run 1,000 products and accept 600, all 1,000 count toward your contracted allotment. Set your quality thresholds and product selection deliberately before you run.

Every re-run counts. That's the practical argument for the workflow we recommend throughout these docs: prove a config on a small sample, then run at volume once. A tuned config on the first full run is dramatically cheaper than three passes over your whole catalog.