What makes good source data
Enrichment is only as good as the data you feed it. That’s by design: the engine writes from your source data and refuses to invent facts beyond it. This page tells you what “good” looks like and what to fix first.
The golden rule: enrichment amplifies, it doesn’t fabricate
Every claim in your enriched content must trace back to your source data. If your data says a shirt is 100% cotton, enrichment can turn that into compelling copy about breathability and softness. If your data doesn’t mention material at all, the enriched copy won’t either — and that gap shows up in your results rather than being papered over with plausible fiction.
This is a feature. Fabricated product claims are the fastest way to lose customer trust (and, on some channels, your listing). The accuracy factor of your quality score exists to catch exactly this.
FDX Enrichment generates language: titles, descriptions, feature bullets, Q&A, and SEO text. It does not infer or fill structured attribute values like color, material, or size, and it does not assign products to taxonomy categories — that work is attribution, which is not part of data enrichment today but is on the roadmap. If a structured attribute is missing from your source data, enrichment won’t invent it.
What good source data looks like
The more of these your products have, the better the output:
- A real product name — not just a SKU or model number.
- Factual substance — materials, dimensions, features, use cases, what’s in the box. Even rough bullet points give the engine something true to work with.
- Accurate basics — brand, category, price. Errors here don’t get fixed by enrichment; they get amplified.
- Distinct data per product — if fifty products share one boilerplate description, expect fifty similar outputs. Variance in equals variance out.
Variants and your source data
Because you can enrich at either the product or the variant level, it’s worth knowing which of your data lives where. If your variant records carry meaningful detail — a colorway name, a material that changes by option — variant-level enrichment can use it. If your variants differ only by size and share everything else, product-level enrichment gets you the same quality for a fraction of the volume. See Product level or variant level.
What to fix before enriching
Run down this list before your first big run:
- Correct outright errors. Wrong materials, wrong dimensions, wrong brand names — enrichment writes confidently from whatever you give it.
- Kill placeholder text. “Description coming soon” and lorem ipsum produce exactly the output you’d expect.
- Check your thinnest products. Sort by description length; the bottom of that list either needs a data pass first or should be excluded from early runs.
- Standardize where cheap. Consistent units and terminology in source data mean fewer consistency issues in output.
Where output lands in your pipeline
Enrichment writes to new, dedicated fields in your database, applied as a raw data override — your imported source data is never replaced, and you can always compare what came in against what enrichment produced. Because the enriched value sits in the raw layer, everything downstream can act on it: transformers, transformed data overrides, and the feed build process.
Enrichment applies to your raw imported data, before your transformers run. That ordering matters: your transformer logic and export rules operate on enriched fields the same way they operate on any other field, so nothing about your downstream pipeline needs to change. Details in Enrichment, transformers, and exports.